Custom Principal & Authentication Data Passing

[Cantor, Scott]

On 6/8/15, 11:35 PM, "cneberg" <cneberg at gmail.com> wrote:


>
>I'd like it to survive SSO between multiple SP's.   Currently it works to 
>the first SP, but then succeeds copying the principal name to the second 
>but appears to loose all of the extra attributes I pulled from it 
>originally.

Yes, that's the serialization requirement.

>It also only appears to work if I my class extends UsernamePrincipal 
>otherwise it gives  urn:oasis:names:tc:SAML:2.0:status:UnknownPrincipal.

I don't follow. That's a SAML status code, so if you're getting that in 
response to an SP's request, it's not because of anything we're talking 
about...

>When you say serialization do you mean normal java serialization - which 
>my principal supports (stand alone it does any way, java serialization 
>fails when I extend UsernamePrincipal), or serialization to json like is 
>done in the GenericPrincipalSerializer.java
> and if its the latter, how do I register my own serializer?

Not a simple answer, but for now, the simplest way is to violate the 
system/ rules and edit system/conf/general-authn-system.xml file and just 
track it across upgrades.

The "correct" way right now is to duplicate/modify the bean called 
"shibboleth.DefaultAuthenticationResultSerializer" in that file into 
general-authn.xml, and add your own bean(s) to the principalSerializers 
property. You would then inject your new bean in any flow that was 
handling your Principal subtype via p:resultSerializer-ref inside the flow 
descriptor in general-authn.xml (overriding the use of the default bean).

If you file a RFE, I'll look at exposing that machinery better so you can 
add your own serializers. I didn't know how to handle that when that was 
all sketched out, but I have betters ways of doing it now with list 
merging and I never went back to this.

>I don't know the expected max size of a serialized session, is there an 
>recommended maxium size?   

Very small, unless you're not using the cookie-based store. Total Safari 
cookie size per domain is 8k. The serializer machinery allows you to add 
symbolics to compress into numbers also. But if it's not constant data, 
that obviously won't help much.

>Depending on the size I might consider only putting a random ID in the 
>principal and instead provisioning authenticated identity to a temp data 
>store and writing a data store plugin to look up the ID at attribute 
>resolution time.

That would suggest to me you could dump the client side store anyway if 
you have a data store you can replicate like that, and then you don't need 
to care about size.

-- Scott