Shibboleth session vs Application session

[Sathish Anickode]

Thanks for your updates. Currently, we are looking to provide single sign-on features within our internal application only and do not have any need to integrate with a third party Identity provider. Based on our current scenario, I am observing the following:

We have configured the user session on IdP to timeout after 15 minutes. We have two internal application App1 and App2 hosted on different servers and the session timeout is set to 15 minutes. Both the application uses the same User/Password authentication on the Idp. Because we are enabling single sign-on between App1 and App2, the users does not see any distinction between the two different apps and appears as a single app to them.

User logs into Application 1 and performs some operation. They are then idle for 10 minutes, accesses App2 and performs some operations for next ten minutes in this app. In the mean-time, since App1 has been inactive for 20 minutes, it's session along with the users session in IdP  timed out. When the user tries to access App1 after 20 mins, the app will try to authenticate and redirects the user to the login page, as the Idp user session has expired. 

I am finding that the IdP user session does not extend the user session timeout, when the user authenticates with App2 after 10 minutes. The documentation states that the user session is reset when the user tries to authenticate with a service provider. But in my test that does not seem to be the case. Is my observation correct or am I missing something?


-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Eric Goodman
Sent: Thursday, December 11, 2014 5:52 PM
To: Shib Users
Subject: RE: Shibboleth session vs Application session




>Thanks for your reply. Based on discussions and a better understanding 
>of Shibboleth inner workings, I would like to clarify my requirements:

>Per the PCI requirements, I want the user to be forced to 
>re-authenticate if there were no activity on any associated SP sessions 
>for more than 15 minutes. We need not re-authenticate if the user did 
>an activity in at least one of the SP sessions in the last 15 minutes.

I understand the general case and that's what I responded to. Scott's responses were relevant to the general case as well.

You use the phrase "activity on any associated SP sessions". I assume you mean "activity in my application", but that's not terribly important unless you have some specific implication of the term "associated SP sessions".


But in any case, your SP's session can be controlled exactly as you seem to want. Scott gave reference to the settings (idle timeout and max lifetime) in his first reply. From your application's point of view, presuming that you've set things up as you seem to intend, this would meet your needs. 

If by "forced to re-authenticate" you mean "get a new assertion from the IdP", you are now done.


If by "forced to re-authenticate" you mean "*should* be asked to re-enter his/her username and password" you can configure the SP to request "ForceAuthn". From a protocol standpoint, adding forceauthn="true" to the SP's AuthN request is what you need. If your responsibility is to make it clear that this is the behavior you want, then you are (arguably) done once you add that forceauthn element. 


If by "forced to re-authenticate" you mean "I need to be able to show in an auditable way that every user is actually prompted to re-enter his/her username and password", then you get into "that can of worms" around ForceAuthn Scott referred to, which is what I was replying to. In short, you can tell the IdP what you expect, but IdP installations do not reliably honor the request (or at least not the way you intend they should). The only way to verify that the IdP actually prompts the user under all circumstances is (unfortunately, and unscalably) to validate that the IdP installation(s) you are trusting actually honor your ForceAuthn request, which can only be done by inspecting the IdP. (Technically you should also either require signed requests at the IdP or verify the AuthnInstant in the returned assertion at the SP as well). If you verify all of this you are now, arguably done.


If the IdP does not honor or respond to ForceAuthn correctly, and if you aren't the IdP operator (and thus can't change the operation of the IdP), you are pretty much stuck at this point.


--- Eric



-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Eric Goodman
Sent: Thursday, December 11, 2014 4:04 PM
To: Shib Users
Subject: RE: Shibboleth session vs Application session

>Unless you mean the IdP, but that's much more complicated, now you're 
>talking about SSO and those implications. That doesn't comport with any 
>kind of control at the SP end. If you need that kind of control, you 
>have to use ForceAuthn, and open that can of worms (cue Eric), or it 
>doesn't matter what you do at the SP end.

I keep missing these cues.

Just to clarify what Scott is saying here: Presuming you've timed out the SP session (which the rest of this thread addresses), you only have 2 choices to ensure the user is prompted to relogin:

1) Configure the IdP not to support SSO at all (i.e., disable the PreviousSession hander). 
2) Use the ForceAuthn option in the SP call to the IdP.

Either of these approaches in theory makes the user re-enter their password. But if you absolutely require being sure the user is being prompted to authenticate, this is insufficient. 

Mostly this means that you have to verify IdP relies on some external authentication method which cannot be cached or renewed without the user's involvement. Examples where an IdP could reauthenticate the user without the user seeing a prompt include: SPNEGO authentication, NTLM-over-HTTP authentication and CAS authentication. (A user using a password safe like LastPass or 1password would do this too, but that's completely beyond your control).

So the mechanism you seem to be asking for that forces the user to re-authenticate is there in SAML, but since the IdP doesn't actually perform the authentication it's up to you to verify that the IdP is "doing the right thing". 

--- Eric


--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net