Terrific! Okay... original questions:
1) Webflow: is it normal to get a redirection to Facebook or another IdP when I made the request (for such a configuration of course)? Is this request meant to happen in a browser? (because it's the use case it was made for) It is normal. The usecases in which this mechanism would be used would involve the KnoxSSO service/feature. What we are doing with that is providing a normalization of authentication mechanisms by federating each auth event through a JWT token that gets set as a cookie. These usecases allow us to provide WebSSO flows for Hadoop UIs and other applications and those applications to only ever have to know about KnoxSSO tokens. What is slightly less normal is that the flow needs to have KnoxSSO in the middle. For instance: 1. a browser requests a resource from a KnoxSSO participating service provider 2. the service provider redirects the browser to KnoxSSO since there is no cookie 3. KnoxSSO is protected with pac4j provider and redirects the browser to FB 4. user authenticates to FB 5. pac4j accepts the FB authentication and normalizes the security context to a J2E Subject 6. WebSSO service then creates a signed JWT token, sets the cookie and redirects to the originally requested resource 7. originally requested resource finds the hadoop-jwt cookie, validates the token and verifies the signature and grants access to the resource 2) Callback url: https://localhost:8443/gateway/sandbox/callback currently returns a 404, so I must declare this url somewhere to be taken into account and pass to the pac4j filter. It would be even better if it could be done by the pac4j deployment contributor. How and where to do that? This is an interesting question and one that may have multiple solutions: * we may be able to add the callback filter as part of the original provider and just point them to the same URL. This would require the ability to chain them where one knows to not handle a request that is really meant for the other. * If we truly need a separate URL the way you depict it there then we will need to add a new service which would be unfortunate because it couples the use of a certain provider to the use of a particular service. 3) 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? This is fine. You will add your properties to the provider properties in the topology for the pac4j provider. You can find example code in the article to blindly add all properties to the filter init params. Incidentally, the storage of credentials directly in config files should be avoided. See the use of the AliasService where such credentials can be persisted in a credential store and resolved at runtime. I will find examples of this for you - we can go forward with config based values but will need to fix that later. 4) Web session: I seem to be able to use the web session to sore data. Can you confirm that point? This is probably not going to work. Keep in mind that there may be a cluster of Knox instances running and the session is not replicated across all instances. Additionally, keep in mind that your provider will only be engaged on the first request to KnoxSSO and then not until the token/cookie expires. On Thu, Nov 12, 2015 at 11:25 AM, Jérôme LELEU <lel...@gmail.com> wrote: > Hi, > > Thanks for your feedback. I didn't understand why the dependency was > required so I didn't add it. > > Now, it starts working: > > *$ curl -ivk > "https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS > <https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS>"* > ** Trying ::1...* > ** Connected to localhost (::1) port 8443 (#0)* > ** TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384* > ** Server certificate: localhost* > *> GET /gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS HTTP/1.1* > *> Host: localhost:8443* > *> User-Agent: curl/7.43.0* > *> Accept: */** > *>* > *< HTTP/1.1 302 Found* > *HTTP/1.1 302 Found* > *< Set-Cookie: > JSESSIONID=jsk1e89neg3l10xg39ar3a5mt;Path=/gateway/sandbox;Secure* > *Set-Cookie: > JSESSIONID=jsk1e89neg3l10xg39ar3a5mt;Path=/gateway/sandbox;Secure* > *< Expires: Thu, 01 Jan 1970 00:00:00 GMT* > *Expires: Thu, 01 Jan 1970 00:00:00 GMT* > *< Location: > > https://www.facebook.com/v2.2/dialog/oauth?client_id=x&redirect_uri=https%3A%2F%2Flocalhost%3A8443%2Fgateway%2Fsandbox%2Fcallback%3Fclient_name%3DFacebookClient&state=QCS9Vz83i9&scope=user_likes%2Cuser_about_me%2Cuser_birthday%2Cuser_education_history%2Cemail%2Cuser_hometown%2Cuser_relationship_details%2Cuser_location%2Cuser_religion_politics%2Cuser_relationships%2Cuser_website%2Cuser_work_history > < > https://www.facebook.com/v2.2/dialog/oauth?client_id=x&redirect_uri=https%3A%2F%2Flocalhost%3A8443%2Fgateway%2Fsandbox%2Fcallback%3Fclient_name%3DFacebookClient&state=QCS9Vz83i9&scope=user_likes%2Cuser_about_me%2Cuser_birthday%2Cuser_education_history%2Cemail%2Cuser_hometown%2Cuser_relationship_details%2Cuser_location%2Cuser_religion_politics%2Cuser_relationships%2Cuser_website%2Cuser_work_history > >* > *Location: > > https://www.facebook.com/v2.2/dialog/oauth?client_id=x&redirect_uri=https%3A%2F%2Flocalhost%3A8443%2Fgateway%2Fsandbox%2Fcallback%3Fclient_name%3DFacebookClient&state=QCS9Vz83i9&scope=user_likes%2Cuser_about_me%2Cuser_birthday%2Cuser_education_history%2Cemail%2Cuser_hometown%2Cuser_relationship_details%2Cuser_location%2Cuser_religion_politics%2Cuser_relationships%2Cuser_website%2Cuser_work_history > < > https://www.facebook.com/v2.2/dialog/oauth?client_id=x&redirect_uri=https%3A%2F%2Flocalhost%3A8443%2Fgateway%2Fsandbox%2Fcallback%3Fclient_name%3DFacebookClient&state=QCS9Vz83i9&scope=user_likes%2Cuser_about_me%2Cuser_birthday%2Cuser_education_history%2Cemail%2Cuser_hometown%2Cuser_relationship_details%2Cuser_location%2Cuser_religion_politics%2Cuser_relationships%2Cuser_website%2Cuser_work_history > >* > *< Content-Length: 0* > > > The response is clearly a redirection to Facebook for authentication (using > a configuration with Facebook). > > > > *Even better*: as the pac4j gateway relies on the j2e-pac4j library, all > authentication mechanisms are supported. So I tried with a direct client > like the basic auth (where login must be equals to password): > > requiresAuthenticationFilter.setClientName("DirectBasicAuthClient"); > requiresAuthenticationFilter.setConfig(new Config(new > DirectBasicAuthClient(new > SimpleTestUsernamePasswordAuthenticator()))); > > And it seems to works: the authentication is successful in the > Pac4jDispatcherFilter, the adapter filter is called and the pac4j user > profile is retrieved and passed to the *Subject.doAs*. I finally have a 500 > response, but it's not a surprise as I don't have any running Hadoop: > > 2015-11-12 17:07:12,748 WARN hadoop.gateway > (DefaultDispatch.java:executeOutboundRequest(115)) - Connection exception > dispatching request: > http://localhost:50070/webhdfs/v1/tmp?op=LISTSTATUS&user.name=jleleu > org.apache.http.conn.HttpHostConnectException: Connect to localhost:50070 > [localhost/127.0.0.1, localhost/0:0:0:0:0:0:0:1] failed: Connection > refused > > Reading this stacktrace, I assume that I have been authenticated and > authorized to call the Hadoop service behind and the identity (user.name) > is exactly the one I used to make the request: > > *curl -ivk --user jleleu:jleleu > "https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS > <https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS>"* > > > > *So I'm finally back to my original questions to go further:* > > 1) Webflow: is it normal to get a redirection to Facebook or another IdP > when I made the request (for such a configuration of course)? Is this > request meant to happen in a browser? (because it's the use case it was > made for) > > 2) Callback url: https://localhost:8443/gateway/sandbox/callback currently > returns a 404, so I must declare this url somewhere to be taken into > account and pass to the pac4j filter. It would be even better if it could > be done by the pac4j deployment contributor. > > How and where to do that? > > 3) 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? > > 4) Web session: I seem to be able to use the web session to sore data. > Can you confirm that point? > > > Thanks. > > Best regards, > Jérôme > > > > > > > > > 2015-11-12 14:55 GMT+01:00 larry mccay <lmc...@apache.org>: > > > Yes, Kevin, that seems to be missing from the pull request. > > Also, the parent pom doesn't have all of the changes needed to add a new > > module. > > > > See the section in the article called "Root Level Pom.xml" and the > section > > below that for the "Gateway Release Module Pom.xml" > > > > > https://github.com/lmccay/gateway-provider-security-pseudo/blob/master/AddingFederationProvider.md#root-level-pomxml > > > > On Thu, Nov 12, 2015 at 8:04 AM, Kevin Minder < > > kevin.min...@hortonworks.com> > > wrote: > > > > > I think I know what it probably is. The gateway-release module pom.xml > > is > > > what actually defines the classpath of the final packaged server. If > you > > > take a look at that you will see it references all of the providers > that > > > are intended to be included by default. Try adding yours to the > > > dependencies. > > > > > > > > > > > > > > > On 11/12/15, 7:49 AM, "larry mccay" <lmc...@apache.org> wrote: > > > > > > >We really need to fix this behavior... > > > > > > > >It seems you traded in your random authentication provider for a > random > > > >federation provider. :/ > > > > > > > >This is most likely due to not having your new provider on the > classpath > > > >for the serviceLoader to find. > > > > > > > >Just to try and articulate how it works... > > > > > > > >The deployment machinery loads all of the federation (whichever role) > > > >providers contributors that is finds on the classpath - via the > > > > > > > > > >src/main/resources/META-INF/services/org.apache.hadoop.gateway.deploy.ProviderDeploymentContributor > > > >- and interrogates each for its name to match to the name in the > > topology. > > > >Once it finds a match it allows the contributor to "contribute" to the > > > >creation of the topology specific webapp. Part of which includes > adding > > > >filters to the gateway.xml. > > > > > > > >We currently have an issue wherein, given a name that doesn't match > any > > > >found on the classpath, a random provider is returned. This needs to > be > > > >fixed to fail deployment with appropriate error messages. > > > > > > > >Now, this usually comes down to one of 2 things: > > > > > > > >1. there is no > > > > > > src/main/resources/META-INF/services/org.apache.hadoop.gateway.deploy.ProviderDeploymentContributor > > > >file in the provider or it contains the classname of some other > > > contributor > > > >2. the provider itself isn't on the gateway classpath. I see that your > > > >service file seems to be defined properly - so it is probably not on > the > > > >classpath. Did you add the new provider to the parent pom? The article > > > >should provide all you need to do so. > > > > > > > >I will file a JIRA to fix the random provider issue. > > > > > > > >On Thu, Nov 12, 2015 at 7:18 AM, Jérôme LELEU <lel...@gmail.com> > wrote: > > > > > > > >> Hi, > > > >> > > > >> By changing the role to the appropriate value, the error is gone, > but > > I > > > >> have a new problem: > > > >> > > > >> *Caused by: javax.servlet.ServletException: Required authentication > > > >> provider URL is missing.* > > > >> * at > > > >> > > > >> > > > > > > org.apache.hadoop.gateway.provider.federation.jwt.filter.SSOCookieFederationFilter.init(SSOCookieFederationFilter.java:90)* > > > >> > > > >> My sandbox.xml file only references the pac4j provider as well as > the > > > >> Default (role: identity-assertion) and static (role: hostmap) ones. > > > >> > > > >> Though, the SSOCookieFederationFilter is defined in the gateway.xml > > > file of > > > >> my sandbox deployment. Why do I need it? What's the expected > > > authentication > > > >> provider url? How this gatweay.xml is generated? > > > >> > > > >> Thanks. > > > >> Best regards, > > > >> Jérôme > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> 2015-11-10 17:36 GMT+01:00 Kevin Minder < > kevin.min...@hortonworks.com > > >: > > > >> > > > >> > To be a bit more explicit your Pac4jFederationProviderContributor > > > >> declares > > > >> > itself to be of role “federation” but when you used it in the > > > sandbox.xml > > > >> > topology file you were attempting to configure it as an provider > > with > > > >> role > > > >> > authentication. > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > On 11/10/15, 11:32 AM, "larry mccay" <lmc...@apache.org> wrote: > > > >> > > > > >> > >Let's get you past the error that you are getting... > > > >> > > > > > >> > >It seems as though you have change the topology for pac4j but > > didn't > > > >> > change > > > >> > >the role to "federation". > > > >> > >It looks like it is grabbing a random authentication provider and > > > seems > > > >> to > > > >> > >be the hadoop-auth provider. > > > >> > > > > > >> > >Change that to federation and see if that helps. > > > >> > > > > > >> > >On Tue, Nov 10, 2015 at 11:21 AM, larry mccay <lmc...@apache.org > > > > > >> wrote: > > > >> > > > > > >> > >> Hi Jérôme - > > > >> > >> > > > >> > >> Happy to see you here! > > > >> > >> I apologize for having missed your note on the list a few days > > ago. > > > >> > >> > > > >> > >> Glad to see that the article was helpful and it seems like you > > are > > > >> > making > > > >> > >> great progress. > > > >> > >> > > > >> > >> Let me dig into your note a bit deeper and answer your > questions. > > > >> > >> > > > >> > >> Welcome! > > > >> > >> > > > >> > >> --larry > > > >> > >> > > > >> > >> On Tue, Nov 10, 2015 at 11:14 AM, Jérôme LELEU < > lel...@gmail.com > > > > > > >> > wrote: > > > >> > >> > > > >> > >>> 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 < > > > >> kevin.min...@hortonworks.com > > > >> > >: > > > >> > >>> > > > >> > >>>> 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" <lel...@gmail.com> > 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 < > > > lel...@gmail.com> > > > >> > >>>> 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 > > > >> > >>>> >>>> > > > >> > >>>> >>>> > > > >> > >>>> > > > >> > >>> > > > >> > >>> > > > >> > >> > > > >> > > > > >> > > > > > >
