We have ServiceNow among other applications configured in ADFS for SSO, ServiceNow is the only app using SP Initiated signon however.
Sometimes when you log out, it behaves as it should and goes to https://adfs.example.com.au/adfs/ls/?wa=wsignout1.0 and tells you that you are signed out but sometimes instead of going to the signed out page you just get redirected back to ServiceNow, (you can see another SAML request happening and it lets you in) and your session is still logged in. Obviously this represents a security issue! The User logs out then leaves the machine without looking and the session is still open!
Anyone come across this before? It seems SP Initiated Sign On is buggy and I need to fix these log out issues for security reasons.
The wa=wsignout1.0 is intended to use for wsfed applications. servicenow as a SAML2 app should be sending a properly constructed samlp:logoutrequest to the /adfs/ls endpoint to do a signout properly.
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?
Currently I'm trying to get Salesforce to hook up with an ADFS cluster. I have it working, but I notice when users go to their bookmarked Salesforce pages without first logging in to ADFS (that are saved past the login point of their journey through the site) they receive a general ADFS error
An error occurred. Contact your administrator for more information.
I think this error is expected since they aren't authenticated with ADFS yet.
However, when they receive this error, is there a way to have them automatically be redirected to the login page on ADFS to log into Salesforce? I want to enhance their experience so they don't see errors so much.
ADFS is on Server 2012 R2.
I fixed this by ensuring the Salesforce custom domain was published to all users and that bookmark settings were properly set.
https://help.salesforce.com/apex/HTViewHelpDoc?id=domain_name_testing_and_rollout.htm&language=en_US
https://help.salesforce.com/apex/HTViewHelpDoc?id=domain_name_login_id_prov.htm&language=en_US
After reading a few articles on SAML, including "SAML for dummies," and the SAML wiki article, I'm still entirely unclear as to how SAML actually solves the SSO problem. Suppose I take something like a Google account as an example. My understanding is that if I go to GMail and SAML is implemented, I will be redirected to an IDP, which, let's say, is Google's sign-in authority. My browser then goes there with a redirect, and I'm asked to log in. After providing the correct login info, I return to GMail with a token and SAML response encrypted with Google Sign-in's private key, which is then authenticated using GMail's public key, thus verifying that I am, in fact, who I say I am.
What's confusing to me, is that this seems to solve the problem of signing in the first time, or into a single application, but I don't understand what happens when I now go to Google Drive. Even if my browser saves the SAML token/response as a cookie, I would have to sign in again after the token expires, which, I read, is something like 2 minutes later. Moreover, even within the same application, requests to separate resources or endpoints seem like they would time-out in the same fashion.
The only hint I have is that, according to the wiki article, step 1 has the target resource at the SP check for "a valid security context." However, if GMail and Drive are separate applications which aren't communicating with each other, how would Drive know that I already have a valid security context?
Questions:
After the initial authentication, what information needs to be sent with future requests to the same or different application/endpoint? For example, perhaps the SAML assertion saved and resent with every request.
How is this information secured/verified?
What timeouts are associated with SAML's SSO, and how are the timeouts enforced on both the SP and IDP sides?
What you are missing is that the Idp (Google's sign in page in your example) sets a session cookie on the first login. When you access Google drive as the second application, it has indeed no knowledge of the gmail session. Google drive does a redirect to the idp to get an authentication.
Now, the idp has an active session thanks to the cookie on the idp domain. That makes it possible for the idp to reply to google drive with a new assertion, generated from the persisted session information.
You're right that each assertion is normally only valid for a few minutes, but that isn't a problem as the idp can create a new assertion for each application.
For timeouts: The Idp can set a SessionNotOnOrAfter condition in the assertion to tell the SP that it must terminate the session at a given time.
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
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.