Hi,
Perfect timing ;-) I have started implemented the pac4j support in Knox,
it's a very basic attempt: https://github.com/apache/knox/pull/2/files
This implementation reuses the pac4j implementation for J2E. I have a
ProviderDeploymentContributorBase which registers two filters:
- the first one is a dispatcher filter which uses the j2e-pac4j
CallbackFilter on the /callabck url (it finishes the authentication process
after a successful authentication at some identity provider) and uses the
j2e-pac4j RequiresAuthenticationFilter otherwise (redirection to the
identity provider to start the authentication when the user is not
authenticated)
- the second one is an identity adapter which gets the current
authenticated user from the pac4j point of view and populates the J2E
security context.
* I have the following error:
2015-11-10 16:30:22,347 ERROR hadoop.gateway
(GatewayFilter.java:doFilter(135)) - Gateway processing failed:
javax.servlet.ServletException: javax.servlet.ServletException:
Authentication type must be specified: simple|kerberos|<class>
javax.servlet.ServletException: javax.servlet.ServletException:
Authentication type must be specified: simple|kerberos|<class>
at
org.apache.hadoop.gateway.GatewayFilter$Holder.getInstance(GatewayFilter.java:354)
Notice I have changed the sandbox.xml file to use pac4j instead of Shiro,
maybe it's not the right way:
https://github.com/apache/knox/pull/2/files#diff-128ca80baa2dfd6c2d25de7b8160b9d9R24
Any idea of the problem?
* Am I understanding webflows correctly?
I use the default request to: curl -ivk "
https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS";
It looks like a REST request, though I'm expecting the following webflow:
redirection of the user to the identity provider, successful login,
redirection back to the /callback url of the gateway: do I get it right?
* The callback url
I currently do a check expecting the last part of the url to end with
/callback, but does the gateway will receive requests on this url? Do I
have to do something special?
It's highly recommended to only have one callback url as this url is
defined on the identity provider side.
* How to pass configuration?
Currently, I hardcoded a FacebookClient for Facebook authentication, but we
should be able to pass the appropriate client like Facebook or SAML.
Basically, we could do that using filter properties: facebook.key +
facebook.secret means we use Facebook authentication with the appropriate
key and secret for example. Any recommendation?
* Can I use the J2E session to store the requested protected url and other
information?
Or do I need to do something special?
Thanks.
Best regards,
Jérôme
2015-11-10 17:03 GMT+01:00 Kevin Minder <[email protected]>:
> Hi Jerome,
> This sounds very exciting and is just the sort of thing the open
> architecture of Knox is intended to allow. Larry and I have looked at
> pac4j a number of times thinking that it would be a good fit and would
> provide a great feature set to the Hadoop community.
> Kevin.
>
>
>
> On 11/6/15, 3:31 AM, "Jérôme LELEU" <[email protected]> wrote:
>
> >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
> >>>>
> >>>>
>
