Oh - do I need to build j2e-pac4 locally in order to resolve the dependencies?
[ERROR] Failed to execute goal on project gateway-provider-security-pac4j: Could not resolve dependencies for project org.apache.knox:gateway-provider-security-pac4j:jar:0.7.0-SNAPSHOT: The following artifacts could not be resolved: org.pac4j:j2e-pac4j:jar:1.2.1-SNAPSHOT, org.pac4j:pac4j-http:jar:1.8.1-SNAPSHOT, org.pac4j:pac4j-config:jar:1.8.1-SNAPSHOT: Could not find artifact org.pac4j:j2e-pac4j:jar:1.2.1-SNAPSHOT in public ( http://nexus-private.hortonworks.com/nexus/content/groups/public/) -> [Help 1] On Wed, Dec 2, 2015 at 10:05 AM, larry mccay <larry.mc...@gmail.com> wrote: > 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 <larry.mc...@gmail.com> 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 <lel...@gmail.com> 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 <larry.mc...@gmail.com>: >>> >>> > 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 >>> > > > >>> > > >>> > >>> >> >> >
