gateway-provider-security-pac4j doesn't build - do you have a pending change for your pom.xml or something?
On Wed, Dec 2, 2015 at 7:02 AM, larry mccay <[email protected]> wrote: > Hi Jérôme - > > Yes, that is the flow that I imagined as I walked through it yesterday. > It's great that there is an online CAS server to use - that's what was > keeping me from trying it out. > > I will give it a go and keep you posted. > > thanks, > > --larry > > On Wed, Dec 2, 2015 at 3:41 AM, Jérôme LELEU <[email protected]> wrote: > >> Hi, >> >> I'm a bit lost: how the principal provided in Subject.doAs should become >> available in request.getPrincipalUser() ? >> >> I've done one more debugging session, but unsuccessfully. I'm confident >> the >> flow is correct. >> Let me resume what I understand one more time: >> - I call >> https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS, >> the SSOCookieProvider redirects me to >> >> https://127.0.0.1:8443/gateway/idp/api/v1/websso?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS >> - on this url, the pac4j provider is called first (before the KnoxSSO >> service), the current url is saved before redirecting to the CAS server >> where I log in >> - back to the callback url ( >> >> https://127.0.0.1:8443/gateway/idp/api/v1/websso?client_name=CasClient&ticket=ST-9-W12oWBh63C5Eub7IWNlj-cas01.example.org >> ), >> the pac4j provider is called again before the KnoxSSO service, deals with >> the authentication process, saved the current user profile in a cookie and >> redirects to the originally requested url >> - on the originally requested url ( >> >> https://127.0.0.1:8443/gateway/idp/api/v1/websso?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS >> ), >> the pac4j provider is called again, which retrieves the current user >> profile and grants access that's why we go to the Pac4jIdentityAdapter, >> which retrieves the current user profile and perform a doAs. >> >> Then, it dives into the Knox plumbery and there must be something wrong >> happening. >> >> In the Subject.doAs called in Pac4jIdentityAdapter, the request is a >> XForwardedHeaderRequestWrapper and the request.getUserPrincipal() is null. >> The CommonIdentityAssertionFilter is called (line 58), the request is the >> same and the subject found is correct, the request is wrapped by >> a IdentityAsserterHttpServletRequestWrapper. In >> the AbstractIdentityAssertionFilter (line 100), the request is the wrapped >> one, the currentSubject is the right one. Then, I'm not sure what should >> happen in the source code, but the doFilterInternal method is called (in >> the continueChainAsPrincipal method). Finally, the ServletContainer filter >> is called to delegate to the WebSsoResource where request.getUserPrincipal >> returns null. >> >> Do you see something wrong in the latest steps ? >> >> I think it would really help if you could debug it yourself. Clone my >> repo: >> git clone https://github.com/leleuj/knox leleujknox, switch to the >> branch: >> git checkout pac4j, build everything, deploy knox, start in debug, start >> the debugger in your favorite IDE, call: >> https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS. The >> login must be the same as the password on the CAS server (an online one). >> Then a breakpoint in the Pac4jIdentityAdapter line 63 is a good starting >> point. >> >> Thanks. >> Best regards, >> Jérôme >> >> >> >> >> 2015-12-01 19:38 GMT+01:00 larry mccay <[email protected]>: >> >> > 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 <[email protected]> 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 <[email protected]>: >> > > >> > > > inline... >> > > > >> > > > On Wed, Nov 25, 2015 at 5:04 AM, Jérôme LELEU <[email protected]> >> > 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 >> > > > >> > > >> > >> > >
