Hi, Let's open this private discussion on the Knox dev mailing list.
I'm Jerome Leleu and the creator of pac4j (https://github.com/pac4j/pac4j), a security engine for Java with many implementations for J2E, Play, Spring, Vertx, Ratpack... The idea is to offer something as powerful as Spring Security, but a lot easier and for all Java frameworks / tools and all authentication mechanisms. Two years ago, we had a discussion with Larry on how pac4j could be used in Knox. Meanwhile, both projects have grown up and I'm back to try to see if pac4j can help Knox in terms of security. ----- In its latest version, pac4j can be used to build a full security library, not only focused on delegated authentication (Facebook, SAML). So we have the concepts of direct clients (a client is an authentication mechanism): basic auth, header, token... and indirect clients: SAML, Facebook, OpenID, CAS... It seems to be very close to the Authentication and Federation Providers concepts from Knox. The provided article is great and as it's focused on authentication with a real example, it's easier to start with it. Thanks for your answers. Like Shiro, pac4j has LDAP support and caching can be done. The only difference is that pac4j relies on ldaptive (http://www.ldaptive.org/). But I think you're right: it would be better to start by implementing the Federation part which might be the most expected feature for Knox users (a bit like buji-pac4j: https://github.com/bujiio/buji-pac4j is for Shiro) and see if it's worth the work to have an authentication provider with pac4j in addition to the one of Shiro. I plan to start working on that next week. Do you accept pull requests on Github (it would make discussion easier on source code)? Any feedback will be appreciated. Thanks. Best regards, Jérôme 2015-11-05 17:13 GMT+01:00 larry mccay: > Hi Jérôme - > > Contributions coming from the community are owned and maintained by the > entire community. > You would certainly not be expected to do all work on it and at the same > time any assistance and upgrade messages that you provided would be awesome. > > As for an empty module for pac4j, maybe the following example project > would be helpful to you: > > https://github.com/lmccay/gateway-provider-security-pseudo > > It is in support of an article to illustrate how to go about adding a > authentication or federation provider - as you would be doing: > > https://github.com/lmccay/gateway-provider-security-pseudo/blob/master/AddingFederationProvider.md > > That may be easier to consume than the entire developers guide. > That said, it would be great if you could describe what makes the dev > guide too much - if that is the case. > > I'll take a stab at your questions here but we should move more detailed > discussions on the topic to the dev@ list in order to keep this in the > open and provide insights to others: > > 1) What do I do with the authenticated user: where / how do I fill this > identity in Knox? > > We normalize the authentication event into a Java subject to represent the > user, groups and impersonated user as appropriate. > In cases - like shiro - where we don't have access to the actual > authenticating code and we need to normalize the provider specific security > context, we add another filter. You can look at the shiro provider for an > example. The code inside the simple example provider in the article also > shows what is expected at least in terms of the PrimaryPrincipal. > > 2) How to handle errors: not authenticated, not authorized? > > We aren't intrusive on what should be done by a provider here. > Generally, authentication failures result in a 401 and authorizations in a > 403 and they are usually sent by the provider. > > 3) How to handle redirections to an external provider? > > Redirects are sent by the providers themselves with a 307 or 302. > You can look at the SSOCookieFederationFilter in the jwt module as an > example if you like. > > 4) Should the pac4j filter also handle authorizations (pac4j can do that)? > > This is an interesting question. > Knox provides a separate slot in the provider chain for authorization. > It is there because of the ability for identity assertion providers to map > principals in order to impersonate another user or map external usernames > to those used inside of hadoop clusters. So, the authorization decisions > are made based on those identities. > > If we can add the authorization filter as an authorization provider rather > than part of the authentication provider than that might make sense. > Although, the security context is normalized as Knox expects not as pac4j > authorization probably does. Now, if there is real value in doing so, the > pac4j Subject adaptor could stuff additional context into the Subject or > the request that can be accessed later by the pac4j authorization provider. > > So, it can be done - the question is whether there is compelling reason to > do so. > > 5) How to test? > > This can be challenging especially for external authentications and web > app flows. > Generally, unit testing as much as possible is required. > We would want to make sure that the security context normalization happens > as expected, etc. > > Additional considerations: > > 1. Our Shiro provider does group lookup and caching of the authentication > event for optimizing interactions with authentication servers, LDAP, AD, > etc. We wouldn't want to lose these. Doing so would be a non-starter for > most folks replacing what Shiro is used for today. > 2. It is probably best to concentrate on the gaps that pac4j can fill for > openid, oauth, etc for the initial contribution and if the usecases handled > by Shiro can be done better, easier, simpler then we can consider a > migration path. > > BTW - we have a couple very interesting possibilities for strong and > multi-factor authentication that would be enabled by OpenID immediately. > > Hope this isn't too long a response and that it is helpful for you. > > Let's determine what an initial contribution would be for and bring a > proposal to the dev@ list and/or file a jira for the integration. > This would be great for adding features and growing the community - so we > are all for it! > > thanks, > > --larry > > > On Thu, Nov 5, 2015 at 9:43 AM, Jérôme LELEU <[email protected]> wrote: > >> Hi, >> >> I see that Shiro is already used for basic auth and LDAP authentication >> and Picketlink for SAML. pac4j v1.8 can now handle both cases and even >> more. So I think we could create a gateway-provider-security-pac4j >> supporting all authentication mechanisms and not only OpenID. >> >> pac4j implementations generally work with two filters: one to protect a >> resource and play direct authentication like basic auth (and check >> authorizations) and a callback filter to finish remote authentication like >> Facebook, SAML, OpenID. The easiest one is the j2e-pac4j with: >> https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/RequiresAuthenticationFilter.java#L96 >> and >> https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/CallbackFilter.java#L65 >> >> That said, I have already many pac4j implementations to handle so I'm >> pushing communities to maintain on their own their pac4j implementations: >> can we imagine having an official: gateway-provider-security-pac4j module >> maintained by the Knox community with my help of course? This is the kind >> of message I deliver to communities when a new version of pac4j is >> available so that they can upgrade: >> https://github.com/ratpack/ratpack/issues/819 >> >> I read: https://knox.apache.org/books/knox-0-6-0/dev-guide.html#Providers, >> it might be easy for Knox contributors, but it's a bit hard for me to get >> in everything: can you or someone in the Knox community provides me an >> empty gateway-provider-security-pac4j module and the default expectations >> from a Knox point of view? >> My main questions: >> 1) What do I do with the authenticated user: where / how do I fill this >> identity in Knox? >> 2) How to handle errors: not authenticated, not authorized? >> 3) How to handle redirections to an external provider? >> 4) Should the pac4j filter also handle authorizations (pac4j can do that)? >> 5) How to test? >> >> Thanks. >> Best regards, >> Jérôme >> >> >> >> >> 2015-11-03 16:58 GMT+01:00 larry mccay: >> >>> Hi Jérôme - >>> >>> We were evaluating buji-pac4j for SSO with SAML and ended up going with >>> Picketlink at the time. >>> That said, we do have a pluggable architecture that would allow for a >>> pac4j provider as well. >>> >>> If you are interested in contributing such a provider that would >>> certainly be welcome. >>> There is someone in the community working on an openid provider but >>> perhaps pac4j would be the way to go there? >>> >>> thanks, >>> >>> --larry >>> >>>
