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! :-)
Related
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
I'm creating a web app to work with Azure AD.
I'm going through the process of making the REST requests, etc., and I'm a bit confused as to the endpoint URL parameters given by AD versus those given in the help documentation versus what I'm given in the AD console online. On some of the documentation pages, the endpoints are given as "https://login.windows.net/[some domain].onmicrosoft/...", where on the AD console, I'm given a long hash, with no ".onmicrosoft/..." present. I'm having problems with both (something else is obviously wrong), but I can't proceed debugging that until I know which I should proceed with, so I know that this isn't causing the problem.
The "hash" is actually a GUID, and is your tenant ID - the unique identifier for your Azure AD tenant. When constructing the login.windows.net endpoints you can use the tenant ID and the domain name (yourtenant.onmicrosoft.com) interchangeably.
See this post from Vitorrio Bertocci for more details on the subject.
This is indeed confusing and not well hashed out in the documentation.
I've created a web-app that also uses Office 365 authentication with Azure AD, and I am using the hash generated by the Azure AD console for my endpoint URLs, and everything is functioning well. Whatever the AD console gives you online is correct, and will work for your particular app (the hash given is in fact replacing a .onmicrosoft domain, and will work well).
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?
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").
I'm new to WIF - sorry in advance if my questions seems to be very basic...
I have a 1 WebSite lets say localhost that require username/password authentication. Access to //localhost/ForSecuredClientsOnly should require only client certificate to access the site.
AFAIK client certificates authenticaion is handled by IIS, how should I handle this problem if I want to use STS?
My ideas:
Use 1 STS, set IIS to Accept certificate (not to require) and read certificate in STS and figure out whether user can access the resource.
I was reading through http://msdn.microsoft.com/en-us/library/ff359105(v=PandP.10).aspx and
http://blogs.msdn.com/b/eugeniop/archive/2010/04/03/wif-and-mvc-how-it-works.aspx but when I'm already logged in to //localhost and try to access //localhost/ForSecuredClientsOnly STS thinks that I'm a valid user.
I'm returning new Redirect result from ForSecuredClientsOnly (path from SignInRequestMessage, since user does not belongs to group X) but the realm is always: //localhost/ (probably it's expected behaviour and reason why user is authenticated ...)
Use 2 STSs and move //localhost/ForSecuredClientsOnly to //securedClients.localhost. I don't really like idea of having 2 STSs though
Have 1 STS and create to websites pointing to the same STS. I hope that then in STS I'll see that sign-in request is going from different realm and then perform either username/password of client certificate authentication? I would also prefer not to use that option since it's not ideal if I need to create new website per section of the site that requires different authentication.
Questions:
I would like to make idea number 1 working but how can I pass different realm depending on site subsection, I see that I can set HomeRealm property on SignInRequestMessage but how can I later read it in STS? (User.Identity.IsAuthenticated is always true in STS if I already logged in to //localhost).
Should I be using HomeRealm at all to distinguish between site sections?
If you have ideas what's the best approach to read and validate client certificate in STS please let me know. Currently I'm thinking that I should check whether certificate Thumbnail is one of the certificates that I'm allowing - store collection on client certificate Thumbnails in database?
I appreciate all your input.
I think it will be worth looking at the Starter STS community project at Codeplex.