Verify if user is still valid on IdP

1,461 views
Skip to first unread message

Vitor Franchi

unread,
Jun 9, 2016, 5:23:48 PM6/9/16
to SimpleSAMLphp
Hi,

I've a running Windows 2012 R2 with ADFS 2.0. And I have a web application on an Ubuntu LAMP server. I'm kind of new to SAML and ADFS so please correct me if I made any wrong assumptions here. I've looked a lot on the internet trying to find what I need with no success.

So I've managed to use SimpleSAMLphp to authenticate users on my web application using the ADFS server. I followed this article:

I can visit my web application login page, I get redirected to the ADFS login page to enter my user credentials, I get back to my login page with SimpleSAML_Session all set and a cookie with the AuthToken. So far so good. But now, looking at the session expire date, I know the authentication will expire in like 24 hours, or when I close my browse. I really don't want the user to have to keep entering user and password credentials everyday. I would like a "Remember Me" option, to keep the user logged in, but also, if the user get's removed from the Active Directory, I want my app to be able to know that the user in question is not valid anymore and thus, must log him out.

I came across the isPassive argument but I didn't understand what it does entirely and I didn't manage to make it work by calling requireAuth(array("isPassive" => true)); on the beginning of the authentication process. [https://groups.google.com/d/msg/simplesamlphp/y71iJi_TJqM/31D3e7UpKgAJ]

Basically what I want to achieve is to have the user enter the user/pass only once on the ADFS login screen, and then he should stay logged in until he is disconnected from the Active Directory or he hits the logout button, even if he closes the browser I want him to come back logged in. Is that possible? Am I talking nonsense?

Thanks in advance.

Peter Schober

unread,
Jun 10, 2016, 7:18:53 AM6/10/16
to SimpleSAMLphp
* Vitor Franchi <naoten...@gmail.com> [2016-06-09 23:23]:
> So I've managed to use SimpleSAMLphp to authenticate users on my web
> application using the ADFS server. I followed this article:
> http://www.lewisroberts.com/2015/09/06/integrating-simplesamlphp-with-adfs-2012r2/

JFYI, not that it relates to your question or that it's our job to
correct someone else's "documentation":

Step 10 in "Create the Relying Party Trust in ADFS 2012R2" configures
your MS-ADFS to assert the "UPN" attribute as a transient NameID.
That's not appropriate (see the SAML spec on what transient NameIDs
really are) and it's also not correct that this "is required to allow
SimpleSAMLphp to talk with ADFS."
While SSP currently has a bug in this area (it fails when no NameID is
available), it can work with any kind of NameID. There's no
requirement to use transients, and UPN is not a "transient" value.

> But now, looking at the session expire date, I know the
> authentication will expire in like 24 hours, or when I close my
> browse. I really don't want the user to have to keep entering user
> and password credentials everyday.

That's very unusual. Most are satisfied with SSO sessions (on the IDP)
lasting, say, a business day (e.g. 8h) and having SP sessions much
shorter.

And unless the IDP prevents this (by putting a cap on the SP's maximum
session duration) you can have quite long-lived sessions on the SP,
too. (E.g. in the past I had a special kind of SP where sessions
lasted a whole week.)

> I would like a "Remember Me" option, to keep the user logged in, but
> also, if the user get's removed from the Active Directory, I want my
> app to be able to know that the user in question is not valid
> anymore and thus, must log him out.

That's not how session (based on HTTP Cookies) on the web work, or how
SAML works generally. Whether an object representing a person still
exists in LDAP has no bearing on existing sessions or cookies (but
maybe your SAML IDP implementation works differently).

> I came across the isPassive argument but I didn't understand what it
> does entirely

isPassive can be used to test whether the subject's browser still has
an active SSO session at the IDP, not whether the subject exists in
some data store. If your SAML IDP (MS-ADFS) performs administrative
logout of the IDP/SSO session when a person's object is removed from
LDAP then yes, it would do what you'd expect it to.
You'd still have to cycle the subject's browser through the IDP and
back in order to test whether the subject's browser still has an
active SSO session at the IDP or not. So it is disrupting the use of
the protected resource, something you'd want to consider when deciding
how often you'd like to initiate SSO with isPassive set.

isPassive also won't work the way you want if you have short-lived SSO
sessions at the IDP and want long-lived sessions at the SP: Most of
the time the subject would return with a SAML2 error message informing
your SAML SP that no session was found -- and since you're trying to
conflate "valid session exists at the IDP" with "person object exists
in the LDAP store used by the IDP" you wouldn't be able to tell
whether my SSO session at the IDP just expired, or whether I had left
the company.

-peter

Fiscal

unread,
Jun 13, 2016, 6:08:44 PM6/13/16
to simple...@googlegroups.com
Hi peter,

Thanks for the reply. So I can make the session last longer on the SP side, and the IdP is keeping the session alive for 24 hours (I think), it's certainly 1+ day. 

As far as I understood by your answer, everytime the IdP session expires the user must type his login credentials on the IdP screen, so the IdP creates a new session if the user is authorized on the Active Directory, right? Usually, even if the user is removed from the Active Directory, as long as the IdP session is alive, the user will be authorized on the IdP side, correct?

Isn't there a way to tell the IdP to refresh the session? For example, send the IdP the SAML Authorization Token, then the IdP checks with the Active Directory if the user related to that token is still valid, finally it refreshes the authorization with a new token or whatever extending the session time.

Just to clarify, what I'm trying to achieve is a login process similar to Facebook, but using ADFS. As long as you have that hash saved on your cookie, you will be granted access to the application. Under the hood the application may do all sorts of things to keep verifying if that hash is still valid on the servers.

Regards,
--
vfranchi


--
You received this message because you are subscribed to a topic in the Google Groups "SimpleSAMLphp" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/simplesamlphp/oINWJPDC0Cw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to simplesamlph...@googlegroups.com.
To post to this group, send email to simple...@googlegroups.com.
Visit this group at https://groups.google.com/group/simplesamlphp.
For more options, visit https://groups.google.com/d/optout.

Peter Schober

unread,
Jun 13, 2016, 6:31:51 PM6/13/16
to simple...@googlegroups.com
* Fiscal <naoten...@gmail.com> [2016-06-14 00:08]:
> Thanks for the reply. So I can make the session last longer on the
> SP side, and the IdP is keeping the session alive for 24 hours (I
> think), it's certainly 1+ day.

Not sure that's a question or a description of how your imlemetation
currently works.
A SAML IDP can put a maximum limit on the SP session, but I can't tell
you whether your IDP does that wrt your SP. If that's not the case the
SP session can life (much) longer than the SSO session at the IDP.

> As far as I understood by your answer, everytime the IdP session expires
> the user must type his login credentials on the IdP screen

Only if the SAML SP's (and possibly the application's) session was
meanwhile expired AND the subject continues to send requests to the
protected resource (and the SAML SP is configured to intercept them).
The login at the IDP must be triggered by something, the IDP knows
nothing about what the subject does at the SP and vice versa: The fact
that the SSO session at the IDP expired has no practical consequence
if the subject can continue using the SP, i.e. that won't trigger a
redirect to the IDP for authentication.

> so the IdP creates a new session if the user is authorized on the
> Active Directory, right? Usually, even if the user is removed from
> the Active Directory, as long as the IdP session is alive, the user
> will be authorized on the IdP side, correct?

I cannot tell you whether that's how MS-ADFS works or not. A SAML IDP
that works independently of an LDAP directory server will create a
session in its session store (and hand out cookies referencing those
sessions), and those sessions will not magically be invalidated by
changed in the LDAP directory server.
Maybe they will in MS-ADFS, no idea.

> Isn't there a way to tell the IdP to refresh the session? For
> example, send the IdP the SAML Authorization Token, then the IdP
> checks with the Active Directory if the user related to that token
> is still valid, finally it refreshes the authorization with a new
> token or whatever extending the session time.
>
> Just to clarify, what I'm trying to achieve is a login process
> similar to Facebook, but using ADFS. As long as you have that hash
> saved on your cookie, you will be granted access to the
> application. Under the hood the application may do all sorts of
> things to keep verifying if that hash is still valid on the servers.

I have no idea what you're asking here. SimpleSAMLphp (like
Shibboleth, for example) implements standard protocols,
e.g. SAML. SimpleSAMLphp also implements suport for other
protocols. Details about those depend on what you mean/want.

I cannot tell you how to use SimpleSAMLphp to make your MS-ADFS system
behave like Facebook (whatever that means in detail), if that was a
proper question, and one you were after.

I don't know what protocols Facebook implements (some non-standard
version of OpenID Connect or Oauth2, possibly?) or what protocols
MS-ADFS supports or what any of this has to do with this list.

If you're asking whether you can invent your own security protocol
using parts of SimpleSAMLphp code, then the answer is yes, certainly,
as long as you adhere to the software license requirements.
-peter
Reply all
Reply to author
Forward
0 new messages