Hi, This is definitely an option from my point of view, but AuthorizationGenerators can also be used for roles and permissions. Knox 0.8.0 has a first pac4j support for indirect clients. For me, it's a first step, but the final objective is to use all the capabilities of pac4j: REST support, authorizations... in Knox.
So my advice would be to release knox 0.8.0 and stay with the regular Knox identity assertion filters. Then, for Knox 0.9.0, start thinking how we can define a full pac4j configuration like this one: https://github.com/pac4j/j2e-pac4j-demo/blob/master/src/main/java/org/pac4j/demo/j2e/config/DemoConfigFactory.java instead of only using simple parameters. Thanks. Best regards, Jérôme 2016-01-18 18:35 GMT+01:00 larry mccay <[email protected]>: > > 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. > > Are you suggesting that a new identity assertion provider based on the > AuthorizationGenerator might make sense? > I can see that as being an interesting approach: > > 1. configure the pac4j assertion provider and specify which attribute to > use as the authenticated user > 2. optionally map the principal to the effective user > > Would #1 above be consistently available across all indirect clients for > which we have support? > > > On Mon, Jan 18, 2016 at 4:53 AM, Jérôme LELEU <[email protected]> wrote: > > > 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 > > > > > >
