We have a federation where ADFS3 is our main sign on mechanism with Identityserver as a relying party which is handling our Oauth. So when a user logs in we are redirected via the idserver to ADFS where they login, then we are redirected back and the user now has an oauth token issued by identityserver.
We are having issues with logoff when it is initiated by ADFS. Using fiddler I can see ADFS is redirecting to https://idserver/?wa=wsignoutcleanup1.0 but this is returning a 404.
Is this the right URL its calling?
Have we missed something when creating the idserver?
I don't have a callbackpath configured so assume it should pick this up?
Thanks
The problem is that the Katana Ws-Fed middleware from Microsoft doesn't support signout. You will have to implement this yourself -- middleware seems like an obvious approach.
Related
I have a web application that is capable of being a SAML 2.0 IdP as well as a SP, and have successfully implemented SSO between my platform and ADFS, but only when ADFS is the IdP.
This is my first foray into integrating with my platform, using ADFS as a SP and I'm having problems understanding the SSO flow.
In my situation, I have three players: WebApp (IdP), ADFS (SP), RelyingParty (S). The trusts are set up in ADFS, and the user experience is supposed to be a successful login to the RelyingParty having logged in to the WebApp
Setting up a new Claims Provider Trust in ADFS with my web app appear to work perfectly. I can go to my app's IdP-initiated URL which sends an unsolicited SAML message to ADFS's ACS URL. When I do this, I get redirected to /idpinitiatedsignon with the message "You are signed in" and a drop-down of the relying parties I've already set up.
If I click on the login button for the RP, ADFS generates a new AuthNRequest to my web app before eventually getting to the Relying Party.
So, seeing this behaviour, I have two questions:
I would have thought that the initial sign in to ADFS via my IdP-initiated login would have got me though to my RP without the need for going back to the IdP for another sign-in. have I misunderstood, or have I just misconfigured ADFS?
What mechanism is ADFS determining that my IdP is to be used? If I go to the ADFS /adfs/ls/idpinitiatedsignon.aspx page in a browser, I've not involved my IdP at all, and selecting my RP does use my IdP to authorize the user but I've no idea how this is determined since there's no link between the Trust Claims Provider and the Relying Party in ADFS configuration.
What happens if you use loginToRp:
https://your-adfs-server/adfs/ls/IdpInitiated.aspx?loginToRp=your:relying:party:id
You have chosen to use IDP Initiated to ADFS. So ADFS handles the authentication.
If you want to involve your IDP, you need to use SP-Initiated flow from the RelyingParty (S).
Then ADFS will show you the Home Realm Discovery screen and you can pick your IDP.
I am implementing front-channel SAML 2.0 SSO golang Service Provider, with Okta as my Identity Provider (this is just a POC and should eventually work with any IdP).
Implementing the sign on process was straightforward with saml2 package. I've created the login endpoint that redirects to the SAML application login URL at the intended IdP, as well as the POST callback endpoint which is properly receiving the SAML assertion and is able to validate it. After that a session with a random cookie is created with the same TTL as the Identity Provider session TTL. So far everything works well (I haven't implemented Single Sign-Out yet, but I'm planning to).
However, when some time passes and the session expires, I'd like to renew it only if the user is still logged in with the Idp and hasn't been removed from the SAML Application. I would like to avoid redirecting the user to perform SSO again with IdP, because it would mean that if they are still logged in, they would be redirected back to the home page of my application. I wasn't able to find great sources on my options to go about it online.
Questions:
1.1 One solution that comes to mind is storing the requested URL in the RelayState parameter, whenever the session has expired, then redirect the user to the IdP SSO URL. When the redirect returns to the SAML callback POST endpoint, check the RelayState parameter and if set, redirect back to that (original) URL. That means that for users that use the system continuously, I would have to request Assertions very often. Does that make sense?
1.2 A second solution that comes to mind is to implement a back-channel of communicating directly from my SP to the IdP. That would allow me to verify a user is still logged in 'behind the users back'. If that's a sound idea:
a. Do I need to have dedicated code for each IdP?
b. Do I need to load an API key to the IdP which would allow secure communication?
c. Do I need to upload a public certificate to the IdP that would be able to verify that my SP signed the requests?
Will using the Assertion to get an OAuth 2.0 Access Token help me in achieving this?
I've chosen SAML 2.0 for now, since the environment is an enterprise oriented one and I thought it fits well with it based on what I read. Would using OpenID Connect instead help achieve my goals easier and fit well with enterprise oriented products?
I'm trying to integrate Okta as a third party Identity Provider for a system I am working on that is using the IdentityServer 3 framework to support my customers that use Okta. I have everything working great except log out. When a user logs out of my system, it initiates the end session call back to Okta to log the user out. My problem is that the Identity Server is sending a session id along with the post logout redirect uri for context, but Okta refuses to accept the redirect uri because it is not known. I've tried multiple variations in the setup in Okta for this url but because the id value is dynamic, i'm not able to specify an exact url. Is there a way to have it support any urls that are going to a specific hostname or even up to the page path? I've tried adding my host into the API security area for trusted origins but it did not work either. I've also tried overriding the postback url for my system to be a static page, but then the IdentityServer Signout message cookie is never cleaned up correctly. This same code works without any problems when running for Azure as the IDP. Has anyone run into this before and have any thoughts? Any help is appreciated.
An example of the post to Okta at signout with the postback url is something like this,
https://dev-xx.oktapreview.com/oauth2/default/v1/logout?post_logout_redirect_uri=https%3a%2f%2fmyurl.com%2fidp%2flogout%2f%3fid%3d83617adbc6769e5d4d0fbca4dced3991&max_age=5&id_token_hint=eyJraWQiOiJ1aXJYc1RYTkTVVGenBXU1JfMWt6WndNSXBQQUVqT0dndWhjbloxR3pNIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiIwMHU4eTlrajNyT2NreW11cTBoNyIsIm5hbWUiOiJKYW1lcyBSZWFtZXMiLCJsb2NhbGUiOiJlbi1VUyIsImVtYWlsIjoiamFtZXMucmVhbWVzQHJlYWxwYWdlLmNvbSIsInZlciI6MSwiaXNzIjoiaHR0cHM6Ly9kZXYtNDg5MDgyLm9rdGFwcmV2aWV3LmNvbS9vYXV0aDIvZGVmYXVsdCIsImF1ZCI6IjBvYWVvdXMycWFJTWJ3U0dhMGg3IiwiaWF0IjoxNTM2MjQ5NzY2LCJleHAiOjE1MzYyNTMzNjYsImp0aSI6IklELlVUem5sTC1FRUY0aHFoZlNSbG5wV1cyUGRxQzlBRk1PcDZiOTh6UERRUUEiLCJhbXIiOlsicHdkIl0sImlkcCI6IjAwbzh5OWZycXVmOFlpaG50MGg3Iiwibm9uY2UiOiI2MzY3MTg0NjU0NTA1NzI4ODQuWldOaVlqZG1aamt0Wm1Fd01TMDBNVGc1TFRreE4yTXRaR1kzTWpreVl6ZGpOekprTm1GbU16WTJaRFl0TURBeE15MDBNMkUwTFdJM01ERXRNek5oWTJOaU1qZ3daamd4IiwicHJlZmVycmVkX3VzZXJuYW1lIjoiamFtZXMucmVhbWVzQHJlYWxwYWdlLmNvbSIsImdpdmVuX25hbWUiOiJKYW1lcyIsImZhbWlseV9uYW1lIjoiUmVhbWVzIiwiem9uZWluZm8iOiJBbWVyaWNhL0xvc19BbmdlbGVzIiwidXBkYXRlZF9hdCI6MTUyMzYyNjUzMiwiZW1haWxfdmVyaWZpZWQiOnRydWUsImF1dGhfdGltZSI6MTUzNjI0OTc2NiwiY19oYXNoIjoiMWoxa1JTSGhObGRGWGNmSDdCQXRBUSJ9.gvG_8dnlAMr9XI-atCjIKVF04L4oMzerXmeT0BAG76RLle-q2pgb8PDvV4cTicLH16QLzboSgocC6t6WoegbUeJLLuzZHd2rQkm8Y4iRheoV05uKhd2mpLA9LyexlJ9oVJ8Xi_D4BqN_bygphAv79B4L8-Ezz3YgGDmSkK3WutB55_r_7XM0OCCCetvNu4S8KXbKHUxgg5cpQ6y7o-d5eIH6I8bpoOoA0gy7Liwsm7IyQUe5_jdorObgBHIEfDx4mjNRENJUQ7InASwbL7eND7COZYyXRwzn7vHU0_XkBaUW9wsY-VJUaihOwEcgVS1MPbGLoSUY9k0TmcUVN3-Q&state=83617adbc6769e5d4d0fbca4dced3991&x-client-SKU=ID_NET&x-client-ver=1.0.40306.1554
the id=83617... is what is tripping up Okta from trusting the redirect url. I've tried adding all of these combinations of urls into the logout redirect uri setup and none let it accept it,
https://myurl.com/idp/logout/
https://myurl.com/idp/logout/?id=
https://myurl.com/idp/logout?id=
https://myurl.com
https://myurl.com/
https://myurl.com/idp
https://myurl.com/idp/
https://myurl.com/idp/logout
None seem to work.
I am creating simple service provider (SP) on java with wso2 saml sso authorization.
I implemented it in this way (please correct me, if I'm wrong):
User inputs some target Url in browser
My SP's servlet sends redirect to WSO2 IDM.
IDM authorizes the user and redirect to my Consumer Url with
SAMLResponse and RelayState parameters.
Now SP must process this request and redirect user to target Url without redirection to IDM again. Otherwise I'll get the infinite loop, so I think that between step 1 and step 2 should be one more step...
What is the proper way to do this?
Typical implementation
1 User tries to access a protected site
2 A filter checks if the user has an authenticated session.
2.1 If not, redirect to IDP/IDM
2.1.1 IDM authenticates user and redirects back to SP with identity proof
2.1.2 SP creates authenticated session
2.1.3 User is redirected to target URL everything start from 2 again.
Here I have a post describing the flow in more detail
I have seen a similar post but that was more related to ASP. I will explain my situation below.
I am developing a SP(Relying Party) and integrating with ADFS (IDP). Since I am in the integration phase, I want ADFS to forget that I have previously authenticated so that each time I hit the ADFS endpoint (/adfs/ls) with AuthnRequest, I want it to ask for my credentials.
I believe ADFS by default, remembers clients by their remote IP/host name so clearing cookies on client machine does not help. There was a post that gave a link to logout from IDP (https:///adfs/ls/?wa=wsignout1.0&wreply=https:///adfs/ls/?wa=wsignoutcleanup1.0). The ADFS says I have been logged out but when I hit ADFS endpoint, ADFS redirects back to SP with successful AuthResponse.
Can you please tell me how to force reauthenticate/logout on ADFS or point me to the right articles?
The FederatedPassiveSignInStatus control (which should be part of VS if you've installed all the WIF stuff) will help you. Add it to your app. and clicking it will log you out of everything.
Also AD FS: How to Invoke a WS-Federation Sign-Out
Add wfresh=0 as a URL parameter.
This parameter indicates "freshness requirements".
According to the spec:
If specified, this indicates the desired maximum age of authentication specified in minutes.