Company firewall is blocking the discovery document endpoint bc it contains "/." (".well-known/openid-configuration"). The firewall is blocking uri's with period following forward slash.
Is there an api available for overriding the discovery endpoint?
Error:
HTTP404: NOT FOUND - The server has not found anything matching the requested URI (Uniform Resource Identifier).
GET - https://xxx.xxx.com/identityserver/.well-known/openid-configuration
Screnshot of firewall block
Related
I am trying to setup saml sso configuration for my application which is deployed in websphere.
Idp- Azure AD
SP - Websphere application server when my target application deployed
Done TAI configuration as per the Ibm document . But when I hit the test button from idp I could see the saml response in network tab. but i couldn't login to my application and also didn't get any trace related to saml in log files also however i have enabled logs for saml in Troubleshoot. My doubt is sometimes am getting trace which are related to TAI during server stop. For each request should i be getting TAI trace ? and why my saml response not getting intercepted in TAI. How exactly the interception happen with saml response and how do we get to know that saml response got validated.
[15/4/21 16:18:42:855 IST] 00000096 TrustAssociat A SECJ0121I: Trust Association Init class com.ibm.ws.security.web.saml.ACSTrustAssociationInterceptor loaded successfully
acs url -> https://localhost:/browserTest (which is my actual target application url)
metadata and signing certificates also imported correctly.
Thanks for your help.
The acs URL has format like this:
https://<hostname>:<sslport>/samlsps/<any URI pattern string>
if you want to use your application URL
https://localhost:/browserTest
as acs URL, this UR must be able to accept HTTP POST.
I made a custom App for Shopify. But I got the below error when I set up the application AWS EC2.
Refused to frame 'https://***.com:2053/' because it violates the following Content Security Policy directive: "frame-src app.myshopify.io *.shopifyapps.com .myshopify.io .myshopify.com https:// shopify-pos://".
Curiously, when I use Ngrok on the EC2, it works well. On the other hand, when I use the original domain, it doesn't work and I get the error. I have already set up an SSL with Certbot. I confirmed to connect to my domain directly, not via shopify app. I made it referred to this site: https://shopify.dev/tutorials/build-a-shopify-app-with-node-and-react.
I have been researching it for a week tho, I have no clue to resolve it. Do you guys have the same experience and do you know how to resolve it?
The CSP includes https://. According to the specification this does not mean HTTPS on arbitrary ports, but only on default port 443.
Your custom app instead uses https://...:2053 which matches the allowed protocol but does not match the allowed port. When using ngrok both protocol and port match since ngrok is using the default port 443.
On configured AKS there is docker container with application that is using AAD authentication.
Based on this article there is also configured ingress. API is working well.
When I add to Azure Active Directory application registration reply URL with https prefix I receive error "The reply url specified in the request does not match the reply urls configured for the application". And I see that in browser address line redirect_uri is starting with http.
When I add reply URL that is starting with http, then I receive "Exception: Correlation failed".
What I have tried: Add to ingress.yaml setting ingress.kubernetes.io/force-ssl-redirect: "true"
May be there is some way to force ingress run https instead of http, or there might be some AAD redirect configuration? Any ideas?
UPDATE 2: Probably http redirect is because of ADAL.
PS: Was able to find similar topic without an answer
UPDATE3:
I have decided not to use nginx as ingress. Instead I am using now Load balancer. Soon it would be possible to use Azure Application Gateway Ingress Controller
Have you tried this?
By default the controller redirects HTTP clients to the HTTPS port 443 using a 308 Permanent Redirect response if TLS is enabled for that Ingress.
This can be disabled globally using ssl-redirect: "false" in the NGINX config map, or per-Ingress with the nginx.ingress.kubernetes.io/ssl-redirect: "false" annotation in the particular resource.
More information on this on the Ingress documentation link.
You have to make a decision whether to use HTTPS or not. If this is just the start of a development cycle, start without it and get auth to work - but implement HTTPS as soon as possible.
AAD supports both http and https, but of course, the reply urls must be added to the application registration respectively.
As #mihail-stancescu says, ssl-redirect must be set to false, if you choose not to use HTTPS. In addition to this, you also have to ensure that your app does not make the redirect from HTTP to HTTPS.
Using curl with -L -k and -v options will give you a lot of information on what is actually happening with your requests.
When the http/https thing is solved, you have to remove any rewrite annotations you have in your ingress. (e.g. ingress.kubernetes.io/rewrite-target: / should be removed).
Now, if your ingress path to the service in question is e.g. /myservice, then the reply-url should also have that part of the path added ([host]/myservice/signin-oidc) - both in the AAD application registration and in the configuration of your app. (The path in the config should not contain the host)
If you are using https, then you must also have a proper certificate. You can use the free LetsEncrypt (https://letsencrypt.org/) in conjunction with KubeLego (https://github.com/jetstack/kube-lego), where you can find some nice examples on how to implement it.
SOLVED: For other people having this error, please check this:
I configured my endpoint/reply address as http:// whilst my app was running https://.. After changing it to https things worked as expected and I could login on the v2 endpoint as well as query the graph api.
It's also a restriction on the v2 endpoint, so beware of that. It just needs to be in https, see the docs:
Restrictions on redirect URIs
Currently, apps that are registered in the Application Registration Portal are restricted to a limited set of redirect URI values. The redirect URI for web apps and services must begin with the scheme https.
source: https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-limitations
I have configured an application via the apps.dev.microsoft.com portal as described in this sample project.
I was running under a different port though, so when I set up the URLs in the app registrations I changed them to match my port number.
Now I'm receiving this error after the flow is trying to connect back to my application.
How can I debug this, or how do I know what is happening?
Additional technical information:
Correlation ID: 145d8f37-7229-4dce-8ace-c777e4aeef94
Timestamp: 2017-11-02 08:41:21Z
AADSTS50011: The reply address 'http://localhost:60761/signin-oidc'
does not match the reply addresses configured for the
application: '8b640f9d-e7d8-4c41-8a40-15069f5712ee'.
More details: not specified
I also get the notification that this application will be fed to the Azure AD Portal (app registrations) - but I can't find it there.
I'd like to use the URL fetch service for app engine (java). I'm just sending a POST to one of my own servers from a servlet.
AppEngine -> post-to: https://www.myotherserver.com/scripts/log.php
I'm reading the url fetch doc:
Secure Connections and HTTPS
An app can fetch a URL with the HTTPS method to connect to secure servers. Request and response data are transmitted over the network in encrypted form.
The proxy the URL Fetch service uses cannot authenticate the host it is contacting. Because there is no certificate trust chain, the proxy accepts all certificates, including self-signed certificates. The proxy server cannot detect "man in the middle" attacks between App Engine and the remote host when using HTTPS.
I don't understand - the first paragraph makesit sound like everything that goes from the servlet on app engine, to my php script is going to be secure if I use https. The second paragraph makes it sound like the opposite, that it won't actually be secure. Which is it?
Thanks
There are two things HTTPS does for you. One is to encrypt your data so that as it travels over the internet, through various routers and switches, no one can peek at it. The second thing HTTPS does is authenticate that you are actually talking to a certain server. This is the part App Engine can't do. If you were trying to connect to www.myotherserver.com, it is possible that some bad guy named bob could intercept your connection, and pretend to be www.myotherserver.com. Everything you sent to bob would be encrypted on it's way to bob, but bob himself would be able to get the unencrypted data.
In your case, it sounds like you control both the sending server and the destination server, so you could encrypt your data with a shared secret to protect against this possibility.
The UrlFetch through https has been fixed allowing certificate server validation.
validate_certificate
A value of True instructs the application to send a request to the
server only if the certificate is
valid and signed by a trusted CA, and
also includes a hostname that matches
the certificate. A value of False
instructs the application to perform
no certificate validation. A value of
None defaults to the underlying
implementation of URL Fetch. The
underlying implementation currently
defaults to False, but will default to
True in the near future.