Version 14.x an no www/auth/login-xxx.php anymore?

[Harald Hannelius]

Is it so that reading custom login-code from www/auth/login-xxx.php doesn't
work anymore with version 14 and up? It has to be re-written using
exampleauth/lib/Auth/Source/External.php?

Our scenario is an ADFS IdP and a simplesamlphp IdP that has it's login-page
authenticated against the ADFS IdP.

The user goes to a SP, gets redirected to the simplesamlphp IdP. The
login-page on simplesamlphp IdP in turn redirects the user to the ADFS Idp.
Upon returning from ADFS, the simplesamlphp IdP retrieves attributes from
LDAP for $uid, asks consent and redirects the user to the SP.

Does anyone have code for this?

--

Harald Hannelius | harald.hannelius/a\arcada.fi | +358 50 594 1020

[Peter Schober]

* Harald Hannelius <harald.h...@arcada.fi> [2018-05-08 14:44]:

> Our scenario is an ADFS IdP and a simplesamlphp IdP that has it's
> login-page authenticated against the ADFS IdP.
>
> The user goes to a SP, gets redirected to the simplesamlphp IdP. The
> login-page on simplesamlphp IdP in turn redirects the user to the
> ADFS Idp. Upon returning from ADFS, the simplesamlphp IdP retrieves
> attributes from LDAP for $uid, asks consent and redirects the user
> to the SP.
>
> Does anyone have code for this?

SimpleSAMLphp should support that out of the box (depending on what
specific SSO protocol you want to use between MS-ADFS as IDP and SSP
as SP, of course).

If lack of SAML SLO propagation isn't an issue for you then you'd
simply activate a SAML SP on your SSP instance (as per the
documentation) and configure that to use the MS-ADFS instance as its
(only) IDP. Then make the SSP SP the authsource for your SSP IDP.

-peter

[Harald Hannelius]

Yes, I had this working in SimpleSamlPHP 13.x. I was using a self-written
www/auth/login-adfs.php that A) called upon the ADFS to authenticate the
user and B) dig out attributes from OpenLDAP for the user found in the
attributes returned by ADFS.

This code stopped working when I tried with setting up a new IdP with SSP
14.x. It looks like www/auth/* is deprecated.

It looks like I'd have to re-write the code into a class using
exampleauth/lib/Auth/Source/External.php as a template?

I have it semi-working using the UserPass.php template modified to call upon
authentication from ADFS but SSP presents a login-page with login/password
form before redirecting to ADFS. Is it possible to bypass this
login/password-form?

[Jaime Perez Crespo]

Hi Harald,

On 9 May 2018, at 08:39 AM, Harald Hannelius <harald.h...@arcada.fi> wrote:
> Yes, I had this working in SimpleSamlPHP 13.x. I was using a self-written
> www/auth/login-adfs.php that A) called upon the ADFS to authenticate the user and B) dig out attributes from OpenLDAP for the user found in the attributes returned by ADFS.

You don’t need to do any of that, as Peter was saying. Configure the ADFS as an IdP for your SP, and just use the SAML SP authentication source. If you want to add extra attributes from an LDAP server for every user, you can use the ldap:AttributeAddFromLDAP authproc filter:

https://simplesamlphp.org/docs/stable/ldap:ldap

> This code stopped working when I tried with setting up a new IdP with SSP 14.x. It looks like www/auth/* is deprecated.

Don’t do that. The last stable version is 1.15.4. There are plenty of bug fixes, and even worse, security fixes (some of them critical) between 1.14 and 1.15. Make sure you always update your installation to the last version.

Regarding www/auth/*, yes, those are not only deprecated but gone.

> It looks like I'd have to re-write the code into a class using exampleauth/lib/Auth/Source/External.php as a template?

You don’t need a custom authentication source, as I said. But in case you need one, you should use whatever fits best your scenario.

> I have it semi-working using the UserPass.php template modified to call upon authentication from ADFS but SSP presents a login-page with login/password form before redirecting to ADFS. Is it possible to bypass this login/password-form?

Well, if you use a custom auth source based on the UserPass base class, it kind of makes sense that it asks you for a username and password, right?

—
Jaime Pérez
Uninett / Feide

jaime...@uninett.no
jaime...@protonmail.com
9A08 EA20 E062 70B4 616B 43E3 562A FE3A 6293 62C2

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

[Harald Hannelius]

On Wed, 9 May 2018, Jaime Perez Crespo wrote:

Hi Jaime!

> On 9 May 2018, at 08:39 AM, Harald Hannelius <harald.h...@arcada.fi> wrote:
>> Yes, I had this working in SimpleSamlPHP 13.x. I was using a self-written
>> www/auth/login-adfs.php that A) called upon the ADFS to authenticate the user and B) dig out attributes from OpenLDAP for the user found in the attributes returned by ADFS.
>
> You don’t need to do any of that, as Peter was saying. Configure the ADFS
> as an IdP for your SP, and just use the SAML SP authentication source. If
> you want to add extra attributes from an LDAP server for every user, you
> can use the ldap:AttributeAddFromLDAP authproc filter:

This sounds exactly what I want. And ldap:AttributeAddFromLDAP sounds so
much easier and portable.

But how do I go about using the ADFS as an IdP for the login-page on my SSP
IdP (configured as a service)? What should I put in my saml20-idp-hosted.php
in 'auth'?

> https://simplesamlphp.org/docs/stable/ldap:ldap
>
>> This code stopped working when I tried with setting up a new IdP with SSP 14.x. It looks like www/auth/* is deprecated.
>
> Don’t do that. The last stable version is 1.15.4. There are plenty of bug fixes, and even worse, security fixes (some of them critical) between 1.14 and 1.15. Make sure you always update your installation to the last version.

I'm actually using the version bundled with Debian 9.

>> I have it semi-working using the UserPass.php template modified to call upon authentication from ADFS but SSP presents a login-page with login/password form before redirecting to ADFS. Is it possible to bypass this login/password-form?
>
> Well, if you use a custom auth source based on the UserPass base class, it kind of makes sense that it asks you for a username and password, right?

It obviously does :)

[Peter Schober]

* Harald Hannelius <harald.h...@arcada.fi> [2018-05-09 08:39]:

> On Tue, 8 May 2018, Peter Schober wrote:
> > SimpleSAMLphp should support that out of the box
>

> Yes, I had this working in SimpleSamlPHP 13.x. I was using a self-written

> www/auth/login-adfs.php that [...]

You're not reading what I said. Simply configure your SSP instance as
both a SAML SP and a SAML IDP, as per the documentation for each role.
Then make the SSP SP use your MS-ADFS IDP.
Then make the SSP IDP use the SSP SP as authsource.
No programming.
No external authsource.
Only configuration.
-peter

[Peter Schober]

* Harald Hannelius <harald.h...@arcada.fi> [2018-05-09 12:52]:

> But how do I go about using the ADFS as an IdP for the login-page on
> my SSP IdP (configured as a service)?

Let go of that "login-page" thing, will you.
You add a SAML IDP to SSP exactly the way The Fine Documentation explains.

> What should I put in my saml20-idp-hosted.php in 'auth'?

The name of the authsource of your SAML SP (e.g. "default-sp").

> I'm actually using the version bundled with Debian 9.

Thijs would know but theoretically you should get backported security
fixes. Unless you're sure you do you'd better ascertain that yourself,
though.
-peter

[Harald Hannelius]

On Wed, 9 May 2018, Peter Schober wrote:

> * Harald Hannelius <harald.h...@arcada.fi> [2018-05-09 08:39]:
>> On Tue, 8 May 2018, Peter Schober wrote:
>>> SimpleSAMLphp should support that out of the box
>>
>> Yes, I had this working in SimpleSamlPHP 13.x. I was using a self-written
>> www/auth/login-adfs.php that [...]
>
> You're not reading what I said. Simply configure your SSP instance as
> both a SAML SP and a SAML IDP, as per the documentation for each role.

This I have been doing.

> Then make the SSP SP use your MS-ADFS IDP.

This works too, I am able to log on using default-sp, which redirects me to
ADFS and back to the SP

> Then make the SSP IDP use the SSP SP as authsource.

This is the part I'm not getting or finding in the docs on how to do it.

> No programming.
> No external authsource.
> Only configuration.
> -peter
>
>

[Peter Schober]

* Harald Hannelius <harald.h...@arcada.fi> [2018-05-09 13:17]:

> > Then make the SSP IDP use the SSP SP as authsource.
>
> This is the part I'm not getting or finding in the docs on how to do it.

I already answered that elsewhere in this thread.

Maybe the documentation
https://simplesamlphp.org/docs/stable/simplesamlphp-reference-idp-hosted
could be more clear, though it already states:

auth
Which authentication module should be used to authenticate users
on this IdP.

Since running a proxy is not the normal (or even fully supported,
today) way of using the SSP software I personally wouldn't want to
call too much attention here to the fact that you specifically could
add the name of a SAML SP authsource as the value of that parameter,
making the SSP instance into a proxy.

-peter

[Harald Hannelius]

On Wed, 9 May 2018, Peter Schober wrote:

BINGO! This was the info I didn't understand. Wish I'd got it a few years
back. The solution was much easier than I thought.

May 09 15:43:39 simplesamlphp ERROR [ab3baca655] Backtrace:
May 09 15:43:39 simplesamlphp ERROR [ab3baca655] 0
/usr/share/simplesamlphp/www/module.php:180 (N/A)
May 09 15:43:39 simplesamlphp ERROR [ab3baca655] Caused by: Exception:
core:TargetedID: Missing UserID for this user. Please check the
'userid.attribute' option in the metadata against the attributes provided by
the authentication source.

Now I only have to understand the attributes in AD, and somehow get SSP to
use them.

May 09 15:43:39 simplesamlphp DEBUG [ab3baca655] <AttributeStatement>
May 09 15:43:39 simplesamlphp DEBUG [ab3baca655] <Attribute
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn">
May 09 15:43:39 simplesamlphp DEBUG [ab3baca655]
<AttributeValue>har...@arcada.fi</AttributeValue>
May 09 15:43:39 simplesamlphp DEBUG [ab3baca655] </Attribute>
May 09 15:43:39 simplesamlphp DEBUG [ab3baca655] <Attribute Name="uid">
May 09 15:43:39 simplesamlphp DEBUG [ab3baca655]
<AttributeValue>harald</AttributeValue>
May 09 15:43:39 simplesamlphp DEBUG [ab3baca655] </Attribute>
May 09 15:43:39 simplesamlphp DEBUG [ab3baca655] </AttributeStatement>

I tried mapping upn and
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn to
edupersonprincipalname in the beginning of authproc.idp, but I'm not sure if
I'm really understanding where the proper place to do this would be.

Oh how easy the days when attributes had short names :)

[Tim van Dijen]

When using authproc-filters, consider the following:
- Is the filter specific to an IdP? (i.e. for ADFS you always have to convert http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn to
edupersonprincipalname) > The filter should go in the saml20-idp-remote.php
- Is the filter specific to an SP? (i.e. a certain SP needs this one extra attribute from LDAP, but other SP's don't) > The filter should fo in the saml20-sp-remote.php
- Is the filter generic? (i.e. you always want the consent question, regardless of the SP/IDP) > The filter should go in the global authproc config in config.php

- Tim

Op woensdag 9 mei 2018 14:46:52 UTC+2 schreef Harald Hannelius:

<AttributeValue>harald@arcada.fi</AttributeValue>

[Peter Schober]

* Harald Hannelius <harald.h...@arcada.fi> [2018-05-09 14:46]:

> Oh how easy the days when attributes had short names :)

Not really, because it's mainly the ugliness of the fully qualified
attribute names that saves you from having to support "full name",
"full_name", "fullName", "name", "Name", and so on. :\

Adding an authproc filter that maps fully qualified on-the-wire
ugliness to -- only locally meaningful and therefore simple --
internal names should be the least of the issues on has to deal with
with federated identity management... Let's see how you fare trying to
implement Tim's suggestions.

-peter

[Harald Hannelius]

On Wed, 9 May 2018, Tim van Dijen wrote:

> When using authproc-filters, consider the following:
> - Is the filter specific to an IdP? (i.e. for ADFS you always have to convert
> http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn to
> edupersonprincipalname) > The filter should go in the saml20-idp-remote.php

Thank you, this helps a lot!

That file is auto-generated via config-metarefresh.php. I remember asking
this question earlier too, is there a mechanism to massage the metadata
that is auto-generated. Like adding a 'attributes' to google's metadata
instead of just defaulting to releasing _all_ of them?

I really like the idea of automagically updated metadata, but there would
have to be some kind of post-editing possible that is also automated.

[Harald Hannelius]

On Wed, 9 May 2018, Peter Schober wrote:

> * Harald Hannelius <harald.h...@arcada.fi> [2018-05-09 14:46]:
>> Oh how easy the days when attributes had short names :)
>
> Not really, because it's mainly the ugliness of the fully qualified
> attribute names that saves you from having to support "full name",
> "full_name", "fullName", "name", "Name", and so on. :\

True that. We where previously a SAML 1.3 only IdP. Then a 2.0 and 1.3 IdP
and now only a 2.0 Idp. However, all logic was built around mapping names
oids and stuff back and fourth. I really look forward to having a SAML 2.0
only setup.

> Adding an authproc filter that maps fully qualified on-the-wire
> ugliness to -- only locally meaningful and therefore simple --
> internal names should be the least of the issues on has to deal with
> with federated identity management... Let's see how you fare trying to
> implement Tim's suggestions.

Curious as well, but not tonight anymore.