<p>Thanks for the input, I'll take it consideration.</p>
<p>I'd still like to know how to retrieve the role from the java subject though if anybody knows how to do it.</p>
<div class="gmail_quote">On Jun 20, 2013 7:26 PM, "Cantor, Scott" <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 6/20/13 1:20 PM, "Byte Flinger" <<a href="mailto:byteflinger@gmail.com">byteflinger@gmail.com</a>> wrote:<br>
<br>
>If the Ldaploginmodule is already adding a role to the principal then it<br>
>will be a custom principal regardless of whether I retrieve that data<br>
>from it or not, no?<br>
<br>
Yes, but there's a difference between relying on something and not relying<br>
on it, if that information disappears across some boundary in the future.<br>
<br>
>It's not about being an issue or not to do an extra ldap connection but<br>
>more of an optimization thing since one less connection is always better.<br>
<br>
No, it's not always better, that's my point. There are other<br>
considerations.<br>
<br>
>Regarding your last sentence, are you saying that the functionality of<br>
>commiting a role exists solely for the purpose of making it harder to<br>
>serialize the authentication result (which I am guessing, if so, is a<br>
>security feature)?<br>
<br>
No, it exists to add roles in JAAS. That has the effect of makng the<br>
user's principal name an incomplete representation of the result. Custom<br>
principals added to a Java Subject are not Serializable in Java, and<br>
cannot be asked to persist themselves in any standard way, which means<br>
preserving them in a cluster requires custom code that you would have to<br>
plug into the IdP in a future version that's not using Terracotta. All to<br>
avoid a meaningless, well-supported query to LDAP. It's not a good<br>
trade-off.<br>
<br>
-- Scott<br>
<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>
</blockquote></div>