SP ignoring unscoped AttributeValue?

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

SP ignoring unscoped AttributeValue?

Vivek Balagangadharan

Hello All,

 

The SP is trying to retrieve 2 attributes: eduPersonTargetedId and eduPersonAffiliation.

 

I get the affiliation, but not the targeted-id. I checked with the IDP, and they are sending both the attributes.

 

The logs at the SP show:

 

Shibd.log

2009-01-07 00:44:37 WARN Shibboleth.AttributeDecoder.Scoped [191]: ignoring unscoped AttributeValue

2009-01-07 00:44:37 INFO Shibboleth.SessionCache [191]: new session created: ID (_eb911bda8eafd6374f567d235b4fa282) IdP (https:// [idp_host]) Protocol(urn:oasis:names:tc:SAML:1.1:protocol) Address (XXX.XXX.95.51)

 

Transaction.log

2009-01-07 00:44:37 INFO Shibboleth-TRANSACTION [191]: New session (ID: _eb911bda8eafd6374f567d235b4fa282) with (applicationId: default) for principal from (IdP: https:// [idp_host]) at (ClientAddress: XXX.XXX.95.51) with (NameIdentifier: _3daafbebaadd9f96dd9494a159853948f1a099d801) using (Protocol: urn:oasis:names:tc:SAML:1.1:protocol) from (AssertionID: _efa9677f02988c21160a4135bca125d0a7096c6c34)

2009-01-07 00:44:37 INFO Shibboleth-TRANSACTION [191]: Cached the following attributes with session (ID: _eb911bda8eafd6374f567d235b4fa282) for (applicationId: default) {

2009-01-07 00:44:37 INFO Shibboleth-TRANSACTION [191]:            unscoped-affiliation (1 values)

2009-01-07 00:44:37 INFO Shibboleth-TRANSACTION [191]: }

 

I checked with the IDP and they are sending “urn:mace:dir:attribute-def:eduPersonTargetedID” attribute.

 

Our guess right now, based on the logs is that the SP is ignoring the attribute. Do you know if it is true?

 

The attribute-map.xml at the SP has:

<Attribute name="urn:mace:dir:attribute-def:eduPersonTargetedID" id="targeted-id">

        <AttributeDecoder xsi:type="ScopedAttributeDecoder"/>      

</Attribute>

 

Should I change the AttributeDecoder to StringAttributeDecoder? Or would you recommend that the IDP make some changes at it’s end to send a scoped attribute value?

 

My SP is connected to many IDPs and with this change, will I break something that is already working with some IDP?

 

Thanks in advance for the help,

 

Vivek Balagangadharan

Reply | Threaded
Open this post in threaded view
|

RE: SP ignoring unscoped AttributeValue?

Cantor, Scott E.
> I checked with the IDP and they are sending "urn:mace:dir:attribute-
> def:eduPersonTargetedID" attribute.

This is a deprecated attribute that has "issues" and should be avoided when
possible. The main requirement to avoid it is that SPs running the newer
software should migrate/rekey systems to rely on the newer, non-deprecated
syntax, and then use the tools provided with the SP to handle IdPs that are
sending the deprecated syntax.

I will document this in a wiki topic today if possible and send a link to
the list.
 
> Our guess right now, based on the logs is that the SP is ignoring the
> attribute. Do you know if it is true?

It's ignoring it because it was sent in an invalid, unscoped form. The IdP
is configured incorrectly.

> Should I change the AttributeDecoder to StringAttributeDecoder?

That won't fix the broken IdP, and it will also disable scope checking of
any deprecated values you get, allowing an IdP to spoof the IDs of another.

> Or would you
> recommend that the IDP make some changes at it's end to send a scoped
> attribute value?

This isn't a choice. IdPs don't just get to send whatever they want and you
should never accommodate such a thing.

> My SP is connected to many IDPs and with this change, will I break
something
> that is already working with some IDP?

You will alter the values you get from most of the IdPs.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: SP ignoring unscoped AttributeValue?

Cantor, Scott E.
In reply to this post by Vivek Balagangadharan
Alright, a draft of some material about dealing with targetedID is now
available.

https://spaces.internet2.edu/display/SHIB2/NativeSPTargetedID

When you see the length, you'll understand why it took all day and why it
hasn't been done before, but hopefully this will help.

To cut to the chase, you'll find my best practice suggestions near the end.
If you do them, things will work nicely. If you don't, they won't, and
that's just life at the moment.

HTH,
-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: SP ignoring unscoped AttributeValue?

peter williams-3
Is the concept of putting the nameid in an attribute an intended construct of SAML2, or a mere sideeffect of someone happenstance defining the type of an attribute value to be a nameid (just as someone else might define another value type to be an assertion, or assertion|nameid)?

Presumably, an assertion delivered as a value is not subject to intended recipient controls. As SP would simply deliver it to the app, unaware of the controls within the assertion.

> -----Original Message-----
> From: Scott Cantor [mailto:[hidden email]]
> Sent: Thursday, January 08, 2009 4:46 PM
> To: [hidden email]
> Subject: RE: [Shib-Users] SP ignoring unscoped AttributeValue?
>
> Alright, a draft of some material about dealing with targetedID is now
> available.
>
> https://spaces.internet2.edu/display/SHIB2/NativeSPTargetedID
>
> When you see the length, you'll understand why it took all day and why
> it
> hasn't been done before, but hopefully this will help.
>
> To cut to the chase, you'll find my best practice suggestions near the
> end.
> If you do them, things will work nicely. If you don't, they won't, and
> that's just life at the moment.
>
> HTH,
> -- Scott
>

Reply | Threaded
Open this post in threaded view
|

RE: SP ignoring unscoped AttributeValue?

Cantor, Scott E.
> Is the concept of putting the nameid in an attribute an intended construct
> of SAML2, or a mere sideeffect of someone happenstance defining the type
of
> an attribute value to be a nameid (just as someone else might define
another
> value type to be an assertion, or assertion|nameid)?

SAML has nothing to say about attribute values except where its attribute
profiles are involved or in its treatment of xsi:type, which is to say that
it should never be used with non-built-in types.

BTW, as a matter of XML schema, the "type" of the attribute value in our
formulation of eduPersonTargetedID is not a NameID. It's a complex, unnamed
type whose only content is a NameID element. Not the same thing. For
example, this is what a NameID-typed value would look like:

<saml2:AttributeValue xsi:type="saml2:NameIDType"
        Format="..." NameQualifier="..." SPNameQualifier="...">
  1234567890
</saml2:AttributeValue>

If it's confusing, then you understand why I didn't do it that way.

> Presumably, an assertion delivered as a value is not subject to intended
> recipient controls. As SP would simply deliver it to the app, unaware of
the
> controls within the assertion.

I suppose that would depend on the use case, but if I were writing some kind
of plugin that was meant to process them, I would certainly be inclined to
process them according to SAML core, or at least expose the option to do so.
It would probably depend on whether I was trying to pass the assertion as
the value or the contents of the assertion as the value(s).

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: SP ignoring unscoped AttributeValue?

Vivek Balagangadharan
In reply to this post by Cantor, Scott E.
Thank you, Scott. This is very helpful.

Regards,
Vivek

-----Original Message-----
From: Scott Cantor [mailto:[hidden email]]
Sent: Thursday, January 08, 2009 9:43 PM
To: [hidden email]
Subject: RE: [Shib-Users] SP ignoring unscoped AttributeValue?

> I checked with the IDP and they are sending "urn:mace:dir:attribute-
> def:eduPersonTargetedID" attribute.

This is a deprecated attribute that has "issues" and should be avoided when
possible. The main requirement to avoid it is that SPs running the newer
software should migrate/rekey systems to rely on the newer, non-deprecated
syntax, and then use the tools provided with the SP to handle IdPs that are
sending the deprecated syntax.

I will document this in a wiki topic today if possible and send a link to
the list.
 
> Our guess right now, based on the logs is that the SP is ignoring the
> attribute. Do you know if it is true?

It's ignoring it because it was sent in an invalid, unscoped form. The IdP
is configured incorrectly.

> Should I change the AttributeDecoder to StringAttributeDecoder?

That won't fix the broken IdP, and it will also disable scope checking of
any deprecated values you get, allowing an IdP to spoof the IDs of another.

> Or would you
> recommend that the IDP make some changes at it's end to send a scoped
> attribute value?

This isn't a choice. IdPs don't just get to send whatever they want and you
should never accommodate such a thing.

> My SP is connected to many IDPs and with this change, will I break
something
> that is already working with some IDP?

You will alter the values you get from most of the IdPs.

-- Scott