Adding Kevin - since he is somehow not getting this thread anymore... On Wed, Nov 25, 2015 at 8:18 AM, larry mccay <larry.mc...@gmail.com> wrote:
> 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 > > >> >> >> >> 2015-11-24 21:25 GMT+01:00 larry mccay <larry.mc...@gmail.com>: >> >> > Yes, look at the code that "blindly copies the parameters as filter init >> > params in your Pac4jFederationProviderContributor >> > There is a toLowerCase, there is no reason that you need that and if you >> > are case sensitive in your external code then you should remove it. >> > >> > On Tue, Nov 24, 2015 at 3:16 PM, Jérôme LELEU <lel...@gmail.com> wrote: >> > >> > > Hi, >> > > >> > > You were right: there was an issue between my xalan dependency >> (excluding >> > > it solves the problem for now). >> > > >> > > But I've noticed something else: even when defining a provider >> parameter >> > > like NAME, I get name as servlet parameter: are the values >> transformed in >> > > lower case when injected in filters or am I missing something? >> > > >> > > Thanks. >> > > Best regards, >> > > Jérôme >> > > >> > > >> > > 2015-11-24 16:38 GMT+01:00 larry mccay <larry.mc...@gmail.com>: >> > > >> > > > We may need to change that line in XmlGatewayDescriptorExporter - >> try >> > > > replacing it with the following: >> > > > >> > > > t.setOutputProperty(OutputKeys.INDENT, "yes"); >> > > > t.setOutputProperty("{http://xml.apache.org/xslt}indent-amount";, >> "2"); >> > > > >> > > > Not sure why you got the next error when you commented it out. >> > > > Again, it may be due to a mismatch in xalan dependencies or some >> other >> > > > transformation provider. >> > > > >> > > > I suspect that we are somehow clashing with your dependency on xalan >> > and >> > > > our jetty dependencies. >> > > > >> > > > On Tue, Nov 24, 2015 at 10:08 AM, Jérôme LELEU <lel...@gmail.com> >> > wrote: >> > > > >> > > > > Hi, >> > > > > >> > > > > I updated the pull request with my latest changes: >> > > > > >> > > > > >> > > > >> > > >> > >> https://github.com/apache/knox/pull/2/files#diff-3b70d7177f6e0b395f99316a73bb71b0R17 >> > > > > >> > > > > Thanks. >> > > > > Best regards, >> > > > > Jérôme >> > > > > >> > > > > >> > > > > 2015-11-24 16:04 GMT+01:00 larry mccay <larry.mc...@gmail.com>: >> > > > > >> > > > > > Hi Jérôme - >> > > > > > >> > > > > > That's a new one for me. >> > > > > > Strikes me as a library mismatch or something. >> > > > > > >> > > > > > What does your pom.xml look like? >> > > > > > >> > > > > > thanks, >> > > > > > >> > > > > > --larry >> > > > > > >> > > > > >> > > > >> > > >> > >> > >
