Getting role attributes from loginHandler (LDAP)
Byte Flinger
byteflinger at gmail.com
Thu Jun 20 13:20:59 EDT 2013
Your email got me a little but confused.
If the Ldaploginmodule is already adding a role to the principal then it
will be a custom principal regardless of whether I retrieve that data from
it or not, no?
It's not about being an issue or not to do an extra ldap connection but
more of an optimization thing since one less connection is always better.
Regarding your last sentence, are you saying that the functionality of
commiting a role exists solely for the purpose of making it harder to
serialize the authentication result (which I am guessing, if so, is a
security feature)?
On Jun 20, 2013 7:10 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:
> On 6/20/13 12:06 PM, "Byte Flinger" <byteflinger at gmail.com> wrote:
>
> >Hi Christopher
> >Thanks for the answer. As mentioned, I did indeed manage to get the
> >wanted information using an LDAP DataConnector however given that the
> >role seems to be already returned by the login module, fast or not, it's
> >still a waste to have to make yet another connection
> > for information that's already been retrieved.
>
> That's how it should be done.
>
> >Trying to get the info out of the principal is exactly what I have been
> >trying to do (among other ways) however so far I have had no luck.
>
> You can, but don't. There are reasons why that will become a more
> complicated thing to do. Using custom principal objects causes problems
> for the storage of sessions and going forward that is not something you
> want to be relying on. If a few extra queries is noticeable to your IdP,
> you have something wrong on the back-end LDAP.
>
> >If this is not possible, what is the use of the role parameters in the
> >Ldaploginmodule anyway since it works to login without it (The module
> >simply won't "commit" any roles, whatever that means).
>
> That's a JAAS concept. It makes it impossible to reliably serialize the
> result of the authenticaton without adding custom code.
>
> -- 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/20130620/2e6983ec/attachment.html
More information about the users
mailing list