We currently have problems with Single Sign Out with ADFS 2.0 and an external IP-STS. Our setup is that:
RP1 <-- trust --> ADFS 2.0 <-- trust --> Custom IP-STS
RP2 <-- trust --> ADFS 2.0 <-- trust --> Custom IP-STS
The Single Sign On part works very well that if users have already logged on using Custom IP-STS to access RP1, thereafter they can access RP2 in the same browser session without having to log on again.
However problem comes in sign out process. When users sign out from RP1, by using Fiddler we can see that:
Sign out request (wsignout1.0) is sent to ADFS
ADFS transfers sign out request to Custom IP-STS
Custom IP-STS processes sign out action properly, and then returns back to ADFS
ADFS does return back to (signed out) RP1
RP1 is no longer authenticated, so of course is prompted for logging in again (CORRECT)
HERE IS PROBLEM: RP2 is still able to work without any problem (with previous claim set). And ADFS does not send any wsignoutcleanup1.0 action to RP2.
I assume that ADFS should do sign out for all RPs having the same session, but it doesn't. Am I wrong? Or am I missing some kind of configuration here?
Of course we have option to explicitly send wsignoutcleanup1.0 action to RPs from Custom IP-STS, but we need to parse the "wctx" in order to get the original RP Url which I don't want to.
I also tried to send wsignoutcleanup1.0 action back to ADFS from Custom IP-STS (step 3), but it didn't help also.
My guess is that you are not returning iframes with wsignoutcleanup but rather images. Thus, adfs does not return nested iframes, in other words it doesn't escalate signout properly.
A correct sequence is
1 application sends the signout request to adfs
2 adfs escalates the request to the external sts
3 sts returns sequence of iframes pointing to authenticated applications (adfs in this case) with wsignoutcleanup
4 adfs returns a nested iframe with wsignoutcleanup to all authenticated apps, including rp1 and rp2
It sounds like the custom STS is not sending the signoutcleanup to ADFS.
Related
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 am beginner in using CAS and i'm using it in one of my project to use its Single Sign On services. Till now i have implemented Single sign on, I have one JAVA client and a PHP Client. But for using Single Sign Out functionality i configured my running CAS according to CAS documentation. I have done all the changes in the deployerConfigContext.xml of my working CAS. My CAS is up running, but on logging out it doesn't show any SAML logout request. I'm using Official PHP Client and Java Client made by me. I think it may be due to these lines which i'm not able to configure it in my Client side.
The way the notification is done (back or front channel) is configured at a service level through the logoutType property. This value is set to LogoutType.BACK_CHANNEL by default.
I'm not able to understand by this line where actually i had to set the Logouttype to BACK_CHANNEL, if its my Client then why is it that it is set to BACK_CHANNEL by default as a Client can be made by anyone.
Any help is highly appreciated.
Thanks in Advance.
Take a look at the jasig documentation: http://jasig.github.io/cas/development/installation/Logout-Single-Signout.html
When a CAS session ends, it notifies each of the services that the SSO
session is no longer valid, and that relying parties need to
invalidate their own session.
This can happen in two ways:
CAS sends an HTTP POST message directly to the service ( back channel communication): this is the traditional way of performing
notification to the service.
CAS redirects (HTTP 302) to the service with a message and a RelayState parameter (front channel communication): This feature is
inspired by SAML SLO, and is needed if the client application is
composed of several servers and use session affinity. The expected
behaviour of the CAS client is to invalidate the application web
session and redirect back to the CAS server with the RelayState
parameter.
And the important part:
Usage Warning!
Front-channel SLO at this point is still experimental.
So your SSO server sends a request to the application directly. The authenticator recognizes that this request is a special one and logouts the referenced user.
Update:
Take a look at the following links:
https://wiki.jasig.org/display/casum/single+sign+out
https://github.com/Jasig/cas/blob/6c3df3a5f42d2d8b771ba773aeda3ba5a4c525e3/cas-server-webapp/src/main/webapp/WEB-INF/spring-configuration/applicationContext.xml
https://github.com/Jasig/cas/blob/6c3df3a5f42d2d8b771ba773aeda3ba5a4c525e3/cas-server-core/src/main/java/org/jasig/cas/logout/LogoutManagerImpl.java
Did you accidantly remove or overwrite your logoutManager declaration in your applicationContext? Is there an logoutManager bean in your running spring context?
I would start by setting break points in the handleLogoutForSloService, performBackChannelLogout and performLogout methods of LogoutManagerImpl.java.
Are they beeing called?
Can you step through them?
Is performBackChannelLogout called?
Is this.httpClient.sendMessageToEndPoint(msg) in performBackChannelLogout successful?
If you are logged on to 2 services, performBackChannelLogout should be called twice with both service urls.
I'm currently making tests with the CAS server 3.5.2 and I'm facing
problems with the logout.
My knowledge in these topics is limited and I don't manage to go further on
that point.
I installed a CAS server and I've got 2 instances of the same java
application that point to that CAS server (appologize if I don't use the
adecuates terms).
So, when I access to the protected resources of my client aplication, I'm
redirected to the CAS login page, I check in my DB if credentials are ok
and then I access the resource. Then, if I access to the same protected
resource from the second instance of the client application I'm not
redirected to login page. That's perfect.
The problem is situated in the logout. To do so, I first execute a
session.invalidate() and access to the CAS logout page. It's ok because,
from the application from which I logged out, I must login again to access
the protected resources. On the other side, the second application remains
connected and I can access the protected resources without login again.
Well, I know that the session.invalidate() is local to the first
application but I thought that CAS server would have "broadcasted" the
desconnexion to the other application but no.
Is there somebody who can give me experience feedback for the single sing
out topic ?
First make sure that SSO is enabled in the CAS properties file, if not make sure the SSO Listener is enabled in the clients.
If they are enabled then my guess would be the issue is in either the LogoutManagerImpl.java or SamlCompliantLogoutMessageCreator.java files.
The SSO in CAS is performed through the back-channel by transmitting a SAML XML message.
I had an issue with the SSO function last year only to find out that the XML message being broadcasted had an error that prevented it from being parsed.
Finally I solved...
In web.xml, the order of filters is important. Filters for Single-sign out must be placed at the begining.
See that section https://wiki.jasig.org/display/CASC/CAS+Client+for+Java+3.1#CASClientforJava3.1-OrderofRequiredFilters
Hi I am facing following issue for single sign out in ADFS 2.0.
I am using ADFS 2.0 as RSTS
Another ADFS 2.0 is registered as claim provider and is configured for Forms authentication.
I have 4 relying parties (RPs) hosted on another IIS server m/c.
I am opening all the 4 RPs in IE after authenticating against Claim Provider. Sign-out works perfectly fine for the first time. But if I sign-in again and click on sign-out ,any one of the RP application remains signed-in after refresh.I could also see the Auth cookie remaining there after sign-out is processed by the ADFS/LS site.
Note: single sign-out work correctly for multiple sign-in and sign-out if the count of RP apps is restricted up to 3.
Am I missing any settings in RSTS?
How R-STS remembers all the RPs for which it's creating the signout cleanup request (wa=wsignoutcleanup1.0)?
If it's a known issue in ADFS2.0, is it resolved in higher version of ADFS (3.0) any guess?
Thanks in advance.
I found the work around and mentioned the details here , but still following questions need some light
1)why that R-STS's adfs/ls site does snot sign-out one or more RP app(s) for multiple sign-in , sign-out. Is it like R-STS's adfs/ls site is randomly loosing one or more RP url in this case?
2)How R-STS's adfs/ls site is maintaining the RPs url and why single sign out does not work in case of multiple sign-in , sign-out without closing the browser?
3) Is this a known bug and is it fixed in higher version of ADFS say 3.0? or any thing I am missing in handling the single sign out?
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.