Extract Attribute Problem

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Extract Attribute Problem

Sébastien PIAU-2
Hello,

I have no problem in order to extract attributes from Test Shib Two IdP, but when I try to extract attributes from an assertion from another IdP, I can't access them.

I've added attributes names in attribute-map.xml, and simplify attribute-
policy.xml as follow :

Attribute-map.xml :

...
    <Attribute name="fn" id="name"/>
    <Attribute name="ln" id="firstName"/>
    <Attribute name="email" id="mail"/>
    <Attribute name="tno" id="telephoneNumber"/>
</Attributes>

Attribute-policy.xml :
 
<afp:AttributeFilterPolicyGroup
    xmlns="urn:mace:shibboleth:2.0:afp:mf:basic"
    xmlns:basic="urn:mace:shibboleth:2.0:afp:mf:basic"
    xmlns:afp="urn:mace:shibboleth:2.0:afp"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    <afp:AttributeFilterPolicy>
        <!-- This policy is in effect in all cases. -->
        <afp:PolicyRequirementRule xsi:type="ANY"/>
        <afp:AttributeRule attributeID="*">
            <afp:PermitValueRule xsi:type="ANY"/>
        </afp:AttributeRule>

    </afp:AttributeFilterPolicy>

</afp:AttributeFilterPolicyGroup>

and the sample assertion content (not encrypted)
 
...
        <ns2:AttributeStatement>
            <ns2:Attribute Name="fn" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
                <ns2:AttributeValue>My First Name</ns2:AttributeValue>
            </ns2:Attribute>
            <ns2:Attribute Name="ln" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
                <ns2:AttributeValue>My Name</ns2:AttributeValue>
            </ns2:Attribute>
            <ns2:Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
                <ns2:AttributeValue>[hidden email]</ns2:AttributeValue>
            </ns2:Attribute>
            <ns2:Attribute Name="tno" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
                <ns2:AttributeValue>1234567890</ns2:AttributeValue>
            </ns2:Attribute>
        </ns2:AttributeStatement>
    </ns2:Assertion>
</Response>


Thanks in advance,


--
Sébastien PIAU
 
 
0954 59 4905 - 06 88 11 658
 
Adoptez l'éco-attitude.
N'imprimez ce message que si cela est vraiment nécessaire.
 
Reply | Threaded
Open this post in threaded view
|

Re: Extract Attribute Problem

Peter Schober
* Sébastien PIAU <[hidden email]> [2009-06-22 15:41]:

> I've added attributes names in attribute-map.xml, and simplify
> attribute-policy.xml as follow :
>
> *Attribute-map.xml :*
>
> ...
>     <Attribute name="*fn*" id="name"/>
>     <Attribute name="*ln*" id="firstName"/>
>     <Attribute name="*email*" id="mail"/>
>     <Attribute name="*tno*" id="telephoneNumber"/>
> </Attributes>
[...]
>         <ns2:AttributeStatement>
>             <ns2:Attribute Name="*fn*"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
>                 <ns2:AttributeValue>My First Name</ns2:AttributeValue>
>             </ns2:Attribute>


For one you shouldn't need to define new attributes for common (and
existing) things like givenname, sn, mail, telephonenumber (on the IdP
side and hence as well on the SP side). Just use the existing
definitions. Second, attriute names should be fully qualified URNs,
for SAML2 preferrably OID-style as per the MACE-Dir SAML Attribute Proile:
http://middleware.internet2.edu/dir/docs/internet2-mace-dir-saml-attributes-200804.pdf

This also saves making changes to all the SPs on the recieving end
(since the distributed attribute-map already contains mapping for all
those).
-peter
Reply | Threaded
Open this post in threaded view
|

Re: Extract Attribute Problem

Cantor, Scott E.
In reply to this post by Sébastien PIAU-2
Sébastien PIAU wrote on 2009-06-22:
> I've added attributes names in attribute-map.xml, and simplify attribute-
> policy.xml as follow :
>
> Attribute-map.xml :
>
>     <Attribute name="fn" id="name"/>

That's not a valid attribute name unless the IdP is willing to send
non-interoperable strings as names. Attribute names should be URIs and the
SP comes packaged with a ton of mappings that follow the appropriate
profiles.

> Attribute-policy.xml :

Are you trying to filter the attributes or do you just want to accept them
from any trusted IdP? If the latter, you shouldn't touch that file.

> and the sample assertion content (not encrypted)

So, what you're doing is intentionally making life hard by using
non-interoperable attribute names. Your problem here is that the SP makes it
intentionally harder to accept attributes with bogus names by defaulting the
NameFormat to the "URI" value defined by SAML in the attribute mapping file.

If you want to use "unspecified", then you have to explicitly add a
nameFormat XML attribute to those mappings containing the
"urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" string.

See https://spaces.internet2.edu/display/SHIB2/NativeSPAttributeExtractor

The best fix is to make the IdP send properly-defined attributes.
 
-- Scott



Reply | Threaded
Open this post in threaded view
|

Re: Extract Attribute Problem

Peter Schober
In reply to this post by Peter Schober
* Peter Schober <[hidden email]> [2009-06-22 16:35]:
> definitions. Second, attriute names should be fully qualified URNs,
> for SAML2 preferrably OID-style as per the MACE-Dir SAML Attribute Proile:
> http://middleware.internet2.edu/dir/docs/internet2-mace-dir-saml-attributes-200804.pdf

Of course that should have been URIs (not URNs), as the link shows and
Scott has also pointed out in his answer. Sorry for the typo/braino,
-peter
Reply | Threaded
Open this post in threaded view
|

Re: Extract Attribute Problem

Sébastien PIAU-2
In reply to this post by Cantor, Scott E.
Thanks a lot everybody,

Attributes are correctly extracted by adding the nameFormat attribute in the attribute-map.xml.
I've asked to obtain-properly defined attributes from the IdP side.


Sébastien PIAU
 
 
0954 59 4905 - 06 88 11 658
 
Adoptez l'éco-attitude.
N'imprimez ce message que si cela est vraiment nécessaire.
 


Scott Cantor a écrit :
Sébastien PIAU wrote on 2009-06-22:
  
I've added attributes names in attribute-map.xml, and simplify attribute-
policy.xml as follow :

Attribute-map.xml :

    <Attribute name="fn" id="name"/>
    

That's not a valid attribute name unless the IdP is willing to send
non-interoperable strings as names. Attribute names should be URIs and the
SP comes packaged with a ton of mappings that follow the appropriate
profiles.

  
Attribute-policy.xml :
    

Are you trying to filter the attributes or do you just want to accept them
from any trusted IdP? If the latter, you shouldn't touch that file.

  
and the sample assertion content (not encrypted)
    

So, what you're doing is intentionally making life hard by using
non-interoperable attribute names. Your problem here is that the SP makes it
intentionally harder to accept attributes with bogus names by defaulting the
NameFormat to the "URI" value defined by SAML in the attribute mapping file.

If you want to use "unspecified", then you have to explicitly add a
nameFormat XML attribute to those mappings containing the
"urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" string.

See https://spaces.internet2.edu/display/SHIB2/NativeSPAttributeExtractor

The best fix is to make the IdP send properly-defined attributes.
 
-- Scott