We are using ADFS 2.0 as a federation provider with a identityprovider (claimsprovider) that uses the SAML2 protocol. The relying parties for ADFS uses WS-Federation protocol.
We are now able to request a relying party, sign-in with the SAML2 identityprovider and sign-out so that ADFS sends a sign-out request to the identityprovider wich we then are truly signed-out from.
The problem occurs when we, during the same session (not closing the browser) request a relying party again, sign-in again with the SAML2 identityprovider and then try to sign-out. What happens is that ADFS shows the signed-out page but does not send a sign-out request to the identityprovider so the process stops there (at ADFS). If we then try to sign-in again we, naturally, just "bounce" at the identityprovider as we are still signed-in there.
After the first sign-out (wich always work) this is what happens at all following attempts.
The relationships and protocols are as follows:
RP <---wsfed---> ADFS <---samlp---> IDP
This is down to the browser caching the credentials for the ADFS server. The user is re-authenticating, but they are not being presented for the credentials as the browser remembers them.
After logging out they should be presented with a browser window that informs them to close their browser to securely logout. This is what has to happen to clear the credential cache.
Related
We have an MVC application (<myapp.somedomain.com>) .net 4.5.2 (OWIN/ADAL) that uses ADFS2016 for AuthN/AuthZ via OIDC/OAuth2. Users' credentials and attributes are stored in AD LDS. A client (X) requested to authenticate in the application via their IdP over SAML2. Is this possible WITHOUT making changes to the application?
The flow I am looking for; for this client the app’s URL would be (<myapp.somedomain.com/?client=x>). Our ADFS would recognize and redirect the client to their IdP where they would authenticate and than they would be send back to our ADFS along with some predefined claims. Our ADFS would map these claims to an Id Token / Access Token for our application to use. Am I dreaming or is this indeed feasible?
Any links to articles / documentation on how this could be achieved would be most helpful.
As #Wiktor suggests, you could add a SAML client-side stack to your app.
The other way is to federate ADFS with the SAML IDP.
When the user is redirected to ADFS, they use Home Realm Discovery to either redirect to the SAML IDP or authenticate on ADFS directly.
ADFS should handle the token conversions but you may have to fiddle around with the claims rules.
I'm working on a java Spring Boot project that manages users and sessions internally. It relies on OIDC, AWS Cognito being the Identity Provider, for sign-in and, I would hope, sign-out of the users.
What I understand from the OIDC Spec for backchannel logout is that:
I must provide an endpoint for logout in my backend application. I am using Pac4J as my OIDC library in a java Spring Boot application, and have enabled the logout endpoint as per the Pac4J Spring Security documentation
The Identity Provider AWS Cognito should send a request to the logout endpoint if the user is signed out from the Identity Provider
When I receive a valid call (as per the OIDC spec) on this endpoint, I must destroy the user's session with my application.
However, the user being logged out of the Identity Provider (AWS Cognito) does not seem to result in a call to the logout endpoint of my application.
I am unable to find documentation for this backchannel behaviour in the AWS Cognito docs.
Have I understood the backchannel logout correctly?
Is this currently unsupported as OIDC logout is still (as of March 12, 2019) in draft status?
I contacted the main developer of Pac4J who was very prompt to reply.
AWS Cognito:
Currently does not seem to support backchannel logout
Pac4J:
Backchannel logout is currently not supported by the library for OIDC, and it isn't on the roadmap either: https://groups.google.com/forum/?fromgroups#!topic/pac4j-users/SD_IgKVZWvM, the /logout referenced in the documentation is for internal (to the app) logout + (if configured) forwarding a logout request to the identity provider. It is NOT a OIDC-backchannel-logout endpoint.
Can someone shed some light on the use case for me. We wave users who will be signing in to third party client applications. Using OAUTH2 framework, the client app will redirect to our site to authenticate. From my undestanding, the Authorization server will return a access token and an id_token (OpenID Connect).
1) If the user is authenticated with us and is redirected to the client application, if they leave the client application and go back into the client application hours later, do they still have go through the whole redirect to our /authorization endpoint to re-authenticate?
2) If the user is authenticated with us and is redirected to the client application, if they leave the client application and go to our site, do they have to login again to authenticate?
Basically, does OpenID Connect over OAUTH2 allow a user to sign in once and then not have to sign in again after subsequent visit to the third party app or our app?
Thanks.
It depends on two things:
a. if the client application maintains a session and that session has not expired yet, the user won't be redirected at all
b. in case the client session timed out, the user will be redirected but if the IDP still has an authentication session running, the user will not have to authenticate and will be sent back immediately to the client app with a new token.
It depends on the IDP session existence/timeout again
Essentially an Identity Provider authenticates users and decides how to do that. It can prompt for credentials but can also create and maintain authentication sessions for the user for (typically) a limited period of time which allows for true Single Sign On (SSO).
Also note that this behaviour does not depend on the exact protocol at hand (OpenID Connect, OAuth or even SAML): it would work the same for any protocol that redirects a user to an Identity Provider in a federated SSO system.
In OpenID Connect, the session at RP typically starts when the RP validates End-User's ID Token. ID token consists of expiration time. So if the user just leaves (not logged out) and the id_token is expired when he access the RP, then the end-user needs to re-authenticate.
If the end-user logged out from the relying party and the OpenID provider supported logout mechanisms such as OIDC session management, OIDC front-channel logout or OIDC back-channel logout, then all RPs sharing the same browser session will be logged out (SLO). Then the end-user needs to login to the OP again to access the RPs.
After spending good time in Spring security with SAML for ADFs login , I am became fan of framework.
I was able to integrate my web application with ADFS for login. But I am missing few requirement here :
1) When we select IDP ADFS login url on my web application login page ,it is moving out of my web application to ADFS login. Which is not desire behavior for business.
2) Also faced problem that , as on successful login user object sent back to my web application from ADFS but in case of login failure it is staying on ADFS login page with login error message.
With this requirement can you please guide me for below requirements.
1) I want to use my own login page (instead of ADFS login redirect) to capture the username and password
2) Pass on those credentials to ADFS server for authentication
3) User authentication flow:
3.a Once user is authenticated, then redirect user to success page
3.b If authentication failed then redirect user to error page. ( Getting failure response from ADFS)
The core idea of SAML-based single sign-of is to decouple system which authenticates users (IDP - identity provider) from the systems which receive information about user's identity without performing the authentication (SP - service providers).
This model implies that SP does not have access to user's credentials, and therefore cannot contain a traditional login screen with username/password.
You can find more details e.g. in wiki of SAML 2.0 Web SSO
Yes, We can do this if IDP provides the authentication API. Okta IDP provides such API.
Check this:okta authentication api
Accoriding to the Spring SAML Extension document :
Local logout terminates only the local session and doesn't affect neither session at IDP, nor sessions at other SPs where user logged in using single sign-on. Local logout can be initialized at scheme://server:port/contextPath/saml/logout?local=true.
For global logout, we have to hit the scheme://server:port/contextPath/saml/logout URL, but for me, it only logs out from the local session, but doesn't logout from the IDP.
This is the [WebSecurityConfig] (https://github.com/vdenotaris/spring-boot-security-saml-sample/blob/master/src/main/java/com/vdenotaris/spring/boot/security/saml/web/config/WebSecurityConfig.java) , that I'm using to create the SAML SP.
My question is, am I doing something wrong here? or is this a problem because of the IDP I'm using (can't mention the IDP as it's one of my firm's SAML SSO).
Or do I have to define any global logout handler here? If yes, How?
Global Logout in case of Single Sign On (SSO) needs support from both the service providers (SP) as well as the Identity Providers (IdP). What you are doing is only enabling the Global Logout endpoint from the SP side which only ensures that the SP will generate a Global Logout request to itself & to the IdP (depending on the SAML profiles/bindings you are using), now how the IdP handles it depends on IdP as well.
In SSO a session at IdP, a session at SP and cookies at user-agent is set on login. To facilitate a single global logout there comes a gap between user expectations and technical limitations. I suggest you to read about SLO issues here: https://wiki.shibboleth.net/confluence/display/CONCEPT/SLOIssues
Shibboleth IdPv3 has provided partial support for Single Logout using both front-channeling (user-agent involved in sending logout to all SPs & IdP) as well as back-channeling (user-agent sends logout request to current SP & IdP, the IdP in turn sends logout request to all logged-in SPs). You can read how Shibboleth IdP v3.2.0 handles logout here: https://wiki.shibboleth.net/confluence/display/IDP30/LogoutConfiguration
I would check the IdP metadata that you have configured. It sounds like an endpoint specified is wrong so it's not receiving what it needs.
With that said, you ought to confirm whether there has been any activity on your IdP's logs regarding any form of logout. Consider DEBUG or TRACE level.