SimpleSAMLphp authentication without user input

[jharf...@toonboom.com]

I'm using SimpleSAMLphp as an IdP to offer SSO into some sites and I've built a little application on top of the IdP to manage users. In one scenario, right after we create a user we need to authenticate that new user and redirect back to a third application (or SP). 

Is there a way to securely authenticate a specific user without needing them to manually input their username and password ? 

I've experimented with some solutions but they're a bit hacky and I'm sure SAML has to have a way to deal with that use case. 

I'm using SQL on the IdP as an authsource

[Peter Schober]

* jharf...@toonboom.com <jharf...@toonboom.com> [2016-03-24 20:46]:

Using a custom authsource you can SSO them into your IDP (I did this
years ago to bootstrap a session from httpd's REMOTE_USER).
But that doesn't deal with the additional issue of doing this only
sometimes (when the account is being set up) but not at other times
(during ordinary SSO to other SPs).
-peter

[jharf...@toonboom.com]

Using a custom authsource you can SSO them into your IDP (I did this
years ago to bootstrap a session from httpd's REMOTE_USER).
But that doesn't deal with the additional issue of doing this only
sometimes (when the account is being set up) but not at other times
(during ordinary SSO to other SPs).
-peter

Thanks, I didn't know about REMOTE_USER. But I can't set that from php though, can I ? 

[Nate Klingenstein]

Is there a way to securely authenticate a specific user without needing them to manually input their username and password ? 

I've experimented with some solutions but they're a bit hacky and I'm sure SAML has to have a way to deal with that use case. 

My understanding is that SAML originally intended to deal with that use case with the NameID signaling that could be placed into AuthnRequests, but that really never took off in deployment.  There are similar implementations popping up in the wild with other protocols such as WS-*, but it’s typically indicative, not trusted.

My generic answer is that services generally perform enforcement on the response, so the request is only used as a way to indicate desired behavior that will lead most probably to an acceptible response.  Most authentication requests aren’t signed or tethered to a particular client.

If a service has enough knowledge of its user base that it can request the authentication of a specific user without asking the user to input credentials, I would usually consider the service to be highly trusted and effectively part of the same domain as the identity provider.  If you just want to signal “don’t prompt for authentication”, that’s an AuthnContext of your choosing or “isPassive=true”.

But, this use case has arisen frequently enough that I could see profiling this capability in a specification for SAML for general use.

[jharf...@toonboom.com]

If a service has enough knowledge of its user base that it can request the authentication of a specific user without asking the user to input credentials, I would usually consider the service to be highly trusted and effectively part of the same domain as the identity provider.  If you just want to signal “don’t prompt for authentication”, that’s an AuthnContext of your choosing or “isPassive=true”.

How do you identify which user to authenticate when using isPassive=true ? 

[Garry Booth]

Assuming the user has authenticated to the machine via Kerberos, SPNEGO, should be OK? Or have I misunderstood the question

--
You received this message because you are subscribed to the Google Groups "SimpleSAMLphp" group.
To unsubscribe from this group and stop receiving emails from it, 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.

[jharf...@toonboom.com]

No the user hasn't authenticated yet, I want to authenticate the user, on the same domain, without their input

[Garry Booth]

Ah ok, sorry. How do you know the user is the user then, without some form of TGT. Or do you not care about the user, just where they come from?

[Garry Booth]

If your trying to restrict access to a resource within a domain, to just users in that domain. Why use an IdP. Just set access to IP and be done with. You seem to be trying to break how an IdP works, rather than looking at how security could work.

[Peter Schober]

* jharf...@toonboom.com <jharf...@toonboom.com> [2016-03-28 17:55]:

> > Using a custom authsource you can SSO them into your IDP (I did this
> > years ago to bootstrap a session from httpd's REMOTE_USER).
> > But that doesn't deal with the additional issue of doing this only
> > sometimes (when the account is being set up) but not at other times
> > (during ordinary SSO to other SPs).
>

> Thanks, I didn't know about REMOTE_USER. But I can't set that from php
> though, can I ?

That's totally irrelevant to your case. To PHP REMOTE_USER is just a
variable to check (e.g. the superglobal $_SERVER['REMOTE_USER']).
My point was that you can create a valid session at the IDP based on
*something* *else*, e.g. a record in an RDBMS, the presence of a
specific HTTP Cookie, some environment variable in the web server,
etc.
By defining a (secure) procedure how to carry over the "logged in"
status of someone accessing your IDP, and evaluating that in a custom
authsource you can get SSO into your SSP IDP, without explicit
authenticiation at your IDP.

Personally I'm not sure doing that is worth it, as you'd still have to
hack around the case that this should only happen on the first login
(or in other special circumstances), so it would need to fail
gracefully, which I don't think is possible without duplicating code
from other authsources. (The technical question being whether you can
fall back to another authsource from within your own custm
authsource. I don't know the answer to that.)
-peter