Hi, The pac4j vision: 1) For direct clients (LDAP authentication for example) which are NOT currently supported by the Knox / pac4j gateway, we have two components: the Authenticator which validates credentials and the ProfileCreator which create a user profile (by default, it relies on the data returned by the Authenticator). It means that for this kind of authentication, we assume we can have two identity sources: one for login, one to get attributes and username. 2) For indirect clients (Facebook or SAML authentication for example) which are currently supported by the Knox / pac4j gateway, we have only one component: the client which represents an authentication mechanism as we assume that all actions (credentials validation, user profile retrieval) are done via one identity source.
We have the additional mechanism of AuthorizationGenerator you can attach to a Client to compute authorizations after the login and user profile retrieval. In fact, you could even use it to switch the identifier of the user profile by one of its attribute. Thanks. Best regards, Jérôme 2016-01-16 17:10 GMT+01:00 larry mccay <[email protected]>: > All - > > The pac4j provider contribution was committed yesterday and we are on track > for our 0.8.0 release. Note that the docs are still being massaged a bit > and will end up in the new 0.8.0 users guide book soon. > > In the meantime, I'd like to start a discussion wrt the requirements for > identity assertion functionality in order to have full usecase coverage for > our new authentication/federation mechanisms. > > A bit of background first... > > Some of the external provider integrations that are enabled by the pac4j > provider: > > 1. result in a PrimaryPrinicipal that is actually an id rather than a > username that could be used directly within the hadoop cluster. > 2. some also allow you to configure the user profile attribute to returned > as the subject - such as SAML (okta). So, we could at least some times have > it be an email address. > 3. others result in an actual username as the PrimaryPrincipal > 4. It is extremely likely that none of these PrimaryPrincipals won't > actually line up with enterprise username that can be used within the > cluster. > > Existing identity assertion providers: > > 1. pseudo/default identity assertion - we have the ability to use principal > mapping to mapping a numeric id/email or whatever to an acceptable username > for hadoop. However, all users that would access hadoop through a topology > configured for pac4j would need to have their principal mappings defined > within the topology. Not a very scalable or manageable approach. The > topology itself would likely end up being huge and they would need to be > sync'd up across all Knox instances in the deployment. > 2. regex identity assertion provider - this provider would be able to take > something like an email address PrimaryPrincipal and extract a username > from that. In some cases, like okta, this may be the proper username for > companies that use okta as a hosted SSO solution. There is no additional > principal mapping capabilities however. > > So, questions/options for 0.8.0 release: > > Option 1. Is static principal mapping within a topology using the > pseudo/default identity assertion provider sufficient for the first release > that has support for these external providers? > > Option 2. Do we need to add principal mapping capabilities to the regex > provider to allow for the extraction of a username AND subsequently mapping > that to another username? > > Option 3. Should we create a new identity asserter that does a look up in > LDAP for mapping an id or email address to the username/CN? A more dynamic > assertion provider like this would certainly be better for scalability and > management but at the same time would require a change to LDAP schemas for > things like twitter id. Email address may not require a schema change but > would require the email address from the external provider to match that > within the corporate LDAP. > > Option 4. Should we consider a central mapping storage identity assertion > provider that would interrogate some KnoxSSO specific mechanism? We could > look at a mapping of PrimaryPrincipal to DN from LDAP, to corporate email > address or directly to username. This would require some separate > registration or user sync mechanism to populate this central store and > likely couple the mappings to a particular user store like LDAP in some > way. It will also introduce a new wrinkle or consideration for Knox > upgrades having actual user data to migrate, etc. For the central store we > could consider: > a. file in HDFS > b. embedded HBase > c. Hive > d. RDBMS > e. LDAP > > Personally, I lean toward the following: > > * Option 1 from above for 0.8.0 release introduces the pac4j provider with > static principal mapping using pseudo/default assertion provider and > possibly add support for principal mapping to the regex provider (Option 2) > for additional flexibility. > > * Option 3 and/or 4 from above for a follow up release/s when we can > determine the exact design for the central store and user sync/registration > mechanism that would best meet the community needs and be sure to put the > time into the upgrade/migration considerations. > > Thoughts? > > thanks, > > --larry >
