<div dir="ltr"><div>Thanks everyone! I've got it working now allowing the same extra attributes to display across multiple sites.<br><br><div><span class=""><font color="#888888">[Daniel Fisher] </font></span>>> Does your custom principal have a constructor that takes a single
string as the name? The GenericPrincipalSerializer requires that
convention.<br><br></div><div><span class=""><font color="#888888"></font></span>Thank you. That tipped helped. <span class="im">My custom Principal can use the </span>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.<br><br></div><span class=""></span></div><div>Let me pass this by the list to see if it looks correct.<br><br></div><div>Summary:<br><br>I need a UserNamePrincipal object in the subject or I get <span class="im">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.<br></span></div><div><span class="im">But I can create a </span><span class="im">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. </span><br></div><div><br></div><div>So My custom principal is implemented like this.<br><br>public class ExtendedRemoteUserAuthPrincipal implements Serializable, CloneablePrincipal<br></div><div><br>private String name;<br><br>public ExtendedRemoteUserAuthPrincipal(String arg) {<br></div><div> name = arg; <br></div><div>}<br><br>// empty constructor required by Serializable interface<br>public void ExtendedRemoteUserAuthPrincipal() {<br></div><div></div><div><div> name = ""; <br></div>}<br><br></div><div>public String getName() {<br></div><div> //equivalent to what goes into the constructor<br></div><div> return name;<br></div><div>}<br></div><div><br>....<br><br></div><div>My external authentication class populates the subject like this.<br><br></div><div>//my custom principal with its custom attributes<br></div><div>ExtendedRemoteUserAuthPrincipal princ_attribs = new ExtendedRemoteUserAuthPrincipal("custom_attrib=value1,custom_attrib2=value2");<br><br></div><div>// 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.<br></div><div>AuthnContextClassRefPrincipal contextclass_princ = new AuthnContextClassRefPrincipal("urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport");<br><br></div><div>// real authenticated username<br></div><div>UsernamePrincipal principal = new UsernamePrincipal(remoteUser);<br><br>HashSet<Principal> principals = new HashSet<Principal>();<br><br></div><div>/* add all the principals together into the subject */<br></div><div>principals.add(principal);<br>principals.add(princ_attribs);<br>principals.add(contextclass_princ);<br><br>final Subject subject = new Subject(false, principals, emptySet1, emptySet2);<br><br></div><div>/* set the subject into the external auth provider */<br></div><div>request.setAttribute(net.shibboleth.idp.authn.ExternalAuthentication.SUBJECT_KEY, subject);<br></div><div><br>..............<br><br>>Very small, unless you're not using the cookie-based store. Total Safari<br>
cookie size per domain is 8k. The serializer machinery allows you to add<br>
symbolics to compress into numbers also. But if it's not constant data,<br>
that obviously won't help much.<br><br></div><div>ok. That's not a lot of space. <br><br></div><div>I'm not sure if need the custom serializer class now, now that I figured out how to use the generic one.<br></div><div>I could even minimize my own symbols - by creating an encoder/decoder as functions of my own principal object.<br><br>>>That would suggest to me you could dump the client side store anyway if<br>
you have a data store you can replicate like that, and then you don't need<br>
to care about size.<br><br></div><div>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.<br><br></div><div>Thanks everyone for your help!<br></div><div><br>-Topher<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 9, 2015 at 9:07 AM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 6/8/15, 11:35 PM, "cneberg" <<a href="mailto:cneberg@gmail.com">cneberg@gmail.com</a>> wrote:<br>
<br>
<br>
><br>
>I'd like it to survive SSO between multiple SP's. Currently it works to<br>
>the first SP, but then succeeds copying the principal name to the second<br>
>but appears to loose all of the extra attributes I pulled from it<br>
>originally.<br>
<br>
</span>Yes, that's the serialization requirement.<br>
<span class=""><br>
>It also only appears to work if I my class extends UsernamePrincipal<br>
>otherwise it gives urn:oasis:names:tc:SAML:2.0:status:UnknownPrincipal.<br>
<br>
</span>I don't follow. That's a SAML status code, so if you're getting that in<br>
response to an SP's request, it's not because of anything we're talking<br>
about...<br>
<span class=""><br>
>When you say serialization do you mean normal java serialization - which<br>
>my principal supports (stand alone it does any way, java serialization<br>
>fails when I extend UsernamePrincipal), or serialization to json like is<br>
>done in the GenericPrincipalSerializer.java<br>
> and if its the latter, how do I register my own serializer?<br>
<br>
</span>Not a simple answer, but for now, the simplest way is to violate the<br>
system/ rules and edit system/conf/general-authn-system.xml file and just<br>
track it across upgrades.<br>
<br>
The "correct" way right now is to duplicate/modify the bean called<br>
"shibboleth.DefaultAuthenticationResultSerializer" in that file into<br>
general-authn.xml, and add your own bean(s) to the principalSerializers<br>
property. You would then inject your new bean in any flow that was<br>
handling your Principal subtype via p:resultSerializer-ref inside the flow<br>
descriptor in general-authn.xml (overriding the use of the default bean).<br>
<br>
If you file a RFE, I'll look at exposing that machinery better so you can<br>
add your own serializers. I didn't know how to handle that when that was<br>
all sketched out, but I have betters ways of doing it now with list<br>
merging and I never went back to this.<br>
<span class=""><br>
>I don't know the expected max size of a serialized session, is there an<br>
>recommended maxium size?<br>
<br>
</span>Very small, unless you're not using the cookie-based store. Total Safari<br>
cookie size per domain is 8k. The serializer machinery allows you to add<br>
symbolics to compress into numbers also. But if it's not constant data,<br>
that obviously won't help much.<br>
<span class=""><br>
>Depending on the size I might consider only putting a random ID in the<br>
>principal and instead provisioning authenticated identity to a temp data<br>
>store and writing a data store plugin to look up the ID at attribute<br>
>resolution time.<br>
<br>
</span>That would suggest to me you could dump the client side store anyway if<br>
you have a data store you can replicate like that, and then you don't need<br>
to care about size.<br>
<div class="HOEnZb"><div class="h5"><br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br></div>