SSP as an IdP, NameID
Peter Schober
person, let alone programmer) I was able to set up an SSP instance
(1.6 branch) as a SAML V2.0 IdP for the first time, that did about 80%
of what I wanted, in less than 45 minutes, including authentication,
attribute resolving and automated metadata management with metadata
sigature checking.
IMO that's quite impressive. Thanks to all involved!
(Attribute manipulation and filtering with authproc filters threw me
back several hours, so I didn't include these tasks in the above
statement. Also I'll have to see how much effort the remaining 5-10%
will take ;)
A few minor remarks:
* The install instructions are missing the part where you need to
$ cp -a config-templates/* config/
Checking this is only mentioned in the upgrading notes.
* The core:TargetedID authproc filter
http://simplesamlphp.org/docs/1.6/core:authproc_targetedid
mentions a "Internet2 compatible eduPersontargetedID" which results
in this construct inside the attribute assertion:
<saml:Attribute
Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue
xsi: type="xs:string">
<saml:NameID
xmlns: saml="urn:oasis:names:tc:SAML:2.0:assertion"
NameQualifier="https://idp.example.org/saml"
SPNameQualifier="https://sp.example.org/saml"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">someuniquestring</saml:NameID>
</saml:AttributeValue>
</saml:Attribute>
I'm not sure how useful this is, stuffing a persistent NameID inside
an attribute and providing an additional transient NameID in the
assertion's Subject. The syntax also looks a bit weird to me
(attribute value of type string, with all XML encoded in entity
references etc.) but I didn't check whether that's legal or not.
Anyway, on the tf-emc2 list consensus was established that
eduPersontargetedID-style persistent NameIDs should go in the
assertion's subject, not in an attribute. How would one go about
configuring this?
As to "Internet2 compatible": the Shib 2.x SP does perform "decoding
NameIDAttribute (persistent-id) from SAML 2 Attribute
(urn:oid:1.3.6.1.4.1.5923.1.1.1.10) with 1 value(s)" but then
seemingly the attribute is not mapped (i.e., cannot be accessed from
the environment and does not show up in the Session handler.)
This is with the default attribute-map.xml as distributed.
Any comments on this? I'll also feed this to the shibboleth-users list
for advice.
I'll follow up on the other issues and beginner questions I'll
certainly have in other emails.
cheers,
-peter
Peter Schober
> * The core:TargetedID authproc filter
> http://simplesamlphp.org/docs/1.6/core:authproc_targetedid
> mentions a "Internet2 compatible eduPersontargetedID" which results
> in this construct inside the attribute assertion:
> The syntax also looks a bit weird to me (attribute value of type
> string, with all XML encoded in entity references etc.) but I didn't
> check whether that's legal or not.
To be more precice, this is what's on the wire (linebreaks and
intendation added for readability):
<saml:Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue xsi:type="xs:string">
<saml:NameID xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
NameQualifier="https://idp.example.org/saml"
SPNameQualifier="https://sp.example.org/saml"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">someuniquestring</saml:NameID>
</saml:AttributeValue>
</saml:Attribute>
So the complete XML structure that constiutes the NameID is encoded as
strings (and AttributeValue has a matching xsi:type="xs:string"),
including the XML tags' delimiters ('<' becomes '<', etc.).
For this attribute that's neither valid (the value of
eduPersonTargetedID "MUST be a NameID element" per 3.3.1.1 of MACE-Dir
SAML Prfiles, which is XML, not strings) nor will it work with the
Shibboleth SP (which is another possible interpretation of "Internet2
compatible eduPersontargetedID" on the documentation's page.).
SAMLCore section 2.7.3.1.1 says "<AttributeValue> [...] is of the
xs:anyType type, which allows any well-formed XML to appear as the
content of the element.", so leaving out the xsi:type="xs:string"
attribute on the AttributeValue, and not doing any encoding should
make this both legal and work.
> As to "Internet2 compatible": the Shib 2.x SP does perform "decoding
> NameIDAttribute (persistent-id) from SAML 2 Attribute
> (urn:oid:1.3.6.1.4.1.5923.1.1.1.10) with 1 value(s)" but then
> seemingly the attribute is not mapped (i.e., cannot be accessed from
> the environment and does not show up in the Session handler.)
Since the value is simple strings, there is no NameID to be found
anywhere, and nothing to be mapped, so the SP is not at fault
here.
-peter
Olav Morken
> Being only mildly familiar with the SSP SP (and not much of a PHP
> person, let alone programmer) I was able to set up an SSP instance
> (1.6 branch) as a SAML V2.0 IdP for the first time, that did about 80%
> of what I wanted, in less than 45 minutes, including authentication,
> attribute resolving and automated metadata management with metadata
> sigature checking.
> IMO that's quite impressive. Thanks to all involved!
>
> (Attribute manipulation and filtering with authproc filters threw me
> back several hours, so I didn't include these tasks in the above
> statement. Also I'll have to see how much effort the remaining 5-10%
> will take ;)
>
> A few minor remarks:
>
> * The install instructions are missing the part where you need to
> $ cp -a config-templates/* config/
> Checking this is only mentioned in the upgrading notes.
Oops, this was supposed to happen when building the release. It looks
like I will have to do a bit of bug-hunting in the release-build
script.
> * The core:TargetedID authproc filter
> http://simplesamlphp.org/docs/1.6/core:authproc_targetedid
> mentions a "Internet2 compatible eduPersontargetedID" which results
> in this construct inside the attribute assertion:
>
> <saml:Attribute
> Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
> <saml:AttributeValue
> xsi: type="xs:string">
> <saml:NameID
> xmlns: saml="urn:oasis:names:tc:SAML:2.0:assertion"
> NameQualifier="https://idp.example.org/saml"
> SPNameQualifier="https://sp.example.org/saml"
> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">someuniquestring</saml:NameID>
> </saml:AttributeValue>
> </saml:Attribute>
>
> I'm not sure how useful this is, stuffing a persistent NameID inside
> an attribute and providing an additional transient NameID in the
> assertion's Subject. The syntax also looks a bit weird to me
> (attribute value of type string, with all XML encoded in entity
> references etc.) but I didn't check whether that's legal or not.
I agree that it looks weird. Unfortunately it is what Shibboleth
expects (except for the xs:string you noted - I will investigate that
error).
> Anyway, on the tf-emc2 list consensus was established that
> eduPersontargetedID-style persistent NameIDs should go in the
> assertion's subject, not in an attribute. How would one go about
> configuring this?
Set NameIDFormat in the sp-remote metadata to
'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent', and set the
'userid.attribute' option in saml20-idp-hosted to an attribute which
contains the unique id of the user (typically eduPersonPrincipalName).
(This area will fortunately see some improvements in version 1.7.)
> As to "Internet2 compatible": the Shib 2.x SP does perform "decoding
> NameIDAttribute (persistent-id) from SAML 2 Attribute
> (urn:oid:1.3.6.1.4.1.5923.1.1.1.10) with 1 value(s)" but then
> seemingly the attribute is not mapped (i.e., cannot be accessed from
> the environment and does not show up in the Session handler.)
> This is with the default attribute-map.xml as distributed.
> Any comments on this? I'll also feed this to the shibboleth-users list
> for advice.
>
> I'll follow up on the other issues and beginner questions I'll
> certainly have in other emails.
Please do that!
--
Olav Morken
UNINETT / Feide
Olav Morken
> * Peter Schober <sp+lists....@univie.ac.at> [2010-06-18 23:18]:
> > * The core:TargetedID authproc filter
> > http://simplesamlphp.org/docs/1.6/core:authproc_targetedid
> > mentions a "Internet2 compatible eduPersontargetedID" which results
> > in this construct inside the attribute assertion:
> [...]
> > The syntax also looks a bit weird to me (attribute value of type
> > string, with all XML encoded in entity references etc.) but I didn't
> > check whether that's legal or not.
>
> To be more precice, this is what's on the wire (linebreaks and
> intendation added for readability):
>
> <saml:Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
> <saml:AttributeValue xsi:type="xs:string">
> <saml:NameID xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
> NameQualifier="https://idp.example.org/saml"
> SPNameQualifier="https://sp.example.org/saml"
> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">someuniquestring</saml:NameID>
> </saml:AttributeValue>
> </saml:Attribute>
>
> So the complete XML structure that constiutes the NameID is encoded as
> strings (and AttributeValue has a matching xsi:type="xs:string"),
> including the XML tags' delimiters ('<' becomes '<', etc.).
Then the error makes sense. It looks like an attribute encoding issue.
I'm thinking that this is a documentation issue. I assume you added
this to the metadata:
'attributeencodings' => array(
'eduPersonTargetedID' => 'raw',
),
Could you try to use 'urn:oid:1.3.6.1.4.1.5923.1.1.1.10' instead of
'eduPersonTargetedID'?
Peter Schober
> > Anyway, on the tf-emc2 list consensus was established that
> > eduPersontargetedID-style persistent NameIDs should go in the
> > assertion's subject, not in an attribute. How would one go about
> > configuring this?
>
> Set NameIDFormat in the sp-remote metadata to
> 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent', and set the
> 'userid.attribute' option in saml20-idp-hosted to an attribute which
> contains the unique id of the user (typically eduPersonPrincipalName).
All Metadata at this IdP comes in via metarefresh and cron.
The SP I tested this with announces support for both formats in it's
SAML V2.0 metadata:
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
however, only :transient makes it into metadata/$federation/saml20-sp-remote.php
'NameIDFormat' => 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient',
(So I guess it's either the old problem of changing runtime behaviour
for remotely managed metadata, or the problem of chosing the right
NameID when several are supported.)
I run into some UNHANDLEDEXCEPTION when (manually) changing this SP's
NameIDFormat in the local metadata to persistent, so I will have to
look into this first.
* Olav Morken <olav....@uninett.no> [2010-06-21 09:01]:
> > So the complete XML structure that constiutes the NameID is encoded as
> > strings (and AttributeValue has a matching xsi:type="xs:string"),
> > including the XML tags' delimiters ('<' becomes '<', etc.).
>
> Then the error makes sense. It looks like an attribute encoding issue.
> I'm thinking that this is a documentation issue. I assume you added
> this to the metadata:
>
> 'attributeencodings' => array(
> 'eduPersonTargetedID' => 'raw',
> ),
>
> Could you try to use 'urn:oid:1.3.6.1.4.1.5923.1.1.1.10' instead of
> 'eduPersonTargetedID'?
Ah, at this point the name2oid mapping I setup from config/config.php
already has been applied, hence the mapped attribute name must be
used. Thanks, this fixes the encoding.
Note that with SAML2 use of the oid-style attribute name is pretty
much required for all MACE-Dir defined attributes, including
eduPersonTargetedID (since the "legacy names" "MUST NOT" be used, [1]
p.11). So if the documentation for the core:TargetedID authproc filter
explicitly mentions "Internet2 compatible eduPersontargetedID", maybe
a note to this regard should be added.
(Default the docs to oid-style name might just cause the opposite
problem: the filter not working because the name2oid mapping wasn't
used.)
Takk!
-peter
[1] http://middleware.internet2.edu/dir/docs/internet2-mace-dir-saml-attributes-200804.pdf
Adam Lantos
<sp+lists....@univie.ac.at> wrote:
> * Olav Morken <olav....@uninett.no> [2010-06-21 08:15]:
> The SP I tested this with announces support for both formats in it's
> SAML V2.0 metadata:
>
> <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
> <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
>
> however, only :transient makes it into metadata/$federation/saml20-sp-remote.php
>
> 'NameIDFormat' => 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient',
>
> (So I guess it's either the old problem of changing runtime behaviour
> for remotely managed metadata, or the problem of chosing the right
> NameID when several are supported.)
There is a known issue in the 1.6branch wrt NameIDFormat handling,
please refer to
http://code.google.com/p/simplesamlphp/issues/detail?id=247 for
details.
cheers,
Adam
Peter Schober
* Peter Schober <sp+lists....@univie.ac.at> [2010-06-21 09:47]:
> I run into some UNHANDLEDEXCEPTION when (manually) changing this SP's
> NameIDFormat in the local metadata to persistent, so I will have to
> look into this first.
With NameIDFormat set to transient, everything works and a
NameID-valued Attribute urn:oid:1.3.6.1.4.1.5923.1.1.1.10 (ePTId) is
being generated.
When I set this to permanent locally, I run into one of two problems
with the 'userid.attribute' setting:
When I leave this at 'uid', which is one of several attributes my
authsource looks up via LDAP and what I use in config/config.php to
generate an ePPN from, via some trickery in the form of:
55 => array(
'class' => 'core:AttributeAdd',
'exampleScopedFoo' => 'f...@example.org, // will not be released
),
57 => array(
'class' => 'core:ScopeAttribute',
'scopeAttribute' => 'exampleScopedFoo',
'sourceAttribute' => 'uid',
'targetAttribute' => 'eduPersonPrincipalName',
),
I am being asked to consent to (among others) the attribute, which
seems to be just fine:
urn:oid:1.3.6.1.4.1.5923.1.1.1.10
<saml:NameID xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
NameQualifier="https://idp.example.org/saml"
SPNameQualifier="https://sp.exaple.org/saml"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">somestring</saml:NameID>
Accepting this with "Yes, continue" the following exception with
backtrace occurs:
(From the log file:)
Jun 21 10:13:31 simplesamlphp ERROR [e74ed6fba6] /samlidp/ssp/module.php/consent/getconsent.php - UserError:
ErrCode:UNHANDLEDEXCEPTION: Missing+attribute+%22uid%22+for+user.+Cannot+generate+user+id.
Missing attribute "uid" for user. Cannot generate user id.
0: /u/home/samlidp/simplesamlphp/lib/SimpleSAML/Utilities.php:1125 (SimpleSAML_Utilities::generateUserIdentifier)
1: /u/home/samlidp/simplesamlphp/modules/saml2/lib/Message.php:474 (sspmod_saml2_Message::generateNameIdValue)
2: /u/home/samlidp/simplesamlphp/modules/saml2/lib/Message.php:631 (sspmod_saml2_Message::buildAssertion)
3: /u/home/samlidp/simplesamlphp/modules/saml/lib/IdP/SAML2.php:49 (sspmod_saml_IdP_SAML2::sendResponse)
4: [builtin] (call_user_func)
5: /u/home/samlidp/simplesamlphp/lib/SimpleSAML/IdP.php:268 (SimpleSAML_IdP::postAuthProc)
6: [builtin] (call_user_func)
7: /u/home/samlidp/simplesamlphp/lib/SimpleSAML/Auth/ProcessingChain.php:261 (SimpleSAML_Auth_ProcessingChain::resumeProcessing)
8: /u/home/samlidp/simplesamlphp/modules/consent/www/getconsent.php:53 (require)
9: /u/home/samlidp/simplesamlphp/www/module.php:135 (N/A)
Note that I don't release 'uid' itself, but adding this to the array
in AttributeLimit does not seem to change anything.
Also the consent module presents the complete NameID just fine (so if
something was missing how can it present a value during consent
gathering -- but I will still need to compare the actual values being
generated). Finally (again), with NameIDFormat set to transient the
NameID comes through fine, albeit as an attribute. Weird.
If I try to change 'userid.attribute' to anything else but 'uid' (in
metadata/saml20-idp-hosted.php) I get a different exception, no matter
what I try ('eduPersonPrincipalName',
'urn:oid:0.9.2342.19200300.100.1.1', 'urn:oid:1.3.6.1.4.1.5923.1.1.1.6'):
core:TargetedID: Missing UserID for this user. Please check the
'userid.attribute' option in the metadata against the attributes
provided by the authentication source.
0: /u/home/samlidp/simplesamlphp/modules/core/lib/Auth/Process/TargetedID.php:88 (sspmod_core_Auth_Process_TargetedID::process)
1: /u/home/samlidp/simplesamlphp/lib/SimpleSAML/Auth/ProcessingChain.php:195 (SimpleSAML_Auth_ProcessingChain::processState)
2: /u/home/samlidp/simplesamlphp/lib/SimpleSAML/IdP.php:310 (SimpleSAML_IdP::postAuth)
3: [builtin] (call_user_func)
4: /u/home/samlidp/simplesamlphp/lib/SimpleSAML/Auth/Default.php:127 (SimpleSAML_Auth_Default::loginCompleted)
5: [builtin] (call_user_func)
6: /u/home/samlidp/simplesamlphp/lib/SimpleSAML/Auth/Source.php:120 (SimpleSAML_Auth_Source::completeAuth)
7: /u/home/samlidp/simplesamlphp/modules/core/lib/Auth/UserPassBase.php:190 (sspmod_core_Auth_UserPassBase::handleLogin)
8: /u/home/samlidp/simplesamlphp/modules/core/www/loginuserpass.php:49 (require)
9: /u/home/samlidp/simplesamlphp/www/module.php:135 (N/A)
The second exception is also what happens when I completely disable
the consent module.
So what should go into the 'userid.attribute' in
metadata/saml20-idp-hosted.php?
Maybe the order of my authproc filters is somehow off? I have all
authproc filters in config/config.php, except for core:TargetedID
which goes into metadata/saml20-idp-hosted.php.
Since I had to use the oid-style named attribute in
'attributeencodings' (as per your previous comment, which fixed the
NameID encoding) I would have guesses that this might also be valid
for 'userid.attribute' (which is just a line above in
metadata/saml20-idp-hosted.php) but that didn't help.
cheers,
-peter
Olav Morken
> I don't get much further, find a long error description below...
>
> * Peter Schober <sp+lists....@univie.ac.at> [2010-06-21 09:47]:
> > I run into some UNHANDLEDEXCEPTION when (manually) changing this SP's
> > NameIDFormat in the local metadata to persistent, so I will have to
> > look into this first.
>
> With NameIDFormat set to transient, everything works and a
> NameID-valued Attribute urn:oid:1.3.6.1.4.1.5923.1.1.1.10 (ePTId) is
> being generated.
> When I set this to permanent locally, I run into one of two problems
> with the 'userid.attribute' setting:
I just looked at it, and it turns out that there is a bug / missing
feature with the userid.attribute option and NameID generation, which
means that it will not work when the attribute is removed before it is
time to send the response. Meanwhile, the core:TargetedID needs the
attribute to be present at the start of the request processing.
I will create a fix for it, and try to create a 1.6.1 release with the
bugfixes that have been done after the 1.6.0-release.
Peter Schober
> I just looked at it, and it turns out that there is a bug / missing
> feature with the userid.attribute option and NameID generation, which
> means that it will not work when the attribute is removed before it is
> time to send the response. Meanwhile, the core:TargetedID needs the
> attribute to be present at the start of the request processing.
>
> I will create a fix for it, and try to create a 1.6.1 release with the
> bugfixes that have been done after the 1.6.0-release.
Thanks for looking into this, but I wrote in one of my previous mail
(and I just rechecked this) that adding the userid.attribute ("uid" in
my case) to the AttributeLimit array did not make things work.
This error message is forwarded to the SP
Status: urn:oasis:names:tc:SAML:2.0:status:Responder
Message: SimpleSAML_Error_UnserializableException: Exception: Missing
attribute "uid" for user. Cannot generate user id.
Maybe I misunderstood what you meant with "the attribute is removed"?
Did you not mean it should work when the userid.attribute is also
released?
Takk,
-peter
Olav Morken
My guess is that it fails due to being renamed to an URI.
Peter Schober
> > Did you not mean it should work when the userid.attribute is also
> > released?
>
> My guess is that it fails due to being renamed to an URI.
OK. I did try naming it the urn:oid-value (as per my previous mail)
but to no avail. Thanks for looking into this,
-peter