Here is a *very* early version of an integration guide for KnoxSSO: http://knox.apache.org/books/knox-0-7-0/knoxsso_integration.html
It will walk you through setting up an environment to for using KnoxSSO to secure the REST APIs using KnoxSSO cookies and a webflow. The initial environment uses simple browser HTTP basic authentication to protect the WebSSO service which hands out the cookies. This allows us to ensure that KnoxSSO is setup properly without introducing a 3rd party provider into the mix first. Once you have it working with Basic Auth then you can switch to your pac4j provider instead of Shiro to protect the websso service and we can start to work through the integration of your provider. Please understand that this is still a document that is very much a work in progress and has content, formatting and other issues. It should serve as a general guide for you in the short term though. Hope it is useful for you! On Fri, Nov 13, 2015 at 9:51 AM, Kevin Minder <kevin.min...@hortonworks.com> wrote: > I’ll add a bit to the logging answer. I created that for several reasons. > 1) Localization as Larry mentions. > 2) It abstract from actual logging provider and you can see for example > gateway-i18n-logging-sl4j as an alternate integration. > 3) Another important aspect is centralization. It centralizes all aspects > of a given message. For example the level for a given message is kept with > the message to hopefully prevent the message from being duplicated with > potentially different levels. It is also intended to support the notion of > Ids and potentially cause/action annotations which are very common as > products mature. > 4) Lastly and possibly the most interesting/important from a developer > perspective is traceability. Once you find the log method for a given > message you can use the IDE to find all of the palaces where a given > message is used. You can also have the IDE tell you if the message isn’t > used anymore. > > All that being said the external components we integrate with certainly > don’t use it. So from that perspective, direct use of log4j if that is > your choice isn’t going to cause any major problems. > > > > > > On 11/13/15, 8:40 AM, "larry mccay" <lmc...@apache.org> wrote: > > >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. > >> > > >> > > >> > > >> >
