I have scenario where we use Thinktecture Identity Server (IdSrv) as both an R-STS and a IP-STS, as well as a O365 / WAAD tentant as an additional IP-STS. The user choose which Identity Provider to use via the Home Realm Discovery functionality in IdSrv.
Now, implementing a unified WS-Federation wsignout from the RP, is difficult, since I can't get the signout process to work properly against WAAD (Against the Thinktecture IP-STS it works fine);
Sorry, but we're having trouble signing you out.
We received a bad sign-out request.
If you wish to sign-out, please click the following link.
ACS20028: The requested redirection URL is invalid.
Well, the wreply URL parameter points to the RP, which the WAAD instance has no knowledge of.
If I try to follow the Sign-Out link, I get
Sorry, but we're having trouble signing you out.
We received a bad request.
ACS20026: The wtrealm parameter is missing or incorrect.
I've tried to modify the URL directly so that its wreply points to the IdSrv (which really is an RP of the WAAD), but I can't get it to work.
Has anyone gotten this to work?
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
Might seem a silly question, but Microsoft's documentation isn't very beginner friendly, I think. It uses as examples "http://localhost:31544" for the sign-on url and "http://MyFirstAADApp" for the redirect URI, but although I understand what a local host is I can't figure out what exactly the numbers on it are and how I define them for my application, and absolutely zero clue of what the redirect URI is supposed to do for a native application and how should I define a URI for my own.
To be more clear on what kind of app I'm trying to add, I merely want to acess the Office 365 management API tools and get some data from it, so I imagine a native app would fulfill my needs for now. Registering the app on Azure AD is required to do so according to Microsoft's documentation.
So expanding on the title, how to define an URI for my native app is what I would mainly like to know. Some further clarification on what exactly is the purpose of this URI as well as to how to use and/or define a localhost URL for an Web app would also be much appreciated.
I know this is ancient, but I don't see a satisfying answer here, and maybe someone will come across this and find it useful. To answer the question asked, unless you're going to work outside of the default MSAL handling of the server responses, and I don't expect you would from your description, I'd just go ahead and use the default:
https://login.microsoftonline.com/common/oauth2/nativeclient
When you go into the Azure AD portal, go to your application and, from the Overview, select the "Set RedirectURL" option, you'll add a platform and select the "Mobile and Desktop Applications" and you'll be provided with the choice of 3 URLs to choose from. My understanding is this is just there for custom handling of authorization tokens and is telling MS where to send those tokens. The MSAL library functions seem to use this link as well, so they're probably handling this in the backend.
I agree with the OP though, the MS docs are severely lacking for newcomers and I wasn't able to find an end-to-end description of what needs to happen to get, in my case, a desktop application to send email through Office365 using 2FA. I would forge ahead as best I could until I hit the next error, then explore that, sort it, then slam into the next one. Rinse and repeat. This was made extra tedious as I had to go through a 3rd party IT group to get the 2FA access codes every time I wanted to test.
Best of luck, hope this helps someone!
how to define an URI for my native app is what I would mainly like to
know.
You should provide a Redirect URI that is unique to your application as it will return to this URI when authentication is complete.
In your application, you will need to add a class level variables that are required for the authentication flow, include ClientId and Redirect URI.
Here is the diagram:
Native application makes a request to the authorization endpoint in Azure AD, this request includes the Application IP ,Redirect URI and application ID URI for the web api.
After user signed in, Azure AD issues an authorization code response back to the client application's redirect URI. After that, the client application stops browser interaction and extracts the authorization code from the response.
Then the client app use this code to sends a request to Azure AD's token endpoint. upon successful validation, Azure AD returns two tokens.
Over HTTPS, the client app uses the returned JWT access token to add the JWT string with a “Bearer” designation in the Authorization header of the request to the web API. The web API then validates the JWT token, and if validation is successful, returns the desired resource.
More information about it, please refer to this article.
For native you can set redirect to be equal to the Application ID URI, which now defaults to look like //app:{ApplicationId}
Redirect uri be starts with SSL URL, so select your project, enable SSL URL and use this auto generated SSL URL (for example : https://localhost:port#) as redirect uri , same to be updated in the azure app registration as additional redirect URIs
How can I change the identity, as an IDP, of the WSO2 IS?
It seems to always call itself localhost!
Some context...
I have deployed an IS and are trying to authenticate against it using SAML2.
Every single example I can find on the internet deploys IS on the same server as the SP, so the IS is on localhost! (by the way, I do arrive at a working IS-SP login on a single computer)
But this is not my case, SP and IS are on two different VMs. When I try to authenticate, after logging in, I get an error:
Caused by: SimpleSAML_Error_Exception: Cannot retrieve metadata for IdP 'localhost' because it isn't a valid IdP for this SP.
I think this error is on the SP side, generated by simpleSamlPhp.
From what I understand, this means that:
* the SP calls the IDP (IS) with a given IDP id (not localhost!) and SP id
* the IDP manages to ask us for login/passwd
* the IDP sends a SAML2 message to the SP
-> here, the IDP probably calls itself "localhost"
* the SP tries to get config (metadata?) for localhost and can't find any!
So the question is: how can I change the IDP id that the IS uses to answer?
I have changed the server name in carbon.xml, and I have changed every localhost I could find in identities.xml, but to no avail.
Thanks for any tips!
in the management portal of WSO2 IS
go to Main / Identity Providers / List
Click on "Resident Identity Provider"
Expand "Inbound Authentication Configuration"
Expand "SAML2 Web SSO Configuration"
Fill in the "Identity Provider Entity Id:"
Note that, without knownledge of the keyword "resident", I have not found this information in any doc or web page or blog.
All examples are provided with localhost.
The place this configuration is stored in not intuitive: going to "identity providers" gives a message "No Identity Providers registered", so it's easy to ignore that this is the page where this configuration lies. The link looks like a title. Subtle, but may lose a lot of time! :-)
WSO2 make great products, but tutorials and docs would benefit from being more open or diverse, I don't know. For example one can call an endpoint "localhost/saml", but is there any other way to call it? What will change? Is there an example somewhere of a deployment with lots of strange and distinct values for fields, "foo", "bar", etc?
Hope this helps others, via google search at least! :-)
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").