Custom Principal & Authentication Data Passing

[cneberg]

Thanks everyone!   I've got it working now allowing the same extra
attributes to display across multiple sites.

[Daniel Fisher] >> Does your custom principal have a constructor that takes
a single string as the name? The GenericPrincipalSerializer requires that
convention.

Thank you.  That tipped helped.  My custom Principal can use the
GenericPrincipalSerializer
successfully iff the new principal constructor takes a string, AND that
string is the equivalent of what  its getName returns.  ie you can pass the
value of getName() from one of my objects into the constructor of another,
and get the equivalent object.

Let me pass this by the list to see if it looks correct.

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.
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.

So My custom principal is implemented like this.

public class ExtendedRemoteUserAuthPrincipal implements Serializable,
CloneablePrincipal

private String name;

public ExtendedRemoteUserAuthPrincipal(String arg) {
    name = arg;
}

// empty constructor required by Serializable interface
public void ExtendedRemoteUserAuthPrincipal() {
    name = "";
}

public String getName() {
    //equivalent to what goes into the constructor
    return name;
}

....

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=value2");

// the auth context class which I would like returned in SAML (fails to do
anything useful) because I have multiple auth types in the
general-authn.xml file and need to use the
shibboleth.authn.External.addDefaultPrincipal param for the trunk.
AuthnContextClassRefPrincipal contextclass_princ = new
AuthnContextClassRefPrincipal("urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport");

// real authenticated username
UsernamePrincipal principal = new UsernamePrincipal(remoteUser);

HashSet<Principal> principals = new HashSet<Principal>();

/* add all the principals together into the subject */
principals.add(principal);
principals.add(princ_attribs);
principals.add(contextclass_princ);

final Subject subject = new Subject(false, principals, emptySet1,
emptySet2);

/* set the subject into the external auth provider */
request.setAttribute(net.shibboleth.idp.authn.ExternalAuthentication.SUBJECT_KEY,
subject);

..............

>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.

ok.  That's not a lot of space.

I'm not sure if need the custom serializer class now, now that I figured
out how to use the generic one.
I could even minimize my own symbols - by creating an encoder/decoder as
functions of my own principal object.

>>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.

True, I will if I have size issues I would just have to take the time to
build the code to access a store like that maybe a sql DB, memcache, etc.

Thanks everyone for your help!

-Topher

On Tue, Jun 9, 2015 at 9:07 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> 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
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150609/c3626240/attachment-0001.html>