Hi, Thanks for the explanations.
I'll use the MessageFactory in the gateway-provider-security-pac4j and log4j for all pac4j components. Best regards, Jérôme 2015-11-13 15:51 GMT+01:00 Kevin Minder <[email protected]>: > 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" <[email protected]> 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 <[email protected]> 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 <[email protected]>: > >> > >> > 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. > >> > > >> > > >> > > >> >
