We have an Azure AD B2C instance with custom policy to allow users to sign with their credential from an external SAML identity provider, the configuration is based on this Microsoft Doc: https://learn.microsoft.com/en-us/azure/active-directory-b2c/identity-provider-generic-saml?tabs=windows&pivots=b2c-custom-policy.
The custom policy works except for the single logout (SLO) request. The interesting part is, in Chrome the SLO request works but in Firefox and Safari it fails.
During a sign out flow the browser (Firefox is used in this example) receives a payload with a SAML logout request from the Azure AD B2C. The payload is then loaded into an iframe so that the SAML logout request can be posted to the SAML IdP. In the row 41 in the client side script in the following image you can see a iframe that is being appended to the DOM in the method frameLoader, and this is where the request fails.
Image of the client side script
And here is the stack trace of the exception for the call to frameLoader.
Image of the stack trace
I thought the issue was related to cookies and cross-site request forgery (CSRF), so I configured a custom domain for the Azure AD B2C, but that didn’t resolve the issue. I also thought it had to do with the SameSite attribute in a cookie, so I tried editing one of them but that didn’t fix the issue.
Is there anyone that has encountered this issue and knows how to resolve it?
UPDATE
Further debugging relieved that the issue is related to Firefox way of handling pop-up window. The SAML SLO request works only when I add the URL of the web application as allowed website for window pop-up in Firefox.
Is there a workaround for allowing iframe to be loaded into the parent web application without adding the URL of the web application as allowed website for window pop-up in Firefox?
it could be a non issue in your use case but there is a feature in Azure LogoutResponses when sent via HTTP-Redirect. The are encoded in lower case. the examples you show do indicate a lowercase uppercase difference %3a instead of %3A in the other image.
The work around is to have the SAML library use the REDIRECT_URI in most cases. As an hack you can replace the letters in the encodings with lowercase characters.
if this is your issue the problem is that the signature cannot match because a and A are not equivalent.
Related
We need help in implementation of MS Login and SSO together on same azure application and we are facing below challenges.
Currently we have implemented MSLogin and SSO authentication with independent Azure application and it is working as expected.
But now customer is expecting that instead of configuring the MSLogin and SSO authentication setting independently in azure for two application can we have it with one azure application only.
Based on above scenario I have following question:
Can we implement MSLogin and SSO authentication together? If any lead would be highly appreciated.
Currently I have some partial implementation of the above approach but facing challenge with redirect URL.
Issue: If I configure the same application for MSLogin & SSO authentication then
For MSLogin its mandatory for us to provide the redirect URL and if we don’t pass it then MSLogin authentication not working.
If we pass this redirect url then the reply URL which we have set for SSO is not getting triggered and always redirecting to MSLogin redirect URL only through azure cloud (don’t have any control).
Any help on above issue is highly appreciated.
• The redirect URL option is featured with those apps who have custom app registrations other than that of Azure apps specified in the gallery for whom the redirect URL is already configured inbuilt to be of Azure sign out page.
• That’s why, the sign out URL is of utmost importance in enterprise applications from where the Identity signing out of that platform is confirmed. Thus, you can check the following method of using a state parameter while configuring the redirect URLs might be useful.
• Create a "shared" redirect URI per application to process the security tokens you receive from the authorization endpoint.
• Your application can send application-specific parameters (such as subdomain URL where the user originated or anything like branding information) in the state parameter. When using a state parameter, guard against CSRF protection as specified in section 10.12 of RFC 6749).
• The application-specific parameters will include all the information needed for the application to render the correct experience for the user, that is, construct the appropriate application state. The Azure AD authorization endpoint strips HTML from the state parameter so make sure you are not passing HTML content in this parameter.
• When Azure AD sends a response to the "shared" redirect URI, it will send the state parameter back to the application.
• The application can then use the value in the state parameter to determine which URL to further send the user to. Make sure you validate for CSRF protection.
• Also, the client must protect these parameters by encrypting the state or verifying it by some means as you are using a personal Microsoft login for authentication purposes which means personal Microsoft accounts will be able to access the application configured in Azure AD, so please validate the domain name in the redirect URI against the token.
Please find the below links for more information: -
https://learn.microsoft.com/en-us/azure/active-directory/develop/reply-url
https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-microsoft
I want to write a script that:
Logs a user into Azure AD with the device code mechanism
Constructs a SAML SSO request URL
Makes the SAML request using the auth from step 1
Gets the SAML response back, and does something with it (not just open it in a browser)
Is there a way to do that with the Azure AD libraries?
I feel like this should be possible and I’m just missing something. Any ideas?
I've tried a bunch of stuff and experimented with code in the Python library, but to no avail.
I would prefer Python, but I can run it in a Docker image so language isn’t so important.
Context
At work, we use Azure AD for authentication, and we can log into the AWS Console using Azure AD and SSO SAML.
If I construct an appropriate SAML request URL and open it in my browser, I go through the in-browser auth flow. When I’m logged in, Azure AD returns a SAML response, and eventually my browser redirects me to the AWS console. It’s a URL of the form:
https://login.microsoftonline.com/11111111-1111-1111-11111111111/saml2?SAMLRequest=<base64 encoded string>
Now I want to do a similar flow for AWS credentials – make a SAML request to log in, read the SAML response, create credentials using assume_role_with_saml, then write those to ~/.aws/credentials. I think that means I have to access the SAML response directly – the browser just drops me at the end of the redirect chain.
Any ideas?
Other ideas
I’m aware of the aws-azure-login npm package which does this by spinning up a headless browser – but it’s unmaintained and I’ve found it to be a flaky.
Right now I have a Python script that opens the SAML request in Chrome (where I log in), then uses the browsercookie library to raid Chrome’s cookie jar and use those for its HTTP requests. That works, but it feels weird to be copying cookies this way. Also, it doesn’t work if I’m ssh'd into a remote server.
I found an answer from a year and a half ago that says “ADAL.JS does not support SAML2 tokens”. Wondering if that might have changed, or am I still stuck?
No - ADAL is OpenID Connect and returns a JWT token.
Why do you need to use SAML? Could you not use OpenID Connect?
Azure AD does not support SAML tokens for the device code flow.
MSAL library from the Azure AD team supports this flow for apps. Please give this a try or you can write code against the protocol itself
I'm using Azure Active Directory B2C with ASP.NET Core, when I click the sign-in it works like a charm on my local machine but when I deploy my web app in Azure it only works with Edge.
With Chrome and Firefox I always have this error:
I am creating a new web app (social network) and I need to be in beta for November because we go to the show in Toronto related to healthcare.
So to manage all the users (creation, login) I use Azure Active Directory B2C.
When I create the user I use the graph API because I need to do some stuff in my workflow but this part works fine.
After this I created my sign-in policy and I customized my branding.
The first problem I have is the password field, how I can place a placeholder there? (see attached picture).
The second problem I have, when I click the login it works #1 in Edge but in Chrome and Firefox I have this error :
An unhandled exception occurred while processing the request.
InvalidOperationException: Invalid non-ASCII or control character in header: 0x000D
Someone got this before ?
I faced the same issue. However, i tried to first "sign up" and then sign in. This resolved the issue.
It's not related to a specific browser and can be reproduced on any oh them with the good repro scenario. I guess your issue is that you try from an HTTP website. Since AADB2C will redirect to an HTTPS page, thus the headers are not well managed and you get this error.
Enforce the https on any website using B2C and you may solve this issue
I have successfully linked ACS to ADFS and our website user's authenticate against ADFS without issue.
I also have legacy sites that authenticate directly against AD via custom code and IAG.
We would like the users of the legacy site, once authenticated, to bypass having to login again to enter our new sites. Removing IAG is not an option at this moment.
I have the ability to add additional pages to the legacy site and I can create addition IP's in ACS. My attempt so far has been to create a self signed cert, generate a federatedmetdata.xml based on that cert file and import that into ACS. That went well. Then I wanted to try and create the WSResponse and claims for the WSignin1.0 request and post that to ACS using the same cert I used to create the metadata file. That action would occur from the legacy site. That has not went so well as I usually receive a HTTP error code of 500 with the "ACS20001: An error occurred while processing a WS-Federation sign-in response" from ACS.
Basically I would like to know if what i am doing is feasible? , or perhaps there is a better way given the constraint of IAG, or if I am close and should continue down the path I am on.
We're building an application which uses ACS. Our usage scenario looks like this:
The user gets a URL like this one https://our.application.com/?requestId=123456 via email and clicks on it
The user gets redirected to the LiveID login screen
After logging in, ACS forwards the user to us, but to https://our.application.com/
Unfortunately, it seems that the "Return URL" setting in the "Relaying Party" on the "Access Control Service Portal" is just a fixed string. Is there a way to propagate the original request to it? If not, what would you suggest as a workaround?
The answer is actually yes, but not without a little work. In step 3, your return URL is being overridden by the one you have configured in your ACS RP by the default ACS login page. This is the page, which ACS hosts for you by default, where you choose your identity provider. (You may not always see it in the browser; it will redirect automatically if you only have one IDP configured.)
You can tell ACS to use a custom login page that you host yourself so that this original URL gets saved. You can download the default ACS login page from ACS portal as something to work off of.
The tricky part comes from the fact that different identity providers using different protocols use different mechanisms to save this original URL.
Some further discussion and code samples about this can be found here, and you might find further solutions to this problem elsewhere on the web:
How do I get the return URL working properly again after downloading a login page from Azure ACS?
I believe the answer's no, and I would suggest using a cookie to store the parameter.
If you want to provide a "returnUrl" via ACS + Microsoft Account you can query the ACS login pages via the IdentitiyProviders.js and pass a "context", e.g.: https://MyACS.accesscontrol.windows.net/v2/metadata/IdentityProviders.js?protocol=wsfederation&realm=MyRealm&reply_to=&context=foooobar&request_id=&version=1.0&callback=&wfresh=0
As a result you will get the Login-URL for Microsoft Account with the wctx parameter:
https://login.live.com/login.srf?wa=wsignin1.0&wtrealm=...&wp=MBI_FED_SSL&wctx=cHI9d3NmZWRlcmF0aW9uJnJtPXVybiUzYW9uZW9mZml4eCUzYWRldiUzYWRlZmF1bHQmY3g9Zm9vb29iYXI1 <-- foobar.
After the login process your configured returnUrl is invoked with the wctx parameter (in my example you will get "foobar").