Re: programmatically login

[Thijs Kinkhorst]

Hi oblivion,

On Wed, 6 Mar 2013 07:44:44 -0800 (PST), oblivion <recalc...@web.de>
wrote:
> We are using a proprietary sso solution which we cannot turn off at this

> moment, so it has to run in parallel with simplesamlPHP.
>
> The idea is that right after having logged in via the proprietary
> sso-method I would programmatically add the necessary saml-credentials
and
> redirect the user to the principal by hand.

Is it not possible to implement the proprietary SSO product as a
simpleSAMLphp authsource?


--
Thijs Kinkhorst <th...@uvt.nl> – LIS Unix

Universiteit van Tilburg – Library and IT Services
Bezoekadres > Warandelaan 2 • Tel. 013 466 3035 • G 236

[Peter Schober]

* oblivion <recalc...@web.de> [2013-03-06 16:45]:

> We are using a proprietary sso solution which we cannot turn off at this
> moment, so
> it has to run in parallel with simplesamlPHP.
>
> The idea is that right after having logged in via the proprietary
> sso-method I would programmatically add the necessary saml-credentials and
> redirect the user to the principal by hand.

A principal is an authenticated subject, or more generally, a "user",
at least in my view. Not sure what you mean by that.

If you have an existing SSO system in place (and need to authenticate
to SAML-based SPs, which you didn't say but I'm assuming to be the
reason you're here) it's rather easy to set up SSP with a custom
authsource (based on the example auth source External, part of the
exampleauth module) and defer the actual authentication to your SSO
system.
SSP will then become a client in your SSO system and provide SSO to
any and all connected SAML SPs, seamlessly.

> The SP is located on the same machine as the principal, the IdP is
> located on the machine where the user logs in via the proprietary
> sso-method.

I'm sorry, I don't understand any of this. For "principal" see above
(You seem to mean "resource" or "application" when you write
"principal", yes?). And I doubt the users log in on the very machine
the IdP runs in?
-peter

[oblivion]

Thanks for pointing me in the right direction.

My use case is very simple:

1. The user navigates to an existing login-page where he enters his credentials.
2. The existing sso solution authenticates him and just refreshes the page, displaying links to various applications.

This functionality needs to stay untouched, all we need to to is pass the successfully-authenticated user to the IdP.

I have created a custom AuthProvider using the exampleauth-module.
My problem is that I do not know how to integrate the SP->IdP->Application flow WITHOUT redirecting the user to the authentication page defined in the exampleauth-module: As the user has already manually navigated to the login-page and successfully logged in via the old SSO-method we simply need to add him to the Idp - NO need to authenticate anymore.

So maybe there exists some functionality similar to the following pseudo-code:

// user has successfully logged in using the already existing SSO method
// now we need to set up the necessary saml-stuff:

SimpleSAML_Auth_Source::magically_add_user_to_idp(username);
refreshPage();

That's it.

As you can see I simply need to inject an ALREADY AUTHENTICATED user into the IdP so that any SP talking to it will get a positive response.

Thanks for any hints!

[Peter Schober]

* oblivion <recalc...@web.de> [2013-03-07 12:40]:

> I have created a custom AuthProvider using the exampleauth-module.
> My problem is that I do not know how to integrate the SP->IdP->Application
> flow WITHOUT redirecting the user to the authentication page defined in the
> exampleauth-module: As the user has already manually navigated to the
> login-page and successfully logged in via the old SSO-method we simply need
> to add him to the Idp - NO need to authenticate anymore.

I thought it could go something like this:

The subject tries to access the SAML SP, the SAML SP requires authN at
your SAML IdP, your SAML IdP requests authentication from your
external authsource (which is your existing SSO system) and your
existing SSO system provides "SSO" to the subject, probably based on
an HTTP Cookie and a session at the service.
No re-authentication requierd. Is that any clearer?
-peter

[oblivion]

Yes, thanks for the explanation.
I am now wondering how does the subject access the SP when they both reside on different hosts/machines?

Does the subject/application have to reside on the same machine as the SP?

That would imply that 10 applications on 10 different servers would demand 10 SPs to be setup and configured?

[Peter Schober]

* oblivion <recalc...@web.de> [2013-03-07 14:03]:

> Yes, thanks for the explanation.
> I am now wondering how does the subject access the SP when they both reside
> on different hosts/machines?
> Does the subject/application have to reside on the same machine as the SP?
> That would imply that 10 applications on 10 different servers would demand
> 10 SPs to be setup and configured?

Yes (unless you decide to hide all that behind a proxy, as Dick will
surely point out ;)
To deploy at scale you can use tools (version control systems,
configuration management systems like puppet or cfeingine, etc.), as
usual.
-peter

[oblivion]

Now I am wondering how the user-credentials coming from the post-array are preserved after the SP has forwarded to the IdP?

Again, the user navigates to an existing login-page where he enters his credentials.

Then we pass responsibility to the SP which contacts the Idp and the already posted login-data is gone.

Does this imply that the login-page has to lie on the IdP's host?

How do you integrate existing web-pages then without having to tear them apart?

[Jaime Pérez Crespo]

Hi,

On Mar 7, 2013, at 19:30 PM, oblivion <recalc...@web.de> wrote:

Now I am wondering how the user-credentials coming from the post-array are preserved after the SP has forwarded to the IdP?

Again, the user navigates to an existing login-page where he enters his credentials.

Then we pass responsibility to the SP which contacts the Idp and the already posted login-data is gone.

Does this imply that the login-page has to lie on the IdP's host?

The whole point of SAML and other similar identity protocols is to decouple authentication from the final applications. The usual relying parties are a Service Provider (SP) and an Identity Provider (IdP). The names are quite explicit, but anyway, the authentication process is of course the IdP's responsibility.

What this means is that you, as an SP, will completely forget about user authentication and you may just keep local information related to the users, but no credentials at all. Whenever you need an user to authenticate, you will ask an IdP to do it for you (by means of a SAML request), and the IdP will gather the user's credentials (whichever they are) and verify them. Therefore, an SP will never handle usernames and passwords.

How do you integrate existing web-pages then without having to tear them apart?

If you already have a login form, for instance, you have to get rid of it (at least for federated access) and substitute it with a call to the authenticate() method of SimpleSAMLphp, which will do the magic for you. It may sound strange at first that you have remove your own login form, but you cannot expect users from institution X to put their institutional credentials in a web form of your own.

Regards,

--

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

[oblivion]

Thanks for your input, everythings clear now.

On Wednesday, March 6, 2013 4:44:44 PM UTC+1, oblivion wrote:

Hi,

We are using a proprietary sso solution which we cannot turn off at this moment, so
it has to run in parallel with simplesamlPHP.

The idea is that right after having logged in via the proprietary sso-method I would programmatically add the necessary saml-credentials and redirect the user to the principal by hand.

I am not sure how to do this though. Maybe I would have to fake the SP?

The SP is located on the same machine as the principal, the IdP is located on the machine where
the user logs in via the proprietary sso-method.

Would such a thing be possible, and if so could you point me to some example code if that exists?

Thanks in advance,

oblivion

[Peter Schober]

* oblivion <recalc...@web.de> [2013-03-07 19:30]:

> Now I am wondering how the user-credentials coming from the
> post-array are preserved after the SP has forwarded to the IdP?

Credentials should not have been requested/entered at the SP.

> Again, the user navigates to an existing login-page where he enters his
> credentials.

You can do that, but you don't have to. Either the login is just to
make available the list of SPs (and users could have just as well
accessed them directly) or you use that list of resources with special
links, initiating the SAML flow at the IDP by sending an unsolicited
response to the SP.
If the links are just ordinary links to the resource the SAML
implementation at the SP will prevent access, redirect to the IDP
which will defer authentication to your existing WebSSO, after the
login there access to the IDP will be granted and the IDP will issue
the response to the SP.

So if you need or want to start everything at some portal (the much
mentioned existing login-page) which presents links to the resources
the IdP-initiated flow is a bit simpler. If people bookmarking the
resource/application should also work, the flow at the SP, as is
standard with SAML.

> Does this imply that the login-page has to lie on the IdP's host?

Yes. Only in your case it is at your exising SSO system, to which your
IDP could be another SSO "client", not at the IDP itself (since you
said you want SSO with you existing SSO system).

> How do you integrate existing web-pages then without having to tear them
> apart?

You can't. (Standards-based cross-domain SSO, where resources never
see the users' credentials does come at a price.)

How much actual tearing-appart is needed varies widely and the work
needed for each application is different. Applications written in PHP
could be changed to use SimpleSAMLphp or use webserver integration.
Others could use other API/code-level integration toolkits (OIOSAML,
Spring Security, etc.) or rely on integration via the webserver (for
httpd there are at least mod_authmemcookie, mod_mellon, Shibboleth),
which has the advantage of not making the changes to the application
specific to the SAML implementation (i.e., you can swap out one for
another without disrupting changes to the app).
Properly designed applications will often allow to externalize
authentication via the webserver out of the box (i.e., with
configuration and not coding). For tighter integration, which means
authorization and maybe groups management, you will often have to have
to set up other stuff around the application or change the application
itself. It all depends.
-peter