> I thought I'd done everything I needed to (both from following their guide and from what I remember
> needing to do for other attributes we release elsewhere). Which bit of config are you thinking of?
If you want it as an attribute you'll need to specify an "Attribute" attribute encoder like "SAML2String" (not "SAML2StringNameID").
But that MS page seems to be saying you need to specify a unique (in time and space) NameID and that objectID is a good idea to use.
It seems to say that the only "attribute" attribute (as opposed to "NameID" attribute) it wants is UserId.
Do you have another attribute declaration trying to generate a NameID? (i.e. with a xxxxNameID encoder)? You might try removing
that if you do have one and see whether the NameID turns into anything. In the default attribute-encoder it 'transientID' is
declared for the NameID and this might be trumping your declaration.
> -----Original Message-----
> From: Discussion list for Shibboleth developments [mailto:[log in to unmask]] On Behalf Of
> Matthew Slowe
> Sent: 08 August 2012 15:04
> To: [log in to unmask]
> Subject: Re: [Am I being a dunce?] Attribute ImmutableID was not encoded because no
> SAML2AttributeEncoder was attached to it.
>
> On 8 Aug 2012, at 14:52, Rod Widdowson <[log in to unmask]> wrote:
>
> >> Unfortunately, Shibboleth (2.3.6) is discarding the ImmutableID
> >> attribute because "no SAML2AttributeEncoder was attached to it." (grepped logs below).
> >
> > That may be OK - you have told Shibboleth to take this ImmutableID and encode it in the "NameID"
> part of the "packet of stuff"
> > (technical terms) which gets sent to the SP.
> >
> > You have not told the IdP to take it and encode it in the "Attribute"
> > part of the "packet of stuff". And that is all that the logs (they are debug) are telling you.
>
> I thought I'd done everything I needed to (both from following their guide and from what I remember
> needing to do for other attributes we release elsewhere). Which bit of config are you thinking of?
>
> > If I go over to testshib
> > (https://sp.testshib.org/cgi-bin/splog.cgi?lines=15000&logname=shibd.log) and look at what the SP
> gets it includes this:
> >
> > <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
> NameQualifier="https://newt.kent.ac.uk/idp/shibboleth"
> > SPNameQualifier="https://sp.testshib.org/shibboleth-sp">_ed96dd0c72e39
> > 7f07f07e56fcd825fd7</saml2:NameID>
> >
> > So the question is whether
> > {ed96dd0c-72e3-97f0-7f-07-e5-6f-cd-82-5f-d7} is the objectguid that you have in your AD for that
> principal?
>
> I don't believe that it's the ImmutableID (which comes from objectGUID which logs report as being
> objectGUID[iS4HRolLVkujjEZ75ZdyAA==]).
>
> I've just commented out the resolver and release config for ImmutableID (which, incidentally, is
> marked as "persistent" rather than "transient") and I'm still getting a random value in there:
>
> <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
> NameQualifier="https://newt.kent.ac.uk/idp/shibboleth"
> SPNameQualifier="https://sp.testshib.org/shibboleth-
> sp">_b563b543cfcf78ccd08086cdb035c58a</saml2:NameID>
>
> Looking back through the testshib logs, each assertion contains a different one (which would make
> sense if it's transient).
>
> --
> Matthew Slowe
> Server Infrastructure Team e: [log in to unmask]
> IS, University of Kent t: +44 (0)1227 824265
> Canterbury, UK w: www.kent.ac.uk=
|