Custom Principal & Authentication Data Passing

[Cantor, Scott]

On 6/9/15, 9:20 PM, "cneberg" <cneberg at gmail.com> wrote:


>Summary:
>
>I need a UserNamePrincipal object in the subject or I get 
>urn:oasis:names:tc:SAML:2.0:status:UnknownPrincipal back to the SP when I 
>try to use my plugin.  Shib won't use my custom Principal for this.

No, you can, but you'd have to write a subject c14n flow to do the 
eventual mapping. It has to be able to produce a username in the end, and 
if it can't get it from a built-in type, then you have to program it to 
get it from somewhere else. There's no requirement in the design for 
UsernamePrincipal, it's just a convention.by cu

>But I can create a UserNamePrincipal based on the value of RemoteUser and 
>pass it into the subject, and then ADDITIONALLY add my custom Principal 
>which keeps track of the additional attributes.

Or that, yes.

>My external authentication class populates the subject like this.
>
>
>//my custom principal with its custom attributes
>
>ExtendedRemoteUserAuthPrincipal princ_attribs = new 
>ExtendedRemoteUserAuthPrincipal("custom_attrib=value1,custom_attrib2=value
>2");

Well, that wouldn't really be how I'd do it, you really should just have 
your Principal subtype carry a map or whatever, or specific properties. 
Playing games with strings I suppose works, but it's certainly not 
necessary.

Otherwise that's all correct.

>I'm not sure if need the custom serializer class now, now that I figured 
>out how to use the generic one.

Your choice. You wanted comments, so my comment is that I don't believe in 
hiding data inside strings, I'd just create my own Serializer class, 
they're not really that much work when the data is simple anyway.

>I could even minimize my own symbols - by creating an encoder/decoder as 
>functions of my own principal object.

Yes.

>Thanks everyone for your help!

Thank you for your persistence and for exercising the design. It's not 
very easy to tell when things work or not when it's mostly in one's head.

-- Scott