v3 Docs Q: Appropriate use of idp.authn.LDAP.returnAttributes?
Chris Phillips
Chris.Phillips at canarie.ca
Tue Jun 30 11:14:58 EDT 2015
This is why I raised the question.
The flexibility to do what Scott has commented on below (write a data
connector. . .)
OR use the attribute-resolver.xml approach
OR even do both is both good in the sense you can do it, but hard to
explain which is preferred as a best practice and configuration guidance.
I see the reasoning behind the technique and desire a bit more
prescriptive description on best practices on where to do things. As an
implementer I also want to align with best practices that the software
team intended for the functionality.
Considering that there isn't a dataConnector written/included now leads me
to describe best practices in this area to be:
- Keep using attribute-resolver.xml as THE place to deal with attributes
that appear in assertions and flows
- When data about a subject is needed during the authentication
(including operational attributes like password policy status etc), use
attributes to be listed via idp.authn.LDAP.returnAttribute and defer to
attribute-resolver.xml as THE place for attribute definition otherwise.
- Advanced uses of idp.authn.LDAP.returnAttribute would be best served by
a data connector that Scott describes
I think the flexibility is great, I'm just trying to call out what would
be the common pattern for implementers.
Let me know if my reasoning is out of alignment..and if it is, how to
adjust..
Chris.
On 2015-06-30, 9:38 AM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:
>On 6/29/15, 10:58 PM, "users on behalf of Daniel Fisher"
><users-bounces at shibboleth.net on behalf of dfisher at vt.edu> wrote:
>>
>>One reason to pull attributes during authentication is that it is the
>>only time you can read attributes as the authenticating user. For some
>>directory implementations it is attractive to simply exercise the user
>>ACLs rather than configuring a service account to read that data.
>
>While that's true, it isn't as simple to punt everything the data
>connector does over to this step. I suppose if you wanted to make that
>more "routine", you could write a data connector that automatically
>generated IdPAttributes based on the LdapEntry in the Subject.
>
>I guess a sample Script could be written to plug into the
>ScriptedDataConnector.
>
>-- Scott
>
>--
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net
More information about the users
mailing list