SSP IdP to Shib SP - attribute release conundrum

[Martin Hamilton]

Hey folks, can anyone advise on recommended settings for an SSP IdP to push scoped attributes via SAML2 POST to a Shibboleth 2 SP?

I have a couple of test installations and have gotten the two talking to each other to the extent that I am able to authenticate as a test user and check my session status via https://my.sp.name/Shibboleth.sso/Session, but struggling with sending attributes.  FYI my Shibboleth log says things like...

2011-03-03 17:44:47 WARN Shibboleth.AttributeFilter [25]: removed value at position (0) of attribute (eppn) from (https://foo.bar/simplesaml/saml2/idp/metadata.php)
2011-03-03 17:44:47 WARN Shibboleth.AttributeFilter [25]: no values left, removing attribute (eppn) from (https://foo.bar/simplesaml/saml2/idp/metadata.php)

Here's an excerpt of my saml2-sp-remote config...

    'AttributeNameFormat'  => 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri',

    'simplesaml.attributes'      => true,

    'attributes'                 => array('urn:oid:1.3.6.1.4.1.5923.1.1.1.6', 'urn:oid:1.3.6.1.4.1.5923.1.1.1.10'),

    'base64attributes'           => false,

    'scopedattributes'           => array('urn:oid:1.3.6.1.4.1.5923.1.1.1.6','urn:oid:1.3.6.1.4.1.5923.1.1.1.10'),

    'attributeencodings' => array(

        'urn:oid:1.3.6.1.4.1.5923.1.1.1.10' => 'raw', /* eduPersonTargetedID */

        'urn:oid:1.3.6.1.4.1.5923.1.1.1.6' => 'raw', /* eduPersonPrincipalName */

    ),

    'authproc' => array(

        10 => array(

                'class' => 'core:TargetedID',

                'nameId' => TRUE,

        ),

        20 => array(

            'class' => 'core:AttributeAdd',

            'urn:oid:1.3.6.1.4.1.5923.1.1.1.6' => 'f...@bar.com',

        ),

        30 => array(

                'class' => 'core:AttributeMap',

                'name2oid',

        ),

[A word about the core:AttributeAdd - my LDAP directory doesn't have eduPersonPrincipalName, but I'm aiming to map another attribute to it eventually.  Thought I would keep things simple by using a static string value to begin with :-]

My SAML assertions (snarfed via Firefox Live Headers) say things like...

<saml:AttributeStatement><saml:Attribute 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 xsi:type="xs:string">f...@bar.com</saml:AttributeValue></saml:Attribute></saml:AttributeStatement>

When I Googled around the subject I found a few people saying that "xs:string" is the wrong type for scoped attributes like eduPersonPrincipalName, and that this should be "SAML2ScopedString" instead.  However, I'm still not entirely clear on what a scoped attribute should look like in the SAML response.  Can anyone help to put me right?

Thanks in advance for your thoughts!

Cheers,

Martin

[Tom Scavo]

On Thu, Mar 3, 2011 at 12:12 PM, Martin Hamilton <m...@martinh.net> wrote:
> Hey folks, can anyone advise on recommended settings for an SSP IdP to push
> scoped attributes via SAML2 POST to a Shibboleth 2 SP?

I believe your issue is at the SP so you might want to ask further
questions on the shibboleth-users mailing list (but read on :).

> 2011-03-03 17:44:47 WARN Shibboleth.AttributeFilter [25]: removed value at
> position (0) of attribute (eppn) from
> (https://foo.bar/simplesaml/saml2/idp/metadata.php)
> 2011-03-03 17:44:47 WARN Shibboleth.AttributeFilter [25]: no values left,
> removing attribute (eppn) from
> (https://foo.bar/simplesaml/saml2/idp/metadata.php)

It seems ePPN values are being filtered at the SP.

>         20 => array(
>             'class' => 'core:AttributeAdd',
>             'urn:oid:1.3.6.1.4.1.5923.1.1.1.6' => 'f...@bar.com',
>         ),
>

> [A word about the core:AttributeAdd - my LDAP directory doesn't have
> eduPersonPrincipalName, but I'm aiming to map another attribute to it
> eventually.  Thought I would keep things simple by using a static string
> value to begin with :-]

That's okay, I guess, but do you have scope "bar.com" in the IdP's
metadata? If not, the SP will surely filter ePPN (since it will assume
the IdP is not authorized to assert scoped attributes with that
scope).

> When I Googled around the subject I found a few people saying that
> "xs:string" is the wrong type for scoped attributes like
> eduPersonPrincipalName, and that this should be "SAML2ScopedString" instead.

No, I don't think so. Keep it as a simple string.

Tom

[Martin Hamilton]

On Thu, Mar 3, 2011 at 6:29 PM, Tom Scavo <trs...@gmail.com> wrote:

That's okay, I guess, but do you have scope "bar.com" in the IdP's

metadata? If not, the SP will surely filter ePPN (since it will assume
the IdP is not authorized to assert scoped attributes with that
scope).

Bingo!  Thanks a million for that - all working now :-)

This was a bit convoluted to set up, so perhaps one worth adding to the documentation, a la Google Apps.

This IdP had managed to interoperate with other instances of SSP and also Guanxi without me having to define a scope in saml20-idp-hosted.php.  However, something along these lines did the trick...

  scope => array('foo.com','bar.com'),

In terms of saml20-sp-remote.php, I found that it was very easy to generate a SAML response that looked OK on the wire, but that Shibboleth (out of the box config at least) barfed on for one reason or another.  FYI here is what I settled on as a template for releasing eduPersonTargetedId and/or eduPersonPrincipalName to Shibboleth SPs...

  $metadata['https://wibble.com/shibboleth'] = array(

    'AssertionConsumerService'   => 'https://wibble.com/Shibboleth.sso/SAML2/POST',

    'AttributeNameFormat'  => 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri', 

    'NameIDFormat'               => 'urn:oasis:names:tc:SAML:2.0:nameid-format:email',

    'simplesaml.nameidattribute' => 'mail',

    'simplesaml.attributes'      => true,

    'attributes' => array('mail','eduPersonTargetedID'),

    'userid.attribute' => 'mail',

    'assertion.encryption' => true,

    'certificate' => 'mycert.pem',

    'base64attributes' => false,

    'redirect.sign' => true,

    'attributeencodings' => array(

        'urn:oid:1.3.6.1.4.1.5923.1.1.1.10' => 'raw', /* eduPersonTargetedID */

        'urn:oid:1.3.6.1.4.1.5923.1.1.1.6' => 'raw', /* eduPersonPrincipalName */

    ),

    'authproc' => array(

        10 => array(

         'class' => 'core:TargetedID',

'nameId' => TRUE,

        ),

50 => array(

'class' => 'core:AttributeMap',

'mail2eppn',

),

60 => array(

'class' => 'core:AttributeMap',

'name2oid',

),

    ),

  );

Then I added 'mail2eppn.php' in the attributemap directory to remap the 'mail' attribute pulled out of our Active Directory to be the eduPersonPrincipalName...

  $attributemap = array(

    'mail' => 'eduPersonPrincipalName',

  );

Thanks again for your help - much appreciated!

Cheers,

Martin

[Tom Scavo]

On Thu, Mar 3, 2011 at 5:21 PM, Martin Hamilton <m...@martinh.net> wrote:
>
> This IdP had managed to interoperate with other instances of SSP and also
> Guanxi without me having to define a scope in saml20-idp-hosted.php.

Scope is one of those deep dark secrets of the universe so I'm not surprised ;-)

>  However, something along these lines did the trick...
>   scope => array('foo.com','bar.com'),

This works fine for a plain vanilla IdP, but what about an IdP Proxy
for which the value of scoped attributes is not known in advance? In
that case, there is usually no static set of scopes that will work, so
the only recourse it seems is to work with SP partners to relax their
filter policy.

Tom