Active Directory backend: empty attributes when consuming form Shibboleth SP
638 views
Skip to first unread message
Lorenzo Milesi
Jul 19, 2021, 11:59:11 PM7/19/21
to simplesamlphp
Hi.
I've configured an IdP with SimpleSamlPHP with auth against Active Directory, tested with Nextcloud as SP and authenticates correctly. But I had to set sAMAccountName as username field.
Now I'm trying to add Apache2 and mod_shib but I get empty attributes after authentication.
In SSP when I test auth I can see all the returned user information from the IdP, and it has all the AD LDAP entries, with AD field names.
I was trying to "standardize" AD fields to common SSO names, so in metadata/saml20-idp-hosted.php I added:
'authproc' => [
50 => [
'class' => 'ldap:AttributeAddFromLDAP',
'attributes' => ['mail'],
'search.filter' => '(mail=%mail%)',
'authsource' => 'my-ad',
],
51 => [
'class' => 'core:AttributeMap',
'mail' => 'email',
'sAMAccountName' => 'uid',
'cn' => ['name', 'displayName'],
'authsource' => 'my-ad',
],
But I still get AD fields in authentication test and empty attribuets in Shibboleth SP session.
Apologise for the silly newbie question, but how can I "standardize" the data returned by AD to a more generic namespace generally usable?
thanks
OS: Ubuntu 20.04
SimpleSamlPHP: 1.19.1
Shibboleth SP: 3.0.4 (3.0.4+dfsg1-1ubuntu0.1)
--
Lorenzo Milesi - lorenzo...@yetopen.com
CTO @ YetOpen Srl
YetOpen - https://www.yetopen.com/
Via Salerno 18 - 23900 Lecco - ITALY - | 4801 Glenwood Avenue - Suite 200 - Raleigh, NC 27612 - USA -
Tel +39 0341 220 205 - inf...@yetopen.com | Phone +1 919-817-8106 - inf...@yetopen.com
Think green - Non stampare questa e-mail se non necessario / Don't print this email unless necessary
-------- D.Lgs. 196/2003 e GDPR 679/2016 --------
Tutte le informazioni contenute in questo messaggio sono riservate ed a uso esclusivo del destinatario.
Tutte le informazioni ivi contenute, compresi eventuali allegati, sono da ritenere confidenziali e riservate secondo i termini
del vigente D.Lgs. 196/2003 in materia di privacy e del Regolamento europeo 679/2016 - GDPR - e quindi ne e' proibita l'utilizzazione ulteriore non autorizzata.
Nel caso in cui questo messaggio Le fosse pervenuto per errore, La invitiamo ad eliminarlo senza copiarlo, stamparlo, a non inoltrarlo a terzi e ad avvertirci non appena possibile.
Grazie.
Confidentiality notice: this email message including any attachment is for the sole use of the intended recipient and may contain confidential and privileged information;
pursuant to Legislative Decree 196/2003 and the European General Data Protection Regulation 679/2016 - GDPR - any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recepient please delete this message without copying, printing or forwarding it to others, and alert us as soon as possible.
Thank you.
I've configured an IdP with SimpleSamlPHP with auth against Active Directory, tested with Nextcloud as SP and authenticates correctly. But I had to set sAMAccountName as username field.
Now I'm trying to add Apache2 and mod_shib but I get empty attributes after authentication.
In SSP when I test auth I can see all the returned user information from the IdP, and it has all the AD LDAP entries, with AD field names.
I was trying to "standardize" AD fields to common SSO names, so in metadata/saml20-idp-hosted.php I added:
'authproc' => [
50 => [
'class' => 'ldap:AttributeAddFromLDAP',
'attributes' => ['mail'],
'search.filter' => '(mail=%mail%)',
'authsource' => 'my-ad',
],
51 => [
'class' => 'core:AttributeMap',
'mail' => 'email',
'sAMAccountName' => 'uid',
'cn' => ['name', 'displayName'],
'authsource' => 'my-ad',
],
But I still get AD fields in authentication test and empty attribuets in Shibboleth SP session.
Apologise for the silly newbie question, but how can I "standardize" the data returned by AD to a more generic namespace generally usable?
thanks
OS: Ubuntu 20.04
SimpleSamlPHP: 1.19.1
Shibboleth SP: 3.0.4 (3.0.4+dfsg1-1ubuntu0.1)
--
Lorenzo Milesi - lorenzo...@yetopen.com
CTO @ YetOpen Srl
YetOpen - https://www.yetopen.com/
Via Salerno 18 - 23900 Lecco - ITALY - | 4801 Glenwood Avenue - Suite 200 - Raleigh, NC 27612 - USA -
Tel +39 0341 220 205 - inf...@yetopen.com | Phone +1 919-817-8106 - inf...@yetopen.com
Think green - Non stampare questa e-mail se non necessario / Don't print this email unless necessary
-------- D.Lgs. 196/2003 e GDPR 679/2016 --------
Tutte le informazioni contenute in questo messaggio sono riservate ed a uso esclusivo del destinatario.
Tutte le informazioni ivi contenute, compresi eventuali allegati, sono da ritenere confidenziali e riservate secondo i termini
del vigente D.Lgs. 196/2003 in materia di privacy e del Regolamento europeo 679/2016 - GDPR - e quindi ne e' proibita l'utilizzazione ulteriore non autorizzata.
Nel caso in cui questo messaggio Le fosse pervenuto per errore, La invitiamo ad eliminarlo senza copiarlo, stamparlo, a non inoltrarlo a terzi e ad avvertirci non appena possibile.
Grazie.
Confidentiality notice: this email message including any attachment is for the sole use of the intended recipient and may contain confidential and privileged information;
pursuant to Legislative Decree 196/2003 and the European General Data Protection Regulation 679/2016 - GDPR - any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recepient please delete this message without copying, printing or forwarding it to others, and alert us as soon as possible.
Thank you.
Tim van Dijen
Jul 20, 2021, 3:53:24 AM7/20/21
to SimpleSAMLphp
Hi Lorenzo,
Shibboleth will expect attributes prefixed according to the mace-namespace, so for example 'urn:mace:dir:attribute-def:mail' instead of just 'mail' (see /etc/shibboleth/attribute-map.xml).
You can use the AttributeMap-filter you're already using to map ldap-attributes to whatever you need.. There's no easier way to do this. Note that you can use as many AttributeMap-filters as you want.. You can also use it in the SP-metadata if you need to map something specific to the SP.
You can use the AttributeMap-filter you're already using to map ldap-attributes to whatever you need.. There's no easier way to do this. Note that you can use as many AttributeMap-filters as you want.. You can also use it in the SP-metadata if you need to map something specific to the SP.
Best practise is probably to map AD-attributes to some generic standard like mace, and from there map to anything specific for an SP in the SP-metadata.
- Tim
Op dinsdag 20 juli 2021 om 05:59:11 UTC+2 schreef Lorenzo Milesi:
Peter Schober
Jul 20, 2021, 4:37:09 AM7/20/21
to SimpleSAMLphp
* Tim van Dijen <tvd...@gmail.com> [2021-07-20 09:53]:
Profiles, if you can find a copy).
So assuming the OP is not using a protocol superseded over 15 years
ago noone should be using urn:mace attribute names today.
(If anything, the most "standard"[1] name format SAML has is URI
naming with urn:oid attribute names, as you'd get from calling the
name2oid attribute map in SimpleSAMLphp.)
But that's not the question here:
> You can use the AttributeMap-filter you're already using to map
> ldap-attributes to whatever you need.. There's no easier way to do
> this. Note that you can use as many AttributeMap-filters as you
> want..
AFAIU the OP was asking why the shown attribute map entry did not seem
to change anything on the wire ("I still get AD fields in
authentication test").
(Of course the only reliable way to determine the correctness of the
output would be showing the actual attribute statements from the SAML
assertion.)
-peter
[1] OASIS SAML V2.0 X.500/LDAP Attribute Profile,
but also https://saml2int.org/profile/0.2.1/#section7
The new/current saml2int profile also assumes urn:oid names,
though this can only be seen implicitly e.g. in SDP-SP18 (unless
I'm simply missing some generic statement there).
> Shibboleth will expect attributes prefixed according to the mace-namespace,
> so for example 'urn:mace:dir:attribute-def:mail' instead of just 'mail'
> (see /etc/shibboleth/attribute-map.xml).
No, those are only allowed for SAML 1 (cf. the MACE-Dir SAML Attribute
> so for example 'urn:mace:dir:attribute-def:mail' instead of just 'mail'
> (see /etc/shibboleth/attribute-map.xml).
Profiles, if you can find a copy).
So assuming the OP is not using a protocol superseded over 15 years
ago noone should be using urn:mace attribute names today.
(If anything, the most "standard"[1] name format SAML has is URI
naming with urn:oid attribute names, as you'd get from calling the
name2oid attribute map in SimpleSAMLphp.)
But that's not the question here:
> You can use the AttributeMap-filter you're already using to map
> ldap-attributes to whatever you need.. There's no easier way to do
> this. Note that you can use as many AttributeMap-filters as you
> want..
to change anything on the wire ("I still get AD fields in
authentication test").
(Of course the only reliable way to determine the correctness of the
output would be showing the actual attribute statements from the SAML
assertion.)
-peter
[1] OASIS SAML V2.0 X.500/LDAP Attribute Profile,
but also https://saml2int.org/profile/0.2.1/#section7
The new/current saml2int profile also assumes urn:oid names,
though this can only be seen implicitly e.g. in SDP-SP18 (unless
I'm simply missing some generic statement there).
Tim van Dijen
Jul 20, 2021, 5:24:41 AM7/20/21
to SimpleSAMLphp
Technically you may be right Peter, but nobody uses OIDs on a daily basis.. Everyone has the human readable mace-dir attributes as aliases for the OIDs.
Also, the latest SAML2INT is way less specific on this matter..
The OP clearly says that in Shibboleth he ends up with no attributes.. That's because he's not sending them as either mace-urn or oid..
Op dinsdag 20 juli 2021 om 10:37:09 UTC+2 schreef Peter Schober:
Peter Schober
Jul 20, 2021, 5:45:31 AM7/20/21
to SimpleSAMLphp
* Tim van Dijen <tvd...@gmail.com> [2021-07-20 11:24]:
(and have been doing so for almost 1.5 decades) on a daily basis.
Of course proper software implentations (such as SimpleSAMLphp and
Shibboleth) will offer aliases for easier *internal* handling both on
the IDP and SP side but that's not using urn:oid any less (on the wire)?
And of course the Shib SP can map arbitrary attribute names to
internal aliases, too, but the OP is certainly right that his IDP
should be producing standard attribute names to begin with, avoiding
the need for every SP (or IDP-SP combo) to bilaterally agree on
naming.
@Lorenzo: Try adding the name2oid attribute map, possibly even
globally to your config.php file.
-peter
> Technically you may be right Peter, but nobody uses OIDs on a daily basis..
> Everyone has the human readable mace-dir attributes as aliases for
> the OIDs.
Not sure what this means: We use urn:oid named attributes exclusively
> Everyone has the human readable mace-dir attributes as aliases for
> the OIDs.
(and have been doing so for almost 1.5 decades) on a daily basis.
Of course proper software implentations (such as SimpleSAMLphp and
Shibboleth) will offer aliases for easier *internal* handling both on
the IDP and SP side but that's not using urn:oid any less (on the wire)?
And of course the Shib SP can map arbitrary attribute names to
internal aliases, too, but the OP is certainly right that his IDP
should be producing standard attribute names to begin with, avoiding
the need for every SP (or IDP-SP combo) to bilaterally agree on
naming.
@Lorenzo: Try adding the name2oid attribute map, possibly even
globally to your config.php file.
-peter
Lorenzo Milesi
Jul 20, 2021, 6:45:59 AM7/20/21
to simplesamlphp
> @Lorenzo: Try adding the name2oid attribute map, possibly even
> globally to your config.php file.
When I do an authentication test from SSP admin section I see the AD LDAP data about the user (displayName, cn, distinguishedName, pwdLastSet...). In the AuthData section I see the same, in PHP format:
{
"Attributes": {
"objectClass": [
"top",
"person",
"organizationalPerson",
"user"
],
"cn": [
"Lorenzo Milesi"
],
"sn": [
"Milesi"
],
"givenName": [
"Lorenzo"
],
"instanceType": [
"4"
],
"whenCreated": [
"20210611211848.0Z"
],
"displayName": [
"Lorenzo Milesi"
],
....
As per Shibboleth SP I still don't get any attribute.
How do I know if the filter has been processed? This is my metadata/saml20-idp-hosted.php
$metadata['__DYNAMIC:1__'] = [
'host' => '__DEFAULT__',
'privatekey' => 'auth.domain.com.key',
'certificate' => 'auth.domain.com.crt',
'auth' => 'my-ad',
'authproc' => [
50 => [
'class' => 'ldap:AttributeAddFromLDAP',
'attributes' => ['mail'],
'search.filter' => '(mail=%mail%)',
'authsource' => 'my-ad',
],
51 => [
'class' => 'core:AttributeMap',
'name2urn', 'name2oid',
50 => [
'class' => 'ldap:AttributeAddFromLDAP',
'attributes' => ['mail'],
'search.filter' => '(mail=%mail%)',
'authsource' => 'my-ad',
],
51 => [
'class' => 'core:AttributeMap',
'%duplicate',
],
52 => [
'authsource' => 'my-ad',
'class' => 'ldap:AttributeAddUsersGroups',
'ldap.product' => 'ActiveDirectory'
],
],
];
for the record I don't even see the group attributes (52) when testing auth.
I enabled debug in config but I only get this:
Jul 20 12:40:28 varie simplesamlphp[2496953]: 7 [c415386035] Library - LDAP __construct(): Setup LDAP with host='dc1.domain.com', tls=true, debug=false, timeout=0, referrals=false
Jul 20 12:40:28 varie simplesamlphp[2496953]: 7 [c415386035] Library - LDAP bind(): Bind successful with DN 'CN=authuser,OU=Users,DC=domain,DC=com'
Jul 20 12:40:28 varie simplesamlphp[2496953]: 7 [c415386035] Library - LDAP search(): Searching base (subtree) 'OU=Users,DC=domain,DC=com' for
'(|(sAMAccountName=lorenzo.milesi)(mail=lorenzo.milesi))'
Jul 20 12:40:28 varie simplesamlphp[2496953]: 7 [c415386035] Library - LDAP bind(): Bind successful with DN 'CN=Lorenzo Milesi,OU=Users,DC=domain,DC=com'
Jul 20 12:40:28 varie simplesamlphp[2496953]: 7 [c415386035] Library - LDAP getAttributes(): Getting all attributes from DN 'CN=Lorenzo Milesi,OU=Users,DC=domain,DC=com'
Jul 20 12:40:28 varie simplesamlphp[2496953]: 7 [c415386035] Library - LDAP getAttributes(): Found attributes '(objectClass,cn,sn,givenName,instanceType,whenCreated,displayName,uSNCreated,name,objectGUID,badPwdCount,codePage,countryCode,badPasswordTime,lastLogoff,lastLogon,primaryGroupID,objectSid,accountExpires,logonCount,sAMAccountName,sAMAccountType,userPrincipalName,objectCategory,mail,userAccountControl,pwdLastSet,lastLogonTimestamp,whenChanged,uSNChanged,distinguishedName)'
Jul 20 12:40:28 varie simplesamlphp[2496953]: 5 STAT [c415386035] User 'lorenzo.milesi' successfully authenticated from 2001:470:26:119:8f:acd:cb25:9167
Jul 20 12:40:28 varie simplesamlphp[2496953]: 7 [c415386035] Deleting state: '_bcc68c37582eb947f6e95b4957ac082672eca743f8'
Jul 20 12:40:28 varie simplesamlphp[2496953]: 7 [c415386035] Session: doLogin("my-ad")
Jul 20 12:40:28 varie simplesamlphp[2127134]: 7 [c415386035] Session: Valid session found with 'my-ad'.
Jul 20 12:40:28 varie simplesamlphp[2127134]: message repeated 2 times: [ 7 [c415386035] Session: Valid session found with 'my-ad'.]
Jul 20 12:40:28 varie simplesamlphp[2127134]: 7 [c415386035] Localization: using old system
Jul 20 12:40:28 varie simplesamlphp[2127134]: 7 [c415386035] Session: Valid session found with 'my-ad'.
Jul 20 12:40:28 varie simplesamlphp[2127134]: 7 [c415386035] Translate: Reading dictionary [/var/www/simplesamlphp/dictionaries/status]
Jul 20 12:40:28 varie simplesamlphp[2127134]: 7 [c415386035] Translate: Reading dictionary [/var/www/simplesamlphp/dictionaries/attributes]
Marco Ferrante
Jul 20, 2021, 4:52:55 PM7/20/21
to simple...@googlegroups.com
Check if shibd.log report any line such as:
2021-**** INFO Shibboleth.AttributeExtractor.XML [1473461]: skipping
unmapped SAML 2.0 Attribute with Name: studentID
If so, there is a mismatch between attribute names in the Idp assertion
and configuration in Shibboleth attribute-map.xml
--
Marco Ferrante (ma...@csita.unige.it)
Università degli Studi di Genova
2021-**** INFO Shibboleth.AttributeExtractor.XML [1473461]: skipping
unmapped SAML 2.0 Attribute with Name: studentID
If so, there is a mismatch between attribute names in the Idp assertion
and configuration in Shibboleth attribute-map.xml
Marco Ferrante (ma...@csita.unige.it)
Università degli Studi di Genova
Lorenzo Milesi
Jul 21, 2021, 2:04:24 AM7/21/21
to simplesamlphp
> 2021-**** INFO Shibboleth.AttributeExtractor.XML [1473461]: skipping
> unmapped SAML 2.0 Attribute with Name: studentID
>
> If so, there is a mismatch between attribute names in the Idp assertion
> and configuration in Shibboleth attribute-map.xml
I do have those messages (see below).
> unmapped SAML 2.0 Attribute with Name: studentID
>
> If so, there is a mismatch between attribute names in the Idp assertion
> and configuration in Shibboleth attribute-map.xml
But I think I first have the issue of mapping AD fields to "standard" ones, on SSP.
I added in metadata/saml20-idp-hosted.php
'authproc' => [
49 => [
'class' => 'core:AttributeMap',
'uid' => 'sAMAccountName',
],
but sAMAccountName isn't translated to uid... I can't understand why, as said before even enabling debug didn't show me errors.
2021-07-21 07:54:56 INFO Shibboleth.AttributeExtractor.XML [2] [default]: skipping unmapped SAML 2.0 Attribute with Name: urn:oid:2.5.4.0, Format:urn:oasis:names:tc:SAML:2.0:attrname-format:basic
2021-07-21 07:54:56 INFO Shibboleth.AttributeExtractor.XML [2] [default]: skipping unmapped SAML 2.0 Attribute with Name: urn:oid:2.5.4.3, Format:urn:oasis:names:tc:SAML:2.0:attrname-format:basic
2021-07-21 07:54:56 INFO Shibboleth.AttributeExtractor.XML [2] [default]: skipping unmapped SAML 2.0 Attribute with Name: urn:oid:2.5.4.4, Format:urn:oasis:names:tc:SAML:2.0:attrname-format:basic
2021-07-21 07:54:56 INFO Shibboleth.AttributeExtractor.XML [2] [default]: skipping unmapped SAML 2.0 Attribute with Name: urn:oid:2.5.4.42, Format:urn:oasis:names:tc:SAML:2.0:attrname-format:basic
2021-07-21 07:54:56 INFO Shibboleth.AttributeExtractor.XML [2] [default]: skipping unmapped SAML 2.0 Attribute with Name: instanceType, Format:urn:oasis:names:tc:SAML:2.0:attrname-format:basic
2021-07-21 07:54:56 INFO Shibboleth.AttributeExtractor.XML [2] [default]: skipping unmapped SAML 2.0 Attribute with Name: whenCreated, Format:urn:oasis:names:tc:SAML:2.0:attrname-format:basic
2021-07-21 07:54:56 INFO Shibboleth.AttributeExtractor.XML [2] [default]: skipping unmapped SAML 2.0 Attribute with Name: urn:oid:2.16.840.1.113730.3.1.241, Format:urn:oasis:names:tc:SAML:2.0:attrname-format:basic
2021-07-21 07:54:56 INFO Shibboleth.AttributeExtractor.XML [2] [default]: skipping unmapped SAML 2.0 Attribute with Name: uSNCreated, Format:urn:oasis:names:tc:SAML:2.0:attrname-format:basic
Peter Schober
Jul 21, 2021, 5:30:23 AM7/21/21
to simplesamlphp
* 'Lorenzo Milesi' via SimpleSAMLphp <simple...@googlegroups.com> [2021-07-21 08:04]:
Assertion (and the logs from the SP you sent won't be complete as
you've only sent one partciluar type of error message) -- you're still
causing yourself and everyone here trying to help you to be flying
blind -- but there's no sign of either sAMAccountName or uid in
anything you sent so far.
The (other) error is something else (now that we finally at least have
some partial evidence of what you're sending, from the SP side):
The attribute *names* are urn:oid:... on the wire, as they should be,
but the attributes' *NameFormat* is "basic" when it should be "uri"
(in all cases except for "instanceType", "whenCreated" and
"uSNCreated", whatever those are, meaning which you probably should't
even be sending those at all):
> 2021-07-21 07:54:56 INFO Shibboleth.AttributeExtractor.XML [2] [default]: skipping unmapped SAML 2.0 Attribute with Name: urn:oid:2.5.4.0, Format:urn:oasis:names:tc:SAML:2.0:attrname-format:basic
There should be no need to send the objectClass LDAP attribute (same
as with the data I mentioned above) so take this as a(nother) hint
that you should also configure an attribute filter limiting what's
going out.
> 2021-07-21 07:54:56 INFO Shibboleth.AttributeExtractor.XML [2] [default]: skipping unmapped SAML 2.0 Attribute with Name: urn:oid:2.5.4.3, Format:urn:oasis:names:tc:SAML:2.0:attrname-format:basic
That's cn (were the NameFormat correct).
> 2021-07-21 07:54:56 INFO Shibboleth.AttributeExtractor.XML [2] [default]: skipping unmapped SAML 2.0 Attribute with Name: urn:oid:2.5.4.4, Format:urn:oasis:names:tc:SAML:2.0:attrname-format:basic
That's sn (were the NameFormat correct).
> 2021-07-21 07:54:56 INFO Shibboleth.AttributeExtractor.XML [2] [default]: skipping unmapped SAML 2.0 Attribute with Name: urn:oid:2.5.4.42, Format:urn:oasis:names:tc:SAML:2.0:attrname-format:basic
That's givenName (were the NameFormat correct).
> 2021-07-21 07:54:56 INFO Shibboleth.AttributeExtractor.XML [2] [default]: skipping unmapped SAML 2.0 Attribute with Name: urn:oid:2.16.840.1.113730.3.1.241, Format:urn:oasis:names:tc:SAML:2.0:attrname-format:basic
That's displayName (were the NameFormat correct).
To be honest, I'd expect the name2oid filter -- that changes the
attribute *names* -- to also change their NameFormat, but seemingly
this is left to the deployer.
Here's the documentation on how to change that:
https://simplesamlphp.org/docs/stable/simplesamlphp-idp#section_6
Best,
-peter
> I do have those messages (see below).
> but sAMAccountName isn't translated to uid... I can't understand
> why, as said before even enabling debug didn't show me errors.
We still haven't seen what you're actually putting into the SAML
> why, as said before even enabling debug didn't show me errors.
Assertion (and the logs from the SP you sent won't be complete as
you've only sent one partciluar type of error message) -- you're still
causing yourself and everyone here trying to help you to be flying
blind -- but there's no sign of either sAMAccountName or uid in
anything you sent so far.
The (other) error is something else (now that we finally at least have
some partial evidence of what you're sending, from the SP side):
The attribute *names* are urn:oid:... on the wire, as they should be,
but the attributes' *NameFormat* is "basic" when it should be "uri"
(in all cases except for "instanceType", "whenCreated" and
"uSNCreated", whatever those are, meaning which you probably should't
even be sending those at all):
> 2021-07-21 07:54:56 INFO Shibboleth.AttributeExtractor.XML [2] [default]: skipping unmapped SAML 2.0 Attribute with Name: urn:oid:2.5.4.0, Format:urn:oasis:names:tc:SAML:2.0:attrname-format:basic
as with the data I mentioned above) so take this as a(nother) hint
that you should also configure an attribute filter limiting what's
going out.
> 2021-07-21 07:54:56 INFO Shibboleth.AttributeExtractor.XML [2] [default]: skipping unmapped SAML 2.0 Attribute with Name: urn:oid:2.5.4.3, Format:urn:oasis:names:tc:SAML:2.0:attrname-format:basic
> 2021-07-21 07:54:56 INFO Shibboleth.AttributeExtractor.XML [2] [default]: skipping unmapped SAML 2.0 Attribute with Name: urn:oid:2.5.4.4, Format:urn:oasis:names:tc:SAML:2.0:attrname-format:basic
> 2021-07-21 07:54:56 INFO Shibboleth.AttributeExtractor.XML [2] [default]: skipping unmapped SAML 2.0 Attribute with Name: urn:oid:2.5.4.42, Format:urn:oasis:names:tc:SAML:2.0:attrname-format:basic
> 2021-07-21 07:54:56 INFO Shibboleth.AttributeExtractor.XML [2] [default]: skipping unmapped SAML 2.0 Attribute with Name: urn:oid:2.16.840.1.113730.3.1.241, Format:urn:oasis:names:tc:SAML:2.0:attrname-format:basic
To be honest, I'd expect the name2oid filter -- that changes the
attribute *names* -- to also change their NameFormat, but seemingly
this is left to the deployer.
Here's the documentation on how to change that:
https://simplesamlphp.org/docs/stable/simplesamlphp-idp#section_6
Best,
-peter
Tim van Dijen
Jul 21, 2021, 5:46:52 AM7/21/21
to SimpleSAMLphp
>
To be honest, I'd expect the name2oid filter -- that changes the
attribute *names* -- to also change their NameFormat, but seemingly
this is left to the deployer.
That's a good point Peter! It's currently not possible due to the way we process attributes internally, but it should be possible as soon as we have our new saml2 library in place.
I'll add an issue on Github as a reminder that we need to improve this.
I'll add an issue on Github as a reminder that we need to improve this.
- Tim
Op woensdag 21 juli 2021 om 11:30:23 UTC+2 schreef Peter Schober:
Peter Schober
Jul 21, 2021, 6:22:31 AM7/21/21
to SimpleSAMLphp
* Tim van Dijen <tvd...@gmail.com> [2021-07-21 11:46]:
> I'll add an issue on Github as a reminder that we need to improve this.
Thanks!
-peter
> It's currently not possible due to the way we process attributes
> internally, but it should be possible as soon as we have our new
> saml2 library in place.
Excellent news!
> internally, but it should be possible as soon as we have our new
> saml2 library in place.
> I'll add an issue on Github as a reminder that we need to improve this.
-peter
Lorenzo Milesi
Jul 21, 2021, 11:24:03 AM7/21/21
to simplesamlphp
> To be honest, I'd expect the name2oid filter -- that changes the
> attribute *names* -- to also change their NameFormat, but seemingly
> this is left to the deployer.
> Here's the documentation on how to change that:
> https://simplesamlphp.org/docs/stable/simplesamlphp-idp#section_6
One last bit I was still missing: the username in Shibboleth SP.
I had to add a mapping in attributemap/name2oid.php:
'sAMAccountName' => 'urn:oid:0.9.2342.19200300.100.1.1',
(@Tim, can I make a PR?) because I wasn't able to rename the field to an existing mapped one, like 'uid', with the following filter:
// Rename samaccountname before transforming to oid
91 => [
'class' => 'core:AttributeMap',
'sAMAccountName' => 'uid',
],
// Map LDAP -> oid
92 => [
'class' => 'core:AttributeMap',
'name2oid',
],
I've enabled SAML debug in SSP and I see:
Jul 21 17:05:39 simplesamlphp[2496953]: 7 [fab5ceef7e] <saml:Attribute Name="urn:oid:0.9.2342.19200300.100.1.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
Jul 21 17:05:39 simplesamlphp[2496953]: 7 [fab5ceef7e] <saml:AttributeValue xsi:type="xs:string">lorenzo.milesi</saml:AttributeValue>
Jul 21 17:05:39 simplesamlphp[2496953]: 7 [fab5ceef7e] </saml:Attribute>
And finally adding urn:oid:0.9.2342.19200300.100.1.1 to Shibboleth's attribute-map.xml I managed to get the username field!!
Thanks everyone for your help, even with the few provided information. Especially to fellow countryman Marco.
Peter Schober
Jul 21, 2021, 12:02:16 PM7/21/21
to simplesamlphp
* 'Lorenzo Milesi' via SimpleSAMLphp <simple...@googlegroups.com> [2021-07-21 17:24]:
According to
https://docs.microsoft.com/en-us/windows/win32/adschema/a-samaccountname
that's "1.2.840.113556.1.4.221"
(found via https://ldapwiki.com/wiki/SamAccountName).
Since you could have both sAMAccountName and uid
(0.9.2342.19200300.100.1.1) in use within the same LDAP system it's
not appropriate to give both the same OID in attributemap/name2oid.php.
> // Rename samaccountname before transforming to oid
> 91 => [
> 'class' => 'core:AttributeMap',
> 'sAMAccountName' => 'uid',
> ],
> // Map LDAP -> oid
> 92 => [
> 'class' => 'core:AttributeMap',
> 'name2oid',
> ],
Does renaming any of the other attributes work that way?
(I haven't done that in a while and haven't checked the documentation.)
> And finally adding urn:oid:0.9.2342.19200300.100.1.1 to Shibboleth's
> attribute-map.xml I managed to get the username field!!
Also finally, note that neither uid nor sAMAccountName are suitable
identifiers for cases where the SP may need to federate with more than
one IDP (as the same sAMAccountName/uid value may refer to different
individuals then).
If there's a chance that there will ever be more than one IDP hooked
up to a given SP I usually chose to use an identifier that's globally
uniqiue by definition from the start, nowadays that would probably be
SAML SubjectID (or eduPersonPrincipalName if wide/r compatibility with
existing systems is of concern).
Best,
-peter
> One last bit I was still missing: the username in Shibboleth SP.
>
> I had to add a mapping in attributemap/name2oid.php:
> 'sAMAccountName' => 'urn:oid:0.9.2342.19200300.100.1.1',
> (@Tim, can I make a PR?) because I wasn't able to rename the field to an existing mapped one, like 'uid', with the following filter:
Note that sAMAccountName has its own OID from Microsoft.
>
> I had to add a mapping in attributemap/name2oid.php:
> 'sAMAccountName' => 'urn:oid:0.9.2342.19200300.100.1.1',
> (@Tim, can I make a PR?) because I wasn't able to rename the field to an existing mapped one, like 'uid', with the following filter:
According to
https://docs.microsoft.com/en-us/windows/win32/adschema/a-samaccountname
that's "1.2.840.113556.1.4.221"
(found via https://ldapwiki.com/wiki/SamAccountName).
Since you could have both sAMAccountName and uid
(0.9.2342.19200300.100.1.1) in use within the same LDAP system it's
not appropriate to give both the same OID in attributemap/name2oid.php.
> // Rename samaccountname before transforming to oid
> 91 => [
> 'class' => 'core:AttributeMap',
> 'sAMAccountName' => 'uid',
> ],
> // Map LDAP -> oid
> 92 => [
> 'class' => 'core:AttributeMap',
> 'name2oid',
> ],
(I haven't done that in a while and haven't checked the documentation.)
> And finally adding urn:oid:0.9.2342.19200300.100.1.1 to Shibboleth's
> attribute-map.xml I managed to get the username field!!
identifiers for cases where the SP may need to federate with more than
one IDP (as the same sAMAccountName/uid value may refer to different
individuals then).
If there's a chance that there will ever be more than one IDP hooked
up to a given SP I usually chose to use an identifier that's globally
uniqiue by definition from the start, nowadays that would probably be
SAML SubjectID (or eduPersonPrincipalName if wide/r compatibility with
existing systems is of concern).
Best,
-peter
Lorenzo Milesi
Jul 22, 2021, 12:51:48 AM7/22/21
to simplesamlphp
> Does renaming any of the other attributes work that way?
> (I haven't done that in a while and haven't checked the documentation.)
https://simplesamlphp.org/docs/stable/core:authproc_attributemap
Attribute maps embedded as parameters:
'authproc' => array(
50 => array(
'class' => 'core:AttributeMap',
'mail' => 'email',
'uid' => 'user'
'cn' => array('name', 'displayName'),
),
),
The mapping is done by OLD => NEW.
I moved the filters and attributes.NameFormat to the SP configuration and they seem to work fine, all of them (I have an app expecting NameFormat urn:oasis:names:tc:SAML:2.0:attrname-format:basic, and I didn't know how to remove a global filter just for one SP).
> Also finally, note that neither uid nor sAMAccountName are suitable
> identifiers for cases where the SP may need to federate with more than
> one IDP (as the same sAMAccountName/uid value may refer to different
> individuals then).
> If there's a chance that there will ever be more than one IDP hooked
> up to a given SP I usually chose to use an identifier that's globally
> uniqiue by definition from the start, nowadays that would probably be
> SAML SubjectID (or eduPersonPrincipalName if wide/r compatibility with
> existing systems is of concern).
thanks
Peter Schober
Jul 22, 2021, 5:47:16 AM7/22/21
to simplesamlphp
* 'Lorenzo Milesi' via SimpleSAMLphp <simple...@googlegroups.com> [2021-07-22 06:51]:
> (I have an app expecting NameFormat
> urn:oasis:names:tc:SAML:2.0:attrname-format:basic, and I didn't know
> how to remove a global filter just for one SP).
And putting it into the SP config/metadata didn't override the global
config setting?
> > Also finally, note that neither uid nor sAMAccountName are suitable
> > identifiers for cases where the SP may need to federate with more than
> > one IDP (as the same sAMAccountName/uid value may refer to different
> > individuals then).
> > If there's a chance that there will ever be more than one IDP hooked
> > up to a given SP I usually chose to use an identifier that's globally
> > uniqiue by definition from the start, nowadays that would probably be
> > SAML SubjectID (or eduPersonPrincipalName if wide/r compatibility with
> > existing systems is of concern).
>
> To obtain this I should map uid/sAMAccountName to
> eduPersonPrincipalName or SubjectID?
There's no one simple answer what data to use as a source for these
attributes. A few comments:
If you haven't been supporting/releasing ePPN yet then don't start now.
SAML SubjectID prohibits (ever!) reassigning values from one person to
another, so the source attribute should be the best / most stable
local key you have available. If you never reassign uid/sAMAccountName
values (not even after a grace period of several years after a person
has left the org) then it could be a usable source attribute,
otherwise not. Maybe something like an employee number would be better
suited (if that fulfills the criteria) or an internal key used for
Identity Management.
Personally I wouldn't release such a piece of data verbatim, I'd
salt+hash it to create the final SubjectID value (plus '@' + Scope).
Others (including the author of the SubjectID spec) use the source
attribute verbatim (plus '@' + Scope).
It may be the case that you simply cannot support SubjectIDs at all
(due to the non-reassignment requirement). Then you'd have to look at
what the alternatives are.
This all depends on your deployment(s) and IDM processes about which
we know nothing.
Best,
-peter
> I moved the filters and attributes.NameFormat to the SP
> configuration and they seem to work fine, all of them
Great!
> configuration and they seem to work fine, all of them
> (I have an app expecting NameFormat
> urn:oasis:names:tc:SAML:2.0:attrname-format:basic, and I didn't know
> how to remove a global filter just for one SP).
config setting?
> > Also finally, note that neither uid nor sAMAccountName are suitable
> > identifiers for cases where the SP may need to federate with more than
> > one IDP (as the same sAMAccountName/uid value may refer to different
> > individuals then).
> > If there's a chance that there will ever be more than one IDP hooked
> > up to a given SP I usually chose to use an identifier that's globally
> > uniqiue by definition from the start, nowadays that would probably be
> > SAML SubjectID (or eduPersonPrincipalName if wide/r compatibility with
> > existing systems is of concern).
>
> To obtain this I should map uid/sAMAccountName to
> eduPersonPrincipalName or SubjectID?
attributes. A few comments:
If you haven't been supporting/releasing ePPN yet then don't start now.
SAML SubjectID prohibits (ever!) reassigning values from one person to
another, so the source attribute should be the best / most stable
local key you have available. If you never reassign uid/sAMAccountName
values (not even after a grace period of several years after a person
has left the org) then it could be a usable source attribute,
otherwise not. Maybe something like an employee number would be better
suited (if that fulfills the criteria) or an internal key used for
Identity Management.
Personally I wouldn't release such a piece of data verbatim, I'd
salt+hash it to create the final SubjectID value (plus '@' + Scope).
Others (including the author of the SubjectID spec) use the source
attribute verbatim (plus '@' + Scope).
It may be the case that you simply cannot support SubjectIDs at all
(due to the non-reassignment requirement). Then you'd have to look at
what the alternatives are.
This all depends on your deployment(s) and IDM processes about which
we know nothing.
Best,
-peter
Lorenzo Milesi
Jul 22, 2021, 10:59:38 AM7/22/21
to simplesamlphp
>> (I have an app expecting NameFormat
>> urn:oasis:names:tc:SAML:2.0:attrname-format:basic, and I didn't know
>> how to remove a global filter just for one SP).
>
> And putting it into the SP config/metadata didn't override the global
> config setting?
I had the filter with key 100 in the global config, I didn't know how to unset() it in the SP config. Thinking about it later I could have added a dummy configuration, but I don't know if thre are better options.
>> urn:oasis:names:tc:SAML:2.0:attrname-format:basic, and I didn't know
>> how to remove a global filter just for one SP).
>
> And putting it into the SP config/metadata didn't override the global
> config setting?
> This all depends on your deployment(s) and IDM processes about which
> we know nothing.
Peter Schober
Jul 23, 2021, 3:26:21 AM7/23/21
to simplesamlphp
* 'Lorenzo Milesi' via SimpleSAMLphp <simple...@googlegroups.com> [2021-07-22 16:59]:
> "the right way".
Unless you have something clearly superior (identifies that never
change are always best) I guess you'll be fine using sAMAccountName or
uid directly, then.
Regarding filter priority I don't think the numbers are actually
configuration keys you'd have to overwrite (AFAIU those just determine
order?) but someone else will have to answer that.
You can always file an RFI to have the documentation improved should
that not be covered currently.
Best,
-peter
> Thanks for the detailed explaination. My setup is very very simple,
> no federations or additional IdP, so I'm just trying to do things
> "the right way".
Unless you have something clearly superior (identifies that never
change are always best) I guess you'll be fine using sAMAccountName or
uid directly, then.
Regarding filter priority I don't think the numbers are actually
configuration keys you'd have to overwrite (AFAIU those just determine
order?) but someone else will have to answer that.
You can always file an RFI to have the documentation improved should
that not be covered currently.
Best,
-peter
Reply all
Reply to author
Forward
0 new messages