Attributes being removed from SAML1 Service Provider because they cannot be encoded.

[Cantor, Scott E.]

On 8/2/11 1:16 PM, "Khanna, Sumit (khannast)" <khannast at ucmail.uc.edu>
wrote:

>Sorry, I'm a little confused. So using SAML1, are SPs supposed to pull
>attributes via the backchannel (is pushing not supported at all in
>SAML1?) I
>contacted support for NIH (the SP) and was told "our federation product is
>CA siteminder and this is not capable of pulling SAML1 attributes through
>backchannel."

Most commercial SPs don't do queries. There is no "should", you do what
you choose to do. If you're fine with plaintext in the browser, you can
push them all. If not, you can default to queries and push as a special
case. Or refuse, your choice.

>I was also a little confused because they required the following
>attributes
>to be released:

That's all standard (via profile) SAML 1.1 except for the OID, which is
the special case of eduPersonPrincipalName encoded in a way that
commercial SPs will handle (scope inside the value). This is covered in
the I2MI attribute profile material that binds eduPerson to SAML.

>In our attribute-resolver, we have all the urn:mace.. for the SAML1String
>and SAML1XMLObject types and we use the OID for all the SAML2 types. The
>OID
>1.3.6.1.4.1.5923.1.1.6 already represents the eduPersonPrincipalName, so I
>asked why it was included twice and was told:

That's accurate.

>I'm kinda lost here. Do I define a new parameter as a SAML1String using
>the
>OID and how do I push those attributes via SAML1?

You may be able to add a a second SAML 1 encoder to the existing EPPN
definition with the OID specified and it will generate both. Or not, since
I'm creating a second definition for the workaround attribute in my IdP
and releasing it explicitly. I probably did that for a reason, but maybe I
just didn't try the easier way.

Configuring push is covered in the wiki under per-relying party setup.

-- Scott