attributes.NameFormat and AttributeLimit filter
Lorenzo Gil Sanchez
I'm trying to connect a pysaml2 SP with a SimpleSAMLphp IdP. In the SP
metadata I have an AttributeConsumingService like this:
<md:AttributeConsumingService index="1">
<md:ServiceName xml:lang="en">My pysaml2 test SP</md:ServiceName>
<md:RequestedAttribute FriendlyName="uid"
Name="urn:oid:0.9.2342.19200300.100.1.1"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
isRequired="true"/>
<md:RequestedAttribute FriendlyName="eduPersonAffiliation"
Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
isRequired="false"/>
</md:AttributeConsumingService>
When I convert this information to SSP metadata format I get this:
'attributes' => array (
0 => 'urn:oid:0.9.2342.19200300.100.1.1',
1 => 'urn:oid:1.3.6.1.4.1.5923.1.1.1.1',
),
'attributes.NameFormat' => 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri',
which is perfectly fine so far.
When I try to authenticate with the IdP the SAML response says the
authentication is a success but the assertion contains no attributes.
I can work around this issue by commenting out the AttributeLimit
filter, which is the one that removes the attributes. The
authentication source generates the attributes in 'name' format such
as ['uid', 'eduPersonAffiliation'] but when the AttributeLimit removes
unwanted attributes it compares them with the ones configured in the
SP metadata. In my case these are
['urn:oid:0.9.2342.19200300.100.1.1',
'urn:oid:1.3.6.1.4.1.5923.1.1.1.1'], which are the same attributes but
in different format.
Ok, I'll try another workaround. This time I keep the AttributeLimit
on but I'm adding another filter before:
10 => array(
'class' => 'core:AttributeMap', 'name2oid'
),
Now, AttributeLimit works and the attributes pass through. The problem
is the final SAML2 Response that is generated has a bad Assertion:
<saml:AttributeStatement>
<saml:Attribute Name="urn:oid:0.9.2342.19200300.100.1.1"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue xsi:type="xs:string">test</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue xsi:type="xs:string">member</saml:AttributeValue>
<saml:AttributeValue xsi:type="xs:string">student</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
The attribute format is said to be
urn:oasis:names:tc:SAML:2.0:attrname-format:basic but this is
incorrect since the attribute names are in the
urn:oasis:names:tc:SAML:2.0:attrname-format:uri format. This makes the
pysaml2 SP quite confused.
So what if AttributeLimit would use the attributes.NameFormat
information of the SP metadata to filter the attributes? It would
convert the attributes in the SP metadata to the 'name' format before
comparing them to the attributes in the $state array.
Does it make sense to you?
Sorry for the long email but I wanted to explain the problem in depth
and give as much information as possible.
Best regards,
Lorenzo
Olav Morken
> Hi,
>
> I'm trying to connect a pysaml2 SP with a SimpleSAMLphp IdP. In the SP
> metadata I have an AttributeConsumingService like this:
>
> <md:AttributeConsumingService index="1">
> <md:ServiceName xml:lang="en">My pysaml2 test SP</md:ServiceName>
> <md:RequestedAttribute FriendlyName="uid"
> Name="urn:oid:0.9.2342.19200300.100.1.1"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
> isRequired="true"/>
> <md:RequestedAttribute FriendlyName="eduPersonAffiliation"
> Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
> isRequired="false"/>
> </md:AttributeConsumingService>
>
> When I convert this information to SSP metadata format I get this:
>
> 'attributes' => array (
> 0 => 'urn:oid:0.9.2342.19200300.100.1.1',
> 1 => 'urn:oid:1.3.6.1.4.1.5923.1.1.1.1',
> ),
> 'attributes.NameFormat' => 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri',
>
> which is perfectly fine so far.
Actually, it is not. It seems that the XML metadata parser disagrees
with what the simpleSAMLphp IdP expects. Try to replace
'attributes.NameFormat' with 'AttributeNameFormat'.
(Unfortunately, we are not consistent with the naming of this option,
and that inconsistency has propagated into metadata building and
parsing. In IdP configuration (saml20-idp-hosted and saml20-sp-remote),
this option is named AttributeNameFormat, while in SP configuration in
config/authsources.php (and metadata/saml20-sp-hosted.php), it is named
'attributes.NameFormat'.)
I'll look into changing it.
[...]
> So what if AttributeLimit would use the attributes.NameFormat
> information of the SP metadata to filter the attributes? It would
> convert the attributes in the SP metadata to the 'name' format before
> comparing them to the attributes in the $state array.
I think the correct solution would be to have a better system for the
actual output of attributes, since what we actually want to do is to
just select which attributes the SP should receive. There is no reason
that filtering and mapping can not be performed as one operation.
Unfortunately, it would require some rethinking of how the IdP outputs
attributes.
Best regards,
Olav Morken
UNINETT / Feide
Lorenzo Gil Sanchez
I already did that (sorry for omitting that part) as I read about it
in the docs:
http://simplesamlphp.org/docs/1.8/simplesamlphp-reference-sp-remote
but that does not change the fact that the AttributeLimit filter out
the attributes unless you put the AttributeMap name2oid before the
AttribteLimit filter.
However (and I didn't notice this the first time), this fixes the
problem that the Assertion sent inside the AuthenticationResponse is
now correct:
<saml:AttributeStatement xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<saml:Attribute Name="urn:oid:0.9.2342.19200300.100.1.1"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue ns1:type="xs:string"
xmlns:ns1="http://www.w3.org/2001/XMLSchema-instance">test</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue ns1:type="xs:string"
xmlns:ns1="http://www.w3.org/2001/XMLSchema-instance">member</saml:AttributeValue>
<saml:AttributeValue ns1:type="xs:string"
xmlns:ns1="http://www.w3.org/2001/XMLSchema-instance">student</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
As you can see, now the NameFormat attribute of the <saml:Attribute>
element is correct :-)
Thanks for your response, Olav.
Best regards,
Lorenzo
> (Unfortunately, we are not consistent with the naming of this option,
> and that inconsistency has propagated into metadata building and
> parsing. In IdP configuration (saml20-idp-hosted and saml20-sp-remote),
> this option is named AttributeNameFormat, while in SP configuration in
> config/authsources.php (and metadata/saml20-sp-hosted.php), it is named
> 'attributes.NameFormat'.)
>
> I'll look into changing it.
>
> [...]
>> So what if AttributeLimit would use the attributes.NameFormat
>> information of the SP metadata to filter the attributes? It would
>> convert the attributes in the SP metadata to the 'name' format before
>> comparing them to the attributes in the $state array.
>
> I think the correct solution would be to have a better system for the
> actual output of attributes, since what we actually want to do is to
> just select which attributes the SP should receive. There is no reason
> that filtering and mapping can not be performed as one operation.
>
> Unfortunately, it would require some rethinking of how the IdP outputs
> attributes.
>
> Best regards,
> Olav Morken
> UNINETT / Feide
>
> --
> You received this message because you are subscribed to the Google Groups "simpleSAMLphp" group.
> To post to this group, send email to simple...@googlegroups.com.
> To unsubscribe from this group, send email to simplesamlph...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/simplesamlphp?hl=en.
>
Olav Morken
> 2012/3/16 Olav Morken <olav....@uninett.no>:
> > Actually, it is not. It seems that the XML metadata parser disagrees
> > with what the simpleSAMLphp IdP expects. Try to replace
> > 'attributes.NameFormat' with 'AttributeNameFormat'.
> >
>
> I already did that (sorry for omitting that part) as I read about it
> in the docs:
>
> http://simplesamlphp.org/docs/1.8/simplesamlphp-reference-sp-remote
>
> but that does not change the fact that the AttributeLimit filter out
> the attributes unless you put the AttributeMap name2oid before the
> AttribteLimit filter.
Yes, that is because nothing cares about the attribute NameFormat in
simpleSAMLphp, except for the code that actually generates the
assertion.
This is something I'd rather not change, but (as I mentioned in my
previous mail), I think it would be better to create a simpler
configuration on the IdP for this. E.g. one option that configures how
the IdP creates the different attributes, and then the SP could just
list which attributes it wants.
> However (and I didn't notice this the first time), this fixes the
> problem that the Assertion sent inside the AuthenticationResponse is
> now correct:
Yes, the goal was to fix the NameFormat on the attributes that are sent.
I just committed r3049, which changes the IdP code to look for
'attributes.NameFormat' before it looks for 'AttributeNameFormat', and
updated all the documentation to refer to 'attributes.NameFormat'.