Hi Jérôme - Great questions and I'm so glad that you are here to ask them.
I think that the set of documentation that I am working on for a KnoxSSO integration guide will probably answer most of your questions. I need to spend a bit more time thinking about the some of it so that I can incorporate that information as well. The cookie approach is what we use in KnoxSSO. Cookies obviously have some disadvantages but is probably the best alternative for KnoxSSO. Something that we need to consider is that KnoxSSO is already keeping track of the original URL for redirecting back to the requested resource. We have to reconcile whether that is separate from the callback needs or actually the same thing. Having a little trouble wrapping my head around it right now - must have more coffee. :) The Messages layer allows for the localization of the actual messages by decoupling the messages from the actual runtime code. I will try and get some docs published as quickly as possible for KnoxSSO integration. thanks, --larry On Fri, Nov 13, 2015 at 3:27 AM, Jérôme LELEU <lel...@gmail.com> wrote: > Hi, > > 1) Webflow: I think I get the idea with the KnoxSSO service: how can I test > everything to ensure pac4j works correctly with it and will be usable in > Hadoop UIs? > > > 2) Callback url: > > For indirect clients, pac4j is designed to be called on any url, to save > it, to call the identity provider providing a static callback url, to be > called back on this static callback url and to restore the originally > requested url. > > From point 1), I conclude that pac4j will always be used with the KnoxSSO > service (for indirect clients): will KnoxSSO call the pac4j provider always > on the same url? Can you describe your first flow with urls? > > Because in that case, I could find a solution where I check for the > client_name parameter to define if it's a callback or a first call. > > Otherwise, I will need a specific pac4j service. > > > 3) Configuration: no problem here, I will use the AliasService. > > > 4) Web session: I really need to put some information in session and check > them on callback: I think I can take the data put in session, save them in > a cookie and restore them before the callback. > > Is it the recommended solution? Can I re-use the components available for > JWT tokens and cookies? And how? > > > 5) Logs: I see in every descriptor the use of Messages and MessagesFactory: > I can't use log4j directly, can I? What's the expected benefits using this > Messages layer? > > > Thanks. > Best regards, > Jérôme > > > > > > 2015-11-12 18:14 GMT+01:00 larry mccay <lmc...@apache.org>: > > > 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. > > > > > > >
