[Shib-Users] Mapping multiple attriubtes to one header

[Leung, Warren]

Hi,

We currently run a federated 1.3 SP and I was wondering if you could map multiple attributes to one header.  The scenario we happened to stumble on, is that certain IdPs are sending us urn based ePPN and other are sending us oid based ePPN.  We need to map ePPN to REMOTE_USER.  What I ended up doing in the AAP is posted below.

<AttributeRule Name="urn:mace:dir:attribute-def:eduPersonPrincipalName" Scoped="true" Header="REMOTE_USER" Alias="user">
        <AnySite>
                <Value Type="regexp">^[^@]+$</Value>
        </AnySite>
</AttributeRule>

<AttributeRule Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" Scoped="true" Header="REMOTE_USER" Alias="user2">
        <SiteRule Name="Some entityID">
                <Value Type="regexp">^[^@]+$</Value>
        </SiteRule>
</AttributeRule>

This ends up working but it is not very scalable since we would have to add a new SiteRule for each IdP sending us an oid based ePPN in this scenario.  Even if we flipped it around, the same thing would have to occur for urn based ePPN.

We plan on upgrading to a 2.1 SP very soon, so if nothing can be done on a 1.3 SP is there anything that can be done on a 2.1 SP.

Thanks

Warren

[Chad La Joie]

I don't think there is anything that can be done in 1.3. In 2.X this
works fine. The default configuration is already set up to handle most
of this I think, but in general you set up two attribute decoders that
dump their information in to the same SP-internal attribute data
structure then you use the mapper to take that attribute and map it to
some HTTP header. The REMOTE_USER header works a bit differently, but
that's the basic jist of it.

You may want to talk with the IdP as well. They probably shouldn't be
using the OID naming scheme for SAML 1 messages. That was something
that was introduced with SAML 2 so it's unlikely that any SAML 1 system
is going to "just support" that.

--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
chad....@switch.ch, http://www.switch.ch

[Bruc Liong]

> This ends up working but it is not very scalable since we would have to add
> a new SiteRule for each IdP sending us an oid based ePPN in this scenario.

Why can't you use AnySite for your OID-based ePPN? Will there be any specific IdPs that would send OID in ePPN and yet not being accepted/mapped to remote user? I would have thought that both OID-based and URN-based could simply be using AnySite.

Bruc

[Scott Cantor]

Yes, you're just imposing site-specific rules without any reason to do so.

But the OID-based version of EPPN is defined for SAML 1.1 as long as you don't define it as a scoped attribute to the old SP. If you do that, it will fail. Using the OID is how you express that the IdP can't support our XML syntax for scopes, and flattens the string. Otherwise the IdP should use the original attribute name.

-- Scott

[Mahabalagiri, Datta]

How do we configure this in a standard way without having to worry about whether your relying party is Shibboleth SP or some Commercial product, SAML1.1 or SAML2 ?

We are dealing with v1.3 SPs and some on v2.1. We are planning to upgrade ourselves, from IdP 1.3 to 2.1.

I looked at the article https://spaces.internet2.edu/display/SHIB2/IdPCommercialInterop. I configured the resolver as in the article; scope is ucla.edu and principal name is joe-bruin. This is what I get

SAML1.1:
<saml:Attribute AttributeName="urn:mace:dir:attribute-def:eduPersonPrincipal
Name" AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri">
<saml:AttributeValue Scope="ucla.edu">joe-bruin</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute AttributeName="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" AttributeNa
espace="urn:mace:shibboleth:1.0:attributeNamespace:uri">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs
="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">joe-...@ucla.edu</saml:AttributeValue>
</saml:Attribute>


SAML2:
<saml:Attribute FriendlyName="eduPersonPrincipalName" Name="urn:oid:1.3.6.1.4
.1.5923.1.1.1.6" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi
="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">joe-...@ucla.edu</saml:AttributeValue>
</saml:Attribute>

Is it the recommended approach then?

--Datta

[Scott Cantor]

Mahabalagiri, Datta wrote on 2009-03-29:
> How do we configure this in a standard way without having to worry about
> whether your relying party is Shibboleth SP or some Commercial product,
> SAML1.1 or SAML2 ?

You follow the profiles defined for the Shibboleth community unless you're forced to work around something.

> We are dealing with v1.3 SPs and some on v2.1. We are planning to upgrade
> ourselves, from IdP 1.3 to 2.1.

If you follow the attribute profiles published, the right things will happen regardless of the version.

> Is it the recommended approach then?

Yes. When you run into a broken SAML 1.1 SP, you can release the OID-named version of EPPN to that SP and not affect any of the others.

-- Scott