What are sessions in simpleSAMLphp for?

[Jacob Weber]

Can someone explain (or point me to an explanation of) the purpose of sessions in simpleSAMLphp,  both as an SP and an IdP? I thought that SAML was just about authentication, not about maintaining any session state.

Here's where I'm confused. As an SP, when the user tries to log into my site, I do something like:

  $auth = new SimpleSAML_Auth_Simple($authSource);

  $auth->requireAuth();

This presents the IdP's login page to the user. Once he logs in, I establish my application's session.

Now say the user logs out, or my session expires. The next time he tries to log in, it will call requireAuth again. But this time, if the SAML session is still active, it won't show the login page; it will just log in automatically.

I know I can use Single Logout to end the IdP's session. But why is there a session in the first place? Is that part of the SAML protocol, or something specific to simpleSAMLphp?

[Peter Schober]

* Jacob Weber <weber...@gmail.com> [2013-08-14 00:33]:

> I know I can use Single Logout to end the IdP's session. But why is
> there a session in the first place? Is that part of the SAML
> protocol, or something specific to simpleSAMLphp?

For the SP-side, without a session in SSP you'd have to go through an
exchange of SAML protocol messages on every single request to the
protected resource (and/or make SSP unusable with simple resources not
implementing their own session).
For the IdP-side you'll need to maintain state about issued assertions
in case you want to support SLO, for example.
-peter

[Jaime Pérez Crespo]

Not to forget Single Sign On itself. How are you supposed to achieve that if there's no session at all in the IdP?

--

Jaime Pérez

UNINETT / Feide

mail: jaime...@uninett.no

xmpp: ja...@jabber.uninett.no

"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost

[Jacob Weber]

On Aug 14, 2013, at 2:03 AM, Peter Schober <peter....@univie.ac.at> wrote:

> For the SP-side, without a session in SSP you'd have to go through an
> exchange of SAML protocol messages on every single request to the
> protected resource (and/or make SSP unusable with simple resources not
> implementing their own session).
> For the IdP-side you'll need to maintain state about issued assertions
> in case you want to support SLO, for example.

But what if the SP has its own session, and just uses SAML to authenticate? Once I authenticate, I no longer need SSP. But if it has its own session, I have to worry about keeping the two in sync. Is there a way to disable SSP's session? Or would that be a bad idea?

On Aug 14, 2013, at 2:18 AM, Jaime Pérez Crespo <jaime...@uninett.no> wrote:

> Not to forget Single Sign On itself. How are you supposed to achieve that if there's no session at all in the IdP?

What if I want the IdP to always show the login form when the SP asks to authenticate?

This is what I'm trying to do: when you click my app's Login button, it uses SAML to ask the IdP to show a login page. At that point, I'll start my session, and SAML should no longer be involved. If I log out and click Login again, the IdP should show the login page again. It shouldn't remember that you had logged in before. Is that a non-standard use of SAML?

Jacob

[Jaime Pérez Crespo]

Hi,

On Aug 14, 2013, at 17:29 PM, Jacob Weber <weber...@gmail.com> wrote:

But what if the SP has its own session, and just uses SAML to authenticate? Once I authenticate, I no longer need SSP. But if it has its own session, I have to worry about keeping the two in sync. Is there a way to disable SSP's session? Or would that be a bad idea?

No, you don't have to keep them in sync. If you don't want SSP to restore your app session when that one ends, simply set SSP's session to be shorter than the one on your app. But of course there's still the session on the IdP, and as you are not the one authenticating the user, you are not the one to decide about session duration.

What if I want the IdP to always show the login form when the SP asks to authenticate?

Why would you want to do that? You might want the user to re-authenticate in some specific cases, but not always. As I said, how are you supposed to achieve Single Sign On then? And if you don't have/want Single Sign On, then why using SAML?

This is what I'm trying to do: when you click my app's Login button, it uses SAML to ask the IdP to show a login page. At that point, I'll start my session, and SAML should no longer be involved. If I log out and click Login again, the IdP should show the login page again. It shouldn't remember that you had logged in before. Is that a non-standard use of SAML?

At this point you keep thinking locally, as an independent application, not as it being part of something bigger. If you are using SAML for login, you _must_ use SAML for logout. If you implement login through SSP, delegating authentication to an external IdP, you can't just logout from your application and hope the rest of the world knows about it. You have to do a Single Log Out.

What you want to do is not only non-standard. It just doesn't make any sense, because at that point you don't need SAML at all if that's what you want.

[Jacob Weber]

On Aug 15, 2013, at 1:25 AM, Jaime Pérez Crespo <jaime...@uninett.no> wrote:

> At this point you keep thinking locally, as an independent application, not as it being part of something bigger. If you are using SAML for login, you _must_ use SAML for logout. If you implement login through SSP, delegating authentication to an external IdP, you can't just logout from your application and hope the rest of the world knows about it. You have to do a Single Log Out.

Hi Jaime. Thanks for your response. It is indeed possible that I've completely misunderstood the purpose of SAML, and shouldn't be using it.

I guess I was looking for something that allows me to share an identity with another site, rather than sharing a session with them. If SAML doesn't support that, than I should probably look elsewhere. (Any suggestions?)

What confuses me, though, is that SAML doesn't specify certain things that would seem important for a shared session. I don't see anything in the protocol about keeping one session alive as long as the other is alive. (It's not just a matter of giving them the same length, since a session's length could be extended due to user activity.) And if one session expires, there's no facility for ending the other one. Is this just left up to the implementations?

Jacob

[Tom Scavo]

On Fri, Aug 16, 2013 at 10:18 AM, Jacob Weber <weber...@gmail.com> wrote:
>
> What confuses me, though, is that SAML doesn't specify certain things that would seem important for a shared session. I don't see anything in the protocol about keeping one session alive as long as the other is alive. (It's not just a matter of giving them the same length, since a session's length could be extended due to user activity.) And if one session expires, there's no facility for ending the other one. Is this just left up to the implementations?

That's a keen observation, and yes, many people think SAML missed the
boat with respect to session management. A newer SSO protocol called
OpenID Connect attempts to correct that, but OIDC is rather immature
at this point so only time will tell if that pans out.

Tom

[Peter Schober]

* Jacob Weber <weber...@gmail.com> [2013-08-16 16:18]:

> I guess I was looking for something that allows me to share an
> identity with another site, rather than sharing a session with
> them.

There's no session sharing in SAML. In the most common case the HTTP
User Agent trades a forms-based authentication for an HTTP Cookie at
the SAML IdP (which provides WebSSO alone) and trades SAML assertions
issued by the IdP for further HTTP Cookies at each SP (in order to
avoid a full roundtrip on each access to proteced resources). Each of
these sessions (corresponding to each HTTP Cookie, and scoped to the
issuing FQDN) are different and fully independend.
-peter

[Jacob Weber]

On Aug 16, 2013, at 8:17 AM, Peter Schober <peter....@univie.ac.at> wrote:
> There's no session sharing in SAML. [...] Each of these sessions [...] are different and fully independent.

So if I understand correctly, the SP's session is more of a cache. If it expires, that doesn't mean that the user needs to log in again; it just means that it needs to go back to the IdP to check. As long as the IdP's session is still active, it will send back the same assertion.

Then it's the IdP's session that really controls the length of time until the user needs to log in again, right? The SP has no control over that. So the IdP is providing not just identity, but the length of time that the identity is valid.

If this is correct, then:

- If the IdP's session expires, it needs to send a Single Logout request to the SP, to invalidate its session. Otherwise the SP could continue to work until its session expires. How would you handle this situation using SSP? It seems like this would need to be a server-to-server call, since the browser might not be making any requests to the IdP.

- But if the SP's session expires, it doesn't need to do a Single Logout. The next time you hit a protected resource on the SP, it will just re-authenticate with the IdP.

BTW, in SSP, are the sessions a fixed duration, or are they extended as long as they're being used?

Thanks for helping me out here.
Jacob

[Jason Haar]

On 17/08/13 04:33, Jacob Weber wrote:
> So if I understand correctly, the SP's session is more of a cache. If
> it expires, that doesn't mean that the user needs to log in again; it
> just means that it needs to go back to the IdP to check. As long as
> the IdP's session is still active, it will send back the same assertion.

Yes. You can (non-SLO) logout of a SP, and when you try to login again,
you will "magically" be logged in without the user noticing the IdP was
involved, as the IdP session was still valid. If the SP developers are
smart, they should set their SP session expiry to the same time as the
IdP - so the two logout events are synchronized - but that's their choice.

> Then it's the IdP's session that really controls the length of time
> until the user needs to log in again, right? The SP has no control
> over that.

Weeelll... You are correct in that if the IdP session expires, the user
cannot log into a fresh SP without fully reauthenticating. But - the SP
can *be coded* to allow a successful SAML login event to give out a 1000
year SP cookie if it so chooses. So in that situation, the fact that an
IdP session has expired has no affect on the users access to that SP.

In fact, we see that all the time with Mobile apps with apparent SAML
support. The *usability* issue with mobile apps means that they are all
designed so that having to type in passwords is an anathema, so even
when they support SAML, it's all about validating the authentication,
then giving out a 1000 year cookie (otherwise known as OAUTH) and never
talking to the IdP again. Totally ruins one of the primary reason
enterprises want to use SSO technology: namely that when an employee
leaves, an enterprise wants them to NOT be able to access any of the
company-supplied apps any more. So they disable/delete their account,
and indeed the ex-employee cannot login via their web browser any more -
but the mobile version of that same app *keeps working* (so far our
experience has shown this to be 100% true :-(

> So the IdP is providing not just identity, but the length of time that
> the identity is valid. If this is correct, then: - If the IdP's
> session expires, it needs to send a Single Logout request to the SP,
> to invalidate its session. Otherwise the SP could continue to work
> until its session expires. How would you handle this situation using
> SSP? It seems like this would need to be a server-to-server call,
> since the browser might not be making any requests to the IdP. - But
> if the SP's session expires, it doesn't need to do a Single Logout.
> The next time you hit a protected resource on the SP, it will just
> re-authenticate with the IdP. BTW, in SSP, are the sessions a fixed
> duration, or are they extended as long as they're being used? Thanks
> for helping me out here. Jacob

None of that is part of the SAML spec, so it just doesn't happen. For
one thing, the IdP doesn't talk to anyone - it's all Browser initiated.
SAML solves centralized authentication for web applications - that's it.
It doesn't handle provisioning or deprovisioning, and barely handles
SLO. In fact, our small usage of SAML so far has shown that SLO doesn't
even work - no commercial SP we've used so far supports SLO and in fact
one of them (Box) is so broken that we had to DISABLE the SLO button
just to stop users complaining. eg if you are logged into 3 SPs
(SP1,Box,SP3) and Box.net errors when you try to SLO, you never get to
"SP3" as your browser stops hopping at the error. ie you end up logged
out of SP1 only. As usual, the sad thing is the open source SPs I've
tried all support SLO - probably because the authors are on this list :-)

As far as setting expiry times, they are definitely configurable with
SSP and are documented in config/config.php

--
Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +1 408 481 8171
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

[Tom Scavo]

On Fri, Aug 16, 2013 at 11:32 PM, Jason Haar <Jason...@trimble.com> wrote:
>
> In fact, we see that all the time with Mobile apps with apparent SAML
> support. The *usability* issue with mobile apps means that they are all
> designed so that having to type in passwords is an anathema, so even
> when they support SAML, it's all about validating the authentication,
> then giving out a 1000 year cookie (otherwise known as OAUTH) and never
> talking to the IdP again. Totally ruins one of the primary reason
> enterprises want to use SSO technology: namely that when an employee
> leaves, an enterprise wants them to NOT be able to access any of the
> company-supplied apps any more. So they disable/delete their account,
> and indeed the ex-employee cannot login via their web browser any more -
> but the mobile version of that same app *keeps working* (so far our
> experience has shown this to be 100% true :-(

Interesting (off topic) observations, but no, this is not SAML on
mobile since clearly these are not browser apps. SAML ECP (as opposed
to SAML Web Browser SSO) is a possible solution but I doubt ECP will
have much impact on mobile despite the fact that an updated version of
the ECP spec is winding its way through the OASIS process as we speak.

You mention OAuth in the same breath, and yes, OAuth2 may turn out to
be relevant in the mobile space, in the guise of OpenID Connect (which
is a profile of OAuth2). As I mentioned earlier in the thread, OIDC
fills some other gaps as well. I hope OIDC is successful in the
marketplace but only time will tell.

The deprovisioning problem you speak of is the holy grail of identity
management. Conceptually, OIDC does a good job of separating authn
from authz but that principle is not generally adhered to in practice.
Instead we find that out-of-band provisioning and deprovisioning is
all the rage today (ala SCIM).

Tom

[Jacob Weber]

Hi Jason,

On Aug 16, 2013, at 8:32 PM, Jason Haar <Jason...@trimble.com> wrote:

> Yes. You can (non-SLO) logout of a SP, and when you try to login again,
> you will "magically" be logged in without the user noticing the IdP was
> involved, as the IdP session was still valid. If the SP developers are
> smart, they should set their SP session expiry to the same time as the
> IdP - so the two logout events are synchronized - but that's their choice.

But wouldn't the SP's session be extended as long as you're using it? Or do you mean it should expire after a fixed period of time, regardless of use?

> None of that is part of the SAML spec, so it just doesn't happen. For
> one thing, the IdP doesn't talk to anyone - it's all Browser initiated.
> SAML solves centralized authentication for web applications - that's it.
> It doesn't handle provisioning or deprovisioning, and barely handles
> SLO. In fact, our small usage of SAML so far has shown that SLO doesn't
> even work

So if SLO doesn't work, how are people dealing with this in real-world uses of SAML? What does an SP do if the user tries to log out? Ending the SP's session alone won't do anything, since it will just log you back in on the next request. Do SPs just not allow users to log out at all?

Thanks,
Jacob

[Jason Haar]

On 19/08/13 06:18, Jacob Weber wrote:
> But wouldn't the SP's session be extended as long as you're using it?
> Or do you mean it should expire after a fixed period of time,
> regardless of use?

You missed my point. You can't ask anyone on this list how some random
web application - that just happens to have SAML bolted onto it - is
designed to handle sessions. That's 100% it's responsibility. Maybe it
will take into account the IdP timeout (it is sent that information as
part of the SAML exchange) - but maybe not too.

I have never seen a "native" SAML web application. All "SAML enabled"
webapps I've seen were written with their own internal identity
management system in mind, and then due to commercial pressure bolted on
SAML as an afterthought (and maybe LDAP, OpenID, Facebook, etc). So
issues to do with concepts of "session" are normally hardwired against
the concepts they wanted for their own IDM

> So if SLO doesn't work, how are people dealing with this in real-world
> uses of SAML? What does an SP do if the user tries to log out? Ending
> the SP's session alone won't do anything, since it will just log you
> back in on the next request. Do SPs just not allow users to log out at
> all? Thanks, Jacob

That's basically it. Today, if you want to *guarantee* that an
ex-employee no longer has access to any of the 24 SP's your IdP is
configured to talk to, then you'll need to get 24 SP admins to log into
those 24 SPs and explicitly do something with their account/profile on
that SP. Yup - total PITA.

What we've done is hacked SSP to log to disk every account that uses a
SP, then have an hourly cronjob that upon noticing that an account that
has ever used the IdP doesn't exist anymore, will email the designated
SP admin of every SP that account ever used, notifying them that they
have to manually enter the SP and delete/whatever that account (eww, you
may need to re-read that sentence a few times ;-). Maybe in time some of
this will be automated, but deprovisioning is hard. eg what about file
storage services like Box.net? Do you just want to delete their account?
What happens to all the files they were the owner of? All sorts of
(human) decisions need to be made. I think that's part of the reason
deprovisioning is difficult to come up with a standard for.