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. > > >
