Hi Jérôme - I am trying to figure out why you aren't getting the username in WebSSOResource. If the default identity-assertion provider is indeed in place then you should get it.
Is the pac4j identity adapter filter in the same request processing as the websso resource? Not an easily asked question - let me try and be clear... Perhaps, you are pivotting during the OAuth handshake and a new request comes in which never makes it to WebSSOResource but sets the security context and when control gets back to the original request processing that context is no longer there? Does that make any sense? thanks, --larry On Tue, Dec 1, 2015 at 11:15 AM, Jérôme LELEU <lel...@gmail.com> wrote: > 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 > > >
