Hi, 1) About the identity-assertion provider, I don't understand what its role is. I added it in my idp.xml topology but unsuccessfully: https://github.com/apache/knox/pull/2/files#diff-4ea9a9a5ee5968f29982478512a63c54R40 Though, I still don't have any principal. I have a log telling me the user profile is retrieved in the Pac4jIdentityAdapter (before the doAs), but the user principal is not retrieved from the request in the KnoxSSO service: https://github.com/apache/knox/blob/master/gateway-service-knoxsso/src/main/java/org/apache/hadoop/gateway/service/knoxsso/WebSSOResource.java#L149
Am I wrong in the identity-assertion provider configuration? Where should I investigate? 2) Several things go into the web session: tokens (for example for OAuth 1.0), flow information (like the authentication has already been performed to avoid infinite loop), authenticated user profile... I need to protect these information and share them among all the gateway instances. To share them, I save them in cookies and to protect them, I encrypt them. Notice that there is a new concept of SessionStore in pac4j and j2e-pac4j with a specific implementation for Knox (the session is stored into cookies) and we could save these session information almost anywhere, like in a clustered cache like Redis or Memcache for example. I'm not too ambitious for this first version though. The encryption now works. My only question is about the generated password: will it be different for each gateway instance? I'm expecting to have the same password as the encrypted cookies are shared. Thanks. Best regards, Jérôme 2015-11-25 14:18 GMT+01:00 larry mccay <larry.mc...@gmail.com>: > inline... > > On Wed, Nov 25, 2015 at 5:04 AM, Jérôme LELEU <lel...@gmail.com> wrote: > > > Hi, > > > > Thanks for all your help. I've made the pac4j integration works in Knox > > (using a simple basic auth where login = pwd or a remote CAS server). > > > > > Great! > > > > I have two points left (before more tests and documentation): > > > > 1) In my Pac4jIdentityAdapter, I successfully retrieved the authenticated > > user and perform a doAs with it, but I still end with an error 500. > Putting > > a breakpoint in the WebSSOResource, I get null as the authenticated > > user (*Principal > > p *= (*(HttpServletRequest)request).getUserPrincipal();*). Doing more > > debugging, I see that the original request in my Pac4jIdentityAdapter is > > a XForwardedHeaderRequestWrapper, then a filter is > > called: RegexIdentityAssertionFilter which encapsulates the request in a > > new one: IdentityAsserterHttpServletRequestWrapper. So I don't understand > > why this filter comes into play and why my authenticated subject is > "lost". > > > > > The fact that you are getting the RegExIdentityAssertionFilter sort of > points to an issue in your > topology. Unless you have purposely configured the regex provider. > > Make sure that you have configuration that looks like this in your > topology: > > <provider> > <role>identity-assertion</role> > <name>Default</name> > <enabled>true</enabled> > </provider> > > > > > 2) To save session data, I use cookies: for each key, I have a cookie > whose > > value is the serialized object in base64. I don't think it's secure > enough, > > especially for the authenticated user profile. I think I could use the > > JWTokenAuthority to wrap data in a token: does it make sense to use it? > Is > > there any other way to secure data? What's your recommendation / > > expectation? In a token, it seems I can only set a subject, issuer, > > audience and no extra attributes: am I getting it right? > > > > > What keys do you need to store in "session"? > Putting them in a JWT token in a cookie won't really make it any more > secure. > > They are signed but not encrypted. > We could extend the tokenAuthority to use encrypted tokens as well if > really needed. > And you could put them in the generic claims of the token. > However, this is all pretty much a misuse of the token that is supposed to > represent an identity or authentication event. > > There is another gatewayService that you could use called the CryptoService > - you get to this the same way that you get to the > tokenAuthority, aliasService, etc. > > You could provision a password from your provider contributor - see: > > > https://github.com/apache/knox/blob/539557c902404529c4636bfe0425ba44980cc177/gateway-provider-rewrite-step-encrypt-uri/src/main/java/org/apache/hadoop/gateway/encrypturi/impl/EncryptUriDeploymentContributor.java > > The initializeContribution method initiates the creation of an > alias/password to be used for password based encryption later while > protecting internal URL details. > > Note the simple injection of the AliasService just by adding a > setAliasService method to the contributor. > > Then in EncryptUriProcessor you will find the runtime use of that password > for PBE in: > > > https://github.com/apache/knox/blob/33bb1ce5727a54721baec0125dd1254d275160ac/gateway-provider-rewrite-step-encrypt-uri/src/main/java/org/apache/hadoop/gateway/encrypturi/impl/EncryptUriProcessor.java > > Note the lookup of the cryptoService.initialize() and its use in the > encode(). > > This will certainly allow you to protect the keys within cookies - if that > is what you are looking to do. > > I updated the pull request with my latest source code: > > https://github.com/apache/knox/pull/2 > > > > Thanks. > > Best regards, > > Jérôme > > > > > > > > Hope that is helpful. > > --larry >
