You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@knox.apache.org by Jérôme LELEU <le...@gmail.com> on 2015/11/06 09:31:07 UTC
pac4j and Apache Knox
Hi,
Let's open this private discussion on the Knox dev mailing list.
I'm Jerome Leleu and the creator of pac4j (https://github.com/pac4j/pac4j),
a security engine for Java with many implementations for J2E, Play, Spring,
Vertx, Ratpack... The idea is to offer something as powerful as Spring
Security, but a lot easier and for all Java frameworks / tools and all
authentication mechanisms.
Two years ago, we had a discussion with Larry on how pac4j could be used in
Knox.
Meanwhile, both projects have grown up and I'm back to try to see if pac4j
can help Knox in terms of security.
-----
In its latest version, pac4j can be used to build a full security library,
not only focused on delegated authentication (Facebook, SAML). So we have
the concepts of direct clients (a client is an authentication mechanism):
basic auth, header, token... and indirect clients: SAML, Facebook, OpenID,
CAS...
It seems to be very close to the Authentication and Federation Providers
concepts from Knox.
The provided article is great and as it's focused on authentication with a
real example, it's easier to start with it.
Thanks for your answers.
Like Shiro, pac4j has LDAP support and caching can be done. The only
difference is that pac4j relies on ldaptive (http://www.ldaptive.org/). But
I think you're right: it would be better to start by implementing the
Federation part which might be the most expected feature for Knox users (a
bit like buji-pac4j: https://github.com/bujiio/buji-pac4j is for Shiro) and
see if it's worth the work to have an authentication provider with pac4j in
addition to the one of Shiro.
I plan to start working on that next week. Do you accept pull requests on
Github (it would make discussion easier on source code)?
Any feedback will be appreciated.
Thanks.
Best regards,
Jérôme
2015-11-05 17:13 GMT+01:00 larry mccay:
> Hi Jérôme -
>
> Contributions coming from the community are owned and maintained by the
> entire community.
> You would certainly not be expected to do all work on it and at the same
> time any assistance and upgrade messages that you provided would be awesome.
>
> As for an empty module for pac4j, maybe the following example project
> would be helpful to you:
>
> https://github.com/lmccay/gateway-provider-security-pseudo
>
> It is in support of an article to illustrate how to go about adding a
> authentication or federation provider - as you would be doing:
>
> https://github.com/lmccay/gateway-provider-security-pseudo/blob/master/AddingFederationProvider.md
>
> That may be easier to consume than the entire developers guide.
> That said, it would be great if you could describe what makes the dev
> guide too much - if that is the case.
>
> I'll take a stab at your questions here but we should move more detailed
> discussions on the topic to the dev@ list in order to keep this in the
> open and provide insights to others:
>
> 1) What do I do with the authenticated user: where / how do I fill this
> identity in Knox?
>
> We normalize the authentication event into a Java subject to represent the
> user, groups and impersonated user as appropriate.
> In cases - like shiro - where we don't have access to the actual
> authenticating code and we need to normalize the provider specific security
> context, we add another filter. You can look at the shiro provider for an
> example. The code inside the simple example provider in the article also
> shows what is expected at least in terms of the PrimaryPrincipal.
>
> 2) How to handle errors: not authenticated, not authorized?
>
> We aren't intrusive on what should be done by a provider here.
> Generally, authentication failures result in a 401 and authorizations in a
> 403 and they are usually sent by the provider.
>
> 3) How to handle redirections to an external provider?
>
> Redirects are sent by the providers themselves with a 307 or 302.
> You can look at the SSOCookieFederationFilter in the jwt module as an
> example if you like.
>
> 4) Should the pac4j filter also handle authorizations (pac4j can do that)?
>
> This is an interesting question.
> Knox provides a separate slot in the provider chain for authorization.
> It is there because of the ability for identity assertion providers to map
> principals in order to impersonate another user or map external usernames
> to those used inside of hadoop clusters. So, the authorization decisions
> are made based on those identities.
>
> If we can add the authorization filter as an authorization provider rather
> than part of the authentication provider than that might make sense.
> Although, the security context is normalized as Knox expects not as pac4j
> authorization probably does. Now, if there is real value in doing so, the
> pac4j Subject adaptor could stuff additional context into the Subject or
> the request that can be accessed later by the pac4j authorization provider.
>
> So, it can be done - the question is whether there is compelling reason to
> do so.
>
> 5) How to test?
>
> This can be challenging especially for external authentications and web
> app flows.
> Generally, unit testing as much as possible is required.
> We would want to make sure that the security context normalization happens
> as expected, etc.
>
> Additional considerations:
>
> 1. Our Shiro provider does group lookup and caching of the authentication
> event for optimizing interactions with authentication servers, LDAP, AD,
> etc. We wouldn't want to lose these. Doing so would be a non-starter for
> most folks replacing what Shiro is used for today.
> 2. It is probably best to concentrate on the gaps that pac4j can fill for
> openid, oauth, etc for the initial contribution and if the usecases handled
> by Shiro can be done better, easier, simpler then we can consider a
> migration path.
>
> BTW - we have a couple very interesting possibilities for strong and
> multi-factor authentication that would be enabled by OpenID immediately.
>
> Hope this isn't too long a response and that it is helpful for you.
>
> Let's determine what an initial contribution would be for and bring a
> proposal to the dev@ list and/or file a jira for the integration.
> This would be great for adding features and growing the community - so we
> are all for it!
>
> thanks,
>
> --larry
>
>
> On Thu, Nov 5, 2015 at 9:43 AM, Jérôme LELEU <le...@gmail.com> wrote:
>
>> Hi,
>>
>> I see that Shiro is already used for basic auth and LDAP authentication
>> and Picketlink for SAML. pac4j v1.8 can now handle both cases and even
>> more. So I think we could create a gateway-provider-security-pac4j
>> supporting all authentication mechanisms and not only OpenID.
>>
>> pac4j implementations generally work with two filters: one to protect a
>> resource and play direct authentication like basic auth (and check
>> authorizations) and a callback filter to finish remote authentication like
>> Facebook, SAML, OpenID. The easiest one is the j2e-pac4j with:
>> https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/RequiresAuthenticationFilter.java#L96
>> and
>> https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/CallbackFilter.java#L65
>>
>> That said, I have already many pac4j implementations to handle so I'm
>> pushing communities to maintain on their own their pac4j implementations:
>> can we imagine having an official: gateway-provider-security-pac4j module
>> maintained by the Knox community with my help of course? This is the kind
>> of message I deliver to communities when a new version of pac4j is
>> available so that they can upgrade:
>> https://github.com/ratpack/ratpack/issues/819
>>
>> I read: https://knox.apache.org/books/knox-0-6-0/dev-guide.html#Providers,
>> it might be easy for Knox contributors, but it's a bit hard for me to get
>> in everything: can you or someone in the Knox community provides me an
>> empty gateway-provider-security-pac4j module and the default expectations
>> from a Knox point of view?
>> My main questions:
>> 1) What do I do with the authenticated user: where / how do I fill this
>> identity in Knox?
>> 2) How to handle errors: not authenticated, not authorized?
>> 3) How to handle redirections to an external provider?
>> 4) Should the pac4j filter also handle authorizations (pac4j can do that)?
>> 5) How to test?
>>
>> Thanks.
>> Best regards,
>> Jérôme
>>
>>
>>
>>
>> 2015-11-03 16:58 GMT+01:00 larry mccay:
>>
>>> Hi Jérôme -
>>>
>>> We were evaluating buji-pac4j for SSO with SAML and ended up going with
>>> Picketlink at the time.
>>> That said, we do have a pluggable architecture that would allow for a
>>> pac4j provider as well.
>>>
>>> If you are interested in contributing such a provider that would
>>> certainly be welcome.
>>> There is someone in the community working on an openid provider but
>>> perhaps pac4j would be the way to go there?
>>>
>>> thanks,
>>>
>>> --larry
>>>
>>>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Good catch. Will test with the right role...
2015-11-10 17:36 GMT+01:00 Kevin Minder <ke...@hortonworks.com>:
> To be a bit more explicit your Pac4jFederationProviderContributor declares
> itself to be of role “federation” but when you used it in the sandbox.xml
> topology file you were attempting to configure it as an provider with role
> authentication.
>
>
>
>
> On 11/10/15, 11:32 AM, "larry mccay" <lm...@apache.org> wrote:
>
> >Let's get you past the error that you are getting...
> >
> >It seems as though you have change the topology for pac4j but didn't
> change
> >the role to "federation".
> >It looks like it is grabbing a random authentication provider and seems to
> >be the hadoop-auth provider.
> >
> >Change that to federation and see if that helps.
> >
> >On Tue, Nov 10, 2015 at 11:21 AM, larry mccay <lm...@apache.org> wrote:
> >
> >> Hi Jérôme -
> >>
> >> Happy to see you here!
> >> I apologize for having missed your note on the list a few days ago.
> >>
> >> Glad to see that the article was helpful and it seems like you are
> making
> >> great progress.
> >>
> >> Let me dig into your note a bit deeper and answer your questions.
> >>
> >> Welcome!
> >>
> >> --larry
> >>
> >> On Tue, Nov 10, 2015 at 11:14 AM, Jérôme LELEU <le...@gmail.com>
> wrote:
> >>
> >>> Hi,
> >>>
> >>> Perfect timing ;-) I have started implemented the pac4j support in
> Knox,
> >>> it's a very basic attempt: https://github.com/apache/knox/pull/2/files
> >>>
> >>> This implementation reuses the pac4j implementation for J2E. I have a
> >>> ProviderDeploymentContributorBase which registers two filters:
> >>> - the first one is a dispatcher filter which uses the j2e-pac4j
> >>> CallbackFilter on the /callabck url (it finishes the authentication
> process
> >>> after a successful authentication at some identity provider) and uses
> the
> >>> j2e-pac4j RequiresAuthenticationFilter otherwise (redirection to the
> >>> identity provider to start the authentication when the user is not
> >>> authenticated)
> >>> - the second one is an identity adapter which gets the current
> >>> authenticated user from the pac4j point of view and populates the J2E
> >>> security context.
> >>>
> >>>
> >>> * I have the following error:
> >>>
> >>> 2015-11-10 16:30:22,347 ERROR hadoop.gateway
> >>> (GatewayFilter.java:doFilter(135)) - Gateway processing failed:
> >>> javax.servlet.ServletException: javax.servlet.ServletException:
> >>> Authentication type must be specified: simple|kerberos|<class>
> >>> javax.servlet.ServletException: javax.servlet.ServletException:
> >>> Authentication type must be specified: simple|kerberos|<class>
> >>> at
> >>>
> org.apache.hadoop.gateway.GatewayFilter$Holder.getInstance(GatewayFilter.java:354)
> >>>
> >>> Notice I have changed the sandbox.xml file to use pac4j instead of
> Shiro,
> >>> maybe it's not the right way:
> >>>
> https://github.com/apache/knox/pull/2/files#diff-128ca80baa2dfd6c2d25de7b8160b9d9R24
> >>>
> >>> Any idea of the problem?
> >>>
> >>>
> >>> * Am I understanding webflows correctly?
> >>>
> >>> I use the default request to: curl -ivk "
> >>> https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS"
> >>>
> >>> It looks like a REST request, though I'm expecting the following
> webflow:
> >>> redirection of the user to the identity provider, successful login,
> >>> redirection back to the /callback url of the gateway: do I get it
> right?
> >>>
> >>>
> >>> * The callback url
> >>>
> >>> I currently do a check expecting the last part of the url to end with
> >>> /callback, but does the gateway will receive requests on this url? Do I
> >>> have to do something special?
> >>>
> >>> It's highly recommended to only have one callback url as this url is
> >>> defined on the identity provider side.
> >>>
> >>>
> >>> * How to pass configuration?
> >>>
> >>> Currently, I hardcoded a FacebookClient for Facebook authentication,
> but
> >>> we should be able to pass the appropriate client like Facebook or SAML.
> >>> Basically, we could do that using filter properties: facebook.key +
> >>> facebook.secret means we use Facebook authentication with the
> appropriate
> >>> key and secret for example. Any recommendation?
> >>>
> >>>
> >>> * Can I use the J2E session to store the requested protected url and
> >>> other information?
> >>>
> >>> Or do I need to do something special?
> >>>
> >>>
> >>> Thanks.
> >>> Best regards,
> >>> Jérôme
> >>>
> >>> 2015-11-10 17:03 GMT+01:00 Kevin Minder <kevin.minder@hortonworks.com
> >:
> >>>
> >>>> Hi Jerome,
> >>>> This sounds very exciting and is just the sort of thing the open
> >>>> architecture of Knox is intended to allow. Larry and I have looked at
> >>>> pac4j a number of times thinking that it would be a good fit and would
> >>>> provide a great feature set to the Hadoop community.
> >>>> Kevin.
> >>>>
> >>>>
> >>>>
> >>>> On 11/6/15, 3:31 AM, "Jérôme LELEU" <le...@gmail.com> wrote:
> >>>>
> >>>> >Hi,
> >>>> >
> >>>> >Let's open this private discussion on the Knox dev mailing list.
> >>>> >
> >>>> >I'm Jerome Leleu and the creator of pac4j (
> >>>> https://github.com/pac4j/pac4j),
> >>>> >a security engine for Java with many implementations for J2E, Play,
> >>>> Spring,
> >>>> >Vertx, Ratpack... The idea is to offer something as powerful as
> Spring
> >>>> >Security, but a lot easier and for all Java frameworks / tools and
> all
> >>>> >authentication mechanisms.
> >>>> >
> >>>> >Two years ago, we had a discussion with Larry on how pac4j could be
> >>>> used in
> >>>> >Knox.
> >>>> >
> >>>> >Meanwhile, both projects have grown up and I'm back to try to see if
> >>>> pac4j
> >>>> >can help Knox in terms of security.
> >>>> >
> >>>> >-----
> >>>> >
> >>>> >In its latest version, pac4j can be used to build a full security
> >>>> library,
> >>>> >not only focused on delegated authentication (Facebook, SAML). So we
> >>>> have
> >>>> >the concepts of direct clients (a client is an authentication
> >>>> mechanism):
> >>>> >basic auth, header, token... and indirect clients: SAML, Facebook,
> >>>> OpenID,
> >>>> >CAS...
> >>>> >It seems to be very close to the Authentication and Federation
> Providers
> >>>> >concepts from Knox.
> >>>> >
> >>>> >The provided article is great and as it's focused on authentication
> >>>> with a
> >>>> >real example, it's easier to start with it.
> >>>> >
> >>>> >Thanks for your answers.
> >>>> >
> >>>> >Like Shiro, pac4j has LDAP support and caching can be done. The only
> >>>> >difference is that pac4j relies on ldaptive (
> http://www.ldaptive.org/).
> >>>> But
> >>>> >I think you're right: it would be better to start by implementing the
> >>>> >Federation part which might be the most expected feature for Knox
> users
> >>>> (a
> >>>> >bit like buji-pac4j: https://github.com/bujiio/buji-pac4j is for
> >>>> Shiro) and
> >>>> >see if it's worth the work to have an authentication provider with
> >>>> pac4j in
> >>>> >addition to the one of Shiro.
> >>>> >
> >>>> >I plan to start working on that next week. Do you accept pull
> requests
> >>>> on
> >>>> >Github (it would make discussion easier on source code)?
> >>>> >
> >>>> >Any feedback will be appreciated.
> >>>> >
> >>>> >Thanks.
> >>>> >Best regards,
> >>>> >Jérôme
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> >2015-11-05 17:13 GMT+01:00 larry mccay:
> >>>> >
> >>>> >> Hi Jérôme -
> >>>> >>
> >>>> >> Contributions coming from the community are owned and maintained by
> >>>> the
> >>>> >> entire community.
> >>>> >> You would certainly not be expected to do all work on it and at the
> >>>> same
> >>>> >> time any assistance and upgrade messages that you provided would be
> >>>> awesome.
> >>>> >>
> >>>> >> As for an empty module for pac4j, maybe the following example
> project
> >>>> >> would be helpful to you:
> >>>> >>
> >>>> >> https://github.com/lmccay/gateway-provider-security-pseudo
> >>>> >>
> >>>> >> It is in support of an article to illustrate how to go about
> adding a
> >>>> >> authentication or federation provider - as you would be doing:
> >>>> >>
> >>>> >>
> >>>>
> https://github.com/lmccay/gateway-provider-security-pseudo/blob/master/AddingFederationProvider.md
> >>>> >>
> >>>> >> That may be easier to consume than the entire developers guide.
> >>>> >> That said, it would be great if you could describe what makes the
> dev
> >>>> >> guide too much - if that is the case.
> >>>> >>
> >>>> >> I'll take a stab at your questions here but we should move more
> >>>> detailed
> >>>> >> discussions on the topic to the dev@ list in order to keep this in
> >>>> the
> >>>> >> open and provide insights to others:
> >>>> >>
> >>>> >> 1) What do I do with the authenticated user: where / how do I fill
> >>>> this
> >>>> >> identity in Knox?
> >>>> >>
> >>>> >> We normalize the authentication event into a Java subject to
> >>>> represent the
> >>>> >> user, groups and impersonated user as appropriate.
> >>>> >> In cases - like shiro - where we don't have access to the actual
> >>>> >> authenticating code and we need to normalize the provider specific
> >>>> security
> >>>> >> context, we add another filter. You can look at the shiro provider
> >>>> for an
> >>>> >> example. The code inside the simple example provider in the article
> >>>> also
> >>>> >> shows what is expected at least in terms of the PrimaryPrincipal.
> >>>> >>
> >>>> >> 2) How to handle errors: not authenticated, not authorized?
> >>>> >>
> >>>> >> We aren't intrusive on what should be done by a provider here.
> >>>> >> Generally, authentication failures result in a 401 and
> authorizations
> >>>> in a
> >>>> >> 403 and they are usually sent by the provider.
> >>>> >>
> >>>> >> 3) How to handle redirections to an external provider?
> >>>> >>
> >>>> >> Redirects are sent by the providers themselves with a 307 or 302.
> >>>> >> You can look at the SSOCookieFederationFilter in the jwt module as
> an
> >>>> >> example if you like.
> >>>> >>
> >>>> >> 4) Should the pac4j filter also handle authorizations (pac4j can do
> >>>> that)?
> >>>> >>
> >>>> >> This is an interesting question.
> >>>> >> Knox provides a separate slot in the provider chain for
> authorization.
> >>>> >> It is there because of the ability for identity assertion providers
> >>>> to map
> >>>> >> principals in order to impersonate another user or map external
> >>>> usernames
> >>>> >> to those used inside of hadoop clusters. So, the authorization
> >>>> decisions
> >>>> >> are made based on those identities.
> >>>> >>
> >>>> >> If we can add the authorization filter as an authorization provider
> >>>> rather
> >>>> >> than part of the authentication provider than that might make
> sense.
> >>>> >> Although, the security context is normalized as Knox expects not as
> >>>> pac4j
> >>>> >> authorization probably does. Now, if there is real value in doing
> so,
> >>>> the
> >>>> >> pac4j Subject adaptor could stuff additional context into the
> Subject
> >>>> or
> >>>> >> the request that can be accessed later by the pac4j authorization
> >>>> provider.
> >>>> >>
> >>>> >> So, it can be done - the question is whether there is compelling
> >>>> reason to
> >>>> >> do so.
> >>>> >>
> >>>> >> 5) How to test?
> >>>> >>
> >>>> >> This can be challenging especially for external authentications and
> >>>> web
> >>>> >> app flows.
> >>>> >> Generally, unit testing as much as possible is required.
> >>>> >> We would want to make sure that the security context normalization
> >>>> happens
> >>>> >> as expected, etc.
> >>>> >>
> >>>> >> Additional considerations:
> >>>> >>
> >>>> >> 1. Our Shiro provider does group lookup and caching of the
> >>>> authentication
> >>>> >> event for optimizing interactions with authentication servers,
> LDAP,
> >>>> AD,
> >>>> >> etc. We wouldn't want to lose these. Doing so would be a
> non-starter
> >>>> for
> >>>> >> most folks replacing what Shiro is used for today.
> >>>> >> 2. It is probably best to concentrate on the gaps that pac4j can
> fill
> >>>> for
> >>>> >> openid, oauth, etc for the initial contribution and if the usecases
> >>>> handled
> >>>> >> by Shiro can be done better, easier, simpler then we can consider a
> >>>> >> migration path.
> >>>> >>
> >>>> >> BTW - we have a couple very interesting possibilities for strong
> and
> >>>> >> multi-factor authentication that would be enabled by OpenID
> >>>> immediately.
> >>>> >>
> >>>> >> Hope this isn't too long a response and that it is helpful for you.
> >>>> >>
> >>>> >> Let's determine what an initial contribution would be for and
> bring a
> >>>> >> proposal to the dev@ list and/or file a jira for the integration.
> >>>> >> This would be great for adding features and growing the community -
> >>>> so we
> >>>> >> are all for it!
> >>>> >>
> >>>> >> thanks,
> >>>> >>
> >>>> >> --larry
> >>>> >>
> >>>> >>
> >>>> >> On Thu, Nov 5, 2015 at 9:43 AM, Jérôme LELEU <le...@gmail.com>
> >>>> wrote:
> >>>> >>
> >>>> >>> Hi,
> >>>> >>>
> >>>> >>> I see that Shiro is already used for basic auth and LDAP
> >>>> authentication
> >>>> >>> and Picketlink for SAML. pac4j v1.8 can now handle both cases and
> >>>> even
> >>>> >>> more. So I think we could create a gateway-provider-security-pac4j
> >>>> >>> supporting all authentication mechanisms and not only OpenID.
> >>>> >>>
> >>>> >>> pac4j implementations generally work with two filters: one to
> >>>> protect a
> >>>> >>> resource and play direct authentication like basic auth (and check
> >>>> >>> authorizations) and a callback filter to finish remote
> >>>> authentication like
> >>>> >>> Facebook, SAML, OpenID. The easiest one is the j2e-pac4j with:
> >>>> >>>
> >>>>
> https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/RequiresAuthenticationFilter.java#L96
> >>>> >>> and
> >>>> >>>
> >>>>
> https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/CallbackFilter.java#L65
> >>>> >>>
> >>>> >>> That said, I have already many pac4j implementations to handle so
> I'm
> >>>> >>> pushing communities to maintain on their own their pac4j
> >>>> implementations:
> >>>> >>> can we imagine having an official: gateway-provider-security-pac4j
> >>>> module
> >>>> >>> maintained by the Knox community with my help of course? This is
> the
> >>>> kind
> >>>> >>> of message I deliver to communities when a new version of pac4j is
> >>>> >>> available so that they can upgrade:
> >>>> >>> https://github.com/ratpack/ratpack/issues/819
> >>>> >>>
> >>>> >>> I read:
> >>>> https://knox.apache.org/books/knox-0-6-0/dev-guide.html#Providers,
> >>>> >>> it might be easy for Knox contributors, but it's a bit hard for me
> >>>> to get
> >>>> >>> in everything: can you or someone in the Knox community provides
> me
> >>>> an
> >>>> >>> empty gateway-provider-security-pac4j module and the default
> >>>> expectations
> >>>> >>> from a Knox point of view?
> >>>> >>> My main questions:
> >>>> >>> 1) What do I do with the authenticated user: where / how do I fill
> >>>> this
> >>>> >>> identity in Knox?
> >>>> >>> 2) How to handle errors: not authenticated, not authorized?
> >>>> >>> 3) How to handle redirections to an external provider?
> >>>> >>> 4) Should the pac4j filter also handle authorizations (pac4j can
> do
> >>>> that)?
> >>>> >>> 5) How to test?
> >>>> >>>
> >>>> >>> Thanks.
> >>>> >>> Best regards,
> >>>> >>> Jérôme
> >>>> >>>
> >>>> >>>
> >>>> >>>
> >>>> >>>
> >>>> >>> 2015-11-03 16:58 GMT+01:00 larry mccay:
> >>>> >>>
> >>>> >>>> Hi Jérôme -
> >>>> >>>>
> >>>> >>>> We were evaluating buji-pac4j for SSO with SAML and ended up
> going
> >>>> with
> >>>> >>>> Picketlink at the time.
> >>>> >>>> That said, we do have a pluggable architecture that would allow
> for
> >>>> a
> >>>> >>>> pac4j provider as well.
> >>>> >>>>
> >>>> >>>> If you are interested in contributing such a provider that would
> >>>> >>>> certainly be welcome.
> >>>> >>>> There is someone in the community working on an openid provider
> but
> >>>> >>>> perhaps pac4j would be the way to go there?
> >>>> >>>>
> >>>> >>>> thanks,
> >>>> >>>>
> >>>> >>>> --larry
> >>>> >>>>
> >>>> >>>>
> >>>>
> >>>
> >>>
> >>
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
Adding Kevin - since he is somehow not getting this thread anymore...
On Wed, Nov 25, 2015 at 8:18 AM, larry mccay <la...@gmail.com> wrote:
> inline...
>
> On Wed, Nov 25, 2015 at 5:04 AM, Jérôme LELEU <le...@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 <la...@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 <le...@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 <la...@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 <le...@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 <la...@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
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Yes, it's a good explanation. The j2e-pac4j does not do that in fact as for
all pac4j implementations, the ProfileManager based on the current
WebContext is the good way to get the current authenticated user...
2015-12-03 13:28 GMT+01:00 larry mccay <la...@gmail.com>:
> "Why it doesn't work for pac4j while it works for others is a bit strange
> to
> me,"
>
> I forgot to address this and it may be of interest for you in pac4j...
>
> I believe that the other authentication providers that I have tested with
> have their own request wrappers that are taking care of the
> getUserPrincipal method. Shiro and Picketlink must both take care of that
> after successful authentication when they are in an EE environment.
>
> The pac4j for EE maybe should consider doing the same?
>
> The fact that all providers won't necessarily do this means that Knox
> should do it as well - just in case.
>
> On Wed, Dec 2, 2015 at 12:12 PM, Jérôme LELEU <le...@gmail.com> wrote:
>
> > Hi,
> >
> > Why it doesn't work for pac4j while it works for others is a bit strange
> to
> > me, but if you have the patch in front of your eyes, I'd rather prefer
> you
> > to commit it. In all cases, I'll sync with the master.
> >
> > There was one question you didn't answer previously: is the password
> > generated for the pac4j provider the same across all gateway instances?
> > Because I expect to have the same value as I use it to encrypt / decrypt
> > data.
> >
> > I will add the Javadoc. After that, you can review the pull request more
> > completely.
> >
> > What do you expect for the documentation?
> >
> > Notice that pac4j dependencies are still snapshots, but they will be
> > released in a week or two.
> >
> > Thanks.
> > Best regards,
> > Jérôme
> >
> >
> > 2015-12-02 17:51 GMT+01:00 larry mccay <la...@gmail.com>:
> >
> > > Jérôme -
> > >
> > > If you would like to add that change as part of your patch or as a
> > > separately filed JIRA to fix a bug that would certainly be welcomed.
> > > Otherwise, I can do it.
> > >
> > > Let me know.
> > >
> > > thanks,
> > >
> > > --larry
> > >
> > > On Wed, Dec 2, 2015 at 11:44 AM, larry mccay <la...@gmail.com>
> > > wrote:
> > >
> > > > Okay - I had to add an override of getUserPrincipal() to the
> > > > IdentityAsserterHttpServletRequestWrapper and return the member
> > variable
> > > > username and it works like a charm.
> > > >
> > > > Why I haven't seen this same behavior with other providers is a bit
> of
> > a
> > > > mystery but they must be adding other wrappers that handle it.
> > > > This is quite cool, Jérôme!
> > > >
> > > > On Wed, Dec 2, 2015 at 10:41 AM, larry mccay <la...@gmail.com>
> > > > wrote:
> > > >
> > > >> That was it - thanks!
> > > >>
> > > >> On Wed, Dec 2, 2015 at 10:20 AM, Jérôme LELEU <le...@gmail.com>
> > wrote:
> > > >>
> > > >>> This is my exact command line: mvn -Prelease clean install
> > -DskipTests
> > > >>>
> > > >>> You use an internal Maven repository to fetch dependencies from
> > > internet:
> > > >>> http://nexus-private.hortonworks.com/nexus/content/groups/public/
> > > >>>
> > > >>> Does this repository have access to the remote Snapshots Sonatype
> > repo?
> > > >>>
> > > >>>
> > > >>>
> > > >>> 2015-12-02 16:16 GMT+01:00 larry mccay <la...@gmail.com>:
> > > >>>
> > > >>> > hmmm - I used:
> > > >>> >
> > > >>> > mvn clean install -DskipTests=true -Prelease
> > > >>> >
> > > >>> > The repository entry is in there already.
> > > >>> > No worky.
> > > >>> >
> > > >>> > On Wed, Dec 2, 2015 at 10:12 AM, Jérôme LELEU <le...@gmail.com>
> > > >>> wrote:
> > > >>> >
> > > >>> > > Hi,
> > > >>> > >
> > > >>> > > You need the j2e-pac4j dependencies as well as the pac4j-*
> > > >>> dependencies,
> > > >>> > > but you don't need to build them locally (hopefully).
> > > >>> > >
> > > >>> > > But you need a dependency on the Sonatype snapshots repository
> > > >>> (where the
> > > >>> > > snapshot versions are hosted), which is added for Maven in the
> > root
> > > >>> > > pom.xml:
> > > >>> > >
> > > >>> > >
> > > >>> >
> > > >>>
> > >
> >
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> > > >>> > >
> > > >>> > > If you use Ant for the build, there is maybe a glitch to find
> the
> > > >>> > Sonatype
> > > >>> > > Maven repo.
> > > >>> > >
> > > >>> > > Thanks.
> > > >>> > > Best regards,
> > > >>> > > Jérôme
> > > >>> > >
> > > >>> > >
> > > >>> > > 2015-12-02 16:06 GMT+01:00 larry mccay <larry.mccay@gmail.com
> >:
> > > >>> > >
> > > >>> > > > 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.mccay@gmail.com>
> > > >>> > > > wrote:
> > > >>> > > >
> > > >>> > > > > gateway-provider-security-pac4j doesn't build - do you
> have a
> > > >>> pending
> > > >>> > > > > change for your pom.xml or something?
> > > >>> > > > >
> > > >>> >
> > > >>>
> > > >>
> > > >>
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
"Why it doesn't work for pac4j while it works for others is a bit strange to
me,"
I forgot to address this and it may be of interest for you in pac4j...
I believe that the other authentication providers that I have tested with
have their own request wrappers that are taking care of the
getUserPrincipal method. Shiro and Picketlink must both take care of that
after successful authentication when they are in an EE environment.
The pac4j for EE maybe should consider doing the same?
The fact that all providers won't necessarily do this means that Knox
should do it as well - just in case.
On Wed, Dec 2, 2015 at 12:12 PM, Jérôme LELEU <le...@gmail.com> wrote:
> Hi,
>
> Why it doesn't work for pac4j while it works for others is a bit strange to
> me, but if you have the patch in front of your eyes, I'd rather prefer you
> to commit it. In all cases, I'll sync with the master.
>
> There was one question you didn't answer previously: is the password
> generated for the pac4j provider the same across all gateway instances?
> Because I expect to have the same value as I use it to encrypt / decrypt
> data.
>
> I will add the Javadoc. After that, you can review the pull request more
> completely.
>
> What do you expect for the documentation?
>
> Notice that pac4j dependencies are still snapshots, but they will be
> released in a week or two.
>
> Thanks.
> Best regards,
> Jérôme
>
>
> 2015-12-02 17:51 GMT+01:00 larry mccay <la...@gmail.com>:
>
> > Jérôme -
> >
> > If you would like to add that change as part of your patch or as a
> > separately filed JIRA to fix a bug that would certainly be welcomed.
> > Otherwise, I can do it.
> >
> > Let me know.
> >
> > thanks,
> >
> > --larry
> >
> > On Wed, Dec 2, 2015 at 11:44 AM, larry mccay <la...@gmail.com>
> > wrote:
> >
> > > Okay - I had to add an override of getUserPrincipal() to the
> > > IdentityAsserterHttpServletRequestWrapper and return the member
> variable
> > > username and it works like a charm.
> > >
> > > Why I haven't seen this same behavior with other providers is a bit of
> a
> > > mystery but they must be adding other wrappers that handle it.
> > > This is quite cool, Jérôme!
> > >
> > > On Wed, Dec 2, 2015 at 10:41 AM, larry mccay <la...@gmail.com>
> > > wrote:
> > >
> > >> That was it - thanks!
> > >>
> > >> On Wed, Dec 2, 2015 at 10:20 AM, Jérôme LELEU <le...@gmail.com>
> wrote:
> > >>
> > >>> This is my exact command line: mvn -Prelease clean install
> -DskipTests
> > >>>
> > >>> You use an internal Maven repository to fetch dependencies from
> > internet:
> > >>> http://nexus-private.hortonworks.com/nexus/content/groups/public/
> > >>>
> > >>> Does this repository have access to the remote Snapshots Sonatype
> repo?
> > >>>
> > >>>
> > >>>
> > >>> 2015-12-02 16:16 GMT+01:00 larry mccay <la...@gmail.com>:
> > >>>
> > >>> > hmmm - I used:
> > >>> >
> > >>> > mvn clean install -DskipTests=true -Prelease
> > >>> >
> > >>> > The repository entry is in there already.
> > >>> > No worky.
> > >>> >
> > >>> > On Wed, Dec 2, 2015 at 10:12 AM, Jérôme LELEU <le...@gmail.com>
> > >>> wrote:
> > >>> >
> > >>> > > Hi,
> > >>> > >
> > >>> > > You need the j2e-pac4j dependencies as well as the pac4j-*
> > >>> dependencies,
> > >>> > > but you don't need to build them locally (hopefully).
> > >>> > >
> > >>> > > But you need a dependency on the Sonatype snapshots repository
> > >>> (where the
> > >>> > > snapshot versions are hosted), which is added for Maven in the
> root
> > >>> > > pom.xml:
> > >>> > >
> > >>> > >
> > >>> >
> > >>>
> >
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> > >>> > >
> > >>> > > If you use Ant for the build, there is maybe a glitch to find the
> > >>> > Sonatype
> > >>> > > Maven repo.
> > >>> > >
> > >>> > > Thanks.
> > >>> > > Best regards,
> > >>> > > Jérôme
> > >>> > >
> > >>> > >
> > >>> > > 2015-12-02 16:06 GMT+01:00 larry mccay <la...@gmail.com>:
> > >>> > >
> > >>> > > > 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.mccay@gmail.com>
> > >>> > > > wrote:
> > >>> > > >
> > >>> > > > > gateway-provider-security-pac4j doesn't build - do you have a
> > >>> pending
> > >>> > > > > change for your pom.xml or something?
> > >>> > > > >
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Thanks for the review. I will read your comments and post on the JIRA...
2015-12-14 15:28 GMT+01:00 larry mccay <la...@gmail.com>:
> Hi Jérôme -
>
> Not sure if you saw but I added review comments to KNOX-641.
>
> I think that we need to determine whether we want the testBasicAuth in the
> provider itself.
>
> Let's follow up on the JIRA.
>
> thanks,
>
> --larry
>
> On Fri, Dec 11, 2015 at 8:44 AM, Jérôme LELEU <le...@gmail.com> wrote:
>
> > Hi,
> >
> > No problem. It can go into a version 0.8.0 if needed. The truth is that
> > there is only one change outside the new pac4j module, so I think risks
> are
> > extremly limited.
> >
> > Just let met know.
> >
> > Thanks.
> > Best regards,
> > Jérôme
> >
> >
> > 2015-12-11 14:23 GMT+01:00 larry mccay <la...@gmail.com>:
> >
> > > Hi Jérôme -
> > >
> > > I have unfortunately not had a chance to pull, review and test it yet
> and
> > > have intended to do that today.
> > > I apologize for the delay.
> > >
> > > I was actually thinking that this would go into a follow up release
> that
> > we
> > > would try and get done rapidly after the 0.7.0 release but we can
> discuss
> > > the target and its chances of destabilizing 0.7.0.
> > >
> > > I believe that it is rather self-contained with only a few changes to
> > > external modules.
> > >
> > > Opening the JIRAs is perfect and I was going to do that once I started
> > the
> > > review.
> > >
> > > Let's continue review comments and collaboration on those JIRAs.
> > > I will add you to the contributors list so that we can assign them to
> > you.
> > >
> > > Thank you for your contributions and your patience, Jérôme!
> > >
> > > --larry
> > >
> > > On Fri, Dec 11, 2015 at 3:00 AM, Jérôme LELEU <le...@gmail.com>
> wrote:
> > >
> > > > Hi,
> > > >
> > > > I didn't get any new feedback on the pull request so I assume
> > everything
> > > is
> > > > ok from your point of view.
> > > >
> > > > I released pac4j v1.8.1 and j2e-pac4j v1.2.1 so I updated the pull
> > > request
> > > > to use them and successfully re-tested everything.
> > > >
> > > > I opened KNOX-641 and submitted the corresponding patch.
> > > >
> > > > I also wrote the documentation, opened KNOX-642 and submitted the
> > > > corresponding patch (just to let you know that it doesn't work out of
> > the
> > > > box in Windows, I had to replace mvn.bat by mvn.cmd to make ant
> work).
> > > >
> > > > Even if the branch 0.7.0 has already been created, I assumed this new
> > > pac4j
> > > > provider will go into this version 0.7.0 (dependency on the
> > > 0.7.0-SNAPSHOT
> > > > parent version).
> > > >
> > > > Just let me know if everything is ok and when it's goind to be
> merged.
> > > >
> > > > Thanks.
> > > > Best regards,
> > > > Jérôme
> > > >
> > > >
> > > >
> > > >
> > > > 2015-12-04 14:20 GMT+01:00 larry mccay <la...@gmail.com>:
> > > >
> > > > > That ability to configure multiple mechanisms based on clientName
> is
> > > > really
> > > > > interesting for Knox.
> > > > > Currently, we require separate topologies per authentication
> > mechanism.
> > > > > The ability to configure them all in one is really great.
> > > > >
> > > > > We would need to think through the best way to provide the
> clientName
> > > > > parameter.
> > > > > Since this is targeting KnoxSSO it can actually be added to the
> > > > providerURL
> > > > > used to redirect from the participating application.
> > > > > Regardless of the authentication mechanism used each application
> will
> > > > still
> > > > > get the same JWT based cookie.
> > > > >
> > > > > I think that should work really nicely.
> > > > >
> > > > >
> > > > > On Fri, Dec 4, 2015 at 7:17 AM, larry mccay <larry.mccay@gmail.com
> >
> > > > wrote:
> > > > >
> > > > > > Excellent, Jérôme.
> > > > > > Thanks!
> > > > > >
> > > > > > On Fri, Dec 4, 2015 at 2:40 AM, Jérôme LELEU <le...@gmail.com>
> > > wrote:
> > > > > >
> > > > > >> Hi,
> > > > > >>
> > > > > >> I will write how to configure the pac4j provider in the
> > > documentation,
> > > > > but
> > > > > >> I can already give you some insights.
> > > > > >>
> > > > > >> My main goal is always to respect the key design principles of
> > pac4j
> > > > > >> whatever the environment / framework in which it is implemented.
> > For
> > > > > Knox,
> > > > > >> I'm pretty happy with the use of the j2e-pac4j library, which
> > means
> > > > that
> > > > > >> almost all the pac4j features are available, especially both
> > direct
> > > > and
> > > > > >> indirect clients. So it can do what Shiro already does but also,
> > as
> > > we
> > > > > >> agreed together, supports remote authentications.
> > > > > >>
> > > > > >> It is only limited by what you can currently configure. And even
> > > > > >> configuration is a pac4j feature as the CAS server has the same
> > > need.
> > > > > >> Everything happens in this class:
> > > > > >>
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java
> > > > > >> ,
> > > > > >> which allows you to configure Facebook, Twitter, a CAS server, a
> > > SAML
> > > > > IdP
> > > > > >> or an OpenID Connect provider. All the provided parameters to
> the
> > > > pac4j
> > > > > >> provider are put into a Map and the ConfigPropertiesFactory is
> > built
> > > > > with
> > > > > >> this Map to return the built client (= authentication
> mechanism).
> > > > > >>
> > > > > >> You have one more specific option for Knox as a basic
> > authentication
> > > > > popup
> > > > > >> where the username must match the password, you can define that
> > by:
> > > > > >>
> > > > > >> <param>
> > > > > >> <name>clientName</name>
> > > > > >> <value>testBasicAuth</value>
> > > > > >> </param>
> > > > > >>
> > > > > >>
> > > > > >> It's for testing only.
> > > > > >>
> > > > > >> For a CAS server:
> > > > > >>
> > > > > >> <param>
> > > > > >> <name>cas.loginUrl</name>
> > > > > >> <value>https://casserverpac4j.herokuapp.com/login</value>
> > > > > >> </param>
> > > > > >>
> > > > > >>
> > > > > >> Here are all the properties available for building clients
> (their
> > > > > meaning
> > > > > >> is obvious):
> > > > > >>
> > > > > >> facebook.id
> > > > > >> facebook.secret
> > > > > >> facebook.scope
> > > > > >> facebook.fields
> > > > > >> twitter.id
> > > > > >> twitter.secret
> > > > > >> saml.keystorePassword
> > > > > >> saml.privateKeyPassword
> > > > > >> saml.keystorePath
> > > > > >> saml.identityProviderMetadataPath
> > > > > >> saml.maximumAuthenticationLifetime
> > > > > >> saml.serviceProviderEntityId
> > > > > >> saml.serviceProviderMetadataPath
> > > > > >> cas.loginUrl
> > > > > >> cas.protocol
> > > > > >> oidc.id
> > > > > >> oidc.secret
> > > > > >> oidc.discoveryUri
> > > > > >> oidc.customParamKey1
> > > > > >> oidc.customParamValue1
> > > > > >>
> > > > > >>
> > > > > >> If you define multiple clients, the first one will be used for
> > > > > >> authentication, but you can explicitly choose the client you
> want
> > to
> > > > use
> > > > > >> via the clientName parameter, assuming you want to switch from
> > > client
> > > > > >> depending on environment for example.
> > > > > >>
> > > > > >> So if you want to add some new authentication mechanism, you
> must
> > > > first
> > > > > >> check that it is available in pac4j (if it's not, it's another
> > > > > discussion,
> > > > > >> but generally, it is). Then, you'll need to upgrade the
> > > > > >> ConfigPropertiesFactory by submitting a new pull request to the
> > > pac4j
> > > > > >> project (I can do it myself, but I'm sure you could do that
> > easily),
> > > > > >> finally wait for the new pac4j release and switch pac4j versions
> > in
> > > > Knox
> > > > > >> to
> > > > > >> benefit from the new feature.
> > > > > >> The good thing is that if someone related to the CAS server does
> > the
> > > > > same
> > > > > >> thing for CAS (in pac4j), you will automatically get it when
> > you'll
> > > > > >> upgrade
> > > > > >> pac4j.
> > > > > >>
> > > > > >> To go even further, replacing LDAP Shiro authentication is just
> a
> > > > matter
> > > > > >> of
> > > > > >> making pac4j LDAP authentication available via configuration
> > > > parameters.
> > > > > >>
> > > > > >> I hope it was clear enough.
> > > > > >>
> > > > > >> Thanks.
> > > > > >> Best regards,
> > > > > >> Jérôme
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> 2015-12-03 20:45 GMT+01:00 larry mccay <la...@gmail.com>:
> > > > > >>
> > > > > >> > Excellent!
> > > > > >> >
> > > > > >> > I will carve out some time to do code review.
> > > > > >> > We will need to get some insights into how to go about
> testing:
> > > > > >> >
> > > > > >> > * is the CAS server going to be available for testing?
> > > > > >> > * what are the specific and generic/standard (if any)
> > > authentication
> > > > > >> > mechanisms available - for instance:
> > > > > >> > - Facebook, Google, LinkedIn and CAS are specifics
> > > > > >> > - OAuth 2, OpenID Connect, SAML are generic/standards -
> that
> > > may
> > > > > be
> > > > > >> > used for the above specifics...
> > > > > >> > * how do we test things other than CAS - in terms of getting
> > > > > >> credentials,
> > > > > >> > configuration, etc
> > > > > >> >
> > > > > >> > We could certainly do this is phases as well.
> > > > > >> >
> > > > > >> > If you can enumerate the things that should work and provide
> > some
> > > > > >> testing
> > > > > >> > details for CAS or as many as possible and OpenID Connect then
> > we
> > > > can
> > > > > >> test
> > > > > >> > the specific implementations that you provide and enable the
> > > testing
> > > > > of
> > > > > >> > another OpenID Connect effort that is in the works in the
> > > community.
> > > > > >> >
> > > > > >> > I'm not sure whether we want to commit contributions that are
> > > > > dependent
> > > > > >> on
> > > > > >> > snapshots - we certainly can't release with any such
> > dependencies.
> > > > > >> > I would hate to add a cleanup task to a release to make sure
> > there
> > > > are
> > > > > >> no
> > > > > >> > snapshots in there.
> > > > > >> > We will probably wait until after the pac4j releases to
> commit.
> > > > > >> >
> > > > > >> > I am really happy that this integration is happening and that
> it
> > > > went
> > > > > >> > rather smoothly.
> > > > > >> > These sorts of authentication protocols are complex and I
> think
> > we
> > > > > >> lined up
> > > > > >> > pretty well overall.
> > > > > >> >
> > > > > >> > Thanks for your work!
> > > > > >> >
> > > > > >> > On Thu, Dec 3, 2015 at 2:28 PM, Jérôme LELEU <
> leleuj@gmail.com>
> > > > > wrote:
> > > > > >> >
> > > > > >> > > Hi,
> > > > > >> > >
> > > > > >> > > I just sync'ed with master, cleaned dependencies and added
> > > missing
> > > > > >> > > Javadocs. Everything works correctly now. Many thanks.
> > > > > >> > >
> > > > > >> > > The pull request is ready for a full code review:
> > > > > >> > > https://github.com/apache/knox/pull/2
> > > > > >> > >
> > > > > >> > > I'll write the documentation after the pac4j releases (I
> hope
> > > next
> > > > > >> week).
> > > > > >> > >
> > > > > >> > > Thanks.
> > > > > >> > > Best regards,
> > > > > >> > > Jérôme
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > 2015-12-02 19:18 GMT+01:00 larry mccay <
> larry.mccay@gmail.com
> > >:
> > > > > >> > >
> > > > > >> > > > Fixed in https://issues.apache.org/jira/browse/KNOX-636.
> > > > > >> > > >
> > > > > >> > > > On Wed, Dec 2, 2015 at 12:42 PM, larry mccay <
> > > > > larry.mccay@gmail.com
> > > > > >> >
> > > > > >> > > > wrote:
> > > > > >> > > >
> > > > > >> > > > > Sure - I can file a JIRA and commit a fix.
> > > > > >> > > > >
> > > > > >> > > > > The secret generation should be done in one instance and
> > > > > >> replicated
> > > > > >> > > > across
> > > > > >> > > > > others.
> > > > > >> > > > > This replication/management of the credential stores is
> > > > outside
> > > > > of
> > > > > >> > the
> > > > > >> > > > > scope of Knox itself as of now.
> > > > > >> > > > >
> > > > > >> > > > > Documentation is done in markdown and is contributing
> > > details
> > > > > are
> > > > > >> > > > > available at:
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
> > > > > >> > > > >
> > > > > >> > > > > Which should give you a general idea.
> > > > > >> > > > >
> > > > > >> > > > > Find an example like: ./trunk/books/0.7.0/
> > > > > >> > > config_preauth_sso_provider.md
> > > > > >> > > > >
> > > > > >> > > > > For an example of typical content and format.
> > > > > >> > > > >
> > > > > >> > > > > Here is how that example renders:
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
> > > > > >> > > > >
> > > > > >> > > > > You'll need to tie it into the rest of the book - just
> > grep
> > > > for
> > > > > >> where
> > > > > >> > > > that
> > > > > >> > > > > filename is referenced.
> > > > > >> > > > > To test how it renders build the site with: "ant" and
> note
> > > the
> > > > > >> url to
> > > > > >> > > the
> > > > > >> > > > > 0.7.0 book.
> > > > > >> > > > >
> > > > > >> > > > >
> > > > > >> > > > > On Wed, Dec 2, 2015 at 12:12 PM, Jérôme LELEU <
> > > > leleuj@gmail.com
> > > > > >
> > > > > >> > > wrote:
> > > > > >> > > > >
> > > > > >> > > > >> Hi,
> > > > > >> > > > >>
> > > > > >> > > > >> Why it doesn't work for pac4j while it works for others
> > is
> > > a
> > > > > bit
> > > > > >> > > strange
> > > > > >> > > > >> to
> > > > > >> > > > >> me, but if you have the patch in front of your eyes,
> I'd
> > > > rather
> > > > > >> > prefer
> > > > > >> > > > you
> > > > > >> > > > >> to commit it. In all cases, I'll sync with the master.
> > > > > >> > > > >>
> > > > > >> > > > >> There was one question you didn't answer previously: is
> > the
> > > > > >> password
> > > > > >> > > > >> generated for the pac4j provider the same across all
> > > gateway
> > > > > >> > > instances?
> > > > > >> > > > >> Because I expect to have the same value as I use it to
> > > > encrypt
> > > > > /
> > > > > >> > > decrypt
> > > > > >> > > > >> data.
> > > > > >> > > > >>
> > > > > >> > > > >> I will add the Javadoc. After that, you can review the
> > pull
> > > > > >> request
> > > > > >> > > more
> > > > > >> > > > >> completely.
> > > > > >> > > > >>
> > > > > >> > > > >> What do you expect for the documentation?
> > > > > >> > > > >>
> > > > > >> > > > >> Notice that pac4j dependencies are still snapshots, but
> > > they
> > > > > >> will be
> > > > > >> > > > >> released in a week or two.
> > > > > >> > > > >>
> > > > > >> > > > >> Thanks.
> > > > > >> > > > >> Best regards,
> > > > > >> > > > >> Jérôme
> > > > > >> > > > >>
> > > > > >> > > > >>
> > > > > >> > > > >> 2015-12-02 17:51 GMT+01:00 larry mccay <
> > > > larry.mccay@gmail.com
> > > > > >:
> > > > > >> > > > >>
> > > > > >> > > > >> > Jérôme -
> > > > > >> > > > >> >
> > > > > >> > > > >> > If you would like to add that change as part of your
> > > patch
> > > > or
> > > > > >> as a
> > > > > >> > > > >> > separately filed JIRA to fix a bug that would
> certainly
> > > be
> > > > > >> > welcomed.
> > > > > >> > > > >> > Otherwise, I can do it.
> > > > > >> > > > >> >
> > > > > >> > > > >> > Let me know.
> > > > > >> > > > >> >
> > > > > >> > > > >> > thanks,
> > > > > >> > > > >> >
> > > > > >> > > > >> > --larry
> > > > > >> > > > >> >
> > > > > >> > > > >> > On Wed, Dec 2, 2015 at 11:44 AM, larry mccay <
> > > > > >> > larry.mccay@gmail.com
> > > > > >> > > >
> > > > > >> > > > >> > wrote:
> > > > > >> > > > >> >
> > > > > >> > > > >> > > Okay - I had to add an override of
> getUserPrincipal()
> > > to
> > > > > the
> > > > > >> > > > >> > > IdentityAsserterHttpServletRequestWrapper and
> return
> > > the
> > > > > >> member
> > > > > >> > > > >> variable
> > > > > >> > > > >> > > username and it works like a charm.
> > > > > >> > > > >> > >
> > > > > >> > > > >> > > Why I haven't seen this same behavior with other
> > > > providers
> > > > > >> is a
> > > > > >> > > bit
> > > > > >> > > > >> of a
> > > > > >> > > > >> > > mystery but they must be adding other wrappers that
> > > > handle
> > > > > >> it.
> > > > > >> > > > >> > > This is quite cool, Jérôme!
> > > > > >> > > > >> > >
> > > > > >> > > > >> > > On Wed, Dec 2, 2015 at 10:41 AM, larry mccay <
> > > > > >> > > larry.mccay@gmail.com
> > > > > >> > > > >
> > > > > >> > > > >> > > wrote:
> > > > > >> > > > >> > >
> > > > > >> > > > >> > >> That was it - thanks!
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >> On Wed, Dec 2, 2015 at 10:20 AM, Jérôme LELEU <
> > > > > >> > leleuj@gmail.com>
> > > > > >> > > > >> wrote:
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >>> This is my exact command line: mvn -Prelease
> clean
> > > > > install
> > > > > >> > > > >> -DskipTests
> > > > > >> > > > >> > >>>
> > > > > >> > > > >> > >>> You use an internal Maven repository to fetch
> > > > > dependencies
> > > > > >> > from
> > > > > >> > > > >> > internet:
> > > > > >> > > > >> > >>>
> > > > > >> > >
> > > http://nexus-private.hortonworks.com/nexus/content/groups/public/
> > > > > >> > > > >> > >>>
> > > > > >> > > > >> > >>> Does this repository have access to the remote
> > > > Snapshots
> > > > > >> > > Sonatype
> > > > > >> > > > >> repo?
> > > > > >> > > > >> > >>>
> > > > > >> > > > >> > >>>
> > > > > >> > > > >> > >>>
> > > > > >> > > > >> > >>> 2015-12-02 16:16 GMT+01:00 larry mccay <
> > > > > >> larry.mccay@gmail.com
> > > > > >> > >:
> > > > > >> > > > >> > >>>
> > > > > >> > > > >> > >>> > hmmm - I used:
> > > > > >> > > > >> > >>> >
> > > > > >> > > > >> > >>> > mvn clean install -DskipTests=true -Prelease
> > > > > >> > > > >> > >>> >
> > > > > >> > > > >> > >>> > The repository entry is in there already.
> > > > > >> > > > >> > >>> > No worky.
> > > > > >> > > > >> > >>> >
> > > > > >> > > > >> > >>> > On Wed, Dec 2, 2015 at 10:12 AM, Jérôme LELEU <
> > > > > >> > > leleuj@gmail.com
> > > > > >> > > > >
> > > > > >> > > > >> > >>> wrote:
> > > > > >> > > > >> > >>> >
> > > > > >> > > > >> > >>> > > Hi,
> > > > > >> > > > >> > >>> > >
> > > > > >> > > > >> > >>> > > You need the j2e-pac4j dependencies as well
> as
> > > the
> > > > > >> pac4j-*
> > > > > >> > > > >> > >>> dependencies,
> > > > > >> > > > >> > >>> > > but you don't need to build them locally
> > > > (hopefully).
> > > > > >> > > > >> > >>> > >
> > > > > >> > > > >> > >>> > > But you need a dependency on the Sonatype
> > > snapshots
> > > > > >> > > repository
> > > > > >> > > > >> > >>> (where the
> > > > > >> > > > >> > >>> > > snapshot versions are hosted), which is added
> > for
> > > > > >> Maven in
> > > > > >> > > the
> > > > > >> > > > >> root
> > > > > >> > > > >> > >>> > > pom.xml:
> > > > > >> > > > >> > >>> > >
> > > > > >> > > > >> > >>> > >
> > > > > >> > > > >> > >>> >
> > > > > >> > > > >> > >>>
> > > > > >> > > > >> >
> > > > > >> > > > >>
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> > > > > >> > > > >> > >>> > >
> > > > > >> > > > >> > >>> > > If you use Ant for the build, there is maybe
> a
> > > > glitch
> > > > > >> to
> > > > > >> > > find
> > > > > >> > > > >> the
> > > > > >> > > > >> > >>> > Sonatype
> > > > > >> > > > >> > >>> > > Maven repo.
> > > > > >> > > > >> > >>> > >
> > > > > >> > > > >> > >>> > > Thanks.
> > > > > >> > > > >> > >>> > > Best regards,
> > > > > >> > > > >> > >>> > > Jérôme
> > > > > >> > > > >> > >>> > >
> > > > > >> > > > >> > >>> > >
> > > > > >> > > > >> > >>> > > 2015-12-02 16:06 GMT+01:00 larry mccay <
> > > > > >> > > larry.mccay@gmail.com
> > > > > >> > > > >:
> > > > > >> > > > >> > >>> > >
> > > > > >> > > > >> > >>> > > > 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.mccay@gmail.com>
> > > > > >> > > > >> > >>> > > > wrote:
> > > > > >> > > > >> > >>> > > >
> > > > > >> > > > >> > >>> > > > > gateway-provider-security-pac4j doesn't
> > > build -
> > > > > do
> > > > > >> you
> > > > > >> > > > have
> > > > > >> > > > >> a
> > > > > >> > > > >> > >>> pending
> > > > > >> > > > >> > >>> > > > > change for your pom.xml or something?
> > > > > >> > > > >> > >>> > > > >
> > > > > >> > > > >> > >>> >
> > > > > >> > > > >> > >>>
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >
> > > > > >> > > > >> >
> > > > > >> > > > >>
> > > > > >> > > > >
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
Nevermind - I had to add ?client_name=SAML2Client to the end of the sso url
in okta and in the topology.
Now, I am running into a mismatch of audience expectations.
I set the audience in the okta application to be KnoxSSO.
I guess there is a parameter in the topology to sync up with that?
On Fri, Jan 15, 2016 at 10:38 AM, larry mccay <lm...@apache.org> wrote:
> Hi Jérôme -
>
> Thanks for the updated docs - I will take a look today.
>
> I am currently still trying to test okta and stuck in a redirect loop.
> Did you have to change anything in order to get the request.getParameter(Clients.DEFAULT_CLIENT_NAME_PARAMETER)
> set for the callbacks from okta? It is null in my environment and therefore
> it moves on to the following:
>
> // otherwise just apply security and requires authentication
>
> // apply RequiresAuthenticationFilter
>
> requiresAuthenticationFilter.doFilter(servletRequest,
> servletResponse, filterChain);
>
> which obviously results in the redirect loop.
>
> Curious whether you ran into that...
>
> thanks,
>
> --larry
>
> On Fri, Jan 15, 2016 at 4:00 AM, Jérôme LELEU <le...@gmail.com> wrote:
>
>> Hi,
>>
>> I just uploaded a new patch for the documentation with the links pointing
>> to the pac4j wiki. It should be clearer.
>>
>> Thanks.
>> Best regards,
>> Jérôme
>>
>>
>> 2016-01-14 13:20 GMT+01:00 larry mccay <lm...@apache.org>:
>>
>> > That sounds pretty reasonable.
>> > I will likely document a few of the integrations that are possible in
>> > blogs/tutorials anyway.
>> >
>> > I don't want testing of Knox at release time to have to jump around to
>> much
>> > in order to be able to test.
>> > I think we can make that all good though.
>> >
>> > I will see what I can do with okta today.
>> >
>> > On Thu, Jan 14, 2016 at 5:00 AM, Jérôme LELEU <le...@gmail.com> wrote:
>> >
>> > > Hi,
>> > >
>> > > Yes, the documentation is a bit too light. But you guessed it right:
>> we
>> > > need to have a keystore for encryption.
>> > >
>> > > The saml.identityProviderMetadataPath can point to a local resource or
>> > to a
>> > > remote one, using the right prefix: resource:, file: or an url (by
>> > default,
>> > > it is a file path). This must be documented though.
>> > >
>> > > With Okta, I used the defined url (Single Sign On URL = Recipient URL
>> =
>> > > Destination URL) for the serviceProviderEntityId, but I think it may
>> > > depends on IdP as well. Reading the spec, it must be an URI, but I'm
>> not
>> > > sure if the SP metadata should be really available on this url. For
>> Okta,
>> > > it doesn't matter.
>> > >
>> > > According to your SAML configuration, the SP metadata will be
>> generated
>> > > somewhere and this somewhere can be defined via the
>> > > serviceProviderMetadataPath parameter. You generally need to update
>> your
>> > > metadata to the IdP (not required for Okta though). Both the SP and
>> IdP
>> > > must know each other.
>> > >
>> > > When writing the documentation, I went fast on these parameters with
>> the
>> > > feeling they were regular ones, but indeed, the description in the
>> Knox
>> > > manual is not enough. This is somehow a bit normal as the real
>> > > documentation for SAML is on the SAML wiki:
>> > > https://github.com/pac4j/pac4j/wiki/Clients#details-for-saml-support
>> > >
>> > > So I propose to keep the Knox documentation mostly "as is", but add
>> links
>> > > to the pac4j wiki (where I could more easily made updates). All pac4j
>> > > integrations need this documentation so it's better to centralize it,
>> > from
>> > > my point of view. What do you think?
>> > >
>> > > Thanks.
>> > > Best regards,
>> > > Jérôme
>> > >
>> > >
>> > >
>> > > 2016-01-13 19:37 GMT+01:00 larry mccay <lm...@apache.org>:
>> > >
>> > > > Hi Jérôme -
>> > > >
>> > > > I'm trying to configure the pac4j provider for an okta "application"
>> > > that I
>> > > > created.
>> > > > The following (from KNOX-642 docs patch) isn't quite enough to make
>> it
>> > > > clear to me how to go about doing so:
>> > > >
>> > > > +saml.keystorePassword | Password of the keystore
>> (storepass)
>> > > > +saml.privateKeyPassword | Password for the private key
>> > > (keypass)
>> > > > +saml.keystorePath | Path of the keystore
>> > > > +saml.identityProviderMetadataPath | Path of the identity
>> > > > provider metadata
>> > > > +saml.maximumAuthenticationLifetime | Maximum lifetime for
>> > > > authentication
>> > > > +saml.serviceProviderEntityId | Identifier of the service
>> > > > provider
>> > > > +saml.serviceProviderMetadataPath | Path of the service
>> > > provider
>> > > > metadata
>> > > >
>> > > > I assume that I can use the gateway.jks keystore and the
>> > gateway-identity
>> > > > keypair to do the request signing and that that information is what
>> is
>> > > > needed for the first 3 params. Unfortunately, I don't see any use of
>> > > > gateway services to get the master secret therefore it needs to be
>> in
>> > > clear
>> > > > text here. This won't work - but may not be a show stopper for
>> > committing
>> > > > to master as long as we follow up with a fix.
>> > > >
>> > > > Can saml.identityProviderMetadataPath point to a remote location or
>> > does
>> > > it
>> > > > have to be local to the SP application. This would likely require
>> it to
>> > > be
>> > > > on the local filesystem, provisioned by the contributor into the
>> > > generated
>> > > > web app or in some central location via NFS or something like that.
>> > > >
>> > > > The okta application that I created is called KnoxSSO - is that the
>> > value
>> > > > for saml.serviceProviderEntityId?
>> > > >
>> > > > The saml.serviceProviderMetadataPath has the same questions as the
>> > > metadata
>> > > > for the IDP. In addition, is there a sample metadata file that we
>> can
>> > > > provide for the use of pac4j with KnoxSSO?
>> > > >
>> > > > I think that getting this working and clean (no clear text
>> passwords)
>> > > will
>> > > > make a great feature and blog for featuring pac4j provider and the
>> > 0.8.0
>> > > > release. So, let's try and iron this out clearly.
>> > > >
>> > > > I would really like to get this working and committed in the next
>> > couple
>> > > > days to free us up for follow up items. In particular we need time
>> to
>> > > > figure out whether the identity assertion providers that we
>> currently
>> > > have
>> > > > will suffice for an apache release that is featuring this new
>> > > > functionality.
>> > > >
>> > > > I will also add the above comments/questions to the JIRA for
>> > visibility.
>> > > >
>> > > > thanks,
>> > > >
>> > > > --larry
>> > > >
>> > > > On Fri, Jan 8, 2016 at 12:40 PM, larry mccay <lm...@apache.org>
>> > wrote:
>> > > >
>> > > > > Jérôme -
>> > > > >
>> > > > > My testing of OpenID Connect is blocked.
>> > > > > Can you see the comments in KNOX-641?
>> > > > >
>> > > > > thanks,
>> > > > >
>> > > > > --larry
>> > > > >
>> > > > > On Wed, Jan 6, 2016 at 2:30 PM, larry mccay <
>> larry.mccay@gmail.com>
>> > > > wrote:
>> > > > >
>> > > > >> Jérôme -
>> > > > >>
>> > > > >> Please see the comments on KNOX-641.
>> > > > >>
>> > > > >> thanks,
>> > > > >>
>> > > > >> --larry
>> > > > >>
>> > > > >> On Wed, Jan 6, 2016 at 11:24 AM, Kevin Minder <
>> > > > >> kevin.minder@hortonworks.com> wrote:
>> > > > >>
>> > > > >>> I can certainly appreciate the issue of including external
>> > resources
>> > > in
>> > > > >>> automated tests. Nothing has driven me more crazy over the
>> years.
>> > > The
>> > > > >>> flip side of this of course is not finding out about a breakage
>> > until
>> > > > >>> someone is willing to go through the manual testing which will
>> > > > typically
>> > > > >>> happen just before a release. Also the implication is that
>> these
>> > > > testing
>> > > > >>> procedures must be very will documented so that they can be
>> > continue
>> > > > to be
>> > > > >>> run once any of us are no longer active in the project.
>> > > > >>>
>> > > > >>>
>> > > > >>>
>> > > > >>> On 1/6/16, 2:12 AM, "Jérôme LELEU" <le...@gmail.com> wrote:
>> > > > >>>
>> > > > >>> >Hi,
>> > > > >>> >
>> > > > >>> >Yes, you can hit the CAS server at Heroku. Notice it's a Heroku
>> > free
>> > > > >>> server
>> > > > >>> >so it needs to be re-activated first (it takes a couple of
>> > seconds).
>> > > > So
>> > > > >>> for
>> > > > >>> >a UI test, you should first hit it, wait 30 seconds and then
>> > perform
>> > > > the
>> > > > >>> >test.
>> > > > >>> >
>> > > > >>> >Just my 2 cents:
>> > > > >>> >Using automated UI tests was my first strategy for pac4j but I
>> > > > finally
>> > > > >>> >gave up because public providers change very often, at least
>> > enough
>> > > to
>> > > > >>> make
>> > > > >>> >the maintenance tests a nightmare. Currently, I'm using manual
>> > tests
>> > > > >>> (the
>> > > > >>> >same for all demos), it takes me around 5 minutes to play them
>> all
>> > > by
>> > > > >>> hand
>> > > > >>> >(for a demo) and I launched manually the UI tests I have for
>> every
>> > > > major
>> > > > >>> >pac4j release. Just to say UI tests are not that easy. For a
>> CAS
>> > > > server,
>> > > > >>> >it's fairly feasible as the CAS server and protocol change
>> rarely.
>> > > > >>> >That's why for Knox, I did some compromise with a simulated web
>> > test
>> > > > >>> (based
>> > > > >>> >on the basic auth). See:
>> > > > >>> >
>> > > > >>>
>> > > >
>> > >
>> >
>> https://github.com/apache/knox/pull/2/files#diff-d0c880ca71b310dbe57975c577535e97R47
>> > > > >>> >
>> > > > >>> >Thanks.
>> > > > >>> >Best regards,
>> > > > >>> >Jérôme
>> > > > >>> >
>> > > > >>> >
>> > > > >>> >
>> > > > >>> >2016-01-05 21:20 GMT+01:00 Kevin Minder <
>> > > kevin.minder@hortonworks.com
>> > > > >:
>> > > > >>> >
>> > > > >>> >> From my perspective it would be ideal if there were some
>> > > automatable
>> > > > >>> >> functional tests for this. I’m not advocating that these be
>> > > > something
>> > > > >>> >> included in “mvn clean install” as that is running too long
>> as
>> > it
>> > > > is.
>> > > > >>> >> Given that I don’t have as much context as Larry, I have some
>> > > > >>> questions
>> > > > >>> >> about what this would take. Lets say we had permission to
>> hit
>> > > > >>> >> https://casserverpac4j.herokuapp.com/login as part of some
>> low
>> > > > >>> frequency
>> > > > >>> >> automated tests (e.g. Once nighty). What static credentials
>> and
>> > > > >>> other test
>> > > > >>> >> automation infrastructure would need to be implemented in
>> > support
>> > > of
>> > > > >>> this?
>> > > > >>> >> I understand that the test suite would require at a minimum
>> > > > >>> >> 1) a test driver
>> > > > >>> >> 2) a protected mock UI and
>> > > > >>> >> 3) an appropriately configured Knox
>> > > > >>> >> 4) a profile enabled maven module
>> > > > >>> >> 5) an Apache jenkins job
>> > > > >>> >> but I’m sure I’m missing other things. I’m certainly
>> willing to
>> > > > help
>> > > > >>> >> setup the skeleton infrastructure (e.g. test driver, mock UI,
>> > > maven
>> > > > >>> module,
>> > > > >>> >> jenkins job)
>> > > > >>> >>
>> > > > >>> >>
>> > > > >>> >>
>> > > > >>> >> On 1/5/16, 2:54 PM, "larry mccay" <la...@gmail.com>
>> > wrote:
>> > > > >>> >>
>> > > > >>> >> >Okay, very good.
>> > > > >>> >> >I've used TestShib for the picketlink provider - thanks for
>> the
>> > > > >>> pointers!
>> > > > >>> >> >
>> > > > >>> >> >On Tue, Jan 5, 2016 at 1:38 PM, Jérôme LELEU <
>> leleuj@gmail.com
>> > >
>> > > > >>> wrote:
>> > > > >>> >> >
>> > > > >>> >> >> The online CAS server (
>> > > > https://casserverpac4j.herokuapp.com/login)
>> > > > >>> uses
>> > > > >>> >> >> the
>> > > > >>> >> >> CAS protocol. SAML support can be tested using some online
>> > IdP
>> > > > like
>> > > > >>> >> Okta,
>> > > > >>> >> >> TestShib, OpenFeide, Ssocircle...
>> > > > >>> >> >>
>> > > > >>> >> >>
>> > > > >>> >> >> 2016-01-05 17:32 GMT+01:00 larry mccay <
>> > larry.mccay@gmail.com
>> > > >:
>> > > > >>> >> >>
>> > > > >>> >> >> > Great - thanks for that pointer!
>> > > > >>> >> >> >
>> > > > >>> >> >> > I will take a look at that and help drive the release
>> > related
>> > > > >>> testing.
>> > > > >>> >> >> > Merge testing will be gated on CAS server (is this SAML
>> or
>> > > CAS
>> > > > >>> >> protocol?)
>> > > > >>> >> >> > and testBasicAuth.
>> > > > >>> >> >> >
>> > > > >>> >> >> > On Tue, Jan 5, 2016 at 10:52 AM, Jérôme LELEU <
>> > > > leleuj@gmail.com>
>> > > > >>> >> wrote:
>> > > > >>> >> >> >
>> > > > >>> >> >> > > Hi,
>> > > > >>> >> >> > >
>> > > > >>> >> >> > > Glad to hear back from you!
>> > > > >>> >> >> > >
>> > > > >>> >> >> > > The core pac4j project is fully tested by unit tests
>> (and
>> > > > some
>> > > > >>> >> >> > integration
>> > > > >>> >> >> > > tests I run for major version), then all pac4j
>> > > > implementations
>> > > > >>> are
>> > > > >>> >> each
>> > > > >>> >> >> > > tested by the appropriate demo: j2e-pac4j-demo tests
>> > > > j2e-pac4j,
>> > > > >>> >> >> > > spring-webmvc-pac4j-demo tests spring-webmvc-pac4j,
>> etc.
>> > > > >>> >> >> > >
>> > > > >>> >> >> > > So if you take a look at:
>> > > > >>> >> >> > >
>> > > > >>> >> >> > >
>> > > > >>> >> >> >
>> > > > >>> >> >>
>> > > > >>> >>
>> > > > >>>
>> > > >
>> > >
>> >
>> https://github.com/pac4j/j2e-pac4j-demo/blob/master/src/main/java/org/pac4j/demo/j2e/config/DemoConfigFactory.java#L27
>> > > > >>> >> >> > > (for example), you have all the required information
>> to
>> > > test.
>> > > > >>> >> >> > >
>> > > > >>> >> >> > > I can do that on my own, but it can be good for the
>> Knox
>> > > > >>> community
>> > > > >>> >> to
>> > > > >>> >> >> > start
>> > > > >>> >> >> > > working / testing the pac4j support. It's up to yoy.
>> > > > >>> >> >> > >
>> > > > >>> >> >> > > Thanks.
>> > > > >>> >> >> > > Best regards,
>> > > > >>> >> >> > > Jérôme
>> > > > >>> >> >> > >
>> > > > >>> >> >> > >
>> > > > >>> >> >> > > 2016-01-05 16:11 GMT+01:00 larry mccay <
>> > > > larry.mccay@gmail.com
>> > > > >>> >:
>> > > > >>> >> >> > >
>> > > > >>> >> >> > > > Hello Jérôme -
>> > > > >>> >> >> > > >
>> > > > >>> >> >> > > > Happy New Year!
>> > > > >>> >> >> > > >
>> > > > >>> >> >> > > > I am going to start reviewing your updates today,
>> > > > hopefully.
>> > > > >>> >> >> > > > I was thinking that we need to start discussions on
>> > what
>> > > > the
>> > > > >>> key
>> > > > >>> >> >> > usecases
>> > > > >>> >> >> > > > are and how to go about testing them.
>> > > > >>> >> >> > > > We can certainly test the testBasicAuth and against
>> the
>> > > > >>> hosted CAS
>> > > > >>> >> >> > server
>> > > > >>> >> >> > > > but what about FB, openid, OAuth, etc?
>> > > > >>> >> >> > > >
>> > > > >>> >> >> > > > I'm not sure that FB would be a key feature but
>> OpenID
>> > > > >>> Connect and
>> > > > >>> >> >> > OAuth
>> > > > >>> >> >> > > > would be - as is SAML.
>> > > > >>> >> >> > > > I think CAS buys us SAML testing - assuming that the
>> > > > >>> >> configuration of
>> > > > >>> >> >> > the
>> > > > >>> >> >> > > > hosted server is actually a SAML 2 instance.
>> > > > >>> >> >> > > >
>> > > > >>> >> >> > > > What about the others?
>> > > > >>> >> >> > > >
>> > > > >>> >> >> > > > I don't know that we need to be able to test them
>> all
>> > > > before
>> > > > >>> merge
>> > > > >>> >> >> but
>> > > > >>> >> >> > > some
>> > > > >>> >> >> > > > sort of manual verification would be great.
>> > > > >>> >> >> > > > We would need to be able to test them before the
>> next
>> > > > release
>> > > > >>> >> which
>> > > > >>> >> >> > would
>> > > > >>> >> >> > > > be featuring the pac4j functionality.
>> > > > >>> >> >> > > >
>> > > > >>> >> >> > > > Maybe you can describe how you go about testing such
>> > > things
>> > > > >>> for
>> > > > >>> >> the
>> > > > >>> >> >> > pac4j
>> > > > >>> >> >> > > > project itself?
>> > > > >>> >> >> > > >
>> > > > >>> >> >> > > > thanks,
>> > > > >>> >> >> > > >
>> > > > >>> >> >> > > > --larry
>> > > > >>> >> >> > > >
>> > > > >>> >> >> > > >
>> > > > >>> >> >> > > > On Tue, Jan 5, 2016 at 9:55 AM, Jérôme LELEU <
>> > > > >>> leleuj@gmail.com>
>> > > > >>> >> >> wrote:
>> > > > >>> >> >> > > >
>> > > > >>> >> >> > > > > Hi,
>> > > > >>> >> >> > > > >
>> > > > >>> >> >> > > > > Happy new year!
>> > > > >>> >> >> > > > >
>> > > > >>> >> >> > > > > A few days ago, I updated my patch of the pac4j
>> > gateway
>> > > > >>> provider
>> > > > >>> >> >> > > > according
>> > > > >>> >> >> > > > > to all comments on
>> > > > >>> >> https://issues.apache.org/jira/browse/KNOX-641
>> > > > >>> >> >> as
>> > > > >>> >> >> > > > well
>> > > > >>> >> >> > > > > as the documentation on KNOX-642.
>> > > > >>> >> >> > > > >
>> > > > >>> >> >> > > > > Is everything ok for the merge?
>> > > > >>> >> >> > > > >
>> > > > >>> >> >> > > > > Thanks.
>> > > > >>> >> >> > > > > Best regards,
>> > > > >>> >> >> > > > > Jérôme
>> > > > >>> >> >> > > > >
>> > > > >>> >> >> > > > >
>> > > > >>> >> >> > > > > 2015-12-14 15:28 GMT+01:00 larry mccay <
>> > > > >>> larry.mccay@gmail.com>:
>> > > > >>> >> >> > > > >
>> > > > >>> >> >> > > > > > Hi Jérôme -
>> > > > >>> >> >> > > > > >
>> > > > >>> >> >> > > > > > Not sure if you saw but I added review comments
>> to
>> > > > >>> KNOX-641.
>> > > > >>> >> >> > > > > >
>> > > > >>> >> >> > > > > > I think that we need to determine whether we
>> want
>> > the
>> > > > >>> >> >> testBasicAuth
>> > > > >>> >> >> > > in
>> > > > >>> >> >> > > > > the
>> > > > >>> >> >> > > > > > provider itself.
>> > > > >>> >> >> > > > > >
>> > > > >>> >> >> > > > > > Let's follow up on the JIRA.
>> > > > >>> >> >> > > > > >
>> > > > >>> >> >> > > > > > thanks,
>> > > > >>> >> >> > > > > >
>> > > > >>> >> >> > > > > > --larry
>> > > > >>> >> >> > > > > >
>> > > > >>> >> >> > > > > > On Fri, Dec 11, 2015 at 8:44 AM, Jérôme LELEU <
>> > > > >>> >> leleuj@gmail.com>
>> > > > >>> >> >> > > > wrote:
>> > > > >>> >> >> > > > > >
>> > > > >>> >> >> > > > > > > Hi,
>> > > > >>> >> >> > > > > > >
>> > > > >>> >> >> > > > > > > No problem. It can go into a version 0.8.0 if
>> > > needed.
>> > > > >>> The
>> > > > >>> >> truth
>> > > > >>> >> >> > is
>> > > > >>> >> >> > > > that
>> > > > >>> >> >> > > > > > > there is only one change outside the new pac4j
>> > > > module,
>> > > > >>> so I
>> > > > >>> >> >> think
>> > > > >>> >> >> > > > risks
>> > > > >>> >> >> > > > > > are
>> > > > >>> >> >> > > > > > > extremly limited.
>> > > > >>> >> >> > > > > > >
>> > > > >>> >> >> > > > > > > Just let met know.
>> > > > >>> >> >> > > > > > >
>> > > > >>> >> >> > > > > > > Thanks.
>> > > > >>> >> >> > > > > > > Best regards,
>> > > > >>> >> >> > > > > > > Jérôme
>> > > > >>> >> >> > > > > > >
>> > > > >>> >> >> > > > > > >
>> > > > >>> >> >> > > > > > > 2015-12-11 14:23 GMT+01:00 larry mccay <
>> > > > >>> >> larry.mccay@gmail.com
>> > > > >>> >> >> >:
>> > > > >>> >> >> > > > > > >
>> > > > >>> >> >> > > > > > > > Hi Jérôme -
>> > > > >>> >> >> > > > > > > >
>> > > > >>> >> >> > > > > > > > I have unfortunately not had a chance to
>> pull,
>> > > > >>> review and
>> > > > >>> >> >> test
>> > > > >>> >> >> > it
>> > > > >>> >> >> > > > yet
>> > > > >>> >> >> > > > > > and
>> > > > >>> >> >> > > > > > > > have intended to do that today.
>> > > > >>> >> >> > > > > > > > I apologize for the delay.
>> > > > >>> >> >> > > > > > > >
>> > > > >>> >> >> > > > > > > > I was actually thinking that this would go
>> > into a
>> > > > >>> follow
>> > > > >>> >> up
>> > > > >>> >> >> > > release
>> > > > >>> >> >> > > > > > that
>> > > > >>> >> >> > > > > > > we
>> > > > >>> >> >> > > > > > > > would try and get done rapidly after the
>> 0.7.0
>> > > > >>> release
>> > > > >>> >> but we
>> > > > >>> >> >> > can
>> > > > >>> >> >> > > > > > discuss
>> > > > >>> >> >> > > > > > > > the target and its chances of destabilizing
>> > > 0.7.0.
>> > > > >>> >> >> > > > > > > >
>> > > > >>> >> >> > > > > > > > I believe that it is rather self-contained
>> with
>> > > > only
>> > > > >>> a few
>> > > > >>> >> >> > > changes
>> > > > >>> >> >> > > > to
>> > > > >>> >> >> > > > > > > > external modules.
>> > > > >>> >> >> > > > > > > >
>> > > > >>> >> >> > > > > > > > Opening the JIRAs is perfect and I was
>> going to
>> > > do
>> > > > >>> that
>> > > > >>> >> once
>> > > > >>> >> >> I
>> > > > >>> >> >> > > > > started
>> > > > >>> >> >> > > > > > > the
>> > > > >>> >> >> > > > > > > > review.
>> > > > >>> >> >> > > > > > > >
>> > > > >>> >> >> > > > > > > > Let's continue review comments and
>> > collaboration
>> > > on
>> > > > >>> those
>> > > > >>> >> >> > JIRAs.
>> > > > >>> >> >> > > > > > > > I will add you to the contributors list so
>> that
>> > > we
>> > > > >>> can
>> > > > >>> >> assign
>> > > > >>> >> >> > > them
>> > > > >>> >> >> > > > to
>> > > > >>> >> >> > > > > > > you.
>> > > > >>> >> >> > > > > > > >
>> > > > >>> >> >> > > > > > > > Thank you for your contributions and your
>> > > patience,
>> > > > >>> >> Jérôme!
>> > > > >>> >> >> > > > > > > >
>> > > > >>> >> >> > > > > > > > --larry
>> > > > >>> >> >> > > > > > > >
>> > > > >>> >> >> > > > > > > > On Fri, Dec 11, 2015 at 3:00 AM, Jérôme
>> LELEU <
>> > > > >>> >> >> > leleuj@gmail.com>
>> > > > >>> >> >> > > > > > wrote:
>> > > > >>> >> >> > > > > > > >
>> > > > >>> >> >> > > > > > > > > Hi,
>> > > > >>> >> >> > > > > > > > >
>> > > > >>> >> >> > > > > > > > > I didn't get any new feedback on the pull
>> > > request
>> > > > >>> so I
>> > > > >>> >> >> assume
>> > > > >>> >> >> > > > > > > everything
>> > > > >>> >> >> > > > > > > > is
>> > > > >>> >> >> > > > > > > > > ok from your point of view.
>> > > > >>> >> >> > > > > > > > >
>> > > > >>> >> >> > > > > > > > > I released pac4j v1.8.1 and j2e-pac4j
>> v1.2.1
>> > > so I
>> > > > >>> >> updated
>> > > > >>> >> >> the
>> > > > >>> >> >> > > > pull
>> > > > >>> >> >> > > > > > > > request
>> > > > >>> >> >> > > > > > > > > to use them and successfully re-tested
>> > > > everything.
>> > > > >>> >> >> > > > > > > > >
>> > > > >>> >> >> > > > > > > > > I opened KNOX-641 and submitted the
>> > > corresponding
>> > > > >>> patch.
>> > > > >>> >> >> > > > > > > > >
>> > > > >>> >> >> > > > > > > > > I also wrote the documentation, opened
>> > KNOX-642
>> > > > and
>> > > > >>> >> >> submitted
>> > > > >>> >> >> > > the
>> > > > >>> >> >> > > > > > > > > corresponding patch (just to let you know
>> > that
>> > > it
>> > > > >>> >> doesn't
>> > > > >>> >> >> > work
>> > > > >>> >> >> > > > out
>> > > > >>> >> >> > > > > of
>> > > > >>> >> >> > > > > > > the
>> > > > >>> >> >> > > > > > > > > box in Windows, I had to replace mvn.bat
>> by
>> > > > >>> mvn.cmd to
>> > > > >>> >> make
>> > > > >>> >> >> > ant
>> > > > >>> >> >> > > > > > work).
>> > > > >>> >> >> > > > > > > > >
>> > > > >>> >> >> > > > > > > > > Even if the branch 0.7.0 has already been
>> > > > created,
>> > > > >>> I
>> > > > >>> >> >> assumed
>> > > > >>> >> >> > > this
>> > > > >>> >> >> > > > > new
>> > > > >>> >> >> > > > > > > > pac4j
>> > > > >>> >> >> > > > > > > > > provider will go into this version 0.7.0
>> > > > >>> (dependency on
>> > > > >>> >> the
>> > > > >>> >> >> > > > > > > > 0.7.0-SNAPSHOT
>> > > > >>> >> >> > > > > > > > > parent version).
>> > > > >>> >> >> > > > > > > > >
>> > > > >>> >> >> > > > > > > > > Just let me know if everything is ok and
>> when
>> > > > it's
>> > > > >>> >> goind to
>> > > > >>> >> >> > be
>> > > > >>> >> >> > > > > > merged.
>> > > > >>> >> >> > > > > > > > >
>> > > > >>> >> >> > > > > > > > > Thanks.
>> > > > >>> >> >> > > > > > > > > Best regards,
>> > > > >>> >> >> > > > > > > > > Jérôme
>> > > > >>> >> >> > > > > > > > >
>> > > > >>> >> >> > > > > > > > >
>> > > > >>> >> >> > > > > > > > >
>> > > > >>> >> >> > > > > > > > >
>> > > > >>> >> >> > > > > > > > > 2015-12-04 14:20 GMT+01:00 larry mccay <
>> > > > >>> >> >> > larry.mccay@gmail.com
>> > > > >>> >> >> > > >:
>> > > > >>> >> >> > > > > > > > >
>> > > > >>> >> >> > > > > > > > > > That ability to configure multiple
>> > mechanisms
>> > > > >>> based on
>> > > > >>> >> >> > > > clientName
>> > > > >>> >> >> > > > > > is
>> > > > >>> >> >> > > > > > > > > really
>> > > > >>> >> >> > > > > > > > > > interesting for Knox.
>> > > > >>> >> >> > > > > > > > > > Currently, we require separate
>> topologies
>> > per
>> > > > >>> >> >> > authentication
>> > > > >>> >> >> > > > > > > mechanism.
>> > > > >>> >> >> > > > > > > > > > The ability to configure them all in
>> one is
>> > > > >>> really
>> > > > >>> >> great.
>> > > > >>> >> >> > > > > > > > > >
>> > > > >>> >> >> > > > > > > > > > We would need to think through the best
>> way
>> > > to
>> > > > >>> provide
>> > > > >>> >> >> the
>> > > > >>> >> >> > > > > > clientName
>> > > > >>> >> >> > > > > > > > > > parameter.
>> > > > >>> >> >> > > > > > > > > > Since this is targeting KnoxSSO it can
>> > > actually
>> > > > >>> be
>> > > > >>> >> added
>> > > > >>> >> >> to
>> > > > >>> >> >> > > the
>> > > > >>> >> >> > > > > > > > > providerURL
>> > > > >>> >> >> > > > > > > > > > used to redirect from the participating
>> > > > >>> application.
>> > > > >>> >> >> > > > > > > > > > Regardless of the authentication
>> mechanism
>> > > used
>> > > > >>> each
>> > > > >>> >> >> > > > application
>> > > > >>> >> >> > > > > > will
>> > > > >>> >> >> > > > > > > > > still
>> > > > >>> >> >> > > > > > > > > > get the same JWT based cookie.
>> > > > >>> >> >> > > > > > > > > >
>> > > > >>> >> >> > > > > > > > > > I think that should work really nicely.
>> > > > >>> >> >> > > > > > > > > >
>> > > > >>> >> >> > > > > > > > > >
>> > > > >>> >> >> > > > > > > > > > On Fri, Dec 4, 2015 at 7:17 AM, larry
>> > mccay <
>> > > > >>> >> >> > > > > larry.mccay@gmail.com
>> > > > >>> >> >> > > > > > >
>> > > > >>> >> >> > > > > > > > > wrote:
>> > > > >>> >> >> > > > > > > > > >
>> > > > >>> >> >> > > > > > > > > > > Excellent, Jérôme.
>> > > > >>> >> >> > > > > > > > > > > Thanks!
>> > > > >>> >> >> > > > > > > > > > >
>> > > > >>> >> >> > > > > > > > > > > On Fri, Dec 4, 2015 at 2:40 AM, Jérôme
>> > > LELEU
>> > > > <
>> > > > >>> >> >> > > > leleuj@gmail.com
>> > > > >>> >> >> > > > > >
>> > > > >>> >> >> > > > > > > > wrote:
>> > > > >>> >> >> > > > > > > > > > >
>> > > > >>> >> >> > > > > > > > > > >> Hi,
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > > >> I will write how to configure the
>> pac4j
>> > > > >>> provider in
>> > > > >>> >> >> the
>> > > > >>> >> >> > > > > > > > documentation,
>> > > > >>> >> >> > > > > > > > > > but
>> > > > >>> >> >> > > > > > > > > > >> I can already give you some insights.
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > > >> My main goal is always to respect the
>> > key
>> > > > >>> design
>> > > > >>> >> >> > > principles
>> > > > >>> >> >> > > > of
>> > > > >>> >> >> > > > > > > pac4j
>> > > > >>> >> >> > > > > > > > > > >> whatever the environment / framework
>> in
>> > > > which
>> > > > >>> it is
>> > > > >>> >> >> > > > > implemented.
>> > > > >>> >> >> > > > > > > For
>> > > > >>> >> >> > > > > > > > > > Knox,
>> > > > >>> >> >> > > > > > > > > > >> I'm pretty happy with the use of the
>> > > > j2e-pac4j
>> > > > >>> >> >> library,
>> > > > >>> >> >> > > > which
>> > > > >>> >> >> > > > > > > means
>> > > > >>> >> >> > > > > > > > > that
>> > > > >>> >> >> > > > > > > > > > >> almost all the pac4j features are
>> > > available,
>> > > > >>> >> >> especially
>> > > > >>> >> >> > > both
>> > > > >>> >> >> > > > > > > direct
>> > > > >>> >> >> > > > > > > > > and
>> > > > >>> >> >> > > > > > > > > > >> indirect clients. So it can do what
>> > Shiro
>> > > > >>> already
>> > > > >>> >> does
>> > > > >>> >> >> > but
>> > > > >>> >> >> > > > > also,
>> > > > >>> >> >> > > > > > > as
>> > > > >>> >> >> > > > > > > > we
>> > > > >>> >> >> > > > > > > > > > >> agreed together, supports remote
>> > > > >>> authentications.
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > > >> It is only limited by what you can
>> > > currently
>> > > > >>> >> >> configure.
>> > > > >>> >> >> > > And
>> > > > >>> >> >> > > > > even
>> > > > >>> >> >> > > > > > > > > > >> configuration is a pac4j feature as
>> the
>> > > CAS
>> > > > >>> server
>> > > > >>> >> has
>> > > > >>> >> >> > the
>> > > > >>> >> >> > > > > same
>> > > > >>> >> >> > > > > > > > need.
>> > > > >>> >> >> > > > > > > > > > >> Everything happens in this class:
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > >
>> > > > >>> >> >> > > > > > > > >
>> > > > >>> >> >> > > > > > > >
>> > > > >>> >> >> > > > > > >
>> > > > >>> >> >> > > > > >
>> > > > >>> >> >> > > > >
>> > > > >>> >> >> > > >
>> > > > >>> >> >> > >
>> > > > >>> >> >> >
>> > > > >>> >> >>
>> > > > >>> >>
>> > > > >>>
>> > > >
>> > >
>> >
>> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java
>> > > > >>> >> >> > > > > > > > > > >> ,
>> > > > >>> >> >> > > > > > > > > > >> which allows you to configure
>> Facebook,
>> > > > >>> Twitter, a
>> > > > >>> >> CAS
>> > > > >>> >> >> > > > > server, a
>> > > > >>> >> >> > > > > > > > SAML
>> > > > >>> >> >> > > > > > > > > > IdP
>> > > > >>> >> >> > > > > > > > > > >> or an OpenID Connect provider. All
>> the
>> > > > >>> provided
>> > > > >>> >> >> > parameters
>> > > > >>> >> >> > > > to
>> > > > >>> >> >> > > > > > the
>> > > > >>> >> >> > > > > > > > > pac4j
>> > > > >>> >> >> > > > > > > > > > >> provider are put into a Map and the
>> > > > >>> >> >> > > ConfigPropertiesFactory
>> > > > >>> >> >> > > > is
>> > > > >>> >> >> > > > > > > built
>> > > > >>> >> >> > > > > > > > > > with
>> > > > >>> >> >> > > > > > > > > > >> this Map to return the built client
>> (=
>> > > > >>> >> authentication
>> > > > >>> >> >> > > > > > mechanism).
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > > >> You have one more specific option for
>> > Knox
>> > > > as
>> > > > >>> a
>> > > > >>> >> basic
>> > > > >>> >> >> > > > > > > authentication
>> > > > >>> >> >> > > > > > > > > > popup
>> > > > >>> >> >> > > > > > > > > > >> where the username must match the
>> > > password,
>> > > > >>> you can
>> > > > >>> >> >> > define
>> > > > >>> >> >> > > > > that
>> > > > >>> >> >> > > > > > > by:
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > > >> <param>
>> > > > >>> >> >> > > > > > > > > > >> <name>clientName</name>
>> > > > >>> >> >> > > > > > > > > > >> <value>testBasicAuth</value>
>> > > > >>> >> >> > > > > > > > > > >> </param>
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > > >> It's for testing only.
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > > >> For a CAS server:
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > > >> <param>
>> > > > >>> >> >> > > > > > > > > > >> <name>cas.loginUrl</name>
>> > > > >>> >> >> > > > > > > > > > >> <value>
>> > > > >>> >> https://casserverpac4j.herokuapp.com/login
>> > > > >>> >> >> > > </value>
>> > > > >>> >> >> > > > > > > > > > >> </param>
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > > >> Here are all the properties available
>> > for
>> > > > >>> building
>> > > > >>> >> >> > clients
>> > > > >>> >> >> > > > > > (their
>> > > > >>> >> >> > > > > > > > > > meaning
>> > > > >>> >> >> > > > > > > > > > >> is obvious):
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > > >> facebook.id
>> > > > >>> >> >> > > > > > > > > > >> facebook.secret
>> > > > >>> >> >> > > > > > > > > > >> facebook.scope
>> > > > >>> >> >> > > > > > > > > > >> facebook.fields
>> > > > >>> >> >> > > > > > > > > > >> twitter.id
>> > > > >>> >> >> > > > > > > > > > >> twitter.secret
>> > > > >>> >> >> > > > > > > > > > >> saml.keystorePassword
>> > > > >>> >> >> > > > > > > > > > >> saml.privateKeyPassword
>> > > > >>> >> >> > > > > > > > > > >> saml.keystorePath
>> > > > >>> >> >> > > > > > > > > > >> saml.identityProviderMetadataPath
>> > > > >>> >> >> > > > > > > > > > >> saml.maximumAuthenticationLifetime
>> > > > >>> >> >> > > > > > > > > > >> saml.serviceProviderEntityId
>> > > > >>> >> >> > > > > > > > > > >> saml.serviceProviderMetadataPath
>> > > > >>> >> >> > > > > > > > > > >> cas.loginUrl
>> > > > >>> >> >> > > > > > > > > > >> cas.protocol
>> > > > >>> >> >> > > > > > > > > > >> oidc.id
>> > > > >>> >> >> > > > > > > > > > >> oidc.secret
>> > > > >>> >> >> > > > > > > > > > >> oidc.discoveryUri
>> > > > >>> >> >> > > > > > > > > > >> oidc.customParamKey1
>> > > > >>> >> >> > > > > > > > > > >> oidc.customParamValue1
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > > >> If you define multiple clients, the
>> > first
>> > > > one
>> > > > >>> will
>> > > > >>> >> be
>> > > > >>> >> >> > used
>> > > > >>> >> >> > > > for
>> > > > >>> >> >> > > > > > > > > > >> authentication, but you can
>> explicitly
>> > > > choose
>> > > > >>> the
>> > > > >>> >> >> client
>> > > > >>> >> >> > > you
>> > > > >>> >> >> > > > > > want
>> > > > >>> >> >> > > > > > > to
>> > > > >>> >> >> > > > > > > > > use
>> > > > >>> >> >> > > > > > > > > > >> via the clientName parameter,
>> assuming
>> > you
>> > > > >>> want to
>> > > > >>> >> >> > switch
>> > > > >>> >> >> > > > from
>> > > > >>> >> >> > > > > > > > client
>> > > > >>> >> >> > > > > > > > > > >> depending on environment for example.
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > > >> So if you want to add some new
>> > > > authentication
>> > > > >>> >> >> mechanism,
>> > > > >>> >> >> > > you
>> > > > >>> >> >> > > > > > must
>> > > > >>> >> >> > > > > > > > > first
>> > > > >>> >> >> > > > > > > > > > >> check that it is available in pac4j
>> (if
>> > > it's
>> > > > >>> not,
>> > > > >>> >> it's
>> > > > >>> >> >> > > > another
>> > > > >>> >> >> > > > > > > > > > discussion,
>> > > > >>> >> >> > > > > > > > > > >> but generally, it is). Then, you'll
>> need
>> > > to
>> > > > >>> upgrade
>> > > > >>> >> >> the
>> > > > >>> >> >> > > > > > > > > > >> ConfigPropertiesFactory by
>> submitting a
>> > > new
>> > > > >>> pull
>> > > > >>> >> >> request
>> > > > >>> >> >> > > to
>> > > > >>> >> >> > > > > the
>> > > > >>> >> >> > > > > > > > pac4j
>> > > > >>> >> >> > > > > > > > > > >> project (I can do it myself, but I'm
>> > sure
>> > > > you
>> > > > >>> >> could do
>> > > > >>> >> >> > > that
>> > > > >>> >> >> > > > > > > easily),
>> > > > >>> >> >> > > > > > > > > > >> finally wait for the new pac4j
>> release
>> > and
>> > > > >>> switch
>> > > > >>> >> >> pac4j
>> > > > >>> >> >> > > > > versions
>> > > > >>> >> >> > > > > > > in
>> > > > >>> >> >> > > > > > > > > Knox
>> > > > >>> >> >> > > > > > > > > > >> to
>> > > > >>> >> >> > > > > > > > > > >> benefit from the new feature.
>> > > > >>> >> >> > > > > > > > > > >> The good thing is that if someone
>> > related
>> > > to
>> > > > >>> the
>> > > > >>> >> CAS
>> > > > >>> >> >> > > server
>> > > > >>> >> >> > > > > does
>> > > > >>> >> >> > > > > > > the
>> > > > >>> >> >> > > > > > > > > > same
>> > > > >>> >> >> > > > > > > > > > >> thing for CAS (in pac4j), you will
>> > > > >>> automatically
>> > > > >>> >> get
>> > > > >>> >> >> it
>> > > > >>> >> >> > > when
>> > > > >>> >> >> > > > > > > you'll
>> > > > >>> >> >> > > > > > > > > > >> upgrade
>> > > > >>> >> >> > > > > > > > > > >> pac4j.
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > > >> To go even further, replacing LDAP
>> Shiro
>> > > > >>> >> >> authentication
>> > > > >>> >> >> > is
>> > > > >>> >> >> > > > > just
>> > > > >>> >> >> > > > > > a
>> > > > >>> >> >> > > > > > > > > matter
>> > > > >>> >> >> > > > > > > > > > >> of
>> > > > >>> >> >> > > > > > > > > > >> making pac4j LDAP authentication
>> > available
>> > > > via
>> > > > >>> >> >> > > configuration
>> > > > >>> >> >> > > > > > > > > parameters.
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > > >> I hope it was clear enough.
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > > >> Thanks.
>> > > > >>> >> >> > > > > > > > > > >> Best regards,
>> > > > >>> >> >> > > > > > > > > > >> Jérôme
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > > >> 2015-12-03 20:45 GMT+01:00 larry
>> mccay <
>> > > > >>> >> >> > > > larry.mccay@gmail.com
>> > > > >>> >> >> > > > > >:
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > > >> > Excellent!
>> > > > >>> >> >> > > > > > > > > > >> >
>> > > > >>> >> >> > > > > > > > > > >> > I will carve out some time to do
>> code
>> > > > >>> review.
>> > > > >>> >> >> > > > > > > > > > >> > We will need to get some insights
>> into
>> > > how
>> > > > >>> to go
>> > > > >>> >> >> about
>> > > > >>> >> >> > > > > > testing:
>> > > > >>> >> >> > > > > > > > > > >> >
>> > > > >>> >> >> > > > > > > > > > >> > * is the CAS server going to be
>> > > available
>> > > > >>> for
>> > > > >>> >> >> testing?
>> > > > >>> >> >> > > > > > > > > > >> > * what are the specific and
>> > > > >>> generic/standard (if
>> > > > >>> >> >> any)
>> > > > >>> >> >> > > > > > > > authentication
>> > > > >>> >> >> > > > > > > > > > >> > mechanisms available - for
>> instance:
>> > > > >>> >> >> > > > > > > > > > >> > - Facebook, Google, LinkedIn
>> and
>> > CAS
>> > > > are
>> > > > >>> >> >> specifics
>> > > > >>> >> >> > > > > > > > > > >> > - OAuth 2, OpenID Connect, SAML
>> > are
>> > > > >>> >> >> > > generic/standards
>> > > > >>> >> >> > > > -
>> > > > >>> >> >> > > > > > that
>> > > > >>> >> >> > > > > > > > may
>> > > > >>> >> >> > > > > > > > > > be
>> > > > >>> >> >> > > > > > > > > > >> > used for the above specifics...
>> > > > >>> >> >> > > > > > > > > > >> > * how do we test things other than
>> > CAS -
>> > > > in
>> > > > >>> >> terms of
>> > > > >>> >> >> > > > getting
>> > > > >>> >> >> > > > > > > > > > >> credentials,
>> > > > >>> >> >> > > > > > > > > > >> > configuration, etc
>> > > > >>> >> >> > > > > > > > > > >> >
>> > > > >>> >> >> > > > > > > > > > >> > We could certainly do this is
>> phases
>> > as
>> > > > >>> well.
>> > > > >>> >> >> > > > > > > > > > >> >
>> > > > >>> >> >> > > > > > > > > > >> > If you can enumerate the things
>> that
>> > > > should
>> > > > >>> work
>> > > > >>> >> and
>> > > > >>> >> >> > > > provide
>> > > > >>> >> >> > > > > > > some
>> > > > >>> >> >> > > > > > > > > > >> testing
>> > > > >>> >> >> > > > > > > > > > >> > details for CAS or as many as
>> possible
>> > > and
>> > > > >>> OpenID
>> > > > >>> >> >> > > Connect
>> > > > >>> >> >> > > > > then
>> > > > >>> >> >> > > > > > > we
>> > > > >>> >> >> > > > > > > > > can
>> > > > >>> >> >> > > > > > > > > > >> test
>> > > > >>> >> >> > > > > > > > > > >> > the specific implementations that
>> you
>> > > > >>> provide and
>> > > > >>> >> >> > enable
>> > > > >>> >> >> > > > the
>> > > > >>> >> >> > > > > > > > testing
>> > > > >>> >> >> > > > > > > > > > of
>> > > > >>> >> >> > > > > > > > > > >> > another OpenID Connect effort that
>> is
>> > in
>> > > > the
>> > > > >>> >> works
>> > > > >>> >> >> in
>> > > > >>> >> >> > > the
>> > > > >>> >> >> > > > > > > > community.
>> > > > >>> >> >> > > > > > > > > > >> >
>> > > > >>> >> >> > > > > > > > > > >> > I'm not sure whether we want to
>> commit
>> > > > >>> >> contributions
>> > > > >>> >> >> > > that
>> > > > >>> >> >> > > > > are
>> > > > >>> >> >> > > > > > > > > > dependent
>> > > > >>> >> >> > > > > > > > > > >> on
>> > > > >>> >> >> > > > > > > > > > >> > snapshots - we certainly can't
>> release
>> > > > with
>> > > > >>> any
>> > > > >>> >> such
>> > > > >>> >> >> > > > > > > dependencies.
>> > > > >>> >> >> > > > > > > > > > >> > I would hate to add a cleanup task
>> to
>> > a
>> > > > >>> release
>> > > > >>> >> to
>> > > > >>> >> >> > make
>> > > > >>> >> >> > > > sure
>> > > > >>> >> >> > > > > > > there
>> > > > >>> >> >> > > > > > > > > are
>> > > > >>> >> >> > > > > > > > > > >> no
>> > > > >>> >> >> > > > > > > > > > >> > snapshots in there.
>> > > > >>> >> >> > > > > > > > > > >> > We will probably wait until after
>> the
>> > > > pac4j
>> > > > >>> >> releases
>> > > > >>> >> >> > to
>> > > > >>> >> >> > > > > > commit.
>> > > > >>> >> >> > > > > > > > > > >> >
>> > > > >>> >> >> > > > > > > > > > >> > I am really happy that this
>> > integration
>> > > is
>> > > > >>> >> happening
>> > > > >>> >> >> > and
>> > > > >>> >> >> > > > > that
>> > > > >>> >> >> > > > > > it
>> > > > >>> >> >> > > > > > > > > went
>> > > > >>> >> >> > > > > > > > > > >> > rather smoothly.
>> > > > >>> >> >> > > > > > > > > > >> > These sorts of authentication
>> > protocols
>> > > > are
>> > > > >>> >> complex
>> > > > >>> >> >> > and
>> > > > >>> >> >> > > I
>> > > > >>> >> >> > > > > > think
>> > > > >>> >> >> > > > > > > we
>> > > > >>> >> >> > > > > > > > > > >> lined up
>> > > > >>> >> >> > > > > > > > > > >> > pretty well overall.
>> > > > >>> >> >> > > > > > > > > > >> >
>> > > > >>> >> >> > > > > > > > > > >> > Thanks for your work!
>> > > > >>> >> >> > > > > > > > > > >> >
>> > > > >>> >> >> > > > > > > > > > >> > On Thu, Dec 3, 2015 at 2:28 PM,
>> Jérôme
>> > > > >>> LELEU <
>> > > > >>> >> >> > > > > > leleuj@gmail.com>
>> > > > >>> >> >> > > > > > > > > > wrote:
>> > > > >>> >> >> > > > > > > > > > >> >
>> > > > >>> >> >> > > > > > > > > > >> > > Hi,
>> > > > >>> >> >> > > > > > > > > > >> > >
>> > > > >>> >> >> > > > > > > > > > >> > > I just sync'ed with master,
>> cleaned
>> > > > >>> >> dependencies
>> > > > >>> >> >> and
>> > > > >>> >> >> > > > added
>> > > > >>> >> >> > > > > > > > missing
>> > > > >>> >> >> > > > > > > > > > >> > > Javadocs. Everything works
>> correctly
>> > > > now.
>> > > > >>> Many
>> > > > >>> >> >> > thanks.
>> > > > >>> >> >> > > > > > > > > > >> > >
>> > > > >>> >> >> > > > > > > > > > >> > > The pull request is ready for a
>> full
>> > > > code
>> > > > >>> >> review:
>> > > > >>> >> >> > > > > > > > > > >> > >
>> > https://github.com/apache/knox/pull/2
>> > > > >>> >> >> > > > > > > > > > >> > >
>> > > > >>> >> >> > > > > > > > > > >> > > I'll write the documentation
>> after
>> > the
>> > > > >>> pac4j
>> > > > >>> >> >> > releases
>> > > > >>> >> >> > > (I
>> > > > >>> >> >> > > > > > hope
>> > > > >>> >> >> > > > > > > > next
>> > > > >>> >> >> > > > > > > > > > >> week).
>> > > > >>> >> >> > > > > > > > > > >> > >
>> > > > >>> >> >> > > > > > > > > > >> > > Thanks.
>> > > > >>> >> >> > > > > > > > > > >> > > Best regards,
>> > > > >>> >> >> > > > > > > > > > >> > > Jérôme
>> > > > >>> >> >> > > > > > > > > > >> > >
>> > > > >>> >> >> > > > > > > > > > >> > >
>> > > > >>> >> >> > > > > > > > > > >> > > 2015-12-02 19:18 GMT+01:00 larry
>> > > mccay <
>> > > > >>> >> >> > > > > > larry.mccay@gmail.com
>> > > > >>> >> >> > > > > > > >:
>> > > > >>> >> >> > > > > > > > > > >> > >
>> > > > >>> >> >> > > > > > > > > > >> > > > Fixed in
>> > > > >>> >> >> > > > https://issues.apache.org/jira/browse/KNOX-636
>> > > > >>> >> >> > > > > .
>> > > > >>> >> >> > > > > > > > > > >> > > >
>> > > > >>> >> >> > > > > > > > > > >> > > > On Wed, Dec 2, 2015 at 12:42
>> PM,
>> > > larry
>> > > > >>> mccay
>> > > > >>> >> <
>> > > > >>> >> >> > > > > > > > > > larry.mccay@gmail.com
>> > > > >>> >> >> > > > > > > > > > >> >
>> > > > >>> >> >> > > > > > > > > > >> > > > wrote:
>> > > > >>> >> >> > > > > > > > > > >> > > >
>> > > > >>> >> >> > > > > > > > > > >> > > > > Sure - I can file a JIRA and
>> > > commit
>> > > > a
>> > > > >>> fix.
>> > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > >>> >> >> > > > > > > > > > >> > > > > The secret generation should
>> be
>> > > done
>> > > > >>> in one
>> > > > >>> >> >> > > instance
>> > > > >>> >> >> > > > > and
>> > > > >>> >> >> > > > > > > > > > >> replicated
>> > > > >>> >> >> > > > > > > > > > >> > > > across
>> > > > >>> >> >> > > > > > > > > > >> > > > > others.
>> > > > >>> >> >> > > > > > > > > > >> > > > > This replication/management
>> of
>> > the
>> > > > >>> >> credential
>> > > > >>> >> >> > > stores
>> > > > >>> >> >> > > > > is
>> > > > >>> >> >> > > > > > > > > outside
>> > > > >>> >> >> > > > > > > > > > of
>> > > > >>> >> >> > > > > > > > > > >> > the
>> > > > >>> >> >> > > > > > > > > > >> > > > > scope of Knox itself as of
>> now.
>> > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > >>> >> >> > > > > > > > > > >> > > > > Documentation is done in
>> > markdown
>> > > > and
>> > > > >>> is
>> > > > >>> >> >> > > > contributing
>> > > > >>> >> >> > > > > > > > details
>> > > > >>> >> >> > > > > > > > > > are
>> > > > >>> >> >> > > > > > > > > > >> > > > > available at:
>> > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > >>> >> >> > > > > > > > > > >> > > >
>> > > > >>> >> >> > > > > > > > > > >> > >
>> > > > >>> >> >> > > > > > > > > > >> >
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > >
>> > > > >>> >> >> > > > > > > > >
>> > > > >>> >> >> > > > > > > >
>> > > > >>> >> >> > > > > > >
>> > > > >>> >> >> > > > > >
>> > > > >>> >> >> > > > >
>> > > > >>> >> >> > > >
>> > > > >>> >> >> > >
>> > > > >>> >> >> >
>> > > > >>> >> >>
>> > > > >>> >>
>> > > > >>>
>> > > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
>> > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > >>> >> >> > > > > > > > > > >> > > > > Which should give you a
>> general
>> > > > idea.
>> > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > >>> >> >> > > > > > > > > > >> > > > > Find an example like:
>> > > > >>> ./trunk/books/0.7.0/
>> > > > >>> >> >> > > > > > > > > > >> > > config_preauth_sso_provider.md
>> > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > >>> >> >> > > > > > > > > > >> > > > > For an example of typical
>> > content
>> > > > and
>> > > > >>> >> format.
>> > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > >>> >> >> > > > > > > > > > >> > > > > Here is how that example
>> > renders:
>> > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > >>> >> >> > > > > > > > > > >> > > >
>> > > > >>> >> >> > > > > > > > > > >> > >
>> > > > >>> >> >> > > > > > > > > > >> >
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > >
>> > > > >>> >> >> > > > > > > > >
>> > > > >>> >> >> > > > > > > >
>> > > > >>> >> >> > > > > > >
>> > > > >>> >> >> > > > > >
>> > > > >>> >> >> > > > >
>> > > > >>> >> >> > > >
>> > > > >>> >> >> > >
>> > > > >>> >> >> >
>> > > > >>> >> >>
>> > > > >>> >>
>> > > > >>>
>> > > >
>> > >
>> >
>> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
>> > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > >>> >> >> > > > > > > > > > >> > > > > You'll need to tie it into
>> the
>> > > rest
>> > > > >>> of the
>> > > > >>> >> >> book
>> > > > >>> >> >> > -
>> > > > >>> >> >> > > > just
>> > > > >>> >> >> > > > > > > grep
>> > > > >>> >> >> > > > > > > > > for
>> > > > >>> >> >> > > > > > > > > > >> where
>> > > > >>> >> >> > > > > > > > > > >> > > > that
>> > > > >>> >> >> > > > > > > > > > >> > > > > filename is referenced.
>> > > > >>> >> >> > > > > > > > > > >> > > > > To test how it renders build
>> the
>> > > > site
>> > > > >>> with:
>> > > > >>> >> >> > "ant"
>> > > > >>> >> >> > > > and
>> > > > >>> >> >> > > > > > note
>> > > > >>> >> >> > > > > > > > the
>> > > > >>> >> >> > > > > > > > > > >> url to
>> > > > >>> >> >> > > > > > > > > > >> > > the
>> > > > >>> >> >> > > > > > > > > > >> > > > > 0.7.0 book.
>> > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > >>> >> >> > > > > > > > > > >> > > > > On Wed, Dec 2, 2015 at 12:12
>> PM,
>> > > > >>> Jérôme
>> > > > >>> >> LELEU
>> > > > >>> >> >> <
>> > > > >>> >> >> > > > > > > > > leleuj@gmail.com
>> > > > >>> >> >> > > > > > > > > > >
>> > > > >>> >> >> > > > > > > > > > >> > > wrote:
>> > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> Hi,
>> > > > >>> >> >> > > > > > > > > > >> > > > >>
>> > > > >>> >> >> > > > > > > > > > >> > > > >> Why it doesn't work for
>> pac4j
>> > > while
>> > > > >>> it
>> > > > >>> >> works
>> > > > >>> >> >> > for
>> > > > >>> >> >> > > > > others
>> > > > >>> >> >> > > > > > > is
>> > > > >>> >> >> > > > > > > > a
>> > > > >>> >> >> > > > > > > > > > bit
>> > > > >>> >> >> > > > > > > > > > >> > > strange
>> > > > >>> >> >> > > > > > > > > > >> > > > >> to
>> > > > >>> >> >> > > > > > > > > > >> > > > >> me, but if you have the
>> patch
>> > in
>> > > > >>> front of
>> > > > >>> >> >> your
>> > > > >>> >> >> > > > eyes,
>> > > > >>> >> >> > > > > > I'd
>> > > > >>> >> >> > > > > > > > > rather
>> > > > >>> >> >> > > > > > > > > > >> > prefer
>> > > > >>> >> >> > > > > > > > > > >> > > > you
>> > > > >>> >> >> > > > > > > > > > >> > > > >> to commit it. In all cases,
>> > I'll
>> > > > >>> sync with
>> > > > >>> >> >> the
>> > > > >>> >> >> > > > > master.
>> > > > >>> >> >> > > > > > > > > > >> > > > >>
>> > > > >>> >> >> > > > > > > > > > >> > > > >> There was one question you
>> > didn't
>> > > > >>> answer
>> > > > >>> >> >> > > > previously:
>> > > > >>> >> >> > > > > is
>> > > > >>> >> >> > > > > > > the
>> > > > >>> >> >> > > > > > > > > > >> password
>> > > > >>> >> >> > > > > > > > > > >> > > > >> generated for the pac4j
>> > provider
>> > > > the
>> > > > >>> same
>> > > > >>> >> >> > across
>> > > > >>> >> >> > > > all
>> > > > >>> >> >> > > > > > > > gateway
>> > > > >>> >> >> > > > > > > > > > >> > > instances?
>> > > > >>> >> >> > > > > > > > > > >> > > > >> Because I expect to have the
>> > same
>> > > > >>> value
>> > > > >>> >> as I
>> > > > >>> >> >> > use
>> > > > >>> >> >> > > it
>> > > > >>> >> >> > > > > to
>> > > > >>> >> >> > > > > > > > > encrypt
>> > > > >>> >> >> > > > > > > > > > /
>> > > > >>> >> >> > > > > > > > > > >> > > decrypt
>> > > > >>> >> >> > > > > > > > > > >> > > > >> data.
>> > > > >>> >> >> > > > > > > > > > >> > > > >>
>> > > > >>> >> >> > > > > > > > > > >> > > > >> I will add the Javadoc.
>> After
>> > > that,
>> > > > >>> you
>> > > > >>> >> can
>> > > > >>> >> >> > > review
>> > > > >>> >> >> > > > > the
>> > > > >>> >> >> > > > > > > pull
>> > > > >>> >> >> > > > > > > > > > >> request
>> > > > >>> >> >> > > > > > > > > > >> > > more
>> > > > >>> >> >> > > > > > > > > > >> > > > >> completely.
>> > > > >>> >> >> > > > > > > > > > >> > > > >>
>> > > > >>> >> >> > > > > > > > > > >> > > > >> What do you expect for the
>> > > > >>> documentation?
>> > > > >>> >> >> > > > > > > > > > >> > > > >>
>> > > > >>> >> >> > > > > > > > > > >> > > > >> Notice that pac4j
>> dependencies
>> > > are
>> > > > >>> still
>> > > > >>> >> >> > > snapshots,
>> > > > >>> >> >> > > > > but
>> > > > >>> >> >> > > > > > > > they
>> > > > >>> >> >> > > > > > > > > > >> will be
>> > > > >>> >> >> > > > > > > > > > >> > > > >> released in a week or two.
>> > > > >>> >> >> > > > > > > > > > >> > > > >>
>> > > > >>> >> >> > > > > > > > > > >> > > > >> Thanks.
>> > > > >>> >> >> > > > > > > > > > >> > > > >> Best regards,
>> > > > >>> >> >> > > > > > > > > > >> > > > >> Jérôme
>> > > > >>> >> >> > > > > > > > > > >> > > > >>
>> > > > >>> >> >> > > > > > > > > > >> > > > >>
>> > > > >>> >> >> > > > > > > > > > >> > > > >> 2015-12-02 17:51 GMT+01:00
>> > larry
>> > > > >>> mccay <
>> > > > >>> >> >> > > > > > > > > larry.mccay@gmail.com
>> > > > >>> >> >> > > > > > > > > > >:
>> > > > >>> >> >> > > > > > > > > > >> > > > >>
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > Jérôme -
>> > > > >>> >> >> > > > > > > > > > >> > > > >> >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > If you would like to add
>> that
>> > > > >>> change as
>> > > > >>> >> >> part
>> > > > >>> >> >> > of
>> > > > >>> >> >> > > > > your
>> > > > >>> >> >> > > > > > > > patch
>> > > > >>> >> >> > > > > > > > > or
>> > > > >>> >> >> > > > > > > > > > >> as a
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > separately filed JIRA to
>> fix
>> > a
>> > > > bug
>> > > > >>> that
>> > > > >>> >> >> would
>> > > > >>> >> >> > > > > > certainly
>> > > > >>> >> >> > > > > > > > be
>> > > > >>> >> >> > > > > > > > > > >> > welcomed.
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > Otherwise, I can do it.
>> > > > >>> >> >> > > > > > > > > > >> > > > >> >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > Let me know.
>> > > > >>> >> >> > > > > > > > > > >> > > > >> >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > thanks,
>> > > > >>> >> >> > > > > > > > > > >> > > > >> >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > --larry
>> > > > >>> >> >> > > > > > > > > > >> > > > >> >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > On Wed, Dec 2, 2015 at
>> 11:44
>> > > AM,
>> > > > >>> larry
>> > > > >>> >> >> mccay
>> > > > >>> >> >> > <
>> > > > >>> >> >> > > > > > > > > > >> > larry.mccay@gmail.com
>> > > > >>> >> >> > > > > > > > > > >> > > >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > wrote:
>> > > > >>> >> >> > > > > > > > > > >> > > > >> >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > > Okay - I had to add an
>> > > override
>> > > > >>> of
>> > > > >>> >> >> > > > > > getUserPrincipal()
>> > > > >>> >> >> > > > > > > > to
>> > > > >>> >> >> > > > > > > > > > the
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >
>> > > > >>> >> IdentityAsserterHttpServletRequestWrapper
>> > > > >>> >> >> > and
>> > > > >>> >> >> > > > > > return
>> > > > >>> >> >> > > > > > > > the
>> > > > >>> >> >> > > > > > > > > > >> member
>> > > > >>> >> >> > > > > > > > > > >> > > > >> variable
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > > username and it works
>> like
>> > a
>> > > > >>> charm.
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > > Why I haven't seen this
>> > same
>> > > > >>> behavior
>> > > > >>> >> >> with
>> > > > >>> >> >> > > > other
>> > > > >>> >> >> > > > > > > > > providers
>> > > > >>> >> >> > > > > > > > > > >> is a
>> > > > >>> >> >> > > > > > > > > > >> > > bit
>> > > > >>> >> >> > > > > > > > > > >> > > > >> of a
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > > mystery but they must be
>> > > adding
>> > > > >>> other
>> > > > >>> >> >> > > wrappers
>> > > > >>> >> >> > > > > that
>> > > > >>> >> >> > > > > > > > > handle
>> > > > >>> >> >> > > > > > > > > > >> it.
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > > This is quite cool,
>> Jérôme!
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > > On Wed, Dec 2, 2015 at
>> > 10:41
>> > > > AM,
>> > > > >>> larry
>> > > > >>> >> >> > mccay
>> > > > >>> >> >> > > <
>> > > > >>> >> >> > > > > > > > > > >> > > larry.mccay@gmail.com
>> > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > > wrote:
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >> That was it - thanks!
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >> On Wed, Dec 2, 2015 at
>> > 10:20
>> > > > AM,
>> > > > >>> >> Jérôme
>> > > > >>> >> >> > > LELEU
>> > > > >>> >> >> > > > <
>> > > > >>> >> >> > > > > > > > > > >> > leleuj@gmail.com>
>> > > > >>> >> >> > > > > > > > > > >> > > > >> wrote:
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> This is my exact
>> command
>> > > > line:
>> > > > >>> mvn
>> > > > >>> >> >> > > -Prelease
>> > > > >>> >> >> > > > > > clean
>> > > > >>> >> >> > > > > > > > > > install
>> > > > >>> >> >> > > > > > > > > > >> > > > >> -DskipTests
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> You use an internal
>> Maven
>> > > > >>> >> repository to
>> > > > >>> >> >> > > fetch
>> > > > >>> >> >> > > > > > > > > > dependencies
>> > > > >>> >> >> > > > > > > > > > >> > from
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > internet:
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
>> > > > >>> >> >> > > > > > > > > > >> > >
>> > > > >>> >> >> > > > > > > >
>> > > > >>> >> >> > >
>> > > > >>>
>> http://nexus-private.hortonworks.com/nexus/content/groups/public/
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> Does this repository
>> have
>> > > > >>> access to
>> > > > >>> >> the
>> > > > >>> >> >> > > > remote
>> > > > >>> >> >> > > > > > > > > Snapshots
>> > > > >>> >> >> > > > > > > > > > >> > > Sonatype
>> > > > >>> >> >> > > > > > > > > > >> > > > >> repo?
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> 2015-12-02 16:16
>> > GMT+01:00
>> > > > >>> larry
>> > > > >>> >> mccay
>> > > > >>> >> >> <
>> > > > >>> >> >> > > > > > > > > > >> larry.mccay@gmail.com
>> > > > >>> >> >> > > > > > > > > > >> > >:
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > hmmm - I used:
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > mvn clean install
>> > > > >>> -DskipTests=true
>> > > > >>> >> >> > > > -Prelease
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > The repository
>> entry is
>> > > in
>> > > > >>> there
>> > > > >>> >> >> > already.
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > No worky.
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > On Wed, Dec 2, 2015
>> at
>> > > > 10:12
>> > > > >>> AM,
>> > > > >>> >> >> Jérôme
>> > > > >>> >> >> > > > > LELEU <
>> > > > >>> >> >> > > > > > > > > > >> > > leleuj@gmail.com
>> > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> wrote:
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Hi,
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > You need the
>> > j2e-pac4j
>> > > > >>> >> dependencies
>> > > > >>> >> >> > as
>> > > > >>> >> >> > > > well
>> > > > >>> >> >> > > > > > as
>> > > > >>> >> >> > > > > > > > the
>> > > > >>> >> >> > > > > > > > > > >> pac4j-*
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> dependencies,
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > but you don't
>> need to
>> > > > >>> build them
>> > > > >>> >> >> > > locally
>> > > > >>> >> >> > > > > > > > > (hopefully).
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > But you need a
>> > > dependency
>> > > > >>> on the
>> > > > >>> >> >> > > Sonatype
>> > > > >>> >> >> > > > > > > > snapshots
>> > > > >>> >> >> > > > > > > > > > >> > > repository
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> (where the
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > snapshot versions
>> are
>> > > > >>> hosted),
>> > > > >>> >> >> which
>> > > > >>> >> >> > is
>> > > > >>> >> >> > > > > added
>> > > > >>> >> >> > > > > > > for
>> > > > >>> >> >> > > > > > > > > > >> Maven in
>> > > > >>> >> >> > > > > > > > > > >> > > the
>> > > > >>> >> >> > > > > > > > > > >> > > > >> root
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > pom.xml:
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
>> > > > >>> >> >> > > > > > > > > > >> > > > >> >
>> > > > >>> >> >> > > > > > > > > > >> > > > >>
>> > > > >>> >> >> > > > > > > > > > >> > > >
>> > > > >>> >> >> > > > > > > > > > >> > >
>> > > > >>> >> >> > > > > > > > > > >> >
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > >
>> > > > >>> >> >> > > > > > > > >
>> > > > >>> >> >> > > > > > > >
>> > > > >>> >> >> > > > > > >
>> > > > >>> >> >> > > > > >
>> > > > >>> >> >> > > > >
>> > > > >>> >> >> > > >
>> > > > >>> >> >> > >
>> > > > >>> >> >> >
>> > > > >>> >> >>
>> > > > >>> >>
>> > > > >>>
>> > > >
>> > >
>> >
>> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > If you use Ant for
>> > the
>> > > > >>> build,
>> > > > >>> >> there
>> > > > >>> >> >> > is
>> > > > >>> >> >> > > > > maybe
>> > > > >>> >> >> > > > > > a
>> > > > >>> >> >> > > > > > > > > glitch
>> > > > >>> >> >> > > > > > > > > > >> to
>> > > > >>> >> >> > > > > > > > > > >> > > find
>> > > > >>> >> >> > > > > > > > > > >> > > > >> the
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > Sonatype
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Maven repo.
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Thanks.
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Best regards,
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Jérôme
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > 2015-12-02 16:06
>> > > > GMT+01:00
>> > > > >>> larry
>> > > > >>> >> >> > mccay
>> > > > >>> >> >> > > <
>> > > > >>> >> >> > > > > > > > > > >> > > larry.mccay@gmail.com
>> > > > >>> >> >> > > > > > > > > > >> > > > >:
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > 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.mccay@gmail.com
>> >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > wrote:
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > >
>> > > > >>> >> gateway-provider-security-pac4j
>> > > > >>> >> >> > > > doesn't
>> > > > >>> >> >> > > > > > > > build -
>> > > > >>> >> >> > > > > > > > > > do
>> > > > >>> >> >> > > > > > > > > > >> you
>> > > > >>> >> >> > > > > > > > > > >> > > > have
>> > > > >>> >> >> > > > > > > > > > >> > > > >> a
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> pending
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > > change for
>> your
>> > > > >>> pom.xml or
>> > > > >>> >> >> > > something?
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>
>> > > > >>> >> >> > > > > > > > > > >> > > > >> > >
>> > > > >>> >> >> > > > > > > > > > >> > > > >> >
>> > > > >>> >> >> > > > > > > > > > >> > > > >>
>> > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > >>> >> >> > > > > > > > > > >> > > >
>> > > > >>> >> >> > > > > > > > > > >> > >
>> > > > >>> >> >> > > > > > > > > > >> >
>> > > > >>> >> >> > > > > > > > > > >>
>> > > > >>> >> >> > > > > > > > > > >
>> > > > >>> >> >> > > > > > > > > > >
>> > > > >>> >> >> > > > > > > > > >
>> > > > >>> >> >> > > > > > > > >
>> > > > >>> >> >> > > > > > > >
>> > > > >>> >> >> > > > > > >
>> > > > >>> >> >> > > > > >
>> > > > >>> >> >> > > > >
>> > > > >>> >> >> > > >
>> > > > >>> >> >> > >
>> > > > >>> >> >> >
>> > > > >>> >> >>
>> > > > >>> >>
>> > > > >>>
>> > > > >>
>> > > > >>
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
I think that I see...
* client_name is a query parameter that is just used to determine that the
call into the pac4j provider is coming from an IdP post authentication
* clientName is a topology parameter that can be used to select the one
client our of the multiple sets that may be configured
* when no clientName parameter is defined the first one is chosen
It may be interesting to add a client_selector parameter on the client URLs
that indicate which client to use for the incoming request.
As it stands now, we would need multiple knoxsso topologies in order to
provide options like I described in the last email and point to a different
topology for each Login link.
On Tue, Jan 19, 2016 at 6:54 PM, larry mccay <la...@gmail.com> wrote:
> Trying to figure out how to specify the client_name for a given
> authentication attempt when there are multiple mechanisms defined in the
> topology. What I had in mind was providing a couple links to login with:
>
> Login with Okta
> Login with Twitter
> Login with Google
>
> and at the end of each url I thought that I could just indicate
> &client_name=SAMLClient and that it would choose the SAML config in the
> topology.
> That doesn't seem to be how it works - either I am missing something or we
> need a JIRA to fix something.
>
> Can you provide a little more insight into the client selection feature?
>
> Thanks!
>
>
> On Tue, Jan 19, 2016 at 10:11 AM, larry mccay <la...@gmail.com>
> wrote:
>
>> Hmmmm...
>>
>> I think that providing appropriate templates (see the templates directory
>> in the knox install) for both the knoxsso.xml (instead of idp.xml) and
>> sandbox.xml to reflect the same config would provide the same value and be
>> self contained without the need to keep the binaries up to date in the demo
>> with each release.
>>
>> There is probably value in a blog for early access to pac4j provider demo
>> that could point to the demo.
>>
>>
>> On Tue, Jan 19, 2016 at 9:04 AM, Jérôme LELEU <le...@gmail.com> wrote:
>>
>>> Should we add a link in the documentation to point to the demo?
>>>
>>> 2016-01-19 14:19 GMT+01:00 larry mccay <la...@gmail.com>:
>>>
>>> > That's great!
>>> >
>>> > On Tue, Jan 19, 2016 at 7:53 AM, Jérôme LELEU <le...@gmail.com>
>>> wrote:
>>> >
>>> > > Hi,
>>> > >
>>> > > Following my own idea, here is a demo with the Knox / pac4j support:
>>> > > https://github.com/pac4j/knox-pac4j-demo
>>> > > Feel free to submit pull requests if you want me to amend it.
>>> > >
>>> > > What do you think?
>>> > >
>>> > > Thanks.
>>> > > Best regards,
>>> > > Jérôme
>>> > >
>>> > >
>>> > > 2016-01-18 11:03 GMT+01:00 Jérôme LELEU <le...@gmail.com>:
>>> > >
>>> > > > Hi,
>>> > > >
>>> > > > It's great news!
>>> > > >
>>> > > > One more thing I'm thinking of: we always have a demo
>>> corresponding to
>>> > a
>>> > > > pac4j support. It would be great to have a knox-pac4j-demo and
>>> > reference
>>> > > it
>>> > > > from the manual. I can handle it.
>>> > > >
>>> > > > Does it make sense?
>>> > > >
>>> > > > Thanks.
>>> > > > Best regards,
>>> > > > Jérôme
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > > 2016-01-17 6:37 GMT+01:00 larry mccay <lm...@apache.org>:
>>> > > >
>>> > > >> KNOX-641 and KNOX-642 have both been committed to master.
>>> > > >>
>>> > > >> There is a new docs book where you can check out the pac4j docs
>>> > > available:
>>> > > >>
>>> > > >>
>>> > >
>>> >
>>> http://knox.apache.org/books/knox-0-8-0/user-guide.html#Pac4j+Provider+-+CAS+/+OAuth+/+SAML+/+OpenID+Connect
>>> > > >>
>>> > > >> I have some additional ideas for the docs that I will roll out in
>>> the
>>> > > next
>>> > > >> few days.
>>> > > >>
>>> > > >> We need to discuss the identity assertion approach for 0.8.0.
>>> > > >>
>>> > > >> I think we are on track for 1/29 release date.
>>> > > >>
>>> > > >
>>> > >
>>> >
>>>
>>
>>
>
Re: pac4j and Apache Knox
Posted by larry mccay <lm...@apache.org>.
Let's leave it as is for 0.8.0 but we will need to address that in a less
cumbersome way and at the same time be backward compatible.
Groovy class would be an interesting approach but I'm not sure that we will
want configuration to be code running in the gateway.
I am thinking about having the service contributor create a separate
configuration file much the same way that the shiro provider creates
shiro.ini during deployment. The ConfigFactory could then read that file.
This leads to an issue with still representing the config in provider
params that get translated into the more complex config file though. We'll
need to work through that.
LDAP configuration is a great example of something that is rather complex.
A common configuration format that could be used across multiple projects
in Hadoop would actually be pretty welcome. Of course there is the
discovery of it in a common location issue to solve as well but having to
configure LDAP in Apache Knox, Ambari and Ranger and possibly for Hive and
HUE, etc is painful and error prone.
I have often considered a way to provide named configuration resources such
as this that could just be referenced from within individual component
config by name and have it resolved. Give me the "production-ldap" or the
"test-ldap", etc.
Anyway, just some thoughts.
On Mon, Jan 25, 2016 at 5:07 AM, Jérôme LELEU <le...@gmail.com> wrote:
> Hi,
>
> Yes, you're right, it's limited to two custom parameters. My experience
> taught me that two parameters were enough for most cases, but indeed, it
> seems a bit cumbersome to have such configuration.
>
> This mechanism is shared with the CAS server configuration which uses
> properties, thus the name=value did not appear as the best choice.
>
> My feeling about configuration is that we should stay with this basic
> configuration mechanism which is easy and does the job for simple use cases
> (like a CAS server or Facebook) and design a full configuration system for
> all use cases (especially to be able to configure a LDAP authenticator). In
> pac4j, we already have a ConfigFactory interface which is generally
> implemented in frameworks to build a full configuration (example:
>
> https://github.com/pac4j/j2e-pac4j-demo/blob/master/src/main/java/org/pac4j/demo/j2e/config/DemoConfigFactory.java#L23
> ).
>
> I'm thinking of such an advanced mechanism though it requires compilation
> which is maybe not possible in Knox. In that case, what about a Groovy
> class for configuration (implementing the ConfigFactory interface)?
>
> Thanks.
> Best regards,
> Jérôme
>
>
>
> 2016-01-24 15:45 GMT+01:00 larry mccay <la...@gmail.com>:
>
> > Question about the customParamKeyX params...
> >
> > In doing some additional testing with the openid connect integration, it
> > was determined that the scopes provided by default didn't work properly
> for
> > all providers. Therefore, the following was added and it worked great.
> >
> > <param>
> >
> > <name>oidc.customParamKey1</name>
> >
> > <value>scope</value>
> >
> > </param>
> >
> > <param>
> >
> > <name>oidc.customParamValue1</name>
> >
> > <value>openid</value>
> > </param>
> >
> > However, it dawned on me that the currently implementation seems limited
> > to 2 custom params with the key and values separated into different
> > elements.
> >
> > I am wondering whether a comma separated list of name=value pairs in a
> > single customParams element would make sense.
> > Additionally, I wonder whether "customParams" are even needed at all.
> > Couldn't any param that starts with oidc be targeted at the openid
> connect
> > client and likewise for other clients?
> >
> >
> > On Thu, Jan 21, 2016 at 9:02 AM, larry mccay <lm...@apache.org> wrote:
> >
> >> That sounds perfect and actually the right way to keep pac4j and the
> knox
> >> pac4j provider aligned properly.
> >> I filed https://issues.apache.org/jira/browse/KNOX-655 for this effort.
> >>
> >> Thanks, Jérôme!
> >>
> >> --larry
> >>
> >> On Thu, Jan 21, 2016 at 4:38 AM, Jérôme LELEU <le...@gmail.com> wrote:
> >>
> >>> Hi,
> >>>
> >>> Interesting point.
> >>>
> >>> In pac4j, we have a callback controller which uses the client_name
> >>> parameter to finish the login process and a protection filter which
> >>> protects a resource and redirects the user to the identity provider for
> >>> login. Since pac4j 1.8, most libraries using it now accept a
> client_name
> >>> parameter in the protection filter as well to choose the authentication
> >>> mechanism to use if the user is not authenticated.
> >>>
> >>> With Knox, this feature (choosing the authentication mechanism with the
> >>> client_name parameter) is not available as this parameter is already
> used
> >>> to define if it's a callback or an access. This could be changed and we
> >>> could opt for a new convention, like a new pac4jCallback parameter to
> say
> >>> if it's a callback or not. And this way, you could choose on the fly
> >>> which
> >>> authentication mechanism you want to use.
> >>>
> >>> Does it make sense?
> >>>
> >>> This is certainly not a big change: can you open a JIRA for that and
> I'll
> >>> handle it before the 0.8.0 release?
> >>>
> >>> Thanks.
> >>> Best regards,
> >>> Jérôme
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> 2016-01-20 0:54 GMT+01:00 larry mccay <la...@gmail.com>:
> >>>
> >>> > Trying to figure out how to specify the client_name for a given
> >>> > authentication attempt when there are multiple mechanisms defined in
> >>> the
> >>> > topology. What I had in mind was providing a couple links to login
> >>> with:
> >>> >
> >>> > Login with Okta
> >>> > Login with Twitter
> >>> > Login with Google
> >>> >
> >>> > and at the end of each url I thought that I could just indicate
> >>> > &client_name=SAMLClient and that it would choose the SAML config in
> the
> >>> > topology.
> >>> > That doesn't seem to be how it works - either I am missing something
> >>> or we
> >>> > need a JIRA to fix something.
> >>> >
> >>> > Can you provide a little more insight into the client selection
> >>> feature?
> >>> >
> >>> > Thanks!
> >>> >
> >>> >
> >>> > On Tue, Jan 19, 2016 at 10:11 AM, larry mccay <larry.mccay@gmail.com
> >
> >>> > wrote:
> >>> >
> >>> > > Hmmmm...
> >>> > >
> >>> > > I think that providing appropriate templates (see the templates
> >>> directory
> >>> > > in the knox install) for both the knoxsso.xml (instead of idp.xml)
> >>> and
> >>> > > sandbox.xml to reflect the same config would provide the same value
> >>> and
> >>> > be
> >>> > > self contained without the need to keep the binaries up to date in
> >>> the
> >>> > demo
> >>> > > with each release.
> >>> > >
> >>> > > There is probably value in a blog for early access to pac4j
> provider
> >>> demo
> >>> > > that could point to the demo.
> >>> > >
> >>> > >
> >>> > > On Tue, Jan 19, 2016 at 9:04 AM, Jérôme LELEU <le...@gmail.com>
> >>> wrote:
> >>> > >
> >>> > >> Should we add a link in the documentation to point to the demo?
> >>> > >>
> >>> > >> 2016-01-19 14:19 GMT+01:00 larry mccay <la...@gmail.com>:
> >>> > >>
> >>> > >> > That's great!
> >>> > >> >
> >>> > >> > On Tue, Jan 19, 2016 at 7:53 AM, Jérôme LELEU <leleuj@gmail.com
> >
> >>> > wrote:
> >>> > >> >
> >>> > >> > > Hi,
> >>> > >> > >
> >>> > >> > > Following my own idea, here is a demo with the Knox / pac4j
> >>> support:
> >>> > >> > > https://github.com/pac4j/knox-pac4j-demo
> >>> > >> > > Feel free to submit pull requests if you want me to amend it.
> >>> > >> > >
> >>> > >> > > What do you think?
> >>> > >> > >
> >>> > >> > > Thanks.
> >>> > >> > > Best regards,
> >>> > >> > > Jérôme
> >>> > >> > >
> >>> > >> > >
> >>> > >> > > 2016-01-18 11:03 GMT+01:00 Jérôme LELEU <le...@gmail.com>:
> >>> > >> > >
> >>> > >> > > > Hi,
> >>> > >> > > >
> >>> > >> > > > It's great news!
> >>> > >> > > >
> >>> > >> > > > One more thing I'm thinking of: we always have a demo
> >>> > corresponding
> >>> > >> to
> >>> > >> > a
> >>> > >> > > > pac4j support. It would be great to have a knox-pac4j-demo
> and
> >>> > >> > reference
> >>> > >> > > it
> >>> > >> > > > from the manual. I can handle it.
> >>> > >> > > >
> >>> > >> > > > Does it make sense?
> >>> > >> > > >
> >>> > >> > > > Thanks.
> >>> > >> > > > Best regards,
> >>> > >> > > > Jérôme
> >>> > >> > > >
> >>> > >> > > >
> >>> > >> > > >
> >>> > >> > > >
> >>> > >> > > > 2016-01-17 6:37 GMT+01:00 larry mccay <lm...@apache.org>:
> >>> > >> > > >
> >>> > >> > > >> KNOX-641 and KNOX-642 have both been committed to master.
> >>> > >> > > >>
> >>> > >> > > >> There is a new docs book where you can check out the pac4j
> >>> docs
> >>> > >> > > available:
> >>> > >> > > >>
> >>> > >> > > >>
> >>> > >> > >
> >>> > >> >
> >>> > >>
> >>> >
> >>>
> http://knox.apache.org/books/knox-0-8-0/user-guide.html#Pac4j+Provider+-+CAS+/+OAuth+/+SAML+/+OpenID+Connect
> >>> > >> > > >>
> >>> > >> > > >> I have some additional ideas for the docs that I will roll
> >>> out in
> >>> > >> the
> >>> > >> > > next
> >>> > >> > > >> few days.
> >>> > >> > > >>
> >>> > >> > > >> We need to discuss the identity assertion approach for
> 0.8.0.
> >>> > >> > > >>
> >>> > >> > > >> I think we are on track for 1/29 release date.
> >>> > >> > > >>
> >>> > >> > > >
> >>> > >> > >
> >>> > >> >
> >>> > >>
> >>> > >
> >>> > >
> >>> >
> >>>
> >>
> >>
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Hi,
Yes, you're right, it's limited to two custom parameters. My experience
taught me that two parameters were enough for most cases, but indeed, it
seems a bit cumbersome to have such configuration.
This mechanism is shared with the CAS server configuration which uses
properties, thus the name=value did not appear as the best choice.
My feeling about configuration is that we should stay with this basic
configuration mechanism which is easy and does the job for simple use cases
(like a CAS server or Facebook) and design a full configuration system for
all use cases (especially to be able to configure a LDAP authenticator). In
pac4j, we already have a ConfigFactory interface which is generally
implemented in frameworks to build a full configuration (example:
https://github.com/pac4j/j2e-pac4j-demo/blob/master/src/main/java/org/pac4j/demo/j2e/config/DemoConfigFactory.java#L23
).
I'm thinking of such an advanced mechanism though it requires compilation
which is maybe not possible in Knox. In that case, what about a Groovy
class for configuration (implementing the ConfigFactory interface)?
Thanks.
Best regards,
Jérôme
2016-01-24 15:45 GMT+01:00 larry mccay <la...@gmail.com>:
> Question about the customParamKeyX params...
>
> In doing some additional testing with the openid connect integration, it
> was determined that the scopes provided by default didn't work properly for
> all providers. Therefore, the following was added and it worked great.
>
> <param>
>
> <name>oidc.customParamKey1</name>
>
> <value>scope</value>
>
> </param>
>
> <param>
>
> <name>oidc.customParamValue1</name>
>
> <value>openid</value>
> </param>
>
> However, it dawned on me that the currently implementation seems limited
> to 2 custom params with the key and values separated into different
> elements.
>
> I am wondering whether a comma separated list of name=value pairs in a
> single customParams element would make sense.
> Additionally, I wonder whether "customParams" are even needed at all.
> Couldn't any param that starts with oidc be targeted at the openid connect
> client and likewise for other clients?
>
>
> On Thu, Jan 21, 2016 at 9:02 AM, larry mccay <lm...@apache.org> wrote:
>
>> That sounds perfect and actually the right way to keep pac4j and the knox
>> pac4j provider aligned properly.
>> I filed https://issues.apache.org/jira/browse/KNOX-655 for this effort.
>>
>> Thanks, Jérôme!
>>
>> --larry
>>
>> On Thu, Jan 21, 2016 at 4:38 AM, Jérôme LELEU <le...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Interesting point.
>>>
>>> In pac4j, we have a callback controller which uses the client_name
>>> parameter to finish the login process and a protection filter which
>>> protects a resource and redirects the user to the identity provider for
>>> login. Since pac4j 1.8, most libraries using it now accept a client_name
>>> parameter in the protection filter as well to choose the authentication
>>> mechanism to use if the user is not authenticated.
>>>
>>> With Knox, this feature (choosing the authentication mechanism with the
>>> client_name parameter) is not available as this parameter is already used
>>> to define if it's a callback or an access. This could be changed and we
>>> could opt for a new convention, like a new pac4jCallback parameter to say
>>> if it's a callback or not. And this way, you could choose on the fly
>>> which
>>> authentication mechanism you want to use.
>>>
>>> Does it make sense?
>>>
>>> This is certainly not a big change: can you open a JIRA for that and I'll
>>> handle it before the 0.8.0 release?
>>>
>>> Thanks.
>>> Best regards,
>>> Jérôme
>>>
>>>
>>>
>>>
>>>
>>> 2016-01-20 0:54 GMT+01:00 larry mccay <la...@gmail.com>:
>>>
>>> > Trying to figure out how to specify the client_name for a given
>>> > authentication attempt when there are multiple mechanisms defined in
>>> the
>>> > topology. What I had in mind was providing a couple links to login
>>> with:
>>> >
>>> > Login with Okta
>>> > Login with Twitter
>>> > Login with Google
>>> >
>>> > and at the end of each url I thought that I could just indicate
>>> > &client_name=SAMLClient and that it would choose the SAML config in the
>>> > topology.
>>> > That doesn't seem to be how it works - either I am missing something
>>> or we
>>> > need a JIRA to fix something.
>>> >
>>> > Can you provide a little more insight into the client selection
>>> feature?
>>> >
>>> > Thanks!
>>> >
>>> >
>>> > On Tue, Jan 19, 2016 at 10:11 AM, larry mccay <la...@gmail.com>
>>> > wrote:
>>> >
>>> > > Hmmmm...
>>> > >
>>> > > I think that providing appropriate templates (see the templates
>>> directory
>>> > > in the knox install) for both the knoxsso.xml (instead of idp.xml)
>>> and
>>> > > sandbox.xml to reflect the same config would provide the same value
>>> and
>>> > be
>>> > > self contained without the need to keep the binaries up to date in
>>> the
>>> > demo
>>> > > with each release.
>>> > >
>>> > > There is probably value in a blog for early access to pac4j provider
>>> demo
>>> > > that could point to the demo.
>>> > >
>>> > >
>>> > > On Tue, Jan 19, 2016 at 9:04 AM, Jérôme LELEU <le...@gmail.com>
>>> wrote:
>>> > >
>>> > >> Should we add a link in the documentation to point to the demo?
>>> > >>
>>> > >> 2016-01-19 14:19 GMT+01:00 larry mccay <la...@gmail.com>:
>>> > >>
>>> > >> > That's great!
>>> > >> >
>>> > >> > On Tue, Jan 19, 2016 at 7:53 AM, Jérôme LELEU <le...@gmail.com>
>>> > wrote:
>>> > >> >
>>> > >> > > Hi,
>>> > >> > >
>>> > >> > > Following my own idea, here is a demo with the Knox / pac4j
>>> support:
>>> > >> > > https://github.com/pac4j/knox-pac4j-demo
>>> > >> > > Feel free to submit pull requests if you want me to amend it.
>>> > >> > >
>>> > >> > > What do you think?
>>> > >> > >
>>> > >> > > Thanks.
>>> > >> > > Best regards,
>>> > >> > > Jérôme
>>> > >> > >
>>> > >> > >
>>> > >> > > 2016-01-18 11:03 GMT+01:00 Jérôme LELEU <le...@gmail.com>:
>>> > >> > >
>>> > >> > > > Hi,
>>> > >> > > >
>>> > >> > > > It's great news!
>>> > >> > > >
>>> > >> > > > One more thing I'm thinking of: we always have a demo
>>> > corresponding
>>> > >> to
>>> > >> > a
>>> > >> > > > pac4j support. It would be great to have a knox-pac4j-demo and
>>> > >> > reference
>>> > >> > > it
>>> > >> > > > from the manual. I can handle it.
>>> > >> > > >
>>> > >> > > > Does it make sense?
>>> > >> > > >
>>> > >> > > > Thanks.
>>> > >> > > > Best regards,
>>> > >> > > > Jérôme
>>> > >> > > >
>>> > >> > > >
>>> > >> > > >
>>> > >> > > >
>>> > >> > > > 2016-01-17 6:37 GMT+01:00 larry mccay <lm...@apache.org>:
>>> > >> > > >
>>> > >> > > >> KNOX-641 and KNOX-642 have both been committed to master.
>>> > >> > > >>
>>> > >> > > >> There is a new docs book where you can check out the pac4j
>>> docs
>>> > >> > > available:
>>> > >> > > >>
>>> > >> > > >>
>>> > >> > >
>>> > >> >
>>> > >>
>>> >
>>> http://knox.apache.org/books/knox-0-8-0/user-guide.html#Pac4j+Provider+-+CAS+/+OAuth+/+SAML+/+OpenID+Connect
>>> > >> > > >>
>>> > >> > > >> I have some additional ideas for the docs that I will roll
>>> out in
>>> > >> the
>>> > >> > > next
>>> > >> > > >> few days.
>>> > >> > > >>
>>> > >> > > >> We need to discuss the identity assertion approach for 0.8.0.
>>> > >> > > >>
>>> > >> > > >> I think we are on track for 1/29 release date.
>>> > >> > > >>
>>> > >> > > >
>>> > >> > >
>>> > >> >
>>> > >>
>>> > >
>>> > >
>>> >
>>>
>>
>>
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
Question about the customParamKeyX params...
In doing some additional testing with the openid connect integration, it
was determined that the scopes provided by default didn't work properly for
all providers. Therefore, the following was added and it worked great.
<param>
<name>oidc.customParamKey1</name>
<value>scope</value>
</param>
<param>
<name>oidc.customParamValue1</name>
<value>openid</value>
</param>
However, it dawned on me that the currently implementation seems limited to
2 custom params with the key and values separated into different elements.
I am wondering whether a comma separated list of name=value pairs in a
single customParams element would make sense.
Additionally, I wonder whether "customParams" are even needed at all.
Couldn't any param that starts with oidc be targeted at the openid connect
client and likewise for other clients?
On Thu, Jan 21, 2016 at 9:02 AM, larry mccay <lm...@apache.org> wrote:
> That sounds perfect and actually the right way to keep pac4j and the knox
> pac4j provider aligned properly.
> I filed https://issues.apache.org/jira/browse/KNOX-655 for this effort.
>
> Thanks, Jérôme!
>
> --larry
>
> On Thu, Jan 21, 2016 at 4:38 AM, Jérôme LELEU <le...@gmail.com> wrote:
>
>> Hi,
>>
>> Interesting point.
>>
>> In pac4j, we have a callback controller which uses the client_name
>> parameter to finish the login process and a protection filter which
>> protects a resource and redirects the user to the identity provider for
>> login. Since pac4j 1.8, most libraries using it now accept a client_name
>> parameter in the protection filter as well to choose the authentication
>> mechanism to use if the user is not authenticated.
>>
>> With Knox, this feature (choosing the authentication mechanism with the
>> client_name parameter) is not available as this parameter is already used
>> to define if it's a callback or an access. This could be changed and we
>> could opt for a new convention, like a new pac4jCallback parameter to say
>> if it's a callback or not. And this way, you could choose on the fly which
>> authentication mechanism you want to use.
>>
>> Does it make sense?
>>
>> This is certainly not a big change: can you open a JIRA for that and I'll
>> handle it before the 0.8.0 release?
>>
>> Thanks.
>> Best regards,
>> Jérôme
>>
>>
>>
>>
>>
>> 2016-01-20 0:54 GMT+01:00 larry mccay <la...@gmail.com>:
>>
>> > Trying to figure out how to specify the client_name for a given
>> > authentication attempt when there are multiple mechanisms defined in the
>> > topology. What I had in mind was providing a couple links to login with:
>> >
>> > Login with Okta
>> > Login with Twitter
>> > Login with Google
>> >
>> > and at the end of each url I thought that I could just indicate
>> > &client_name=SAMLClient and that it would choose the SAML config in the
>> > topology.
>> > That doesn't seem to be how it works - either I am missing something or
>> we
>> > need a JIRA to fix something.
>> >
>> > Can you provide a little more insight into the client selection feature?
>> >
>> > Thanks!
>> >
>> >
>> > On Tue, Jan 19, 2016 at 10:11 AM, larry mccay <la...@gmail.com>
>> > wrote:
>> >
>> > > Hmmmm...
>> > >
>> > > I think that providing appropriate templates (see the templates
>> directory
>> > > in the knox install) for both the knoxsso.xml (instead of idp.xml) and
>> > > sandbox.xml to reflect the same config would provide the same value
>> and
>> > be
>> > > self contained without the need to keep the binaries up to date in the
>> > demo
>> > > with each release.
>> > >
>> > > There is probably value in a blog for early access to pac4j provider
>> demo
>> > > that could point to the demo.
>> > >
>> > >
>> > > On Tue, Jan 19, 2016 at 9:04 AM, Jérôme LELEU <le...@gmail.com>
>> wrote:
>> > >
>> > >> Should we add a link in the documentation to point to the demo?
>> > >>
>> > >> 2016-01-19 14:19 GMT+01:00 larry mccay <la...@gmail.com>:
>> > >>
>> > >> > That's great!
>> > >> >
>> > >> > On Tue, Jan 19, 2016 at 7:53 AM, Jérôme LELEU <le...@gmail.com>
>> > wrote:
>> > >> >
>> > >> > > Hi,
>> > >> > >
>> > >> > > Following my own idea, here is a demo with the Knox / pac4j
>> support:
>> > >> > > https://github.com/pac4j/knox-pac4j-demo
>> > >> > > Feel free to submit pull requests if you want me to amend it.
>> > >> > >
>> > >> > > What do you think?
>> > >> > >
>> > >> > > Thanks.
>> > >> > > Best regards,
>> > >> > > Jérôme
>> > >> > >
>> > >> > >
>> > >> > > 2016-01-18 11:03 GMT+01:00 Jérôme LELEU <le...@gmail.com>:
>> > >> > >
>> > >> > > > Hi,
>> > >> > > >
>> > >> > > > It's great news!
>> > >> > > >
>> > >> > > > One more thing I'm thinking of: we always have a demo
>> > corresponding
>> > >> to
>> > >> > a
>> > >> > > > pac4j support. It would be great to have a knox-pac4j-demo and
>> > >> > reference
>> > >> > > it
>> > >> > > > from the manual. I can handle it.
>> > >> > > >
>> > >> > > > Does it make sense?
>> > >> > > >
>> > >> > > > Thanks.
>> > >> > > > Best regards,
>> > >> > > > Jérôme
>> > >> > > >
>> > >> > > >
>> > >> > > >
>> > >> > > >
>> > >> > > > 2016-01-17 6:37 GMT+01:00 larry mccay <lm...@apache.org>:
>> > >> > > >
>> > >> > > >> KNOX-641 and KNOX-642 have both been committed to master.
>> > >> > > >>
>> > >> > > >> There is a new docs book where you can check out the pac4j
>> docs
>> > >> > > available:
>> > >> > > >>
>> > >> > > >>
>> > >> > >
>> > >> >
>> > >>
>> >
>> http://knox.apache.org/books/knox-0-8-0/user-guide.html#Pac4j+Provider+-+CAS+/+OAuth+/+SAML+/+OpenID+Connect
>> > >> > > >>
>> > >> > > >> I have some additional ideas for the docs that I will roll
>> out in
>> > >> the
>> > >> > > next
>> > >> > > >> few days.
>> > >> > > >>
>> > >> > > >> We need to discuss the identity assertion approach for 0.8.0.
>> > >> > > >>
>> > >> > > >> I think we are on track for 1/29 release date.
>> > >> > > >>
>> > >> > > >
>> > >> > >
>> > >> >
>> > >>
>> > >
>> > >
>> >
>>
>
>
Re: pac4j and Apache Knox
Posted by larry mccay <lm...@apache.org>.
Wonderful!
I will review it some time today.
Thanks, Jérôme!
On Mon, Jan 25, 2016 at 6:52 AM, Jérôme LELEU <le...@gmail.com> wrote:
> Hi,
>
> I just uploaded a patch for KNOX-655 and successfully tested it: using
> https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS, I'm
> redirected to my CAS server for login. I can force the authentication on
> Facebook using: https://127.0.0.1:8443/gateway/idp/api/v1/websso?
> *client_name=FacebookClient*&originalUrl=
> https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
>
> The documentation needs to be amended on two points:
>
> 1) about the clientName definition: if more than one client is defined, it
> must define the default pac4j client to use (the order of the properties
> defined in the configuration are not taken into account, it's the order in
> the pac4j PropertiesConfigFactory in fact); if you want to be able to use
> two clients (let's say a CasClient and a SAML2Client) and you want CAS to
> be the default authentication method, you need to define the clientName as
> follows: CasClient,SAML2Client
>
> 2) a warning must be written somewhere to say that a pac4jCallback=true
> parameter is added to the IDP endpoint url (Knox side) and thus, this must
> be maybe taken into account when defining it on the identity provider side.
>
> Thanks.
> Best regards,
> Jérôme
>
>
> 2016-01-21 15:02 GMT+01:00 larry mccay <lm...@apache.org>:
>
> > That sounds perfect and actually the right way to keep pac4j and the knox
> > pac4j provider aligned properly.
> > I filed https://issues.apache.org/jira/browse/KNOX-655 for this effort.
> >
> > Thanks, Jérôme!
> >
> > --larry
> >
> > On Thu, Jan 21, 2016 at 4:38 AM, Jérôme LELEU <le...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > Interesting point.
> > >
> > > In pac4j, we have a callback controller which uses the client_name
> > > parameter to finish the login process and a protection filter which
> > > protects a resource and redirects the user to the identity provider for
> > > login. Since pac4j 1.8, most libraries using it now accept a
> client_name
> > > parameter in the protection filter as well to choose the authentication
> > > mechanism to use if the user is not authenticated.
> > >
> > > With Knox, this feature (choosing the authentication mechanism with the
> > > client_name parameter) is not available as this parameter is already
> used
> > > to define if it's a callback or an access. This could be changed and we
> > > could opt for a new convention, like a new pac4jCallback parameter to
> say
> > > if it's a callback or not. And this way, you could choose on the fly
> > which
> > > authentication mechanism you want to use.
> > >
> > > Does it make sense?
> > >
> > > This is certainly not a big change: can you open a JIRA for that and
> I'll
> > > handle it before the 0.8.0 release?
> > >
> > > Thanks.
> > > Best regards,
> > > Jérôme
> > >
> > >
> > >
> > >
> > >
> > > 2016-01-20 0:54 GMT+01:00 larry mccay <la...@gmail.com>:
> > >
> > > > Trying to figure out how to specify the client_name for a given
> > > > authentication attempt when there are multiple mechanisms defined in
> > the
> > > > topology. What I had in mind was providing a couple links to login
> > with:
> > > >
> > > > Login with Okta
> > > > Login with Twitter
> > > > Login with Google
> > > >
> > > > and at the end of each url I thought that I could just indicate
> > > > &client_name=SAMLClient and that it would choose the SAML config in
> the
> > > > topology.
> > > > That doesn't seem to be how it works - either I am missing something
> or
> > > we
> > > > need a JIRA to fix something.
> > > >
> > > > Can you provide a little more insight into the client selection
> > feature?
> > > >
> > > > Thanks!
> > > >
> > > >
> > > > On Tue, Jan 19, 2016 at 10:11 AM, larry mccay <larry.mccay@gmail.com
> >
> > > > wrote:
> > > >
> > > > > Hmmmm...
> > > > >
> > > > > I think that providing appropriate templates (see the templates
> > > directory
> > > > > in the knox install) for both the knoxsso.xml (instead of idp.xml)
> > and
> > > > > sandbox.xml to reflect the same config would provide the same value
> > and
> > > > be
> > > > > self contained without the need to keep the binaries up to date in
> > the
> > > > demo
> > > > > with each release.
> > > > >
> > > > > There is probably value in a blog for early access to pac4j
> provider
> > > demo
> > > > > that could point to the demo.
> > > > >
> > > > >
> > > > > On Tue, Jan 19, 2016 at 9:04 AM, Jérôme LELEU <le...@gmail.com>
> > > wrote:
> > > > >
> > > > >> Should we add a link in the documentation to point to the demo?
> > > > >>
> > > > >> 2016-01-19 14:19 GMT+01:00 larry mccay <la...@gmail.com>:
> > > > >>
> > > > >> > That's great!
> > > > >> >
> > > > >> > On Tue, Jan 19, 2016 at 7:53 AM, Jérôme LELEU <leleuj@gmail.com
> >
> > > > wrote:
> > > > >> >
> > > > >> > > Hi,
> > > > >> > >
> > > > >> > > Following my own idea, here is a demo with the Knox / pac4j
> > > support:
> > > > >> > > https://github.com/pac4j/knox-pac4j-demo
> > > > >> > > Feel free to submit pull requests if you want me to amend it.
> > > > >> > >
> > > > >> > > What do you think?
> > > > >> > >
> > > > >> > > Thanks.
> > > > >> > > Best regards,
> > > > >> > > Jérôme
> > > > >> > >
> > > > >> > >
> > > > >> > > 2016-01-18 11:03 GMT+01:00 Jérôme LELEU <le...@gmail.com>:
> > > > >> > >
> > > > >> > > > Hi,
> > > > >> > > >
> > > > >> > > > It's great news!
> > > > >> > > >
> > > > >> > > > One more thing I'm thinking of: we always have a demo
> > > > corresponding
> > > > >> to
> > > > >> > a
> > > > >> > > > pac4j support. It would be great to have a knox-pac4j-demo
> and
> > > > >> > reference
> > > > >> > > it
> > > > >> > > > from the manual. I can handle it.
> > > > >> > > >
> > > > >> > > > Does it make sense?
> > > > >> > > >
> > > > >> > > > Thanks.
> > > > >> > > > Best regards,
> > > > >> > > > Jérôme
> > > > >> > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > 2016-01-17 6:37 GMT+01:00 larry mccay <lm...@apache.org>:
> > > > >> > > >
> > > > >> > > >> KNOX-641 and KNOX-642 have both been committed to master.
> > > > >> > > >>
> > > > >> > > >> There is a new docs book where you can check out the pac4j
> > docs
> > > > >> > > available:
> > > > >> > > >>
> > > > >> > > >>
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> http://knox.apache.org/books/knox-0-8-0/user-guide.html#Pac4j+Provider+-+CAS+/+OAuth+/+SAML+/+OpenID+Connect
> > > > >> > > >>
> > > > >> > > >> I have some additional ideas for the docs that I will roll
> > out
> > > in
> > > > >> the
> > > > >> > > next
> > > > >> > > >> few days.
> > > > >> > > >>
> > > > >> > > >> We need to discuss the identity assertion approach for
> 0.8.0.
> > > > >> > > >>
> > > > >> > > >> I think we are on track for 1/29 release date.
> > > > >> > > >>
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Hi,
I just uploaded a patch for KNOX-655 and successfully tested it: using
https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS, I'm
redirected to my CAS server for login. I can force the authentication on
Facebook using: https://127.0.0.1:8443/gateway/idp/api/v1/websso?
*client_name=FacebookClient*&originalUrl=
https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
The documentation needs to be amended on two points:
1) about the clientName definition: if more than one client is defined, it
must define the default pac4j client to use (the order of the properties
defined in the configuration are not taken into account, it's the order in
the pac4j PropertiesConfigFactory in fact); if you want to be able to use
two clients (let's say a CasClient and a SAML2Client) and you want CAS to
be the default authentication method, you need to define the clientName as
follows: CasClient,SAML2Client
2) a warning must be written somewhere to say that a pac4jCallback=true
parameter is added to the IDP endpoint url (Knox side) and thus, this must
be maybe taken into account when defining it on the identity provider side.
Thanks.
Best regards,
Jérôme
2016-01-21 15:02 GMT+01:00 larry mccay <lm...@apache.org>:
> That sounds perfect and actually the right way to keep pac4j and the knox
> pac4j provider aligned properly.
> I filed https://issues.apache.org/jira/browse/KNOX-655 for this effort.
>
> Thanks, Jérôme!
>
> --larry
>
> On Thu, Jan 21, 2016 at 4:38 AM, Jérôme LELEU <le...@gmail.com> wrote:
>
> > Hi,
> >
> > Interesting point.
> >
> > In pac4j, we have a callback controller which uses the client_name
> > parameter to finish the login process and a protection filter which
> > protects a resource and redirects the user to the identity provider for
> > login. Since pac4j 1.8, most libraries using it now accept a client_name
> > parameter in the protection filter as well to choose the authentication
> > mechanism to use if the user is not authenticated.
> >
> > With Knox, this feature (choosing the authentication mechanism with the
> > client_name parameter) is not available as this parameter is already used
> > to define if it's a callback or an access. This could be changed and we
> > could opt for a new convention, like a new pac4jCallback parameter to say
> > if it's a callback or not. And this way, you could choose on the fly
> which
> > authentication mechanism you want to use.
> >
> > Does it make sense?
> >
> > This is certainly not a big change: can you open a JIRA for that and I'll
> > handle it before the 0.8.0 release?
> >
> > Thanks.
> > Best regards,
> > Jérôme
> >
> >
> >
> >
> >
> > 2016-01-20 0:54 GMT+01:00 larry mccay <la...@gmail.com>:
> >
> > > Trying to figure out how to specify the client_name for a given
> > > authentication attempt when there are multiple mechanisms defined in
> the
> > > topology. What I had in mind was providing a couple links to login
> with:
> > >
> > > Login with Okta
> > > Login with Twitter
> > > Login with Google
> > >
> > > and at the end of each url I thought that I could just indicate
> > > &client_name=SAMLClient and that it would choose the SAML config in the
> > > topology.
> > > That doesn't seem to be how it works - either I am missing something or
> > we
> > > need a JIRA to fix something.
> > >
> > > Can you provide a little more insight into the client selection
> feature?
> > >
> > > Thanks!
> > >
> > >
> > > On Tue, Jan 19, 2016 at 10:11 AM, larry mccay <la...@gmail.com>
> > > wrote:
> > >
> > > > Hmmmm...
> > > >
> > > > I think that providing appropriate templates (see the templates
> > directory
> > > > in the knox install) for both the knoxsso.xml (instead of idp.xml)
> and
> > > > sandbox.xml to reflect the same config would provide the same value
> and
> > > be
> > > > self contained without the need to keep the binaries up to date in
> the
> > > demo
> > > > with each release.
> > > >
> > > > There is probably value in a blog for early access to pac4j provider
> > demo
> > > > that could point to the demo.
> > > >
> > > >
> > > > On Tue, Jan 19, 2016 at 9:04 AM, Jérôme LELEU <le...@gmail.com>
> > wrote:
> > > >
> > > >> Should we add a link in the documentation to point to the demo?
> > > >>
> > > >> 2016-01-19 14:19 GMT+01:00 larry mccay <la...@gmail.com>:
> > > >>
> > > >> > That's great!
> > > >> >
> > > >> > On Tue, Jan 19, 2016 at 7:53 AM, Jérôme LELEU <le...@gmail.com>
> > > wrote:
> > > >> >
> > > >> > > Hi,
> > > >> > >
> > > >> > > Following my own idea, here is a demo with the Knox / pac4j
> > support:
> > > >> > > https://github.com/pac4j/knox-pac4j-demo
> > > >> > > Feel free to submit pull requests if you want me to amend it.
> > > >> > >
> > > >> > > What do you think?
> > > >> > >
> > > >> > > Thanks.
> > > >> > > Best regards,
> > > >> > > Jérôme
> > > >> > >
> > > >> > >
> > > >> > > 2016-01-18 11:03 GMT+01:00 Jérôme LELEU <le...@gmail.com>:
> > > >> > >
> > > >> > > > Hi,
> > > >> > > >
> > > >> > > > It's great news!
> > > >> > > >
> > > >> > > > One more thing I'm thinking of: we always have a demo
> > > corresponding
> > > >> to
> > > >> > a
> > > >> > > > pac4j support. It would be great to have a knox-pac4j-demo and
> > > >> > reference
> > > >> > > it
> > > >> > > > from the manual. I can handle it.
> > > >> > > >
> > > >> > > > Does it make sense?
> > > >> > > >
> > > >> > > > Thanks.
> > > >> > > > Best regards,
> > > >> > > > Jérôme
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > > 2016-01-17 6:37 GMT+01:00 larry mccay <lm...@apache.org>:
> > > >> > > >
> > > >> > > >> KNOX-641 and KNOX-642 have both been committed to master.
> > > >> > > >>
> > > >> > > >> There is a new docs book where you can check out the pac4j
> docs
> > > >> > > available:
> > > >> > > >>
> > > >> > > >>
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> http://knox.apache.org/books/knox-0-8-0/user-guide.html#Pac4j+Provider+-+CAS+/+OAuth+/+SAML+/+OpenID+Connect
> > > >> > > >>
> > > >> > > >> I have some additional ideas for the docs that I will roll
> out
> > in
> > > >> the
> > > >> > > next
> > > >> > > >> few days.
> > > >> > > >>
> > > >> > > >> We need to discuss the identity assertion approach for 0.8.0.
> > > >> > > >>
> > > >> > > >> I think we are on track for 1/29 release date.
> > > >> > > >>
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by larry mccay <lm...@apache.org>.
That sounds perfect and actually the right way to keep pac4j and the knox
pac4j provider aligned properly.
I filed https://issues.apache.org/jira/browse/KNOX-655 for this effort.
Thanks, Jérôme!
--larry
On Thu, Jan 21, 2016 at 4:38 AM, Jérôme LELEU <le...@gmail.com> wrote:
> Hi,
>
> Interesting point.
>
> In pac4j, we have a callback controller which uses the client_name
> parameter to finish the login process and a protection filter which
> protects a resource and redirects the user to the identity provider for
> login. Since pac4j 1.8, most libraries using it now accept a client_name
> parameter in the protection filter as well to choose the authentication
> mechanism to use if the user is not authenticated.
>
> With Knox, this feature (choosing the authentication mechanism with the
> client_name parameter) is not available as this parameter is already used
> to define if it's a callback or an access. This could be changed and we
> could opt for a new convention, like a new pac4jCallback parameter to say
> if it's a callback or not. And this way, you could choose on the fly which
> authentication mechanism you want to use.
>
> Does it make sense?
>
> This is certainly not a big change: can you open a JIRA for that and I'll
> handle it before the 0.8.0 release?
>
> Thanks.
> Best regards,
> Jérôme
>
>
>
>
>
> 2016-01-20 0:54 GMT+01:00 larry mccay <la...@gmail.com>:
>
> > Trying to figure out how to specify the client_name for a given
> > authentication attempt when there are multiple mechanisms defined in the
> > topology. What I had in mind was providing a couple links to login with:
> >
> > Login with Okta
> > Login with Twitter
> > Login with Google
> >
> > and at the end of each url I thought that I could just indicate
> > &client_name=SAMLClient and that it would choose the SAML config in the
> > topology.
> > That doesn't seem to be how it works - either I am missing something or
> we
> > need a JIRA to fix something.
> >
> > Can you provide a little more insight into the client selection feature?
> >
> > Thanks!
> >
> >
> > On Tue, Jan 19, 2016 at 10:11 AM, larry mccay <la...@gmail.com>
> > wrote:
> >
> > > Hmmmm...
> > >
> > > I think that providing appropriate templates (see the templates
> directory
> > > in the knox install) for both the knoxsso.xml (instead of idp.xml) and
> > > sandbox.xml to reflect the same config would provide the same value and
> > be
> > > self contained without the need to keep the binaries up to date in the
> > demo
> > > with each release.
> > >
> > > There is probably value in a blog for early access to pac4j provider
> demo
> > > that could point to the demo.
> > >
> > >
> > > On Tue, Jan 19, 2016 at 9:04 AM, Jérôme LELEU <le...@gmail.com>
> wrote:
> > >
> > >> Should we add a link in the documentation to point to the demo?
> > >>
> > >> 2016-01-19 14:19 GMT+01:00 larry mccay <la...@gmail.com>:
> > >>
> > >> > That's great!
> > >> >
> > >> > On Tue, Jan 19, 2016 at 7:53 AM, Jérôme LELEU <le...@gmail.com>
> > wrote:
> > >> >
> > >> > > Hi,
> > >> > >
> > >> > > Following my own idea, here is a demo with the Knox / pac4j
> support:
> > >> > > https://github.com/pac4j/knox-pac4j-demo
> > >> > > Feel free to submit pull requests if you want me to amend it.
> > >> > >
> > >> > > What do you think?
> > >> > >
> > >> > > Thanks.
> > >> > > Best regards,
> > >> > > Jérôme
> > >> > >
> > >> > >
> > >> > > 2016-01-18 11:03 GMT+01:00 Jérôme LELEU <le...@gmail.com>:
> > >> > >
> > >> > > > Hi,
> > >> > > >
> > >> > > > It's great news!
> > >> > > >
> > >> > > > One more thing I'm thinking of: we always have a demo
> > corresponding
> > >> to
> > >> > a
> > >> > > > pac4j support. It would be great to have a knox-pac4j-demo and
> > >> > reference
> > >> > > it
> > >> > > > from the manual. I can handle it.
> > >> > > >
> > >> > > > Does it make sense?
> > >> > > >
> > >> > > > Thanks.
> > >> > > > Best regards,
> > >> > > > Jérôme
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > 2016-01-17 6:37 GMT+01:00 larry mccay <lm...@apache.org>:
> > >> > > >
> > >> > > >> KNOX-641 and KNOX-642 have both been committed to master.
> > >> > > >>
> > >> > > >> There is a new docs book where you can check out the pac4j docs
> > >> > > available:
> > >> > > >>
> > >> > > >>
> > >> > >
> > >> >
> > >>
> >
> http://knox.apache.org/books/knox-0-8-0/user-guide.html#Pac4j+Provider+-+CAS+/+OAuth+/+SAML+/+OpenID+Connect
> > >> > > >>
> > >> > > >> I have some additional ideas for the docs that I will roll out
> in
> > >> the
> > >> > > next
> > >> > > >> few days.
> > >> > > >>
> > >> > > >> We need to discuss the identity assertion approach for 0.8.0.
> > >> > > >>
> > >> > > >> I think we are on track for 1/29 release date.
> > >> > > >>
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Hi,
Interesting point.
In pac4j, we have a callback controller which uses the client_name
parameter to finish the login process and a protection filter which
protects a resource and redirects the user to the identity provider for
login. Since pac4j 1.8, most libraries using it now accept a client_name
parameter in the protection filter as well to choose the authentication
mechanism to use if the user is not authenticated.
With Knox, this feature (choosing the authentication mechanism with the
client_name parameter) is not available as this parameter is already used
to define if it's a callback or an access. This could be changed and we
could opt for a new convention, like a new pac4jCallback parameter to say
if it's a callback or not. And this way, you could choose on the fly which
authentication mechanism you want to use.
Does it make sense?
This is certainly not a big change: can you open a JIRA for that and I'll
handle it before the 0.8.0 release?
Thanks.
Best regards,
Jérôme
2016-01-20 0:54 GMT+01:00 larry mccay <la...@gmail.com>:
> Trying to figure out how to specify the client_name for a given
> authentication attempt when there are multiple mechanisms defined in the
> topology. What I had in mind was providing a couple links to login with:
>
> Login with Okta
> Login with Twitter
> Login with Google
>
> and at the end of each url I thought that I could just indicate
> &client_name=SAMLClient and that it would choose the SAML config in the
> topology.
> That doesn't seem to be how it works - either I am missing something or we
> need a JIRA to fix something.
>
> Can you provide a little more insight into the client selection feature?
>
> Thanks!
>
>
> On Tue, Jan 19, 2016 at 10:11 AM, larry mccay <la...@gmail.com>
> wrote:
>
> > Hmmmm...
> >
> > I think that providing appropriate templates (see the templates directory
> > in the knox install) for both the knoxsso.xml (instead of idp.xml) and
> > sandbox.xml to reflect the same config would provide the same value and
> be
> > self contained without the need to keep the binaries up to date in the
> demo
> > with each release.
> >
> > There is probably value in a blog for early access to pac4j provider demo
> > that could point to the demo.
> >
> >
> > On Tue, Jan 19, 2016 at 9:04 AM, Jérôme LELEU <le...@gmail.com> wrote:
> >
> >> Should we add a link in the documentation to point to the demo?
> >>
> >> 2016-01-19 14:19 GMT+01:00 larry mccay <la...@gmail.com>:
> >>
> >> > That's great!
> >> >
> >> > On Tue, Jan 19, 2016 at 7:53 AM, Jérôme LELEU <le...@gmail.com>
> wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > > Following my own idea, here is a demo with the Knox / pac4j support:
> >> > > https://github.com/pac4j/knox-pac4j-demo
> >> > > Feel free to submit pull requests if you want me to amend it.
> >> > >
> >> > > What do you think?
> >> > >
> >> > > Thanks.
> >> > > Best regards,
> >> > > Jérôme
> >> > >
> >> > >
> >> > > 2016-01-18 11:03 GMT+01:00 Jérôme LELEU <le...@gmail.com>:
> >> > >
> >> > > > Hi,
> >> > > >
> >> > > > It's great news!
> >> > > >
> >> > > > One more thing I'm thinking of: we always have a demo
> corresponding
> >> to
> >> > a
> >> > > > pac4j support. It would be great to have a knox-pac4j-demo and
> >> > reference
> >> > > it
> >> > > > from the manual. I can handle it.
> >> > > >
> >> > > > Does it make sense?
> >> > > >
> >> > > > Thanks.
> >> > > > Best regards,
> >> > > > Jérôme
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > 2016-01-17 6:37 GMT+01:00 larry mccay <lm...@apache.org>:
> >> > > >
> >> > > >> KNOX-641 and KNOX-642 have both been committed to master.
> >> > > >>
> >> > > >> There is a new docs book where you can check out the pac4j docs
> >> > > available:
> >> > > >>
> >> > > >>
> >> > >
> >> >
> >>
> http://knox.apache.org/books/knox-0-8-0/user-guide.html#Pac4j+Provider+-+CAS+/+OAuth+/+SAML+/+OpenID+Connect
> >> > > >>
> >> > > >> I have some additional ideas for the docs that I will roll out in
> >> the
> >> > > next
> >> > > >> few days.
> >> > > >>
> >> > > >> We need to discuss the identity assertion approach for 0.8.0.
> >> > > >>
> >> > > >> I think we are on track for 1/29 release date.
> >> > > >>
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
Trying to figure out how to specify the client_name for a given
authentication attempt when there are multiple mechanisms defined in the
topology. What I had in mind was providing a couple links to login with:
Login with Okta
Login with Twitter
Login with Google
and at the end of each url I thought that I could just indicate
&client_name=SAMLClient and that it would choose the SAML config in the
topology.
That doesn't seem to be how it works - either I am missing something or we
need a JIRA to fix something.
Can you provide a little more insight into the client selection feature?
Thanks!
On Tue, Jan 19, 2016 at 10:11 AM, larry mccay <la...@gmail.com> wrote:
> Hmmmm...
>
> I think that providing appropriate templates (see the templates directory
> in the knox install) for both the knoxsso.xml (instead of idp.xml) and
> sandbox.xml to reflect the same config would provide the same value and be
> self contained without the need to keep the binaries up to date in the demo
> with each release.
>
> There is probably value in a blog for early access to pac4j provider demo
> that could point to the demo.
>
>
> On Tue, Jan 19, 2016 at 9:04 AM, Jérôme LELEU <le...@gmail.com> wrote:
>
>> Should we add a link in the documentation to point to the demo?
>>
>> 2016-01-19 14:19 GMT+01:00 larry mccay <la...@gmail.com>:
>>
>> > That's great!
>> >
>> > On Tue, Jan 19, 2016 at 7:53 AM, Jérôme LELEU <le...@gmail.com> wrote:
>> >
>> > > Hi,
>> > >
>> > > Following my own idea, here is a demo with the Knox / pac4j support:
>> > > https://github.com/pac4j/knox-pac4j-demo
>> > > Feel free to submit pull requests if you want me to amend it.
>> > >
>> > > What do you think?
>> > >
>> > > Thanks.
>> > > Best regards,
>> > > Jérôme
>> > >
>> > >
>> > > 2016-01-18 11:03 GMT+01:00 Jérôme LELEU <le...@gmail.com>:
>> > >
>> > > > Hi,
>> > > >
>> > > > It's great news!
>> > > >
>> > > > One more thing I'm thinking of: we always have a demo corresponding
>> to
>> > a
>> > > > pac4j support. It would be great to have a knox-pac4j-demo and
>> > reference
>> > > it
>> > > > from the manual. I can handle it.
>> > > >
>> > > > Does it make sense?
>> > > >
>> > > > Thanks.
>> > > > Best regards,
>> > > > Jérôme
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > 2016-01-17 6:37 GMT+01:00 larry mccay <lm...@apache.org>:
>> > > >
>> > > >> KNOX-641 and KNOX-642 have both been committed to master.
>> > > >>
>> > > >> There is a new docs book where you can check out the pac4j docs
>> > > available:
>> > > >>
>> > > >>
>> > >
>> >
>> http://knox.apache.org/books/knox-0-8-0/user-guide.html#Pac4j+Provider+-+CAS+/+OAuth+/+SAML+/+OpenID+Connect
>> > > >>
>> > > >> I have some additional ideas for the docs that I will roll out in
>> the
>> > > next
>> > > >> few days.
>> > > >>
>> > > >> We need to discuss the identity assertion approach for 0.8.0.
>> > > >>
>> > > >> I think we are on track for 1/29 release date.
>> > > >>
>> > > >
>> > >
>> >
>>
>
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Hi,
Regarding the legal stuffs, it's an issue until I upgrade the demo to an
official release. After that, I will only use official releases. At worst,
the demo will be out of date.
We can keep the same link: that's what I do for demos otherwise it's a
nightmare. Previous version x is simply moved in the x branch.
Thanks.
Best regards,
Jérôme
2016-01-21 15:11 GMT+01:00 larry mccay <la...@gmail.com>:
> A build from master is not an official Apache release and there are
> specific rules for referencing release distributions and artifacts.
> Unfortunately, the language that I have found isn't clear enough for me to
> determine what if any violation exists there.
>
> I don't want to introduce a link in docs that will becomes stale for each
> release and require a refresh of the external demo repo that may require
> changes to previous versions of the docs, etc. When we release 0.9.0 - the
> 0.8.0 release will be obsolete. Can we assume that there will be a new one
> for 0.9.0 and have to change the link to point to that? Will the repo that
> was previously 0.8.0 be refreshed to 0.9.0 and subsequently require the
> link to be removed from the 0.8.0 docs?
>
> All of that said, I do see value in pac4j having this quick start demo.
>
> My suggestion is that the link in the Knox docs that point to detailed
> pac4j docs have a prominent pointer to the demo.
> The repo and your docs will be more easily kept in sync than cross project
> dependencies and new releases.
>
> On Thu, Jan 21, 2016 at 4:53 AM, Jérôme LELEU <le...@gmail.com> wrote:
>
> > OK. I still think that the demo is valuable for a quick startup, but
> above
> > all, it means that I must re-create the demo from the Apache release of
> > Knox 0.8.0 as soon as it will be available...
> >
> > I'm not sure to understand what is the problem with the current master in
> > terms of licensing, it's under the Apache license as well, isn't it?
> >
> >
> > 2016-01-20 13:46 GMT+01:00 larry mccay <lm...@apache.org>:
> >
> > > You make an interesting point about usability here.
> > >
> > > At the same time, it highlights the fact that the installation would
> not
> > be
> > > from an Apache distribution channel and I would be concerned about
> folks
> > > checking out the demo and once it was working not picking up an
> official
> > > release.
> > >
> > > The current demo is based on your build from the master branch - I
> > assume.
> > > This isn't an official Apache release which is may be problematic
> > > license-wise.
> > >
> > > The steps that you describe for trying it out are necessary only
> because
> > it
> > > requires a build from master - until 0.8.0 is released. At which time,
> > the
> > > user would download an official Apache release of Knox 0.8.0, unzip it,
> > > copy the templates into place and fire it up.
> > >
> > > It might be interesting to consider a script for copying the templates
> > for
> > > various configurations into place as a usability improvement.
> > >
> > > I will try and find some Apache language about non-Apache distributions
> > for
> > > such a purpose and see whether it is legal to reference them.
> > > In the meantime, I would be interested in others' opinions on the
> matter.
> > >
> > >
> > > On Wed, Jan 20, 2016 at 5:11 AM, Jérôme LELEU <le...@gmail.com>
> wrote:
> > >
> > > > Hi,
> > > >
> > > > You're right: maintaining the demos is a work in itself and we could
> > > > (should) put samples in the templates directory.
> > > >
> > > > Though, I think the demo is valuable to promote Knox: let's say
> someone
> > > as
> > > > an Hadoop installation and want to secure it: how can he try Knox?
> > > Checkout
> > > > the source, build it, copy the templates at the right place: it might
> > be
> > > > discouraging and complicated for a beginner. While with the demo:
> > > checkout,
> > > > copy the launch command and test...
> > > >
> > > > In any case, it's in the pac4j organization.
> > > >
> > > > Thanks.
> > > > Best regards,
> > > > Jérôme
> > > >
> > > >
> > > > 2016-01-19 16:11 GMT+01:00 larry mccay <la...@gmail.com>:
> > > >
> > > > > Hmmmm...
> > > > >
> > > > > I think that providing appropriate templates (see the templates
> > > directory
> > > > > in the knox install) for both the knoxsso.xml (instead of idp.xml)
> > and
> > > > > sandbox.xml to reflect the same config would provide the same value
> > and
> > > > be
> > > > > self contained without the need to keep the binaries up to date in
> > the
> > > > demo
> > > > > with each release.
> > > > >
> > > > > There is probably value in a blog for early access to pac4j
> provider
> > > demo
> > > > > that could point to the demo.
> > > > >
> > > > >
> > > > > On Tue, Jan 19, 2016 at 9:04 AM, Jérôme LELEU <le...@gmail.com>
> > > wrote:
> > > > >
> > > > > > Should we add a link in the documentation to point to the demo?
> > > > > >
> > > > > > 2016-01-19 14:19 GMT+01:00 larry mccay <la...@gmail.com>:
> > > > > >
> > > > > > > That's great!
> > > > > > >
> > > > > > > On Tue, Jan 19, 2016 at 7:53 AM, Jérôme LELEU <
> leleuj@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > Following my own idea, here is a demo with the Knox / pac4j
> > > > support:
> > > > > > > > https://github.com/pac4j/knox-pac4j-demo
> > > > > > > > Feel free to submit pull requests if you want me to amend it.
> > > > > > > >
> > > > > > > > What do you think?
> > > > > > > >
> > > > > > > > Thanks.
> > > > > > > > Best regards,
> > > > > > > > Jérôme
> > > > > > > >
> > > > > > > >
> > > > > > > > 2016-01-18 11:03 GMT+01:00 Jérôme LELEU <le...@gmail.com>:
> > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > It's great news!
> > > > > > > > >
> > > > > > > > > One more thing I'm thinking of: we always have a demo
> > > > corresponding
> > > > > > to
> > > > > > > a
> > > > > > > > > pac4j support. It would be great to have a knox-pac4j-demo
> > and
> > > > > > > reference
> > > > > > > > it
> > > > > > > > > from the manual. I can handle it.
> > > > > > > > >
> > > > > > > > > Does it make sense?
> > > > > > > > >
> > > > > > > > > Thanks.
> > > > > > > > > Best regards,
> > > > > > > > > Jérôme
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 2016-01-17 6:37 GMT+01:00 larry mccay <lm...@apache.org>:
> > > > > > > > >
> > > > > > > > >> KNOX-641 and KNOX-642 have both been committed to master.
> > > > > > > > >>
> > > > > > > > >> There is a new docs book where you can check out the pac4j
> > > docs
> > > > > > > > available:
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://knox.apache.org/books/knox-0-8-0/user-guide.html#Pac4j+Provider+-+CAS+/+OAuth+/+SAML+/+OpenID+Connect
> > > > > > > > >>
> > > > > > > > >> I have some additional ideas for the docs that I will roll
> > out
> > > > in
> > > > > > the
> > > > > > > > next
> > > > > > > > >> few days.
> > > > > > > > >>
> > > > > > > > >> We need to discuss the identity assertion approach for
> > 0.8.0.
> > > > > > > > >>
> > > > > > > > >> I think we are on track for 1/29 release date.
> > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
A build from master is not an official Apache release and there are
specific rules for referencing release distributions and artifacts.
Unfortunately, the language that I have found isn't clear enough for me to
determine what if any violation exists there.
I don't want to introduce a link in docs that will becomes stale for each
release and require a refresh of the external demo repo that may require
changes to previous versions of the docs, etc. When we release 0.9.0 - the
0.8.0 release will be obsolete. Can we assume that there will be a new one
for 0.9.0 and have to change the link to point to that? Will the repo that
was previously 0.8.0 be refreshed to 0.9.0 and subsequently require the
link to be removed from the 0.8.0 docs?
All of that said, I do see value in pac4j having this quick start demo.
My suggestion is that the link in the Knox docs that point to detailed
pac4j docs have a prominent pointer to the demo.
The repo and your docs will be more easily kept in sync than cross project
dependencies and new releases.
On Thu, Jan 21, 2016 at 4:53 AM, Jérôme LELEU <le...@gmail.com> wrote:
> OK. I still think that the demo is valuable for a quick startup, but above
> all, it means that I must re-create the demo from the Apache release of
> Knox 0.8.0 as soon as it will be available...
>
> I'm not sure to understand what is the problem with the current master in
> terms of licensing, it's under the Apache license as well, isn't it?
>
>
> 2016-01-20 13:46 GMT+01:00 larry mccay <lm...@apache.org>:
>
> > You make an interesting point about usability here.
> >
> > At the same time, it highlights the fact that the installation would not
> be
> > from an Apache distribution channel and I would be concerned about folks
> > checking out the demo and once it was working not picking up an official
> > release.
> >
> > The current demo is based on your build from the master branch - I
> assume.
> > This isn't an official Apache release which is may be problematic
> > license-wise.
> >
> > The steps that you describe for trying it out are necessary only because
> it
> > requires a build from master - until 0.8.0 is released. At which time,
> the
> > user would download an official Apache release of Knox 0.8.0, unzip it,
> > copy the templates into place and fire it up.
> >
> > It might be interesting to consider a script for copying the templates
> for
> > various configurations into place as a usability improvement.
> >
> > I will try and find some Apache language about non-Apache distributions
> for
> > such a purpose and see whether it is legal to reference them.
> > In the meantime, I would be interested in others' opinions on the matter.
> >
> >
> > On Wed, Jan 20, 2016 at 5:11 AM, Jérôme LELEU <le...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > You're right: maintaining the demos is a work in itself and we could
> > > (should) put samples in the templates directory.
> > >
> > > Though, I think the demo is valuable to promote Knox: let's say someone
> > as
> > > an Hadoop installation and want to secure it: how can he try Knox?
> > Checkout
> > > the source, build it, copy the templates at the right place: it might
> be
> > > discouraging and complicated for a beginner. While with the demo:
> > checkout,
> > > copy the launch command and test...
> > >
> > > In any case, it's in the pac4j organization.
> > >
> > > Thanks.
> > > Best regards,
> > > Jérôme
> > >
> > >
> > > 2016-01-19 16:11 GMT+01:00 larry mccay <la...@gmail.com>:
> > >
> > > > Hmmmm...
> > > >
> > > > I think that providing appropriate templates (see the templates
> > directory
> > > > in the knox install) for both the knoxsso.xml (instead of idp.xml)
> and
> > > > sandbox.xml to reflect the same config would provide the same value
> and
> > > be
> > > > self contained without the need to keep the binaries up to date in
> the
> > > demo
> > > > with each release.
> > > >
> > > > There is probably value in a blog for early access to pac4j provider
> > demo
> > > > that could point to the demo.
> > > >
> > > >
> > > > On Tue, Jan 19, 2016 at 9:04 AM, Jérôme LELEU <le...@gmail.com>
> > wrote:
> > > >
> > > > > Should we add a link in the documentation to point to the demo?
> > > > >
> > > > > 2016-01-19 14:19 GMT+01:00 larry mccay <la...@gmail.com>:
> > > > >
> > > > > > That's great!
> > > > > >
> > > > > > On Tue, Jan 19, 2016 at 7:53 AM, Jérôme LELEU <le...@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > Following my own idea, here is a demo with the Knox / pac4j
> > > support:
> > > > > > > https://github.com/pac4j/knox-pac4j-demo
> > > > > > > Feel free to submit pull requests if you want me to amend it.
> > > > > > >
> > > > > > > What do you think?
> > > > > > >
> > > > > > > Thanks.
> > > > > > > Best regards,
> > > > > > > Jérôme
> > > > > > >
> > > > > > >
> > > > > > > 2016-01-18 11:03 GMT+01:00 Jérôme LELEU <le...@gmail.com>:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > It's great news!
> > > > > > > >
> > > > > > > > One more thing I'm thinking of: we always have a demo
> > > corresponding
> > > > > to
> > > > > > a
> > > > > > > > pac4j support. It would be great to have a knox-pac4j-demo
> and
> > > > > > reference
> > > > > > > it
> > > > > > > > from the manual. I can handle it.
> > > > > > > >
> > > > > > > > Does it make sense?
> > > > > > > >
> > > > > > > > Thanks.
> > > > > > > > Best regards,
> > > > > > > > Jérôme
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 2016-01-17 6:37 GMT+01:00 larry mccay <lm...@apache.org>:
> > > > > > > >
> > > > > > > >> KNOX-641 and KNOX-642 have both been committed to master.
> > > > > > > >>
> > > > > > > >> There is a new docs book where you can check out the pac4j
> > docs
> > > > > > > available:
> > > > > > > >>
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://knox.apache.org/books/knox-0-8-0/user-guide.html#Pac4j+Provider+-+CAS+/+OAuth+/+SAML+/+OpenID+Connect
> > > > > > > >>
> > > > > > > >> I have some additional ideas for the docs that I will roll
> out
> > > in
> > > > > the
> > > > > > > next
> > > > > > > >> few days.
> > > > > > > >>
> > > > > > > >> We need to discuss the identity assertion approach for
> 0.8.0.
> > > > > > > >>
> > > > > > > >> I think we are on track for 1/29 release date.
> > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
OK. I still think that the demo is valuable for a quick startup, but above
all, it means that I must re-create the demo from the Apache release of
Knox 0.8.0 as soon as it will be available...
I'm not sure to understand what is the problem with the current master in
terms of licensing, it's under the Apache license as well, isn't it?
2016-01-20 13:46 GMT+01:00 larry mccay <lm...@apache.org>:
> You make an interesting point about usability here.
>
> At the same time, it highlights the fact that the installation would not be
> from an Apache distribution channel and I would be concerned about folks
> checking out the demo and once it was working not picking up an official
> release.
>
> The current demo is based on your build from the master branch - I assume.
> This isn't an official Apache release which is may be problematic
> license-wise.
>
> The steps that you describe for trying it out are necessary only because it
> requires a build from master - until 0.8.0 is released. At which time, the
> user would download an official Apache release of Knox 0.8.0, unzip it,
> copy the templates into place and fire it up.
>
> It might be interesting to consider a script for copying the templates for
> various configurations into place as a usability improvement.
>
> I will try and find some Apache language about non-Apache distributions for
> such a purpose and see whether it is legal to reference them.
> In the meantime, I would be interested in others' opinions on the matter.
>
>
> On Wed, Jan 20, 2016 at 5:11 AM, Jérôme LELEU <le...@gmail.com> wrote:
>
> > Hi,
> >
> > You're right: maintaining the demos is a work in itself and we could
> > (should) put samples in the templates directory.
> >
> > Though, I think the demo is valuable to promote Knox: let's say someone
> as
> > an Hadoop installation and want to secure it: how can he try Knox?
> Checkout
> > the source, build it, copy the templates at the right place: it might be
> > discouraging and complicated for a beginner. While with the demo:
> checkout,
> > copy the launch command and test...
> >
> > In any case, it's in the pac4j organization.
> >
> > Thanks.
> > Best regards,
> > Jérôme
> >
> >
> > 2016-01-19 16:11 GMT+01:00 larry mccay <la...@gmail.com>:
> >
> > > Hmmmm...
> > >
> > > I think that providing appropriate templates (see the templates
> directory
> > > in the knox install) for both the knoxsso.xml (instead of idp.xml) and
> > > sandbox.xml to reflect the same config would provide the same value and
> > be
> > > self contained without the need to keep the binaries up to date in the
> > demo
> > > with each release.
> > >
> > > There is probably value in a blog for early access to pac4j provider
> demo
> > > that could point to the demo.
> > >
> > >
> > > On Tue, Jan 19, 2016 at 9:04 AM, Jérôme LELEU <le...@gmail.com>
> wrote:
> > >
> > > > Should we add a link in the documentation to point to the demo?
> > > >
> > > > 2016-01-19 14:19 GMT+01:00 larry mccay <la...@gmail.com>:
> > > >
> > > > > That's great!
> > > > >
> > > > > On Tue, Jan 19, 2016 at 7:53 AM, Jérôme LELEU <le...@gmail.com>
> > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Following my own idea, here is a demo with the Knox / pac4j
> > support:
> > > > > > https://github.com/pac4j/knox-pac4j-demo
> > > > > > Feel free to submit pull requests if you want me to amend it.
> > > > > >
> > > > > > What do you think?
> > > > > >
> > > > > > Thanks.
> > > > > > Best regards,
> > > > > > Jérôme
> > > > > >
> > > > > >
> > > > > > 2016-01-18 11:03 GMT+01:00 Jérôme LELEU <le...@gmail.com>:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > It's great news!
> > > > > > >
> > > > > > > One more thing I'm thinking of: we always have a demo
> > corresponding
> > > > to
> > > > > a
> > > > > > > pac4j support. It would be great to have a knox-pac4j-demo and
> > > > > reference
> > > > > > it
> > > > > > > from the manual. I can handle it.
> > > > > > >
> > > > > > > Does it make sense?
> > > > > > >
> > > > > > > Thanks.
> > > > > > > Best regards,
> > > > > > > Jérôme
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 2016-01-17 6:37 GMT+01:00 larry mccay <lm...@apache.org>:
> > > > > > >
> > > > > > >> KNOX-641 and KNOX-642 have both been committed to master.
> > > > > > >>
> > > > > > >> There is a new docs book where you can check out the pac4j
> docs
> > > > > > available:
> > > > > > >>
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> http://knox.apache.org/books/knox-0-8-0/user-guide.html#Pac4j+Provider+-+CAS+/+OAuth+/+SAML+/+OpenID+Connect
> > > > > > >>
> > > > > > >> I have some additional ideas for the docs that I will roll out
> > in
> > > > the
> > > > > > next
> > > > > > >> few days.
> > > > > > >>
> > > > > > >> We need to discuss the identity assertion approach for 0.8.0.
> > > > > > >>
> > > > > > >> I think we are on track for 1/29 release date.
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by larry mccay <lm...@apache.org>.
You make an interesting point about usability here.
At the same time, it highlights the fact that the installation would not be
from an Apache distribution channel and I would be concerned about folks
checking out the demo and once it was working not picking up an official
release.
The current demo is based on your build from the master branch - I assume.
This isn't an official Apache release which is may be problematic
license-wise.
The steps that you describe for trying it out are necessary only because it
requires a build from master - until 0.8.0 is released. At which time, the
user would download an official Apache release of Knox 0.8.0, unzip it,
copy the templates into place and fire it up.
It might be interesting to consider a script for copying the templates for
various configurations into place as a usability improvement.
I will try and find some Apache language about non-Apache distributions for
such a purpose and see whether it is legal to reference them.
In the meantime, I would be interested in others' opinions on the matter.
On Wed, Jan 20, 2016 at 5:11 AM, Jérôme LELEU <le...@gmail.com> wrote:
> Hi,
>
> You're right: maintaining the demos is a work in itself and we could
> (should) put samples in the templates directory.
>
> Though, I think the demo is valuable to promote Knox: let's say someone as
> an Hadoop installation and want to secure it: how can he try Knox? Checkout
> the source, build it, copy the templates at the right place: it might be
> discouraging and complicated for a beginner. While with the demo: checkout,
> copy the launch command and test...
>
> In any case, it's in the pac4j organization.
>
> Thanks.
> Best regards,
> Jérôme
>
>
> 2016-01-19 16:11 GMT+01:00 larry mccay <la...@gmail.com>:
>
> > Hmmmm...
> >
> > I think that providing appropriate templates (see the templates directory
> > in the knox install) for both the knoxsso.xml (instead of idp.xml) and
> > sandbox.xml to reflect the same config would provide the same value and
> be
> > self contained without the need to keep the binaries up to date in the
> demo
> > with each release.
> >
> > There is probably value in a blog for early access to pac4j provider demo
> > that could point to the demo.
> >
> >
> > On Tue, Jan 19, 2016 at 9:04 AM, Jérôme LELEU <le...@gmail.com> wrote:
> >
> > > Should we add a link in the documentation to point to the demo?
> > >
> > > 2016-01-19 14:19 GMT+01:00 larry mccay <la...@gmail.com>:
> > >
> > > > That's great!
> > > >
> > > > On Tue, Jan 19, 2016 at 7:53 AM, Jérôme LELEU <le...@gmail.com>
> > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Following my own idea, here is a demo with the Knox / pac4j
> support:
> > > > > https://github.com/pac4j/knox-pac4j-demo
> > > > > Feel free to submit pull requests if you want me to amend it.
> > > > >
> > > > > What do you think?
> > > > >
> > > > > Thanks.
> > > > > Best regards,
> > > > > Jérôme
> > > > >
> > > > >
> > > > > 2016-01-18 11:03 GMT+01:00 Jérôme LELEU <le...@gmail.com>:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > It's great news!
> > > > > >
> > > > > > One more thing I'm thinking of: we always have a demo
> corresponding
> > > to
> > > > a
> > > > > > pac4j support. It would be great to have a knox-pac4j-demo and
> > > > reference
> > > > > it
> > > > > > from the manual. I can handle it.
> > > > > >
> > > > > > Does it make sense?
> > > > > >
> > > > > > Thanks.
> > > > > > Best regards,
> > > > > > Jérôme
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2016-01-17 6:37 GMT+01:00 larry mccay <lm...@apache.org>:
> > > > > >
> > > > > >> KNOX-641 and KNOX-642 have both been committed to master.
> > > > > >>
> > > > > >> There is a new docs book where you can check out the pac4j docs
> > > > > available:
> > > > > >>
> > > > > >>
> > > > >
> > > >
> > >
> >
> http://knox.apache.org/books/knox-0-8-0/user-guide.html#Pac4j+Provider+-+CAS+/+OAuth+/+SAML+/+OpenID+Connect
> > > > > >>
> > > > > >> I have some additional ideas for the docs that I will roll out
> in
> > > the
> > > > > next
> > > > > >> few days.
> > > > > >>
> > > > > >> We need to discuss the identity assertion approach for 0.8.0.
> > > > > >>
> > > > > >> I think we are on track for 1/29 release date.
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Hi,
You're right: maintaining the demos is a work in itself and we could
(should) put samples in the templates directory.
Though, I think the demo is valuable to promote Knox: let's say someone as
an Hadoop installation and want to secure it: how can he try Knox? Checkout
the source, build it, copy the templates at the right place: it might be
discouraging and complicated for a beginner. While with the demo: checkout,
copy the launch command and test...
In any case, it's in the pac4j organization.
Thanks.
Best regards,
Jérôme
2016-01-19 16:11 GMT+01:00 larry mccay <la...@gmail.com>:
> Hmmmm...
>
> I think that providing appropriate templates (see the templates directory
> in the knox install) for both the knoxsso.xml (instead of idp.xml) and
> sandbox.xml to reflect the same config would provide the same value and be
> self contained without the need to keep the binaries up to date in the demo
> with each release.
>
> There is probably value in a blog for early access to pac4j provider demo
> that could point to the demo.
>
>
> On Tue, Jan 19, 2016 at 9:04 AM, Jérôme LELEU <le...@gmail.com> wrote:
>
> > Should we add a link in the documentation to point to the demo?
> >
> > 2016-01-19 14:19 GMT+01:00 larry mccay <la...@gmail.com>:
> >
> > > That's great!
> > >
> > > On Tue, Jan 19, 2016 at 7:53 AM, Jérôme LELEU <le...@gmail.com>
> wrote:
> > >
> > > > Hi,
> > > >
> > > > Following my own idea, here is a demo with the Knox / pac4j support:
> > > > https://github.com/pac4j/knox-pac4j-demo
> > > > Feel free to submit pull requests if you want me to amend it.
> > > >
> > > > What do you think?
> > > >
> > > > Thanks.
> > > > Best regards,
> > > > Jérôme
> > > >
> > > >
> > > > 2016-01-18 11:03 GMT+01:00 Jérôme LELEU <le...@gmail.com>:
> > > >
> > > > > Hi,
> > > > >
> > > > > It's great news!
> > > > >
> > > > > One more thing I'm thinking of: we always have a demo corresponding
> > to
> > > a
> > > > > pac4j support. It would be great to have a knox-pac4j-demo and
> > > reference
> > > > it
> > > > > from the manual. I can handle it.
> > > > >
> > > > > Does it make sense?
> > > > >
> > > > > Thanks.
> > > > > Best regards,
> > > > > Jérôme
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 2016-01-17 6:37 GMT+01:00 larry mccay <lm...@apache.org>:
> > > > >
> > > > >> KNOX-641 and KNOX-642 have both been committed to master.
> > > > >>
> > > > >> There is a new docs book where you can check out the pac4j docs
> > > > available:
> > > > >>
> > > > >>
> > > >
> > >
> >
> http://knox.apache.org/books/knox-0-8-0/user-guide.html#Pac4j+Provider+-+CAS+/+OAuth+/+SAML+/+OpenID+Connect
> > > > >>
> > > > >> I have some additional ideas for the docs that I will roll out in
> > the
> > > > next
> > > > >> few days.
> > > > >>
> > > > >> We need to discuss the identity assertion approach for 0.8.0.
> > > > >>
> > > > >> I think we are on track for 1/29 release date.
> > > > >>
> > > > >
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
Hmmmm...
I think that providing appropriate templates (see the templates directory
in the knox install) for both the knoxsso.xml (instead of idp.xml) and
sandbox.xml to reflect the same config would provide the same value and be
self contained without the need to keep the binaries up to date in the demo
with each release.
There is probably value in a blog for early access to pac4j provider demo
that could point to the demo.
On Tue, Jan 19, 2016 at 9:04 AM, Jérôme LELEU <le...@gmail.com> wrote:
> Should we add a link in the documentation to point to the demo?
>
> 2016-01-19 14:19 GMT+01:00 larry mccay <la...@gmail.com>:
>
> > That's great!
> >
> > On Tue, Jan 19, 2016 at 7:53 AM, Jérôme LELEU <le...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > Following my own idea, here is a demo with the Knox / pac4j support:
> > > https://github.com/pac4j/knox-pac4j-demo
> > > Feel free to submit pull requests if you want me to amend it.
> > >
> > > What do you think?
> > >
> > > Thanks.
> > > Best regards,
> > > Jérôme
> > >
> > >
> > > 2016-01-18 11:03 GMT+01:00 Jérôme LELEU <le...@gmail.com>:
> > >
> > > > Hi,
> > > >
> > > > It's great news!
> > > >
> > > > One more thing I'm thinking of: we always have a demo corresponding
> to
> > a
> > > > pac4j support. It would be great to have a knox-pac4j-demo and
> > reference
> > > it
> > > > from the manual. I can handle it.
> > > >
> > > > Does it make sense?
> > > >
> > > > Thanks.
> > > > Best regards,
> > > > Jérôme
> > > >
> > > >
> > > >
> > > >
> > > > 2016-01-17 6:37 GMT+01:00 larry mccay <lm...@apache.org>:
> > > >
> > > >> KNOX-641 and KNOX-642 have both been committed to master.
> > > >>
> > > >> There is a new docs book where you can check out the pac4j docs
> > > available:
> > > >>
> > > >>
> > >
> >
> http://knox.apache.org/books/knox-0-8-0/user-guide.html#Pac4j+Provider+-+CAS+/+OAuth+/+SAML+/+OpenID+Connect
> > > >>
> > > >> I have some additional ideas for the docs that I will roll out in
> the
> > > next
> > > >> few days.
> > > >>
> > > >> We need to discuss the identity assertion approach for 0.8.0.
> > > >>
> > > >> I think we are on track for 1/29 release date.
> > > >>
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Should we add a link in the documentation to point to the demo?
2016-01-19 14:19 GMT+01:00 larry mccay <la...@gmail.com>:
> That's great!
>
> On Tue, Jan 19, 2016 at 7:53 AM, Jérôme LELEU <le...@gmail.com> wrote:
>
> > Hi,
> >
> > Following my own idea, here is a demo with the Knox / pac4j support:
> > https://github.com/pac4j/knox-pac4j-demo
> > Feel free to submit pull requests if you want me to amend it.
> >
> > What do you think?
> >
> > Thanks.
> > Best regards,
> > Jérôme
> >
> >
> > 2016-01-18 11:03 GMT+01:00 Jérôme LELEU <le...@gmail.com>:
> >
> > > Hi,
> > >
> > > It's great news!
> > >
> > > One more thing I'm thinking of: we always have a demo corresponding to
> a
> > > pac4j support. It would be great to have a knox-pac4j-demo and
> reference
> > it
> > > from the manual. I can handle it.
> > >
> > > Does it make sense?
> > >
> > > Thanks.
> > > Best regards,
> > > Jérôme
> > >
> > >
> > >
> > >
> > > 2016-01-17 6:37 GMT+01:00 larry mccay <lm...@apache.org>:
> > >
> > >> KNOX-641 and KNOX-642 have both been committed to master.
> > >>
> > >> There is a new docs book where you can check out the pac4j docs
> > available:
> > >>
> > >>
> >
> http://knox.apache.org/books/knox-0-8-0/user-guide.html#Pac4j+Provider+-+CAS+/+OAuth+/+SAML+/+OpenID+Connect
> > >>
> > >> I have some additional ideas for the docs that I will roll out in the
> > next
> > >> few days.
> > >>
> > >> We need to discuss the identity assertion approach for 0.8.0.
> > >>
> > >> I think we are on track for 1/29 release date.
> > >>
> > >
> >
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
That's great!
On Tue, Jan 19, 2016 at 7:53 AM, Jérôme LELEU <le...@gmail.com> wrote:
> Hi,
>
> Following my own idea, here is a demo with the Knox / pac4j support:
> https://github.com/pac4j/knox-pac4j-demo
> Feel free to submit pull requests if you want me to amend it.
>
> What do you think?
>
> Thanks.
> Best regards,
> Jérôme
>
>
> 2016-01-18 11:03 GMT+01:00 Jérôme LELEU <le...@gmail.com>:
>
> > Hi,
> >
> > It's great news!
> >
> > One more thing I'm thinking of: we always have a demo corresponding to a
> > pac4j support. It would be great to have a knox-pac4j-demo and reference
> it
> > from the manual. I can handle it.
> >
> > Does it make sense?
> >
> > Thanks.
> > Best regards,
> > Jérôme
> >
> >
> >
> >
> > 2016-01-17 6:37 GMT+01:00 larry mccay <lm...@apache.org>:
> >
> >> KNOX-641 and KNOX-642 have both been committed to master.
> >>
> >> There is a new docs book where you can check out the pac4j docs
> available:
> >>
> >>
> http://knox.apache.org/books/knox-0-8-0/user-guide.html#Pac4j+Provider+-+CAS+/+OAuth+/+SAML+/+OpenID+Connect
> >>
> >> I have some additional ideas for the docs that I will roll out in the
> next
> >> few days.
> >>
> >> We need to discuss the identity assertion approach for 0.8.0.
> >>
> >> I think we are on track for 1/29 release date.
> >>
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Hi,
Following my own idea, here is a demo with the Knox / pac4j support:
https://github.com/pac4j/knox-pac4j-demo
Feel free to submit pull requests if you want me to amend it.
What do you think?
Thanks.
Best regards,
Jérôme
2016-01-18 11:03 GMT+01:00 Jérôme LELEU <le...@gmail.com>:
> Hi,
>
> It's great news!
>
> One more thing I'm thinking of: we always have a demo corresponding to a
> pac4j support. It would be great to have a knox-pac4j-demo and reference it
> from the manual. I can handle it.
>
> Does it make sense?
>
> Thanks.
> Best regards,
> Jérôme
>
>
>
>
> 2016-01-17 6:37 GMT+01:00 larry mccay <lm...@apache.org>:
>
>> KNOX-641 and KNOX-642 have both been committed to master.
>>
>> There is a new docs book where you can check out the pac4j docs available:
>>
>> http://knox.apache.org/books/knox-0-8-0/user-guide.html#Pac4j+Provider+-+CAS+/+OAuth+/+SAML+/+OpenID+Connect
>>
>> I have some additional ideas for the docs that I will roll out in the next
>> few days.
>>
>> We need to discuss the identity assertion approach for 0.8.0.
>>
>> I think we are on track for 1/29 release date.
>>
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Hi,
It's great news!
One more thing I'm thinking of: we always have a demo corresponding to a
pac4j support. It would be great to have a knox-pac4j-demo and reference it
from the manual. I can handle it.
Does it make sense?
Thanks.
Best regards,
Jérôme
2016-01-17 6:37 GMT+01:00 larry mccay <lm...@apache.org>:
> KNOX-641 and KNOX-642 have both been committed to master.
>
> There is a new docs book where you can check out the pac4j docs available:
>
> http://knox.apache.org/books/knox-0-8-0/user-guide.html#Pac4j+Provider+-+CAS+/+OAuth+/+SAML+/+OpenID+Connect
>
> I have some additional ideas for the docs that I will roll out in the next
> few days.
>
> We need to discuss the identity assertion approach for 0.8.0.
>
> I think we are on track for 1/29 release date.
>
Re: pac4j and Apache Knox
Posted by larry mccay <lm...@apache.org>.
KNOX-641 and KNOX-642 have both been committed to master.
There is a new docs book where you can check out the pac4j docs available:
http://knox.apache.org/books/knox-0-8-0/user-guide.html#Pac4j+Provider+-+CAS+/+OAuth+/+SAML+/+OpenID+Connect
I have some additional ideas for the docs that I will roll out in the next
few days.
We need to discuss the identity assertion approach for 0.8.0.
I think we are on track for 1/29 release date.
On Fri, Jan 15, 2016 at 11:06 AM, larry mccay <lm...@apache.org> wrote:
> Excellent - it worked!
>
> I will review the docs with the hurdles that I had to overcome in mind.
> Hoping to get this committed today. :)
>
> On Fri, Jan 15, 2016 at 11:02 AM, larry mccay <lm...@apache.org> wrote:
>
>> Okay - got past that now....
>> We are getting closer!
>>
>> On Fri, Jan 15, 2016 at 10:56 AM, Jérôme LELEU <le...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> We have one callback url (the KnoxSSO url) and multiple identity
>>> providers
>>> so to distinguish between all clients, pac4j uses the callback url + the
>>> client_name parameter (Clients.DEFAULT_CLIENT_NAME_PARAMETER).
>>>
>>> The redirection url generated to the identity provider has this
>>> client_name
>>> parameter: this is why it works well with the CAS server which redirects
>>> the user (after a successfull url) to the originally provided url.
>>>
>>> For Okta, on server side, the redirection relies on the defined url. *So
>>> you must define the callback url in Okta as your KnoxSSO url + the
>>> client_name parameter = SAML2Client*.
>>>
>>> I myself have
>>> https://127.0.0.1:8443/gateway/idp/api/v1/websso?client_name=SAML2Client
>>> for my Okta app. And the logic of the pac4j gateway provider is based on
>>> this client_name parameter to know if it's a callback or an access call.
>>> Hence the infinite loop in your case.
>>>
>>> I guess we need to add a warning in the documentation for that. Just let
>>> met know how you want to proceed.
>>>
>>> Thanks.
>>> Best regards,
>>> Jérôme
>>>
>>>
>>>
>>>
>>>
>>> 2016-01-15 16:38 GMT+01:00 larry mccay <lm...@apache.org>:
>>>
>>> > Hi Jérôme -
>>> >
>>> > Thanks for the updated docs - I will take a look today.
>>> >
>>> > I am currently still trying to test okta and stuck in a redirect loop.
>>> > Did you have to change anything in order to get the
>>> > request.getParameter(Clients.DEFAULT_CLIENT_NAME_PARAMETER)
>>> > set for the callbacks from okta? It is null in my environment and
>>> therefore
>>> > it moves on to the following:
>>> >
>>> > // otherwise just apply security and requires authentication
>>> >
>>> > // apply RequiresAuthenticationFilter
>>> >
>>> > requiresAuthenticationFilter.doFilter(servletRequest,
>>> > servletResponse, filterChain);
>>> >
>>> > which obviously results in the redirect loop.
>>> >
>>> > Curious whether you ran into that...
>>> >
>>> > thanks,
>>> >
>>> > --larry
>>> >
>>> > On Fri, Jan 15, 2016 at 4:00 AM, Jérôme LELEU <le...@gmail.com>
>>> wrote:
>>> >
>>> > > Hi,
>>> > >
>>> > > I just uploaded a new patch for the documentation with the links
>>> pointing
>>> > > to the pac4j wiki. It should be clearer.
>>> > >
>>> > > Thanks.
>>> > > Best regards,
>>> > > Jérôme
>>> > >
>>> > >
>>> > > 2016-01-14 13:20 GMT+01:00 larry mccay <lm...@apache.org>:
>>> > >
>>> > > > That sounds pretty reasonable.
>>> > > > I will likely document a few of the integrations that are possible
>>> in
>>> > > > blogs/tutorials anyway.
>>> > > >
>>> > > > I don't want testing of Knox at release time to have to jump
>>> around to
>>> > > much
>>> > > > in order to be able to test.
>>> > > > I think we can make that all good though.
>>> > > >
>>> > > > I will see what I can do with okta today.
>>> > > >
>>> > > > On Thu, Jan 14, 2016 at 5:00 AM, Jérôme LELEU <le...@gmail.com>
>>> > wrote:
>>> > > >
>>> > > > > Hi,
>>> > > > >
>>> > > > > Yes, the documentation is a bit too light. But you guessed it
>>> right:
>>> > we
>>> > > > > need to have a keystore for encryption.
>>> > > > >
>>> > > > > The saml.identityProviderMetadataPath can point to a local
>>> resource
>>> > or
>>> > > > to a
>>> > > > > remote one, using the right prefix: resource:, file: or an url
>>> (by
>>> > > > default,
>>> > > > > it is a file path). This must be documented though.
>>> > > > >
>>> > > > > With Okta, I used the defined url (Single Sign On URL = Recipient
>>> > URL =
>>> > > > > Destination URL) for the serviceProviderEntityId, but I think it
>>> may
>>> > > > > depends on IdP as well. Reading the spec, it must be an URI, but
>>> I'm
>>> > > not
>>> > > > > sure if the SP metadata should be really available on this url.
>>> For
>>> > > Okta,
>>> > > > > it doesn't matter.
>>> > > > >
>>> > > > > According to your SAML configuration, the SP metadata will be
>>> > generated
>>> > > > > somewhere and this somewhere can be defined via the
>>> > > > > serviceProviderMetadataPath parameter. You generally need to
>>> update
>>> > > your
>>> > > > > metadata to the IdP (not required for Okta though). Both the SP
>>> and
>>> > IdP
>>> > > > > must know each other.
>>> > > > >
>>> > > > > When writing the documentation, I went fast on these parameters
>>> with
>>> > > the
>>> > > > > feeling they were regular ones, but indeed, the description in
>>> the
>>> > Knox
>>> > > > > manual is not enough. This is somehow a bit normal as the real
>>> > > > > documentation for SAML is on the SAML wiki:
>>> > > > >
>>> https://github.com/pac4j/pac4j/wiki/Clients#details-for-saml-support
>>> > > > >
>>> > > > > So I propose to keep the Knox documentation mostly "as is", but
>>> add
>>> > > links
>>> > > > > to the pac4j wiki (where I could more easily made updates). All
>>> pac4j
>>> > > > > integrations need this documentation so it's better to
>>> centralize it,
>>> > > > from
>>> > > > > my point of view. What do you think?
>>> > > > >
>>> > > > > Thanks.
>>> > > > > Best regards,
>>> > > > > Jérôme
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > 2016-01-13 19:37 GMT+01:00 larry mccay <lm...@apache.org>:
>>> > > > >
>>> > > > > > Hi Jérôme -
>>> > > > > >
>>> > > > > > I'm trying to configure the pac4j provider for an okta
>>> > "application"
>>> > > > > that I
>>> > > > > > created.
>>> > > > > > The following (from KNOX-642 docs patch) isn't quite enough to
>>> make
>>> > > it
>>> > > > > > clear to me how to go about doing so:
>>> > > > > >
>>> > > > > > +saml.keystorePassword | Password of the keystore
>>> > > (storepass)
>>> > > > > > +saml.privateKeyPassword | Password for the private
>>> key
>>> > > > > (keypass)
>>> > > > > > +saml.keystorePath | Path of the keystore
>>> > > > > > +saml.identityProviderMetadataPath | Path of the
>>> identity
>>> > > > > > provider metadata
>>> > > > > > +saml.maximumAuthenticationLifetime | Maximum
>>> lifetime
>>> > for
>>> > > > > > authentication
>>> > > > > > +saml.serviceProviderEntityId | Identifier of the
>>> service
>>> > > > > > provider
>>> > > > > > +saml.serviceProviderMetadataPath | Path of the
>>> service
>>> > > > > provider
>>> > > > > > metadata
>>> > > > > >
>>> > > > > > I assume that I can use the gateway.jks keystore and the
>>> > > > gateway-identity
>>> > > > > > keypair to do the request signing and that that information is
>>> what
>>> > > is
>>> > > > > > needed for the first 3 params. Unfortunately, I don't see any
>>> use
>>> > of
>>> > > > > > gateway services to get the master secret therefore it needs
>>> to be
>>> > in
>>> > > > > clear
>>> > > > > > text here. This won't work - but may not be a show stopper for
>>> > > > committing
>>> > > > > > to master as long as we follow up with a fix.
>>> > > > > >
>>> > > > > > Can saml.identityProviderMetadataPath point to a remote
>>> location or
>>> > > > does
>>> > > > > it
>>> > > > > > have to be local to the SP application. This would likely
>>> require
>>> > it
>>> > > to
>>> > > > > be
>>> > > > > > on the local filesystem, provisioned by the contributor into
>>> the
>>> > > > > generated
>>> > > > > > web app or in some central location via NFS or something like
>>> that.
>>> > > > > >
>>> > > > > > The okta application that I created is called KnoxSSO - is
>>> that the
>>> > > > value
>>> > > > > > for saml.serviceProviderEntityId?
>>> > > > > >
>>> > > > > > The saml.serviceProviderMetadataPath has the same questions as
>>> the
>>> > > > > metadata
>>> > > > > > for the IDP. In addition, is there a sample metadata file that
>>> we
>>> > can
>>> > > > > > provide for the use of pac4j with KnoxSSO?
>>> > > > > >
>>> > > > > > I think that getting this working and clean (no clear text
>>> > passwords)
>>> > > > > will
>>> > > > > > make a great feature and blog for featuring pac4j provider and
>>> the
>>> > > > 0.8.0
>>> > > > > > release. So, let's try and iron this out clearly.
>>> > > > > >
>>> > > > > > I would really like to get this working and committed in the
>>> next
>>> > > > couple
>>> > > > > > days to free us up for follow up items. In particular we need
>>> time
>>> > to
>>> > > > > > figure out whether the identity assertion providers that we
>>> > currently
>>> > > > > have
>>> > > > > > will suffice for an apache release that is featuring this new
>>> > > > > > functionality.
>>> > > > > >
>>> > > > > > I will also add the above comments/questions to the JIRA for
>>> > > > visibility.
>>> > > > > >
>>> > > > > > thanks,
>>> > > > > >
>>> > > > > > --larry
>>> > > > > >
>>> > > > > > On Fri, Jan 8, 2016 at 12:40 PM, larry mccay <
>>> lmccay@apache.org>
>>> > > > wrote:
>>> > > > > >
>>> > > > > > > Jérôme -
>>> > > > > > >
>>> > > > > > > My testing of OpenID Connect is blocked.
>>> > > > > > > Can you see the comments in KNOX-641?
>>> > > > > > >
>>> > > > > > > thanks,
>>> > > > > > >
>>> > > > > > > --larry
>>> > > > > > >
>>> > > > > > > On Wed, Jan 6, 2016 at 2:30 PM, larry mccay <
>>> > larry.mccay@gmail.com
>>> > > >
>>> > > > > > wrote:
>>> > > > > > >
>>> > > > > > >> Jérôme -
>>> > > > > > >>
>>> > > > > > >> Please see the comments on KNOX-641.
>>> > > > > > >>
>>> > > > > > >> thanks,
>>> > > > > > >>
>>> > > > > > >> --larry
>>> > > > > > >>
>>> > > > > > >> On Wed, Jan 6, 2016 at 11:24 AM, Kevin Minder <
>>> > > > > > >> kevin.minder@hortonworks.com> wrote:
>>> > > > > > >>
>>> > > > > > >>> I can certainly appreciate the issue of including external
>>> > > > resources
>>> > > > > in
>>> > > > > > >>> automated tests. Nothing has driven me more crazy over the
>>> > > years.
>>> > > > > The
>>> > > > > > >>> flip side of this of course is not finding out about a
>>> breakage
>>> > > > until
>>> > > > > > >>> someone is willing to go through the manual testing which
>>> will
>>> > > > > > typically
>>> > > > > > >>> happen just before a release. Also the implication is that
>>> > these
>>> > > > > > testing
>>> > > > > > >>> procedures must be very will documented so that they can be
>>> > > > continue
>>> > > > > > to be
>>> > > > > > >>> run once any of us are no longer active in the project.
>>> > > > > > >>>
>>> > > > > > >>>
>>> > > > > > >>>
>>> > > > > > >>> On 1/6/16, 2:12 AM, "Jérôme LELEU" <le...@gmail.com>
>>> wrote:
>>> > > > > > >>>
>>> > > > > > >>> >Hi,
>>> > > > > > >>> >
>>> > > > > > >>> >Yes, you can hit the CAS server at Heroku. Notice it's a
>>> > Heroku
>>> > > > free
>>> > > > > > >>> server
>>> > > > > > >>> >so it needs to be re-activated first (it takes a couple of
>>> > > > seconds).
>>> > > > > > So
>>> > > > > > >>> for
>>> > > > > > >>> >a UI test, you should first hit it, wait 30 seconds and
>>> then
>>> > > > perform
>>> > > > > > the
>>> > > > > > >>> >test.
>>> > > > > > >>> >
>>> > > > > > >>> >Just my 2 cents:
>>> > > > > > >>> >Using automated UI tests was my first strategy for pac4j
>>> but
>>> > I
>>> > > > > > finally
>>> > > > > > >>> >gave up because public providers change very often, at
>>> least
>>> > > > enough
>>> > > > > to
>>> > > > > > >>> make
>>> > > > > > >>> >the maintenance tests a nightmare. Currently, I'm using
>>> manual
>>> > > > tests
>>> > > > > > >>> (the
>>> > > > > > >>> >same for all demos), it takes me around 5 minutes to play
>>> them
>>> > > all
>>> > > > > by
>>> > > > > > >>> hand
>>> > > > > > >>> >(for a demo) and I launched manually the UI tests I have
>>> for
>>> > > every
>>> > > > > > major
>>> > > > > > >>> >pac4j release. Just to say UI tests are not that easy.
>>> For a
>>> > CAS
>>> > > > > > server,
>>> > > > > > >>> >it's fairly feasible as the CAS server and protocol change
>>> > > rarely.
>>> > > > > > >>> >That's why for Knox, I did some compromise with a
>>> simulated
>>> > web
>>> > > > test
>>> > > > > > >>> (based
>>> > > > > > >>> >on the basic auth). See:
>>> > > > > > >>> >
>>> > > > > > >>>
>>> > > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>> https://github.com/apache/knox/pull/2/files#diff-d0c880ca71b310dbe57975c577535e97R47
>>> > > > > > >>> >
>>> > > > > > >>> >Thanks.
>>> > > > > > >>> >Best regards,
>>> > > > > > >>> >Jérôme
>>> > > > > > >>> >
>>> > > > > > >>> >
>>> > > > > > >>> >
>>> > > > > > >>> >2016-01-05 21:20 GMT+01:00 Kevin Minder <
>>> > > > > kevin.minder@hortonworks.com
>>> > > > > > >:
>>> > > > > > >>> >
>>> > > > > > >>> >> From my perspective it would be ideal if there were some
>>> > > > > automatable
>>> > > > > > >>> >> functional tests for this. I’m not advocating that
>>> these be
>>> > > > > > something
>>> > > > > > >>> >> included in “mvn clean install” as that is running too
>>> long
>>> > as
>>> > > > it
>>> > > > > > is.
>>> > > > > > >>> >> Given that I don’t have as much context as Larry, I have
>>> > some
>>> > > > > > >>> questions
>>> > > > > > >>> >> about what this would take. Lets say we had permission
>>> to
>>> > hit
>>> > > > > > >>> >> https://casserverpac4j.herokuapp.com/login as part of
>>> some
>>> > > low
>>> > > > > > >>> frequency
>>> > > > > > >>> >> automated tests (e.g. Once nighty). What static
>>> credentials
>>> > > and
>>> > > > > > >>> other test
>>> > > > > > >>> >> automation infrastructure would need to be implemented
>>> in
>>> > > > support
>>> > > > > of
>>> > > > > > >>> this?
>>> > > > > > >>> >> I understand that the test suite would require at a
>>> minimum
>>> > > > > > >>> >> 1) a test driver
>>> > > > > > >>> >> 2) a protected mock UI and
>>> > > > > > >>> >> 3) an appropriately configured Knox
>>> > > > > > >>> >> 4) a profile enabled maven module
>>> > > > > > >>> >> 5) an Apache jenkins job
>>> > > > > > >>> >> but I’m sure I’m missing other things. I’m certainly
>>> > willing
>>> > > to
>>> > > > > > help
>>> > > > > > >>> >> setup the skeleton infrastructure (e.g. test driver,
>>> mock
>>> > UI,
>>> > > > > maven
>>> > > > > > >>> module,
>>> > > > > > >>> >> jenkins job)
>>> > > > > > >>> >>
>>> > > > > > >>> >>
>>> > > > > > >>> >>
>>> > > > > > >>> >> On 1/5/16, 2:54 PM, "larry mccay" <
>>> larry.mccay@gmail.com>
>>> > > > wrote:
>>> > > > > > >>> >>
>>> > > > > > >>> >> >Okay, very good.
>>> > > > > > >>> >> >I've used TestShib for the picketlink provider -
>>> thanks for
>>> > > the
>>> > > > > > >>> pointers!
>>> > > > > > >>> >> >
>>> > > > > > >>> >> >On Tue, Jan 5, 2016 at 1:38 PM, Jérôme LELEU <
>>> > > leleuj@gmail.com
>>> > > > >
>>> > > > > > >>> wrote:
>>> > > > > > >>> >> >
>>> > > > > > >>> >> >> The online CAS server (
>>> > > > > > https://casserverpac4j.herokuapp.com/login)
>>> > > > > > >>> uses
>>> > > > > > >>> >> >> the
>>> > > > > > >>> >> >> CAS protocol. SAML support can be tested using some
>>> > online
>>> > > > IdP
>>> > > > > > like
>>> > > > > > >>> >> Okta,
>>> > > > > > >>> >> >> TestShib, OpenFeide, Ssocircle...
>>> > > > > > >>> >> >>
>>> > > > > > >>> >> >>
>>> > > > > > >>> >> >> 2016-01-05 17:32 GMT+01:00 larry mccay <
>>> > > > larry.mccay@gmail.com
>>> > > > > >:
>>> > > > > > >>> >> >>
>>> > > > > > >>> >> >> > Great - thanks for that pointer!
>>> > > > > > >>> >> >> >
>>> > > > > > >>> >> >> > I will take a look at that and help drive the
>>> release
>>> > > > related
>>> > > > > > >>> testing.
>>> > > > > > >>> >> >> > Merge testing will be gated on CAS server (is this
>>> SAML
>>> > > or
>>> > > > > CAS
>>> > > > > > >>> >> protocol?)
>>> > > > > > >>> >> >> > and testBasicAuth.
>>> > > > > > >>> >> >> >
>>> > > > > > >>> >> >> > On Tue, Jan 5, 2016 at 10:52 AM, Jérôme LELEU <
>>> > > > > > leleuj@gmail.com>
>>> > > > > > >>> >> wrote:
>>> > > > > > >>> >> >> >
>>> > > > > > >>> >> >> > > Hi,
>>> > > > > > >>> >> >> > >
>>> > > > > > >>> >> >> > > Glad to hear back from you!
>>> > > > > > >>> >> >> > >
>>> > > > > > >>> >> >> > > The core pac4j project is fully tested by unit
>>> tests
>>> > > (and
>>> > > > > > some
>>> > > > > > >>> >> >> > integration
>>> > > > > > >>> >> >> > > tests I run for major version), then all pac4j
>>> > > > > > implementations
>>> > > > > > >>> are
>>> > > > > > >>> >> each
>>> > > > > > >>> >> >> > > tested by the appropriate demo: j2e-pac4j-demo
>>> tests
>>> > > > > > j2e-pac4j,
>>> > > > > > >>> >> >> > > spring-webmvc-pac4j-demo tests
>>> spring-webmvc-pac4j,
>>> > > etc.
>>> > > > > > >>> >> >> > >
>>> > > > > > >>> >> >> > > So if you take a look at:
>>> > > > > > >>> >> >> > >
>>> > > > > > >>> >> >> > >
>>> > > > > > >>> >> >> >
>>> > > > > > >>> >> >>
>>> > > > > > >>> >>
>>> > > > > > >>>
>>> > > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>> https://github.com/pac4j/j2e-pac4j-demo/blob/master/src/main/java/org/pac4j/demo/j2e/config/DemoConfigFactory.java#L27
>>> > > > > > >>> >> >> > > (for example), you have all the required
>>> information
>>> > to
>>> > > > > test.
>>> > > > > > >>> >> >> > >
>>> > > > > > >>> >> >> > > I can do that on my own, but it can be good for
>>> the
>>> > > Knox
>>> > > > > > >>> community
>>> > > > > > >>> >> to
>>> > > > > > >>> >> >> > start
>>> > > > > > >>> >> >> > > working / testing the pac4j support. It's up to
>>> yoy.
>>> > > > > > >>> >> >> > >
>>> > > > > > >>> >> >> > > Thanks.
>>> > > > > > >>> >> >> > > Best regards,
>>> > > > > > >>> >> >> > > Jérôme
>>> > > > > > >>> >> >> > >
>>> > > > > > >>> >> >> > >
>>> > > > > > >>> >> >> > > 2016-01-05 16:11 GMT+01:00 larry mccay <
>>> > > > > > larry.mccay@gmail.com
>>> > > > > > >>> >:
>>> > > > > > >>> >> >> > >
>>> > > > > > >>> >> >> > > > Hello Jérôme -
>>> > > > > > >>> >> >> > > >
>>> > > > > > >>> >> >> > > > Happy New Year!
>>> > > > > > >>> >> >> > > >
>>> > > > > > >>> >> >> > > > I am going to start reviewing your updates
>>> today,
>>> > > > > > hopefully.
>>> > > > > > >>> >> >> > > > I was thinking that we need to start
>>> discussions on
>>> > > > what
>>> > > > > > the
>>> > > > > > >>> key
>>> > > > > > >>> >> >> > usecases
>>> > > > > > >>> >> >> > > > are and how to go about testing them.
>>> > > > > > >>> >> >> > > > We can certainly test the testBasicAuth and
>>> against
>>> > > the
>>> > > > > > >>> hosted CAS
>>> > > > > > >>> >> >> > server
>>> > > > > > >>> >> >> > > > but what about FB, openid, OAuth, etc?
>>> > > > > > >>> >> >> > > >
>>> > > > > > >>> >> >> > > > I'm not sure that FB would be a key feature but
>>> > > OpenID
>>> > > > > > >>> Connect and
>>> > > > > > >>> >> >> > OAuth
>>> > > > > > >>> >> >> > > > would be - as is SAML.
>>> > > > > > >>> >> >> > > > I think CAS buys us SAML testing - assuming
>>> that
>>> > the
>>> > > > > > >>> >> configuration of
>>> > > > > > >>> >> >> > the
>>> > > > > > >>> >> >> > > > hosted server is actually a SAML 2 instance.
>>> > > > > > >>> >> >> > > >
>>> > > > > > >>> >> >> > > > What about the others?
>>> > > > > > >>> >> >> > > >
>>> > > > > > >>> >> >> > > > I don't know that we need to be able to test
>>> them
>>> > all
>>> > > > > > before
>>> > > > > > >>> merge
>>> > > > > > >>> >> >> but
>>> > > > > > >>> >> >> > > some
>>> > > > > > >>> >> >> > > > sort of manual verification would be great.
>>> > > > > > >>> >> >> > > > We would need to be able to test them before
>>> the
>>> > next
>>> > > > > > release
>>> > > > > > >>> >> which
>>> > > > > > >>> >> >> > would
>>> > > > > > >>> >> >> > > > be featuring the pac4j functionality.
>>> > > > > > >>> >> >> > > >
>>> > > > > > >>> >> >> > > > Maybe you can describe how you go about testing
>>> > such
>>> > > > > things
>>> > > > > > >>> for
>>> > > > > > >>> >> the
>>> > > > > > >>> >> >> > pac4j
>>> > > > > > >>> >> >> > > > project itself?
>>> > > > > > >>> >> >> > > >
>>> > > > > > >>> >> >> > > > thanks,
>>> > > > > > >>> >> >> > > >
>>> > > > > > >>> >> >> > > > --larry
>>> > > > > > >>> >> >> > > >
>>> > > > > > >>> >> >> > > >
>>> > > > > > >>> >> >> > > > On Tue, Jan 5, 2016 at 9:55 AM, Jérôme LELEU <
>>> > > > > > >>> leleuj@gmail.com>
>>> > > > > > >>> >> >> wrote:
>>> > > > > > >>> >> >> > > >
>>> > > > > > >>> >> >> > > > > Hi,
>>> > > > > > >>> >> >> > > > >
>>> > > > > > >>> >> >> > > > > Happy new year!
>>> > > > > > >>> >> >> > > > >
>>> > > > > > >>> >> >> > > > > A few days ago, I updated my patch of the
>>> pac4j
>>> > > > gateway
>>> > > > > > >>> provider
>>> > > > > > >>> >> >> > > > according
>>> > > > > > >>> >> >> > > > > to all comments on
>>> > > > > > >>> >> https://issues.apache.org/jira/browse/KNOX-641
>>> > > > > > >>> >> >> as
>>> > > > > > >>> >> >> > > > well
>>> > > > > > >>> >> >> > > > > as the documentation on KNOX-642.
>>> > > > > > >>> >> >> > > > >
>>> > > > > > >>> >> >> > > > > Is everything ok for the merge?
>>> > > > > > >>> >> >> > > > >
>>> > > > > > >>> >> >> > > > > Thanks.
>>> > > > > > >>> >> >> > > > > Best regards,
>>> > > > > > >>> >> >> > > > > Jérôme
>>> > > > > > >>> >> >> > > > >
>>> > > > > > >>> >> >> > > > >
>>> > > > > > >>> >> >> > > > > 2015-12-14 15:28 GMT+01:00 larry mccay <
>>> > > > > > >>> larry.mccay@gmail.com>:
>>> > > > > > >>> >> >> > > > >
>>> > > > > > >>> >> >> > > > > > Hi Jérôme -
>>> > > > > > >>> >> >> > > > > >
>>> > > > > > >>> >> >> > > > > > Not sure if you saw but I added review
>>> comments
>>> > > to
>>> > > > > > >>> KNOX-641.
>>> > > > > > >>> >> >> > > > > >
>>> > > > > > >>> >> >> > > > > > I think that we need to determine whether
>>> we
>>> > want
>>> > > > the
>>> > > > > > >>> >> >> testBasicAuth
>>> > > > > > >>> >> >> > > in
>>> > > > > > >>> >> >> > > > > the
>>> > > > > > >>> >> >> > > > > > provider itself.
>>> > > > > > >>> >> >> > > > > >
>>> > > > > > >>> >> >> > > > > > Let's follow up on the JIRA.
>>> > > > > > >>> >> >> > > > > >
>>> > > > > > >>> >> >> > > > > > thanks,
>>> > > > > > >>> >> >> > > > > >
>>> > > > > > >>> >> >> > > > > > --larry
>>> > > > > > >>> >> >> > > > > >
>>> > > > > > >>> >> >> > > > > > On Fri, Dec 11, 2015 at 8:44 AM, Jérôme
>>> LELEU <
>>> > > > > > >>> >> leleuj@gmail.com>
>>> > > > > > >>> >> >> > > > wrote:
>>> > > > > > >>> >> >> > > > > >
>>> > > > > > >>> >> >> > > > > > > Hi,
>>> > > > > > >>> >> >> > > > > > >
>>> > > > > > >>> >> >> > > > > > > No problem. It can go into a version
>>> 0.8.0 if
>>> > > > > needed.
>>> > > > > > >>> The
>>> > > > > > >>> >> truth
>>> > > > > > >>> >> >> > is
>>> > > > > > >>> >> >> > > > that
>>> > > > > > >>> >> >> > > > > > > there is only one change outside the new
>>> > pac4j
>>> > > > > > module,
>>> > > > > > >>> so I
>>> > > > > > >>> >> >> think
>>> > > > > > >>> >> >> > > > risks
>>> > > > > > >>> >> >> > > > > > are
>>> > > > > > >>> >> >> > > > > > > extremly limited.
>>> > > > > > >>> >> >> > > > > > >
>>> > > > > > >>> >> >> > > > > > > Just let met know.
>>> > > > > > >>> >> >> > > > > > >
>>> > > > > > >>> >> >> > > > > > > Thanks.
>>> > > > > > >>> >> >> > > > > > > Best regards,
>>> > > > > > >>> >> >> > > > > > > Jérôme
>>> > > > > > >>> >> >> > > > > > >
>>> > > > > > >>> >> >> > > > > > >
>>> > > > > > >>> >> >> > > > > > > 2015-12-11 14:23 GMT+01:00 larry mccay <
>>> > > > > > >>> >> larry.mccay@gmail.com
>>> > > > > > >>> >> >> >:
>>> > > > > > >>> >> >> > > > > > >
>>> > > > > > >>> >> >> > > > > > > > Hi Jérôme -
>>> > > > > > >>> >> >> > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > I have unfortunately not had a chance
>>> to
>>> > > pull,
>>> > > > > > >>> review and
>>> > > > > > >>> >> >> test
>>> > > > > > >>> >> >> > it
>>> > > > > > >>> >> >> > > > yet
>>> > > > > > >>> >> >> > > > > > and
>>> > > > > > >>> >> >> > > > > > > > have intended to do that today.
>>> > > > > > >>> >> >> > > > > > > > I apologize for the delay.
>>> > > > > > >>> >> >> > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > I was actually thinking that this
>>> would go
>>> > > > into a
>>> > > > > > >>> follow
>>> > > > > > >>> >> up
>>> > > > > > >>> >> >> > > release
>>> > > > > > >>> >> >> > > > > > that
>>> > > > > > >>> >> >> > > > > > > we
>>> > > > > > >>> >> >> > > > > > > > would try and get done rapidly after
>>> the
>>> > > 0.7.0
>>> > > > > > >>> release
>>> > > > > > >>> >> but we
>>> > > > > > >>> >> >> > can
>>> > > > > > >>> >> >> > > > > > discuss
>>> > > > > > >>> >> >> > > > > > > > the target and its chances of
>>> destabilizing
>>> > > > > 0.7.0.
>>> > > > > > >>> >> >> > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > I believe that it is rather
>>> self-contained
>>> > > with
>>> > > > > > only
>>> > > > > > >>> a few
>>> > > > > > >>> >> >> > > changes
>>> > > > > > >>> >> >> > > > to
>>> > > > > > >>> >> >> > > > > > > > external modules.
>>> > > > > > >>> >> >> > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > Opening the JIRAs is perfect and I was
>>> > going
>>> > > to
>>> > > > > do
>>> > > > > > >>> that
>>> > > > > > >>> >> once
>>> > > > > > >>> >> >> I
>>> > > > > > >>> >> >> > > > > started
>>> > > > > > >>> >> >> > > > > > > the
>>> > > > > > >>> >> >> > > > > > > > review.
>>> > > > > > >>> >> >> > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > Let's continue review comments and
>>> > > > collaboration
>>> > > > > on
>>> > > > > > >>> those
>>> > > > > > >>> >> >> > JIRAs.
>>> > > > > > >>> >> >> > > > > > > > I will add you to the contributors
>>> list so
>>> > > that
>>> > > > > we
>>> > > > > > >>> can
>>> > > > > > >>> >> assign
>>> > > > > > >>> >> >> > > them
>>> > > > > > >>> >> >> > > > to
>>> > > > > > >>> >> >> > > > > > > you.
>>> > > > > > >>> >> >> > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > Thank you for your contributions and
>>> your
>>> > > > > patience,
>>> > > > > > >>> >> Jérôme!
>>> > > > > > >>> >> >> > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > --larry
>>> > > > > > >>> >> >> > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > On Fri, Dec 11, 2015 at 3:00 AM, Jérôme
>>> > > LELEU <
>>> > > > > > >>> >> >> > leleuj@gmail.com>
>>> > > > > > >>> >> >> > > > > > wrote:
>>> > > > > > >>> >> >> > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > > Hi,
>>> > > > > > >>> >> >> > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > > I didn't get any new feedback on the
>>> pull
>>> > > > > request
>>> > > > > > >>> so I
>>> > > > > > >>> >> >> assume
>>> > > > > > >>> >> >> > > > > > > everything
>>> > > > > > >>> >> >> > > > > > > > is
>>> > > > > > >>> >> >> > > > > > > > > ok from your point of view.
>>> > > > > > >>> >> >> > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > > I released pac4j v1.8.1 and j2e-pac4j
>>> > > v1.2.1
>>> > > > > so I
>>> > > > > > >>> >> updated
>>> > > > > > >>> >> >> the
>>> > > > > > >>> >> >> > > > pull
>>> > > > > > >>> >> >> > > > > > > > request
>>> > > > > > >>> >> >> > > > > > > > > to use them and successfully
>>> re-tested
>>> > > > > > everything.
>>> > > > > > >>> >> >> > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > > I opened KNOX-641 and submitted the
>>> > > > > corresponding
>>> > > > > > >>> patch.
>>> > > > > > >>> >> >> > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > > I also wrote the documentation,
>>> opened
>>> > > > KNOX-642
>>> > > > > > and
>>> > > > > > >>> >> >> submitted
>>> > > > > > >>> >> >> > > the
>>> > > > > > >>> >> >> > > > > > > > > corresponding patch (just to let you
>>> know
>>> > > > that
>>> > > > > it
>>> > > > > > >>> >> doesn't
>>> > > > > > >>> >> >> > work
>>> > > > > > >>> >> >> > > > out
>>> > > > > > >>> >> >> > > > > of
>>> > > > > > >>> >> >> > > > > > > the
>>> > > > > > >>> >> >> > > > > > > > > box in Windows, I had to replace
>>> mvn.bat
>>> > by
>>> > > > > > >>> mvn.cmd to
>>> > > > > > >>> >> make
>>> > > > > > >>> >> >> > ant
>>> > > > > > >>> >> >> > > > > > work).
>>> > > > > > >>> >> >> > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > > Even if the branch 0.7.0 has already
>>> been
>>> > > > > > created,
>>> > > > > > >>> I
>>> > > > > > >>> >> >> assumed
>>> > > > > > >>> >> >> > > this
>>> > > > > > >>> >> >> > > > > new
>>> > > > > > >>> >> >> > > > > > > > pac4j
>>> > > > > > >>> >> >> > > > > > > > > provider will go into this version
>>> 0.7.0
>>> > > > > > >>> (dependency on
>>> > > > > > >>> >> the
>>> > > > > > >>> >> >> > > > > > > > 0.7.0-SNAPSHOT
>>> > > > > > >>> >> >> > > > > > > > > parent version).
>>> > > > > > >>> >> >> > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > > Just let me know if everything is ok
>>> and
>>> > > when
>>> > > > > > it's
>>> > > > > > >>> >> goind to
>>> > > > > > >>> >> >> > be
>>> > > > > > >>> >> >> > > > > > merged.
>>> > > > > > >>> >> >> > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > > Thanks.
>>> > > > > > >>> >> >> > > > > > > > > Best regards,
>>> > > > > > >>> >> >> > > > > > > > > Jérôme
>>> > > > > > >>> >> >> > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > > 2015-12-04 14:20 GMT+01:00 larry
>>> mccay <
>>> > > > > > >>> >> >> > larry.mccay@gmail.com
>>> > > > > > >>> >> >> > > >:
>>> > > > > > >>> >> >> > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > > > That ability to configure multiple
>>> > > > mechanisms
>>> > > > > > >>> based on
>>> > > > > > >>> >> >> > > > clientName
>>> > > > > > >>> >> >> > > > > > is
>>> > > > > > >>> >> >> > > > > > > > > really
>>> > > > > > >>> >> >> > > > > > > > > > interesting for Knox.
>>> > > > > > >>> >> >> > > > > > > > > > Currently, we require separate
>>> > topologies
>>> > > > per
>>> > > > > > >>> >> >> > authentication
>>> > > > > > >>> >> >> > > > > > > mechanism.
>>> > > > > > >>> >> >> > > > > > > > > > The ability to configure them all
>>> in
>>> > one
>>> > > is
>>> > > > > > >>> really
>>> > > > > > >>> >> great.
>>> > > > > > >>> >> >> > > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > > > We would need to think through the
>>> best
>>> > > way
>>> > > > > to
>>> > > > > > >>> provide
>>> > > > > > >>> >> >> the
>>> > > > > > >>> >> >> > > > > > clientName
>>> > > > > > >>> >> >> > > > > > > > > > parameter.
>>> > > > > > >>> >> >> > > > > > > > > > Since this is targeting KnoxSSO it
>>> can
>>> > > > > actually
>>> > > > > > >>> be
>>> > > > > > >>> >> added
>>> > > > > > >>> >> >> to
>>> > > > > > >>> >> >> > > the
>>> > > > > > >>> >> >> > > > > > > > > providerURL
>>> > > > > > >>> >> >> > > > > > > > > > used to redirect from the
>>> participating
>>> > > > > > >>> application.
>>> > > > > > >>> >> >> > > > > > > > > > Regardless of the authentication
>>> > > mechanism
>>> > > > > used
>>> > > > > > >>> each
>>> > > > > > >>> >> >> > > > application
>>> > > > > > >>> >> >> > > > > > will
>>> > > > > > >>> >> >> > > > > > > > > still
>>> > > > > > >>> >> >> > > > > > > > > > get the same JWT based cookie.
>>> > > > > > >>> >> >> > > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > > > I think that should work really
>>> nicely.
>>> > > > > > >>> >> >> > > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > > > On Fri, Dec 4, 2015 at 7:17 AM,
>>> larry
>>> > > > mccay <
>>> > > > > > >>> >> >> > > > > larry.mccay@gmail.com
>>> > > > > > >>> >> >> > > > > > >
>>> > > > > > >>> >> >> > > > > > > > > wrote:
>>> > > > > > >>> >> >> > > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > > > > Excellent, Jérôme.
>>> > > > > > >>> >> >> > > > > > > > > > > Thanks!
>>> > > > > > >>> >> >> > > > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > > > > On Fri, Dec 4, 2015 at 2:40 AM,
>>> > Jérôme
>>> > > > > LELEU
>>> > > > > > <
>>> > > > > > >>> >> >> > > > leleuj@gmail.com
>>> > > > > > >>> >> >> > > > > >
>>> > > > > > >>> >> >> > > > > > > > wrote:
>>> > > > > > >>> >> >> > > > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > > > >> Hi,
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> I will write how to configure
>>> the
>>> > > pac4j
>>> > > > > > >>> provider in
>>> > > > > > >>> >> >> the
>>> > > > > > >>> >> >> > > > > > > > documentation,
>>> > > > > > >>> >> >> > > > > > > > > > but
>>> > > > > > >>> >> >> > > > > > > > > > >> I can already give you some
>>> > insights.
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> My main goal is always to
>>> respect
>>> > the
>>> > > > key
>>> > > > > > >>> design
>>> > > > > > >>> >> >> > > principles
>>> > > > > > >>> >> >> > > > of
>>> > > > > > >>> >> >> > > > > > > pac4j
>>> > > > > > >>> >> >> > > > > > > > > > >> whatever the environment /
>>> framework
>>> > > in
>>> > > > > > which
>>> > > > > > >>> it is
>>> > > > > > >>> >> >> > > > > implemented.
>>> > > > > > >>> >> >> > > > > > > For
>>> > > > > > >>> >> >> > > > > > > > > > Knox,
>>> > > > > > >>> >> >> > > > > > > > > > >> I'm pretty happy with the use
>>> of the
>>> > > > > > j2e-pac4j
>>> > > > > > >>> >> >> library,
>>> > > > > > >>> >> >> > > > which
>>> > > > > > >>> >> >> > > > > > > means
>>> > > > > > >>> >> >> > > > > > > > > that
>>> > > > > > >>> >> >> > > > > > > > > > >> almost all the pac4j features
>>> are
>>> > > > > available,
>>> > > > > > >>> >> >> especially
>>> > > > > > >>> >> >> > > both
>>> > > > > > >>> >> >> > > > > > > direct
>>> > > > > > >>> >> >> > > > > > > > > and
>>> > > > > > >>> >> >> > > > > > > > > > >> indirect clients. So it can do
>>> what
>>> > > > Shiro
>>> > > > > > >>> already
>>> > > > > > >>> >> does
>>> > > > > > >>> >> >> > but
>>> > > > > > >>> >> >> > > > > also,
>>> > > > > > >>> >> >> > > > > > > as
>>> > > > > > >>> >> >> > > > > > > > we
>>> > > > > > >>> >> >> > > > > > > > > > >> agreed together, supports remote
>>> > > > > > >>> authentications.
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> It is only limited by what you
>>> can
>>> > > > > currently
>>> > > > > > >>> >> >> configure.
>>> > > > > > >>> >> >> > > And
>>> > > > > > >>> >> >> > > > > even
>>> > > > > > >>> >> >> > > > > > > > > > >> configuration is a pac4j
>>> feature as
>>> > > the
>>> > > > > CAS
>>> > > > > > >>> server
>>> > > > > > >>> >> has
>>> > > > > > >>> >> >> > the
>>> > > > > > >>> >> >> > > > > same
>>> > > > > > >>> >> >> > > > > > > > need.
>>> > > > > > >>> >> >> > > > > > > > > > >> Everything happens in this
>>> class:
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > >
>>> > > > > > >>> >> >> > > > > > >
>>> > > > > > >>> >> >> > > > > >
>>> > > > > > >>> >> >> > > > >
>>> > > > > > >>> >> >> > > >
>>> > > > > > >>> >> >> > >
>>> > > > > > >>> >> >> >
>>> > > > > > >>> >> >>
>>> > > > > > >>> >>
>>> > > > > > >>>
>>> > > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java
>>> > > > > > >>> >> >> > > > > > > > > > >> ,
>>> > > > > > >>> >> >> > > > > > > > > > >> which allows you to configure
>>> > > Facebook,
>>> > > > > > >>> Twitter, a
>>> > > > > > >>> >> CAS
>>> > > > > > >>> >> >> > > > > server, a
>>> > > > > > >>> >> >> > > > > > > > SAML
>>> > > > > > >>> >> >> > > > > > > > > > IdP
>>> > > > > > >>> >> >> > > > > > > > > > >> or an OpenID Connect provider.
>>> All
>>> > the
>>> > > > > > >>> provided
>>> > > > > > >>> >> >> > parameters
>>> > > > > > >>> >> >> > > > to
>>> > > > > > >>> >> >> > > > > > the
>>> > > > > > >>> >> >> > > > > > > > > pac4j
>>> > > > > > >>> >> >> > > > > > > > > > >> provider are put into a Map and
>>> the
>>> > > > > > >>> >> >> > > ConfigPropertiesFactory
>>> > > > > > >>> >> >> > > > is
>>> > > > > > >>> >> >> > > > > > > built
>>> > > > > > >>> >> >> > > > > > > > > > with
>>> > > > > > >>> >> >> > > > > > > > > > >> this Map to return the built
>>> client
>>> > (=
>>> > > > > > >>> >> authentication
>>> > > > > > >>> >> >> > > > > > mechanism).
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> You have one more specific
>>> option
>>> > for
>>> > > > Knox
>>> > > > > > as
>>> > > > > > >>> a
>>> > > > > > >>> >> basic
>>> > > > > > >>> >> >> > > > > > > authentication
>>> > > > > > >>> >> >> > > > > > > > > > popup
>>> > > > > > >>> >> >> > > > > > > > > > >> where the username must match
>>> the
>>> > > > > password,
>>> > > > > > >>> you can
>>> > > > > > >>> >> >> > define
>>> > > > > > >>> >> >> > > > > that
>>> > > > > > >>> >> >> > > > > > > by:
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> <param>
>>> > > > > > >>> >> >> > > > > > > > > > >> <name>clientName</name>
>>> > > > > > >>> >> >> > > > > > > > > > >> <value>testBasicAuth</value>
>>> > > > > > >>> >> >> > > > > > > > > > >> </param>
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> It's for testing only.
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> For a CAS server:
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> <param>
>>> > > > > > >>> >> >> > > > > > > > > > >> <name>cas.loginUrl</name>
>>> > > > > > >>> >> >> > > > > > > > > > >> <value>
>>> > > > > > >>> >> https://casserverpac4j.herokuapp.com/login
>>> > > > > > >>> >> >> > > </value>
>>> > > > > > >>> >> >> > > > > > > > > > >> </param>
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> Here are all the properties
>>> > available
>>> > > > for
>>> > > > > > >>> building
>>> > > > > > >>> >> >> > clients
>>> > > > > > >>> >> >> > > > > > (their
>>> > > > > > >>> >> >> > > > > > > > > > meaning
>>> > > > > > >>> >> >> > > > > > > > > > >> is obvious):
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> facebook.id
>>> > > > > > >>> >> >> > > > > > > > > > >> facebook.secret
>>> > > > > > >>> >> >> > > > > > > > > > >> facebook.scope
>>> > > > > > >>> >> >> > > > > > > > > > >> facebook.fields
>>> > > > > > >>> >> >> > > > > > > > > > >> twitter.id
>>> > > > > > >>> >> >> > > > > > > > > > >> twitter.secret
>>> > > > > > >>> >> >> > > > > > > > > > >> saml.keystorePassword
>>> > > > > > >>> >> >> > > > > > > > > > >> saml.privateKeyPassword
>>> > > > > > >>> >> >> > > > > > > > > > >> saml.keystorePath
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> saml.identityProviderMetadataPath
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> saml.maximumAuthenticationLifetime
>>> > > > > > >>> >> >> > > > > > > > > > >> saml.serviceProviderEntityId
>>> > > > > > >>> >> >> > > > > > > > > > >> saml.serviceProviderMetadataPath
>>> > > > > > >>> >> >> > > > > > > > > > >> cas.loginUrl
>>> > > > > > >>> >> >> > > > > > > > > > >> cas.protocol
>>> > > > > > >>> >> >> > > > > > > > > > >> oidc.id
>>> > > > > > >>> >> >> > > > > > > > > > >> oidc.secret
>>> > > > > > >>> >> >> > > > > > > > > > >> oidc.discoveryUri
>>> > > > > > >>> >> >> > > > > > > > > > >> oidc.customParamKey1
>>> > > > > > >>> >> >> > > > > > > > > > >> oidc.customParamValue1
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> If you define multiple clients,
>>> the
>>> > > > first
>>> > > > > > one
>>> > > > > > >>> will
>>> > > > > > >>> >> be
>>> > > > > > >>> >> >> > used
>>> > > > > > >>> >> >> > > > for
>>> > > > > > >>> >> >> > > > > > > > > > >> authentication, but you can
>>> > explicitly
>>> > > > > > choose
>>> > > > > > >>> the
>>> > > > > > >>> >> >> client
>>> > > > > > >>> >> >> > > you
>>> > > > > > >>> >> >> > > > > > want
>>> > > > > > >>> >> >> > > > > > > to
>>> > > > > > >>> >> >> > > > > > > > > use
>>> > > > > > >>> >> >> > > > > > > > > > >> via the clientName parameter,
>>> > assuming
>>> > > > you
>>> > > > > > >>> want to
>>> > > > > > >>> >> >> > switch
>>> > > > > > >>> >> >> > > > from
>>> > > > > > >>> >> >> > > > > > > > client
>>> > > > > > >>> >> >> > > > > > > > > > >> depending on environment for
>>> > example.
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> So if you want to add some new
>>> > > > > > authentication
>>> > > > > > >>> >> >> mechanism,
>>> > > > > > >>> >> >> > > you
>>> > > > > > >>> >> >> > > > > > must
>>> > > > > > >>> >> >> > > > > > > > > first
>>> > > > > > >>> >> >> > > > > > > > > > >> check that it is available in
>>> pac4j
>>> > > (if
>>> > > > > it's
>>> > > > > > >>> not,
>>> > > > > > >>> >> it's
>>> > > > > > >>> >> >> > > > another
>>> > > > > > >>> >> >> > > > > > > > > > discussion,
>>> > > > > > >>> >> >> > > > > > > > > > >> but generally, it is). Then,
>>> you'll
>>> > > need
>>> > > > > to
>>> > > > > > >>> upgrade
>>> > > > > > >>> >> >> the
>>> > > > > > >>> >> >> > > > > > > > > > >> ConfigPropertiesFactory by
>>> > submitting
>>> > > a
>>> > > > > new
>>> > > > > > >>> pull
>>> > > > > > >>> >> >> request
>>> > > > > > >>> >> >> > > to
>>> > > > > > >>> >> >> > > > > the
>>> > > > > > >>> >> >> > > > > > > > pac4j
>>> > > > > > >>> >> >> > > > > > > > > > >> project (I can do it myself,
>>> but I'm
>>> > > > sure
>>> > > > > > you
>>> > > > > > >>> >> could do
>>> > > > > > >>> >> >> > > that
>>> > > > > > >>> >> >> > > > > > > easily),
>>> > > > > > >>> >> >> > > > > > > > > > >> finally wait for the new pac4j
>>> > release
>>> > > > and
>>> > > > > > >>> switch
>>> > > > > > >>> >> >> pac4j
>>> > > > > > >>> >> >> > > > > versions
>>> > > > > > >>> >> >> > > > > > > in
>>> > > > > > >>> >> >> > > > > > > > > Knox
>>> > > > > > >>> >> >> > > > > > > > > > >> to
>>> > > > > > >>> >> >> > > > > > > > > > >> benefit from the new feature.
>>> > > > > > >>> >> >> > > > > > > > > > >> The good thing is that if
>>> someone
>>> > > > related
>>> > > > > to
>>> > > > > > >>> the
>>> > > > > > >>> >> CAS
>>> > > > > > >>> >> >> > > server
>>> > > > > > >>> >> >> > > > > does
>>> > > > > > >>> >> >> > > > > > > the
>>> > > > > > >>> >> >> > > > > > > > > > same
>>> > > > > > >>> >> >> > > > > > > > > > >> thing for CAS (in pac4j), you
>>> will
>>> > > > > > >>> automatically
>>> > > > > > >>> >> get
>>> > > > > > >>> >> >> it
>>> > > > > > >>> >> >> > > when
>>> > > > > > >>> >> >> > > > > > > you'll
>>> > > > > > >>> >> >> > > > > > > > > > >> upgrade
>>> > > > > > >>> >> >> > > > > > > > > > >> pac4j.
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> To go even further, replacing
>>> LDAP
>>> > > Shiro
>>> > > > > > >>> >> >> authentication
>>> > > > > > >>> >> >> > is
>>> > > > > > >>> >> >> > > > > just
>>> > > > > > >>> >> >> > > > > > a
>>> > > > > > >>> >> >> > > > > > > > > matter
>>> > > > > > >>> >> >> > > > > > > > > > >> of
>>> > > > > > >>> >> >> > > > > > > > > > >> making pac4j LDAP authentication
>>> > > > available
>>> > > > > > via
>>> > > > > > >>> >> >> > > configuration
>>> > > > > > >>> >> >> > > > > > > > > parameters.
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> I hope it was clear enough.
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> Thanks.
>>> > > > > > >>> >> >> > > > > > > > > > >> Best regards,
>>> > > > > > >>> >> >> > > > > > > > > > >> Jérôme
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> 2015-12-03 20:45 GMT+01:00 larry
>>> > > mccay <
>>> > > > > > >>> >> >> > > > larry.mccay@gmail.com
>>> > > > > > >>> >> >> > > > > >:
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> > Excellent!
>>> > > > > > >>> >> >> > > > > > > > > > >> >
>>> > > > > > >>> >> >> > > > > > > > > > >> > I will carve out some time to
>>> do
>>> > > code
>>> > > > > > >>> review.
>>> > > > > > >>> >> >> > > > > > > > > > >> > We will need to get some
>>> insights
>>> > > into
>>> > > > > how
>>> > > > > > >>> to go
>>> > > > > > >>> >> >> about
>>> > > > > > >>> >> >> > > > > > testing:
>>> > > > > > >>> >> >> > > > > > > > > > >> >
>>> > > > > > >>> >> >> > > > > > > > > > >> > * is the CAS server going to
>>> be
>>> > > > > available
>>> > > > > > >>> for
>>> > > > > > >>> >> >> testing?
>>> > > > > > >>> >> >> > > > > > > > > > >> > * what are the specific and
>>> > > > > > >>> generic/standard (if
>>> > > > > > >>> >> >> any)
>>> > > > > > >>> >> >> > > > > > > > authentication
>>> > > > > > >>> >> >> > > > > > > > > > >> > mechanisms available - for
>>> > instance:
>>> > > > > > >>> >> >> > > > > > > > > > >> > - Facebook, Google,
>>> LinkedIn
>>> > and
>>> > > > CAS
>>> > > > > > are
>>> > > > > > >>> >> >> specifics
>>> > > > > > >>> >> >> > > > > > > > > > >> > - OAuth 2, OpenID Connect,
>>> > SAML
>>> > > > are
>>> > > > > > >>> >> >> > > generic/standards
>>> > > > > > >>> >> >> > > > -
>>> > > > > > >>> >> >> > > > > > that
>>> > > > > > >>> >> >> > > > > > > > may
>>> > > > > > >>> >> >> > > > > > > > > > be
>>> > > > > > >>> >> >> > > > > > > > > > >> > used for the above
>>> specifics...
>>> > > > > > >>> >> >> > > > > > > > > > >> > * how do we test things other
>>> than
>>> > > > CAS -
>>> > > > > > in
>>> > > > > > >>> >> terms of
>>> > > > > > >>> >> >> > > > getting
>>> > > > > > >>> >> >> > > > > > > > > > >> credentials,
>>> > > > > > >>> >> >> > > > > > > > > > >> > configuration, etc
>>> > > > > > >>> >> >> > > > > > > > > > >> >
>>> > > > > > >>> >> >> > > > > > > > > > >> > We could certainly do this is
>>> > phases
>>> > > > as
>>> > > > > > >>> well.
>>> > > > > > >>> >> >> > > > > > > > > > >> >
>>> > > > > > >>> >> >> > > > > > > > > > >> > If you can enumerate the
>>> things
>>> > that
>>> > > > > > should
>>> > > > > > >>> work
>>> > > > > > >>> >> and
>>> > > > > > >>> >> >> > > > provide
>>> > > > > > >>> >> >> > > > > > > some
>>> > > > > > >>> >> >> > > > > > > > > > >> testing
>>> > > > > > >>> >> >> > > > > > > > > > >> > details for CAS or as many as
>>> > > possible
>>> > > > > and
>>> > > > > > >>> OpenID
>>> > > > > > >>> >> >> > > Connect
>>> > > > > > >>> >> >> > > > > then
>>> > > > > > >>> >> >> > > > > > > we
>>> > > > > > >>> >> >> > > > > > > > > can
>>> > > > > > >>> >> >> > > > > > > > > > >> test
>>> > > > > > >>> >> >> > > > > > > > > > >> > the specific implementations
>>> that
>>> > > you
>>> > > > > > >>> provide and
>>> > > > > > >>> >> >> > enable
>>> > > > > > >>> >> >> > > > the
>>> > > > > > >>> >> >> > > > > > > > testing
>>> > > > > > >>> >> >> > > > > > > > > > of
>>> > > > > > >>> >> >> > > > > > > > > > >> > another OpenID Connect effort
>>> that
>>> > > is
>>> > > > in
>>> > > > > > the
>>> > > > > > >>> >> works
>>> > > > > > >>> >> >> in
>>> > > > > > >>> >> >> > > the
>>> > > > > > >>> >> >> > > > > > > > community.
>>> > > > > > >>> >> >> > > > > > > > > > >> >
>>> > > > > > >>> >> >> > > > > > > > > > >> > I'm not sure whether we want
>>> to
>>> > > commit
>>> > > > > > >>> >> contributions
>>> > > > > > >>> >> >> > > that
>>> > > > > > >>> >> >> > > > > are
>>> > > > > > >>> >> >> > > > > > > > > > dependent
>>> > > > > > >>> >> >> > > > > > > > > > >> on
>>> > > > > > >>> >> >> > > > > > > > > > >> > snapshots - we certainly can't
>>> > > release
>>> > > > > > with
>>> > > > > > >>> any
>>> > > > > > >>> >> such
>>> > > > > > >>> >> >> > > > > > > dependencies.
>>> > > > > > >>> >> >> > > > > > > > > > >> > I would hate to add a cleanup
>>> task
>>> > > to
>>> > > > a
>>> > > > > > >>> release
>>> > > > > > >>> >> to
>>> > > > > > >>> >> >> > make
>>> > > > > > >>> >> >> > > > sure
>>> > > > > > >>> >> >> > > > > > > there
>>> > > > > > >>> >> >> > > > > > > > > are
>>> > > > > > >>> >> >> > > > > > > > > > >> no
>>> > > > > > >>> >> >> > > > > > > > > > >> > snapshots in there.
>>> > > > > > >>> >> >> > > > > > > > > > >> > We will probably wait until
>>> after
>>> > > the
>>> > > > > > pac4j
>>> > > > > > >>> >> releases
>>> > > > > > >>> >> >> > to
>>> > > > > > >>> >> >> > > > > > commit.
>>> > > > > > >>> >> >> > > > > > > > > > >> >
>>> > > > > > >>> >> >> > > > > > > > > > >> > I am really happy that this
>>> > > > integration
>>> > > > > is
>>> > > > > > >>> >> happening
>>> > > > > > >>> >> >> > and
>>> > > > > > >>> >> >> > > > > that
>>> > > > > > >>> >> >> > > > > > it
>>> > > > > > >>> >> >> > > > > > > > > went
>>> > > > > > >>> >> >> > > > > > > > > > >> > rather smoothly.
>>> > > > > > >>> >> >> > > > > > > > > > >> > These sorts of authentication
>>> > > > protocols
>>> > > > > > are
>>> > > > > > >>> >> complex
>>> > > > > > >>> >> >> > and
>>> > > > > > >>> >> >> > > I
>>> > > > > > >>> >> >> > > > > > think
>>> > > > > > >>> >> >> > > > > > > we
>>> > > > > > >>> >> >> > > > > > > > > > >> lined up
>>> > > > > > >>> >> >> > > > > > > > > > >> > pretty well overall.
>>> > > > > > >>> >> >> > > > > > > > > > >> >
>>> > > > > > >>> >> >> > > > > > > > > > >> > Thanks for your work!
>>> > > > > > >>> >> >> > > > > > > > > > >> >
>>> > > > > > >>> >> >> > > > > > > > > > >> > On Thu, Dec 3, 2015 at 2:28
>>> PM,
>>> > > Jérôme
>>> > > > > > >>> LELEU <
>>> > > > > > >>> >> >> > > > > > leleuj@gmail.com>
>>> > > > > > >>> >> >> > > > > > > > > > wrote:
>>> > > > > > >>> >> >> > > > > > > > > > >> >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > Hi,
>>> > > > > > >>> >> >> > > > > > > > > > >> > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > I just sync'ed with master,
>>> > > cleaned
>>> > > > > > >>> >> dependencies
>>> > > > > > >>> >> >> and
>>> > > > > > >>> >> >> > > > added
>>> > > > > > >>> >> >> > > > > > > > missing
>>> > > > > > >>> >> >> > > > > > > > > > >> > > Javadocs. Everything works
>>> > > correctly
>>> > > > > > now.
>>> > > > > > >>> Many
>>> > > > > > >>> >> >> > thanks.
>>> > > > > > >>> >> >> > > > > > > > > > >> > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > The pull request is ready
>>> for a
>>> > > full
>>> > > > > > code
>>> > > > > > >>> >> review:
>>> > > > > > >>> >> >> > > > > > > > > > >> > >
>>> > > > https://github.com/apache/knox/pull/2
>>> > > > > > >>> >> >> > > > > > > > > > >> > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > I'll write the documentation
>>> > after
>>> > > > the
>>> > > > > > >>> pac4j
>>> > > > > > >>> >> >> > releases
>>> > > > > > >>> >> >> > > (I
>>> > > > > > >>> >> >> > > > > > hope
>>> > > > > > >>> >> >> > > > > > > > next
>>> > > > > > >>> >> >> > > > > > > > > > >> week).
>>> > > > > > >>> >> >> > > > > > > > > > >> > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > Thanks.
>>> > > > > > >>> >> >> > > > > > > > > > >> > > Best regards,
>>> > > > > > >>> >> >> > > > > > > > > > >> > > Jérôme
>>> > > > > > >>> >> >> > > > > > > > > > >> > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > 2015-12-02 19:18 GMT+01:00
>>> larry
>>> > > > > mccay <
>>> > > > > > >>> >> >> > > > > > larry.mccay@gmail.com
>>> > > > > > >>> >> >> > > > > > > >:
>>> > > > > > >>> >> >> > > > > > > > > > >> > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > Fixed in
>>> > > > > > >>> >> >> > > > https://issues.apache.org/jira/browse/KNOX-636
>>> > > > > > >>> >> >> > > > > .
>>> > > > > > >>> >> >> > > > > > > > > > >> > > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > On Wed, Dec 2, 2015 at
>>> 12:42
>>> > PM,
>>> > > > > larry
>>> > > > > > >>> mccay
>>> > > > > > >>> >> <
>>> > > > > > >>> >> >> > > > > > > > > > larry.mccay@gmail.com
>>> > > > > > >>> >> >> > > > > > > > > > >> >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > wrote:
>>> > > > > > >>> >> >> > > > > > > > > > >> > > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > > Sure - I can file a
>>> JIRA and
>>> > > > > commit
>>> > > > > > a
>>> > > > > > >>> fix.
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > > The secret generation
>>> should
>>> > > be
>>> > > > > done
>>> > > > > > >>> in one
>>> > > > > > >>> >> >> > > instance
>>> > > > > > >>> >> >> > > > > and
>>> > > > > > >>> >> >> > > > > > > > > > >> replicated
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > across
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > > others.
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > > This
>>> replication/management
>>> > of
>>> > > > the
>>> > > > > > >>> >> credential
>>> > > > > > >>> >> >> > > stores
>>> > > > > > >>> >> >> > > > > is
>>> > > > > > >>> >> >> > > > > > > > > outside
>>> > > > > > >>> >> >> > > > > > > > > > of
>>> > > > > > >>> >> >> > > > > > > > > > >> > the
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > > scope of Knox itself as
>>> of
>>> > > now.
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > > Documentation is done in
>>> > > > markdown
>>> > > > > > and
>>> > > > > > >>> is
>>> > > > > > >>> >> >> > > > contributing
>>> > > > > > >>> >> >> > > > > > > > details
>>> > > > > > >>> >> >> > > > > > > > > > are
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > > available at:
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > >
>>> > > > > > >>> >> >> > > > > > > > > > >> >
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > >
>>> > > > > > >>> >> >> > > > > > >
>>> > > > > > >>> >> >> > > > > >
>>> > > > > > >>> >> >> > > > >
>>> > > > > > >>> >> >> > > >
>>> > > > > > >>> >> >> > >
>>> > > > > > >>> >> >> >
>>> > > > > > >>> >> >>
>>> > > > > > >>> >>
>>> > > > > > >>>
>>> > > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > > Which should give you a
>>> > > general
>>> > > > > > idea.
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > > Find an example like:
>>> > > > > > >>> ./trunk/books/0.7.0/
>>> > > > > > >>> >> >> > > > > > > > > > >> > >
>>> config_preauth_sso_provider.md
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > > For an example of
>>> typical
>>> > > > content
>>> > > > > > and
>>> > > > > > >>> >> format.
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > > Here is how that example
>>> > > > renders:
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > >
>>> > > > > > >>> >> >> > > > > > > > > > >> >
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > >
>>> > > > > > >>> >> >> > > > > > >
>>> > > > > > >>> >> >> > > > > >
>>> > > > > > >>> >> >> > > > >
>>> > > > > > >>> >> >> > > >
>>> > > > > > >>> >> >> > >
>>> > > > > > >>> >> >> >
>>> > > > > > >>> >> >>
>>> > > > > > >>> >>
>>> > > > > > >>>
>>> > > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > > You'll need to tie it
>>> into
>>> > the
>>> > > > > rest
>>> > > > > > >>> of the
>>> > > > > > >>> >> >> book
>>> > > > > > >>> >> >> > -
>>> > > > > > >>> >> >> > > > just
>>> > > > > > >>> >> >> > > > > > > grep
>>> > > > > > >>> >> >> > > > > > > > > for
>>> > > > > > >>> >> >> > > > > > > > > > >> where
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > that
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > > filename is referenced.
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > > To test how it renders
>>> build
>>> > > the
>>> > > > > > site
>>> > > > > > >>> with:
>>> > > > > > >>> >> >> > "ant"
>>> > > > > > >>> >> >> > > > and
>>> > > > > > >>> >> >> > > > > > note
>>> > > > > > >>> >> >> > > > > > > > the
>>> > > > > > >>> >> >> > > > > > > > > > >> url to
>>> > > > > > >>> >> >> > > > > > > > > > >> > > the
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > > 0.7.0 book.
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > > On Wed, Dec 2, 2015 at
>>> 12:12
>>> > > PM,
>>> > > > > > >>> Jérôme
>>> > > > > > >>> >> LELEU
>>> > > > > > >>> >> >> <
>>> > > > > > >>> >> >> > > > > > > > > leleuj@gmail.com
>>> > > > > > >>> >> >> > > > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > wrote:
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> Hi,
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> Why it doesn't work for
>>> > pac4j
>>> > > > > while
>>> > > > > > >>> it
>>> > > > > > >>> >> works
>>> > > > > > >>> >> >> > for
>>> > > > > > >>> >> >> > > > > others
>>> > > > > > >>> >> >> > > > > > > is
>>> > > > > > >>> >> >> > > > > > > > a
>>> > > > > > >>> >> >> > > > > > > > > > bit
>>> > > > > > >>> >> >> > > > > > > > > > >> > > strange
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> to
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> me, but if you have the
>>> > patch
>>> > > > in
>>> > > > > > >>> front of
>>> > > > > > >>> >> >> your
>>> > > > > > >>> >> >> > > > eyes,
>>> > > > > > >>> >> >> > > > > > I'd
>>> > > > > > >>> >> >> > > > > > > > > rather
>>> > > > > > >>> >> >> > > > > > > > > > >> > prefer
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > you
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> to commit it. In all
>>> cases,
>>> > > > I'll
>>> > > > > > >>> sync with
>>> > > > > > >>> >> >> the
>>> > > > > > >>> >> >> > > > > master.
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> There was one question
>>> you
>>> > > > didn't
>>> > > > > > >>> answer
>>> > > > > > >>> >> >> > > > previously:
>>> > > > > > >>> >> >> > > > > is
>>> > > > > > >>> >> >> > > > > > > the
>>> > > > > > >>> >> >> > > > > > > > > > >> password
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> generated for the pac4j
>>> > > > provider
>>> > > > > > the
>>> > > > > > >>> same
>>> > > > > > >>> >> >> > across
>>> > > > > > >>> >> >> > > > all
>>> > > > > > >>> >> >> > > > > > > > gateway
>>> > > > > > >>> >> >> > > > > > > > > > >> > > instances?
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> Because I expect to
>>> have
>>> > the
>>> > > > same
>>> > > > > > >>> value
>>> > > > > > >>> >> as I
>>> > > > > > >>> >> >> > use
>>> > > > > > >>> >> >> > > it
>>> > > > > > >>> >> >> > > > > to
>>> > > > > > >>> >> >> > > > > > > > > encrypt
>>> > > > > > >>> >> >> > > > > > > > > > /
>>> > > > > > >>> >> >> > > > > > > > > > >> > > decrypt
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> data.
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> I will add the Javadoc.
>>> > After
>>> > > > > that,
>>> > > > > > >>> you
>>> > > > > > >>> >> can
>>> > > > > > >>> >> >> > > review
>>> > > > > > >>> >> >> > > > > the
>>> > > > > > >>> >> >> > > > > > > pull
>>> > > > > > >>> >> >> > > > > > > > > > >> request
>>> > > > > > >>> >> >> > > > > > > > > > >> > > more
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> completely.
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> What do you expect for
>>> the
>>> > > > > > >>> documentation?
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> Notice that pac4j
>>> > > dependencies
>>> > > > > are
>>> > > > > > >>> still
>>> > > > > > >>> >> >> > > snapshots,
>>> > > > > > >>> >> >> > > > > but
>>> > > > > > >>> >> >> > > > > > > > they
>>> > > > > > >>> >> >> > > > > > > > > > >> will be
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> released in a week or
>>> two.
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> Thanks.
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> Best regards,
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> Jérôme
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> 2015-12-02 17:51
>>> GMT+01:00
>>> > > > larry
>>> > > > > > >>> mccay <
>>> > > > > > >>> >> >> > > > > > > > > larry.mccay@gmail.com
>>> > > > > > >>> >> >> > > > > > > > > > >:
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > Jérôme -
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > If you would like to
>>> add
>>> > > that
>>> > > > > > >>> change as
>>> > > > > > >>> >> >> part
>>> > > > > > >>> >> >> > of
>>> > > > > > >>> >> >> > > > > your
>>> > > > > > >>> >> >> > > > > > > > patch
>>> > > > > > >>> >> >> > > > > > > > > or
>>> > > > > > >>> >> >> > > > > > > > > > >> as a
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > separately filed
>>> JIRA to
>>> > > fix
>>> > > > a
>>> > > > > > bug
>>> > > > > > >>> that
>>> > > > > > >>> >> >> would
>>> > > > > > >>> >> >> > > > > > certainly
>>> > > > > > >>> >> >> > > > > > > > be
>>> > > > > > >>> >> >> > > > > > > > > > >> > welcomed.
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > Otherwise, I can do
>>> it.
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > Let me know.
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > thanks,
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > --larry
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > On Wed, Dec 2, 2015
>>> at
>>> > > 11:44
>>> > > > > AM,
>>> > > > > > >>> larry
>>> > > > > > >>> >> >> mccay
>>> > > > > > >>> >> >> > <
>>> > > > > > >>> >> >> > > > > > > > > > >> > larry.mccay@gmail.com
>>> > > > > > >>> >> >> > > > > > > > > > >> > > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > wrote:
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > > Okay - I had to
>>> add an
>>> > > > > override
>>> > > > > > >>> of
>>> > > > > > >>> >> >> > > > > > getUserPrincipal()
>>> > > > > > >>> >> >> > > > > > > > to
>>> > > > > > >>> >> >> > > > > > > > > > the
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >
>>> > > > > > >>> >> IdentityAsserterHttpServletRequestWrapper
>>> > > > > > >>> >> >> > and
>>> > > > > > >>> >> >> > > > > > return
>>> > > > > > >>> >> >> > > > > > > > the
>>> > > > > > >>> >> >> > > > > > > > > > >> member
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> variable
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > > username and it
>>> works
>>> > > like
>>> > > > a
>>> > > > > > >>> charm.
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > > Why I haven't seen
>>> this
>>> > > > same
>>> > > > > > >>> behavior
>>> > > > > > >>> >> >> with
>>> > > > > > >>> >> >> > > > other
>>> > > > > > >>> >> >> > > > > > > > > providers
>>> > > > > > >>> >> >> > > > > > > > > > >> is a
>>> > > > > > >>> >> >> > > > > > > > > > >> > > bit
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> of a
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > > mystery but they
>>> must
>>> > be
>>> > > > > adding
>>> > > > > > >>> other
>>> > > > > > >>> >> >> > > wrappers
>>> > > > > > >>> >> >> > > > > that
>>> > > > > > >>> >> >> > > > > > > > > handle
>>> > > > > > >>> >> >> > > > > > > > > > >> it.
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > > This is quite cool,
>>> > > Jérôme!
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > > On Wed, Dec 2,
>>> 2015 at
>>> > > > 10:41
>>> > > > > > AM,
>>> > > > > > >>> larry
>>> > > > > > >>> >> >> > mccay
>>> > > > > > >>> >> >> > > <
>>> > > > > > >>> >> >> > > > > > > > > > >> > > larry.mccay@gmail.com
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > > wrote:
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >> That was it -
>>> thanks!
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >> On Wed, Dec 2,
>>> 2015 at
>>> > > > 10:20
>>> > > > > > AM,
>>> > > > > > >>> >> Jérôme
>>> > > > > > >>> >> >> > > LELEU
>>> > > > > > >>> >> >> > > > <
>>> > > > > > >>> >> >> > > > > > > > > > >> > leleuj@gmail.com>
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> wrote:
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> This is my exact
>>> > > command
>>> > > > > > line:
>>> > > > > > >>> mvn
>>> > > > > > >>> >> >> > > -Prelease
>>> > > > > > >>> >> >> > > > > > clean
>>> > > > > > >>> >> >> > > > > > > > > > install
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> -DskipTests
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> You use an
>>> internal
>>> > > Maven
>>> > > > > > >>> >> repository to
>>> > > > > > >>> >> >> > > fetch
>>> > > > > > >>> >> >> > > > > > > > > > dependencies
>>> > > > > > >>> >> >> > > > > > > > > > >> > from
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > internet:
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
>>> > > > > > >>> >> >> > > > > > > > > > >> > >
>>> > > > > > >>> >> >> > > > > > > >
>>> > > > > > >>> >> >> > >
>>> > > > > > >>>
>>> > > http://nexus-private.hortonworks.com/nexus/content/groups/public/
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> Does this
>>> repository
>>> > > have
>>> > > > > > >>> access to
>>> > > > > > >>> >> the
>>> > > > > > >>> >> >> > > > remote
>>> > > > > > >>> >> >> > > > > > > > > Snapshots
>>> > > > > > >>> >> >> > > > > > > > > > >> > > Sonatype
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> repo?
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> 2015-12-02 16:16
>>> > > > GMT+01:00
>>> > > > > > >>> larry
>>> > > > > > >>> >> mccay
>>> > > > > > >>> >> >> <
>>> > > > > > >>> >> >> > > > > > > > > > >> larry.mccay@gmail.com
>>> > > > > > >>> >> >> > > > > > > > > > >> > >:
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > hmmm - I used:
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > mvn clean
>>> install
>>> > > > > > >>> -DskipTests=true
>>> > > > > > >>> >> >> > > > -Prelease
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > The repository
>>> > entry
>>> > > is
>>> > > > > in
>>> > > > > > >>> there
>>> > > > > > >>> >> >> > already.
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > No worky.
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > On Wed, Dec 2,
>>> 2015
>>> > > at
>>> > > > > > 10:12
>>> > > > > > >>> AM,
>>> > > > > > >>> >> >> Jérôme
>>> > > > > > >>> >> >> > > > > LELEU <
>>> > > > > > >>> >> >> > > > > > > > > > >> > > leleuj@gmail.com
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> wrote:
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Hi,
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > You need the
>>> > > > j2e-pac4j
>>> > > > > > >>> >> dependencies
>>> > > > > > >>> >> >> > as
>>> > > > > > >>> >> >> > > > well
>>> > > > > > >>> >> >> > > > > > as
>>> > > > > > >>> >> >> > > > > > > > the
>>> > > > > > >>> >> >> > > > > > > > > > >> pac4j-*
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> dependencies,
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > but you don't
>>> > need
>>> > > to
>>> > > > > > >>> build them
>>> > > > > > >>> >> >> > > locally
>>> > > > > > >>> >> >> > > > > > > > > (hopefully).
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > But you need
>>> a
>>> > > > > dependency
>>> > > > > > >>> on the
>>> > > > > > >>> >> >> > > Sonatype
>>> > > > > > >>> >> >> > > > > > > > snapshots
>>> > > > > > >>> >> >> > > > > > > > > > >> > > repository
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> (where the
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > snapshot
>>> versions
>>> > > are
>>> > > > > > >>> hosted),
>>> > > > > > >>> >> >> which
>>> > > > > > >>> >> >> > is
>>> > > > > > >>> >> >> > > > > added
>>> > > > > > >>> >> >> > > > > > > for
>>> > > > > > >>> >> >> > > > > > > > > > >> Maven in
>>> > > > > > >>> >> >> > > > > > > > > > >> > > the
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> root
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > pom.xml:
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> > > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > >
>>> > > > > > >>> >> >> > > > > > > > > > >> >
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > >
>>> > > > > > >>> >> >> > > > > > >
>>> > > > > > >>> >> >> > > > > >
>>> > > > > > >>> >> >> > > > >
>>> > > > > > >>> >> >> > > >
>>> > > > > > >>> >> >> > >
>>> > > > > > >>> >> >> >
>>> > > > > > >>> >> >>
>>> > > > > > >>> >>
>>> > > > > > >>>
>>> > > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > If you use
>>> Ant
>>> > for
>>> > > > the
>>> > > > > > >>> build,
>>> > > > > > >>> >> there
>>> > > > > > >>> >> >> > is
>>> > > > > > >>> >> >> > > > > maybe
>>> > > > > > >>> >> >> > > > > > a
>>> > > > > > >>> >> >> > > > > > > > > glitch
>>> > > > > > >>> >> >> > > > > > > > > > >> to
>>> > > > > > >>> >> >> > > > > > > > > > >> > > find
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> the
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > Sonatype
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Maven repo.
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Thanks.
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Best regards,
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Jérôme
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > 2015-12-02
>>> 16:06
>>> > > > > > GMT+01:00
>>> > > > > > >>> larry
>>> > > > > > >>> >> >> > mccay
>>> > > > > > >>> >> >> > > <
>>> > > > > > >>> >> >> > > > > > > > > > >> > > larry.mccay@gmail.com
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >:
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > 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.mccay@gmail.com>
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > wrote:
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > >
>>> > > > > > >>> >> gateway-provider-security-pac4j
>>> > > > > > >>> >> >> > > > doesn't
>>> > > > > > >>> >> >> > > > > > > > build -
>>> > > > > > >>> >> >> > > > > > > > > > do
>>> > > > > > >>> >> >> > > > > > > > > > >> you
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > have
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> a
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> pending
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > > change
>>> for
>>> > your
>>> > > > > > >>> pom.xml or
>>> > > > > > >>> >> >> > > something?
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > > >
>>> > > > > > >>> >> >> > > > > > > > > > >> > >
>>> > > > > > >>> >> >> > > > > > > > > > >> >
>>> > > > > > >>> >> >> > > > > > > > > > >>
>>> > > > > > >>> >> >> > > > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > > >
>>> > > > > > >>> >> >> > > > > > > >
>>> > > > > > >>> >> >> > > > > > >
>>> > > > > > >>> >> >> > > > > >
>>> > > > > > >>> >> >> > > > >
>>> > > > > > >>> >> >> > > >
>>> > > > > > >>> >> >> > >
>>> > > > > > >>> >> >> >
>>> > > > > > >>> >> >>
>>> > > > > > >>> >>
>>> > > > > > >>>
>>> > > > > > >>
>>> > > > > > >>
>>> > > > > > >
>>> > > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>>
>>
>
Re: pac4j and Apache Knox
Posted by larry mccay <lm...@apache.org>.
Excellent - it worked!
I will review the docs with the hurdles that I had to overcome in mind.
Hoping to get this committed today. :)
On Fri, Jan 15, 2016 at 11:02 AM, larry mccay <lm...@apache.org> wrote:
> Okay - got past that now....
> We are getting closer!
>
> On Fri, Jan 15, 2016 at 10:56 AM, Jérôme LELEU <le...@gmail.com> wrote:
>
>> Hi,
>>
>> We have one callback url (the KnoxSSO url) and multiple identity providers
>> so to distinguish between all clients, pac4j uses the callback url + the
>> client_name parameter (Clients.DEFAULT_CLIENT_NAME_PARAMETER).
>>
>> The redirection url generated to the identity provider has this
>> client_name
>> parameter: this is why it works well with the CAS server which redirects
>> the user (after a successfull url) to the originally provided url.
>>
>> For Okta, on server side, the redirection relies on the defined url. *So
>> you must define the callback url in Okta as your KnoxSSO url + the
>> client_name parameter = SAML2Client*.
>>
>> I myself have
>> https://127.0.0.1:8443/gateway/idp/api/v1/websso?client_name=SAML2Client
>> for my Okta app. And the logic of the pac4j gateway provider is based on
>> this client_name parameter to know if it's a callback or an access call.
>> Hence the infinite loop in your case.
>>
>> I guess we need to add a warning in the documentation for that. Just let
>> met know how you want to proceed.
>>
>> Thanks.
>> Best regards,
>> Jérôme
>>
>>
>>
>>
>>
>> 2016-01-15 16:38 GMT+01:00 larry mccay <lm...@apache.org>:
>>
>> > Hi Jérôme -
>> >
>> > Thanks for the updated docs - I will take a look today.
>> >
>> > I am currently still trying to test okta and stuck in a redirect loop.
>> > Did you have to change anything in order to get the
>> > request.getParameter(Clients.DEFAULT_CLIENT_NAME_PARAMETER)
>> > set for the callbacks from okta? It is null in my environment and
>> therefore
>> > it moves on to the following:
>> >
>> > // otherwise just apply security and requires authentication
>> >
>> > // apply RequiresAuthenticationFilter
>> >
>> > requiresAuthenticationFilter.doFilter(servletRequest,
>> > servletResponse, filterChain);
>> >
>> > which obviously results in the redirect loop.
>> >
>> > Curious whether you ran into that...
>> >
>> > thanks,
>> >
>> > --larry
>> >
>> > On Fri, Jan 15, 2016 at 4:00 AM, Jérôme LELEU <le...@gmail.com> wrote:
>> >
>> > > Hi,
>> > >
>> > > I just uploaded a new patch for the documentation with the links
>> pointing
>> > > to the pac4j wiki. It should be clearer.
>> > >
>> > > Thanks.
>> > > Best regards,
>> > > Jérôme
>> > >
>> > >
>> > > 2016-01-14 13:20 GMT+01:00 larry mccay <lm...@apache.org>:
>> > >
>> > > > That sounds pretty reasonable.
>> > > > I will likely document a few of the integrations that are possible
>> in
>> > > > blogs/tutorials anyway.
>> > > >
>> > > > I don't want testing of Knox at release time to have to jump around
>> to
>> > > much
>> > > > in order to be able to test.
>> > > > I think we can make that all good though.
>> > > >
>> > > > I will see what I can do with okta today.
>> > > >
>> > > > On Thu, Jan 14, 2016 at 5:00 AM, Jérôme LELEU <le...@gmail.com>
>> > wrote:
>> > > >
>> > > > > Hi,
>> > > > >
>> > > > > Yes, the documentation is a bit too light. But you guessed it
>> right:
>> > we
>> > > > > need to have a keystore for encryption.
>> > > > >
>> > > > > The saml.identityProviderMetadataPath can point to a local
>> resource
>> > or
>> > > > to a
>> > > > > remote one, using the right prefix: resource:, file: or an url (by
>> > > > default,
>> > > > > it is a file path). This must be documented though.
>> > > > >
>> > > > > With Okta, I used the defined url (Single Sign On URL = Recipient
>> > URL =
>> > > > > Destination URL) for the serviceProviderEntityId, but I think it
>> may
>> > > > > depends on IdP as well. Reading the spec, it must be an URI, but
>> I'm
>> > > not
>> > > > > sure if the SP metadata should be really available on this url.
>> For
>> > > Okta,
>> > > > > it doesn't matter.
>> > > > >
>> > > > > According to your SAML configuration, the SP metadata will be
>> > generated
>> > > > > somewhere and this somewhere can be defined via the
>> > > > > serviceProviderMetadataPath parameter. You generally need to
>> update
>> > > your
>> > > > > metadata to the IdP (not required for Okta though). Both the SP
>> and
>> > IdP
>> > > > > must know each other.
>> > > > >
>> > > > > When writing the documentation, I went fast on these parameters
>> with
>> > > the
>> > > > > feeling they were regular ones, but indeed, the description in the
>> > Knox
>> > > > > manual is not enough. This is somehow a bit normal as the real
>> > > > > documentation for SAML is on the SAML wiki:
>> > > > >
>> https://github.com/pac4j/pac4j/wiki/Clients#details-for-saml-support
>> > > > >
>> > > > > So I propose to keep the Knox documentation mostly "as is", but
>> add
>> > > links
>> > > > > to the pac4j wiki (where I could more easily made updates). All
>> pac4j
>> > > > > integrations need this documentation so it's better to centralize
>> it,
>> > > > from
>> > > > > my point of view. What do you think?
>> > > > >
>> > > > > Thanks.
>> > > > > Best regards,
>> > > > > Jérôme
>> > > > >
>> > > > >
>> > > > >
>> > > > > 2016-01-13 19:37 GMT+01:00 larry mccay <lm...@apache.org>:
>> > > > >
>> > > > > > Hi Jérôme -
>> > > > > >
>> > > > > > I'm trying to configure the pac4j provider for an okta
>> > "application"
>> > > > > that I
>> > > > > > created.
>> > > > > > The following (from KNOX-642 docs patch) isn't quite enough to
>> make
>> > > it
>> > > > > > clear to me how to go about doing so:
>> > > > > >
>> > > > > > +saml.keystorePassword | Password of the keystore
>> > > (storepass)
>> > > > > > +saml.privateKeyPassword | Password for the private
>> key
>> > > > > (keypass)
>> > > > > > +saml.keystorePath | Path of the keystore
>> > > > > > +saml.identityProviderMetadataPath | Path of the
>> identity
>> > > > > > provider metadata
>> > > > > > +saml.maximumAuthenticationLifetime | Maximum lifetime
>> > for
>> > > > > > authentication
>> > > > > > +saml.serviceProviderEntityId | Identifier of the
>> service
>> > > > > > provider
>> > > > > > +saml.serviceProviderMetadataPath | Path of the
>> service
>> > > > > provider
>> > > > > > metadata
>> > > > > >
>> > > > > > I assume that I can use the gateway.jks keystore and the
>> > > > gateway-identity
>> > > > > > keypair to do the request signing and that that information is
>> what
>> > > is
>> > > > > > needed for the first 3 params. Unfortunately, I don't see any
>> use
>> > of
>> > > > > > gateway services to get the master secret therefore it needs to
>> be
>> > in
>> > > > > clear
>> > > > > > text here. This won't work - but may not be a show stopper for
>> > > > committing
>> > > > > > to master as long as we follow up with a fix.
>> > > > > >
>> > > > > > Can saml.identityProviderMetadataPath point to a remote
>> location or
>> > > > does
>> > > > > it
>> > > > > > have to be local to the SP application. This would likely
>> require
>> > it
>> > > to
>> > > > > be
>> > > > > > on the local filesystem, provisioned by the contributor into the
>> > > > > generated
>> > > > > > web app or in some central location via NFS or something like
>> that.
>> > > > > >
>> > > > > > The okta application that I created is called KnoxSSO - is that
>> the
>> > > > value
>> > > > > > for saml.serviceProviderEntityId?
>> > > > > >
>> > > > > > The saml.serviceProviderMetadataPath has the same questions as
>> the
>> > > > > metadata
>> > > > > > for the IDP. In addition, is there a sample metadata file that
>> we
>> > can
>> > > > > > provide for the use of pac4j with KnoxSSO?
>> > > > > >
>> > > > > > I think that getting this working and clean (no clear text
>> > passwords)
>> > > > > will
>> > > > > > make a great feature and blog for featuring pac4j provider and
>> the
>> > > > 0.8.0
>> > > > > > release. So, let's try and iron this out clearly.
>> > > > > >
>> > > > > > I would really like to get this working and committed in the
>> next
>> > > > couple
>> > > > > > days to free us up for follow up items. In particular we need
>> time
>> > to
>> > > > > > figure out whether the identity assertion providers that we
>> > currently
>> > > > > have
>> > > > > > will suffice for an apache release that is featuring this new
>> > > > > > functionality.
>> > > > > >
>> > > > > > I will also add the above comments/questions to the JIRA for
>> > > > visibility.
>> > > > > >
>> > > > > > thanks,
>> > > > > >
>> > > > > > --larry
>> > > > > >
>> > > > > > On Fri, Jan 8, 2016 at 12:40 PM, larry mccay <lmccay@apache.org
>> >
>> > > > wrote:
>> > > > > >
>> > > > > > > Jérôme -
>> > > > > > >
>> > > > > > > My testing of OpenID Connect is blocked.
>> > > > > > > Can you see the comments in KNOX-641?
>> > > > > > >
>> > > > > > > thanks,
>> > > > > > >
>> > > > > > > --larry
>> > > > > > >
>> > > > > > > On Wed, Jan 6, 2016 at 2:30 PM, larry mccay <
>> > larry.mccay@gmail.com
>> > > >
>> > > > > > wrote:
>> > > > > > >
>> > > > > > >> Jérôme -
>> > > > > > >>
>> > > > > > >> Please see the comments on KNOX-641.
>> > > > > > >>
>> > > > > > >> thanks,
>> > > > > > >>
>> > > > > > >> --larry
>> > > > > > >>
>> > > > > > >> On Wed, Jan 6, 2016 at 11:24 AM, Kevin Minder <
>> > > > > > >> kevin.minder@hortonworks.com> wrote:
>> > > > > > >>
>> > > > > > >>> I can certainly appreciate the issue of including external
>> > > > resources
>> > > > > in
>> > > > > > >>> automated tests. Nothing has driven me more crazy over the
>> > > years.
>> > > > > The
>> > > > > > >>> flip side of this of course is not finding out about a
>> breakage
>> > > > until
>> > > > > > >>> someone is willing to go through the manual testing which
>> will
>> > > > > > typically
>> > > > > > >>> happen just before a release. Also the implication is that
>> > these
>> > > > > > testing
>> > > > > > >>> procedures must be very will documented so that they can be
>> > > > continue
>> > > > > > to be
>> > > > > > >>> run once any of us are no longer active in the project.
>> > > > > > >>>
>> > > > > > >>>
>> > > > > > >>>
>> > > > > > >>> On 1/6/16, 2:12 AM, "Jérôme LELEU" <le...@gmail.com>
>> wrote:
>> > > > > > >>>
>> > > > > > >>> >Hi,
>> > > > > > >>> >
>> > > > > > >>> >Yes, you can hit the CAS server at Heroku. Notice it's a
>> > Heroku
>> > > > free
>> > > > > > >>> server
>> > > > > > >>> >so it needs to be re-activated first (it takes a couple of
>> > > > seconds).
>> > > > > > So
>> > > > > > >>> for
>> > > > > > >>> >a UI test, you should first hit it, wait 30 seconds and
>> then
>> > > > perform
>> > > > > > the
>> > > > > > >>> >test.
>> > > > > > >>> >
>> > > > > > >>> >Just my 2 cents:
>> > > > > > >>> >Using automated UI tests was my first strategy for pac4j
>> but
>> > I
>> > > > > > finally
>> > > > > > >>> >gave up because public providers change very often, at
>> least
>> > > > enough
>> > > > > to
>> > > > > > >>> make
>> > > > > > >>> >the maintenance tests a nightmare. Currently, I'm using
>> manual
>> > > > tests
>> > > > > > >>> (the
>> > > > > > >>> >same for all demos), it takes me around 5 minutes to play
>> them
>> > > all
>> > > > > by
>> > > > > > >>> hand
>> > > > > > >>> >(for a demo) and I launched manually the UI tests I have
>> for
>> > > every
>> > > > > > major
>> > > > > > >>> >pac4j release. Just to say UI tests are not that easy. For
>> a
>> > CAS
>> > > > > > server,
>> > > > > > >>> >it's fairly feasible as the CAS server and protocol change
>> > > rarely.
>> > > > > > >>> >That's why for Knox, I did some compromise with a simulated
>> > web
>> > > > test
>> > > > > > >>> (based
>> > > > > > >>> >on the basic auth). See:
>> > > > > > >>> >
>> > > > > > >>>
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/knox/pull/2/files#diff-d0c880ca71b310dbe57975c577535e97R47
>> > > > > > >>> >
>> > > > > > >>> >Thanks.
>> > > > > > >>> >Best regards,
>> > > > > > >>> >Jérôme
>> > > > > > >>> >
>> > > > > > >>> >
>> > > > > > >>> >
>> > > > > > >>> >2016-01-05 21:20 GMT+01:00 Kevin Minder <
>> > > > > kevin.minder@hortonworks.com
>> > > > > > >:
>> > > > > > >>> >
>> > > > > > >>> >> From my perspective it would be ideal if there were some
>> > > > > automatable
>> > > > > > >>> >> functional tests for this. I’m not advocating that
>> these be
>> > > > > > something
>> > > > > > >>> >> included in “mvn clean install” as that is running too
>> long
>> > as
>> > > > it
>> > > > > > is.
>> > > > > > >>> >> Given that I don’t have as much context as Larry, I have
>> > some
>> > > > > > >>> questions
>> > > > > > >>> >> about what this would take. Lets say we had permission
>> to
>> > hit
>> > > > > > >>> >> https://casserverpac4j.herokuapp.com/login as part of
>> some
>> > > low
>> > > > > > >>> frequency
>> > > > > > >>> >> automated tests (e.g. Once nighty). What static
>> credentials
>> > > and
>> > > > > > >>> other test
>> > > > > > >>> >> automation infrastructure would need to be implemented in
>> > > > support
>> > > > > of
>> > > > > > >>> this?
>> > > > > > >>> >> I understand that the test suite would require at a
>> minimum
>> > > > > > >>> >> 1) a test driver
>> > > > > > >>> >> 2) a protected mock UI and
>> > > > > > >>> >> 3) an appropriately configured Knox
>> > > > > > >>> >> 4) a profile enabled maven module
>> > > > > > >>> >> 5) an Apache jenkins job
>> > > > > > >>> >> but I’m sure I’m missing other things. I’m certainly
>> > willing
>> > > to
>> > > > > > help
>> > > > > > >>> >> setup the skeleton infrastructure (e.g. test driver, mock
>> > UI,
>> > > > > maven
>> > > > > > >>> module,
>> > > > > > >>> >> jenkins job)
>> > > > > > >>> >>
>> > > > > > >>> >>
>> > > > > > >>> >>
>> > > > > > >>> >> On 1/5/16, 2:54 PM, "larry mccay" <larry.mccay@gmail.com
>> >
>> > > > wrote:
>> > > > > > >>> >>
>> > > > > > >>> >> >Okay, very good.
>> > > > > > >>> >> >I've used TestShib for the picketlink provider - thanks
>> for
>> > > the
>> > > > > > >>> pointers!
>> > > > > > >>> >> >
>> > > > > > >>> >> >On Tue, Jan 5, 2016 at 1:38 PM, Jérôme LELEU <
>> > > leleuj@gmail.com
>> > > > >
>> > > > > > >>> wrote:
>> > > > > > >>> >> >
>> > > > > > >>> >> >> The online CAS server (
>> > > > > > https://casserverpac4j.herokuapp.com/login)
>> > > > > > >>> uses
>> > > > > > >>> >> >> the
>> > > > > > >>> >> >> CAS protocol. SAML support can be tested using some
>> > online
>> > > > IdP
>> > > > > > like
>> > > > > > >>> >> Okta,
>> > > > > > >>> >> >> TestShib, OpenFeide, Ssocircle...
>> > > > > > >>> >> >>
>> > > > > > >>> >> >>
>> > > > > > >>> >> >> 2016-01-05 17:32 GMT+01:00 larry mccay <
>> > > > larry.mccay@gmail.com
>> > > > > >:
>> > > > > > >>> >> >>
>> > > > > > >>> >> >> > Great - thanks for that pointer!
>> > > > > > >>> >> >> >
>> > > > > > >>> >> >> > I will take a look at that and help drive the
>> release
>> > > > related
>> > > > > > >>> testing.
>> > > > > > >>> >> >> > Merge testing will be gated on CAS server (is this
>> SAML
>> > > or
>> > > > > CAS
>> > > > > > >>> >> protocol?)
>> > > > > > >>> >> >> > and testBasicAuth.
>> > > > > > >>> >> >> >
>> > > > > > >>> >> >> > On Tue, Jan 5, 2016 at 10:52 AM, Jérôme LELEU <
>> > > > > > leleuj@gmail.com>
>> > > > > > >>> >> wrote:
>> > > > > > >>> >> >> >
>> > > > > > >>> >> >> > > Hi,
>> > > > > > >>> >> >> > >
>> > > > > > >>> >> >> > > Glad to hear back from you!
>> > > > > > >>> >> >> > >
>> > > > > > >>> >> >> > > The core pac4j project is fully tested by unit
>> tests
>> > > (and
>> > > > > > some
>> > > > > > >>> >> >> > integration
>> > > > > > >>> >> >> > > tests I run for major version), then all pac4j
>> > > > > > implementations
>> > > > > > >>> are
>> > > > > > >>> >> each
>> > > > > > >>> >> >> > > tested by the appropriate demo: j2e-pac4j-demo
>> tests
>> > > > > > j2e-pac4j,
>> > > > > > >>> >> >> > > spring-webmvc-pac4j-demo tests
>> spring-webmvc-pac4j,
>> > > etc.
>> > > > > > >>> >> >> > >
>> > > > > > >>> >> >> > > So if you take a look at:
>> > > > > > >>> >> >> > >
>> > > > > > >>> >> >> > >
>> > > > > > >>> >> >> >
>> > > > > > >>> >> >>
>> > > > > > >>> >>
>> > > > > > >>>
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://github.com/pac4j/j2e-pac4j-demo/blob/master/src/main/java/org/pac4j/demo/j2e/config/DemoConfigFactory.java#L27
>> > > > > > >>> >> >> > > (for example), you have all the required
>> information
>> > to
>> > > > > test.
>> > > > > > >>> >> >> > >
>> > > > > > >>> >> >> > > I can do that on my own, but it can be good for
>> the
>> > > Knox
>> > > > > > >>> community
>> > > > > > >>> >> to
>> > > > > > >>> >> >> > start
>> > > > > > >>> >> >> > > working / testing the pac4j support. It's up to
>> yoy.
>> > > > > > >>> >> >> > >
>> > > > > > >>> >> >> > > Thanks.
>> > > > > > >>> >> >> > > Best regards,
>> > > > > > >>> >> >> > > Jérôme
>> > > > > > >>> >> >> > >
>> > > > > > >>> >> >> > >
>> > > > > > >>> >> >> > > 2016-01-05 16:11 GMT+01:00 larry mccay <
>> > > > > > larry.mccay@gmail.com
>> > > > > > >>> >:
>> > > > > > >>> >> >> > >
>> > > > > > >>> >> >> > > > Hello Jérôme -
>> > > > > > >>> >> >> > > >
>> > > > > > >>> >> >> > > > Happy New Year!
>> > > > > > >>> >> >> > > >
>> > > > > > >>> >> >> > > > I am going to start reviewing your updates
>> today,
>> > > > > > hopefully.
>> > > > > > >>> >> >> > > > I was thinking that we need to start
>> discussions on
>> > > > what
>> > > > > > the
>> > > > > > >>> key
>> > > > > > >>> >> >> > usecases
>> > > > > > >>> >> >> > > > are and how to go about testing them.
>> > > > > > >>> >> >> > > > We can certainly test the testBasicAuth and
>> against
>> > > the
>> > > > > > >>> hosted CAS
>> > > > > > >>> >> >> > server
>> > > > > > >>> >> >> > > > but what about FB, openid, OAuth, etc?
>> > > > > > >>> >> >> > > >
>> > > > > > >>> >> >> > > > I'm not sure that FB would be a key feature but
>> > > OpenID
>> > > > > > >>> Connect and
>> > > > > > >>> >> >> > OAuth
>> > > > > > >>> >> >> > > > would be - as is SAML.
>> > > > > > >>> >> >> > > > I think CAS buys us SAML testing - assuming that
>> > the
>> > > > > > >>> >> configuration of
>> > > > > > >>> >> >> > the
>> > > > > > >>> >> >> > > > hosted server is actually a SAML 2 instance.
>> > > > > > >>> >> >> > > >
>> > > > > > >>> >> >> > > > What about the others?
>> > > > > > >>> >> >> > > >
>> > > > > > >>> >> >> > > > I don't know that we need to be able to test
>> them
>> > all
>> > > > > > before
>> > > > > > >>> merge
>> > > > > > >>> >> >> but
>> > > > > > >>> >> >> > > some
>> > > > > > >>> >> >> > > > sort of manual verification would be great.
>> > > > > > >>> >> >> > > > We would need to be able to test them before the
>> > next
>> > > > > > release
>> > > > > > >>> >> which
>> > > > > > >>> >> >> > would
>> > > > > > >>> >> >> > > > be featuring the pac4j functionality.
>> > > > > > >>> >> >> > > >
>> > > > > > >>> >> >> > > > Maybe you can describe how you go about testing
>> > such
>> > > > > things
>> > > > > > >>> for
>> > > > > > >>> >> the
>> > > > > > >>> >> >> > pac4j
>> > > > > > >>> >> >> > > > project itself?
>> > > > > > >>> >> >> > > >
>> > > > > > >>> >> >> > > > thanks,
>> > > > > > >>> >> >> > > >
>> > > > > > >>> >> >> > > > --larry
>> > > > > > >>> >> >> > > >
>> > > > > > >>> >> >> > > >
>> > > > > > >>> >> >> > > > On Tue, Jan 5, 2016 at 9:55 AM, Jérôme LELEU <
>> > > > > > >>> leleuj@gmail.com>
>> > > > > > >>> >> >> wrote:
>> > > > > > >>> >> >> > > >
>> > > > > > >>> >> >> > > > > Hi,
>> > > > > > >>> >> >> > > > >
>> > > > > > >>> >> >> > > > > Happy new year!
>> > > > > > >>> >> >> > > > >
>> > > > > > >>> >> >> > > > > A few days ago, I updated my patch of the
>> pac4j
>> > > > gateway
>> > > > > > >>> provider
>> > > > > > >>> >> >> > > > according
>> > > > > > >>> >> >> > > > > to all comments on
>> > > > > > >>> >> https://issues.apache.org/jira/browse/KNOX-641
>> > > > > > >>> >> >> as
>> > > > > > >>> >> >> > > > well
>> > > > > > >>> >> >> > > > > as the documentation on KNOX-642.
>> > > > > > >>> >> >> > > > >
>> > > > > > >>> >> >> > > > > Is everything ok for the merge?
>> > > > > > >>> >> >> > > > >
>> > > > > > >>> >> >> > > > > Thanks.
>> > > > > > >>> >> >> > > > > Best regards,
>> > > > > > >>> >> >> > > > > Jérôme
>> > > > > > >>> >> >> > > > >
>> > > > > > >>> >> >> > > > >
>> > > > > > >>> >> >> > > > > 2015-12-14 15:28 GMT+01:00 larry mccay <
>> > > > > > >>> larry.mccay@gmail.com>:
>> > > > > > >>> >> >> > > > >
>> > > > > > >>> >> >> > > > > > Hi Jérôme -
>> > > > > > >>> >> >> > > > > >
>> > > > > > >>> >> >> > > > > > Not sure if you saw but I added review
>> comments
>> > > to
>> > > > > > >>> KNOX-641.
>> > > > > > >>> >> >> > > > > >
>> > > > > > >>> >> >> > > > > > I think that we need to determine whether we
>> > want
>> > > > the
>> > > > > > >>> >> >> testBasicAuth
>> > > > > > >>> >> >> > > in
>> > > > > > >>> >> >> > > > > the
>> > > > > > >>> >> >> > > > > > provider itself.
>> > > > > > >>> >> >> > > > > >
>> > > > > > >>> >> >> > > > > > Let's follow up on the JIRA.
>> > > > > > >>> >> >> > > > > >
>> > > > > > >>> >> >> > > > > > thanks,
>> > > > > > >>> >> >> > > > > >
>> > > > > > >>> >> >> > > > > > --larry
>> > > > > > >>> >> >> > > > > >
>> > > > > > >>> >> >> > > > > > On Fri, Dec 11, 2015 at 8:44 AM, Jérôme
>> LELEU <
>> > > > > > >>> >> leleuj@gmail.com>
>> > > > > > >>> >> >> > > > wrote:
>> > > > > > >>> >> >> > > > > >
>> > > > > > >>> >> >> > > > > > > Hi,
>> > > > > > >>> >> >> > > > > > >
>> > > > > > >>> >> >> > > > > > > No problem. It can go into a version
>> 0.8.0 if
>> > > > > needed.
>> > > > > > >>> The
>> > > > > > >>> >> truth
>> > > > > > >>> >> >> > is
>> > > > > > >>> >> >> > > > that
>> > > > > > >>> >> >> > > > > > > there is only one change outside the new
>> > pac4j
>> > > > > > module,
>> > > > > > >>> so I
>> > > > > > >>> >> >> think
>> > > > > > >>> >> >> > > > risks
>> > > > > > >>> >> >> > > > > > are
>> > > > > > >>> >> >> > > > > > > extremly limited.
>> > > > > > >>> >> >> > > > > > >
>> > > > > > >>> >> >> > > > > > > Just let met know.
>> > > > > > >>> >> >> > > > > > >
>> > > > > > >>> >> >> > > > > > > Thanks.
>> > > > > > >>> >> >> > > > > > > Best regards,
>> > > > > > >>> >> >> > > > > > > Jérôme
>> > > > > > >>> >> >> > > > > > >
>> > > > > > >>> >> >> > > > > > >
>> > > > > > >>> >> >> > > > > > > 2015-12-11 14:23 GMT+01:00 larry mccay <
>> > > > > > >>> >> larry.mccay@gmail.com
>> > > > > > >>> >> >> >:
>> > > > > > >>> >> >> > > > > > >
>> > > > > > >>> >> >> > > > > > > > Hi Jérôme -
>> > > > > > >>> >> >> > > > > > > >
>> > > > > > >>> >> >> > > > > > > > I have unfortunately not had a chance to
>> > > pull,
>> > > > > > >>> review and
>> > > > > > >>> >> >> test
>> > > > > > >>> >> >> > it
>> > > > > > >>> >> >> > > > yet
>> > > > > > >>> >> >> > > > > > and
>> > > > > > >>> >> >> > > > > > > > have intended to do that today.
>> > > > > > >>> >> >> > > > > > > > I apologize for the delay.
>> > > > > > >>> >> >> > > > > > > >
>> > > > > > >>> >> >> > > > > > > > I was actually thinking that this would
>> go
>> > > > into a
>> > > > > > >>> follow
>> > > > > > >>> >> up
>> > > > > > >>> >> >> > > release
>> > > > > > >>> >> >> > > > > > that
>> > > > > > >>> >> >> > > > > > > we
>> > > > > > >>> >> >> > > > > > > > would try and get done rapidly after the
>> > > 0.7.0
>> > > > > > >>> release
>> > > > > > >>> >> but we
>> > > > > > >>> >> >> > can
>> > > > > > >>> >> >> > > > > > discuss
>> > > > > > >>> >> >> > > > > > > > the target and its chances of
>> destabilizing
>> > > > > 0.7.0.
>> > > > > > >>> >> >> > > > > > > >
>> > > > > > >>> >> >> > > > > > > > I believe that it is rather
>> self-contained
>> > > with
>> > > > > > only
>> > > > > > >>> a few
>> > > > > > >>> >> >> > > changes
>> > > > > > >>> >> >> > > > to
>> > > > > > >>> >> >> > > > > > > > external modules.
>> > > > > > >>> >> >> > > > > > > >
>> > > > > > >>> >> >> > > > > > > > Opening the JIRAs is perfect and I was
>> > going
>> > > to
>> > > > > do
>> > > > > > >>> that
>> > > > > > >>> >> once
>> > > > > > >>> >> >> I
>> > > > > > >>> >> >> > > > > started
>> > > > > > >>> >> >> > > > > > > the
>> > > > > > >>> >> >> > > > > > > > review.
>> > > > > > >>> >> >> > > > > > > >
>> > > > > > >>> >> >> > > > > > > > Let's continue review comments and
>> > > > collaboration
>> > > > > on
>> > > > > > >>> those
>> > > > > > >>> >> >> > JIRAs.
>> > > > > > >>> >> >> > > > > > > > I will add you to the contributors list
>> so
>> > > that
>> > > > > we
>> > > > > > >>> can
>> > > > > > >>> >> assign
>> > > > > > >>> >> >> > > them
>> > > > > > >>> >> >> > > > to
>> > > > > > >>> >> >> > > > > > > you.
>> > > > > > >>> >> >> > > > > > > >
>> > > > > > >>> >> >> > > > > > > > Thank you for your contributions and
>> your
>> > > > > patience,
>> > > > > > >>> >> Jérôme!
>> > > > > > >>> >> >> > > > > > > >
>> > > > > > >>> >> >> > > > > > > > --larry
>> > > > > > >>> >> >> > > > > > > >
>> > > > > > >>> >> >> > > > > > > > On Fri, Dec 11, 2015 at 3:00 AM, Jérôme
>> > > LELEU <
>> > > > > > >>> >> >> > leleuj@gmail.com>
>> > > > > > >>> >> >> > > > > > wrote:
>> > > > > > >>> >> >> > > > > > > >
>> > > > > > >>> >> >> > > > > > > > > Hi,
>> > > > > > >>> >> >> > > > > > > > >
>> > > > > > >>> >> >> > > > > > > > > I didn't get any new feedback on the
>> pull
>> > > > > request
>> > > > > > >>> so I
>> > > > > > >>> >> >> assume
>> > > > > > >>> >> >> > > > > > > everything
>> > > > > > >>> >> >> > > > > > > > is
>> > > > > > >>> >> >> > > > > > > > > ok from your point of view.
>> > > > > > >>> >> >> > > > > > > > >
>> > > > > > >>> >> >> > > > > > > > > I released pac4j v1.8.1 and j2e-pac4j
>> > > v1.2.1
>> > > > > so I
>> > > > > > >>> >> updated
>> > > > > > >>> >> >> the
>> > > > > > >>> >> >> > > > pull
>> > > > > > >>> >> >> > > > > > > > request
>> > > > > > >>> >> >> > > > > > > > > to use them and successfully re-tested
>> > > > > > everything.
>> > > > > > >>> >> >> > > > > > > > >
>> > > > > > >>> >> >> > > > > > > > > I opened KNOX-641 and submitted the
>> > > > > corresponding
>> > > > > > >>> patch.
>> > > > > > >>> >> >> > > > > > > > >
>> > > > > > >>> >> >> > > > > > > > > I also wrote the documentation, opened
>> > > > KNOX-642
>> > > > > > and
>> > > > > > >>> >> >> submitted
>> > > > > > >>> >> >> > > the
>> > > > > > >>> >> >> > > > > > > > > corresponding patch (just to let you
>> know
>> > > > that
>> > > > > it
>> > > > > > >>> >> doesn't
>> > > > > > >>> >> >> > work
>> > > > > > >>> >> >> > > > out
>> > > > > > >>> >> >> > > > > of
>> > > > > > >>> >> >> > > > > > > the
>> > > > > > >>> >> >> > > > > > > > > box in Windows, I had to replace
>> mvn.bat
>> > by
>> > > > > > >>> mvn.cmd to
>> > > > > > >>> >> make
>> > > > > > >>> >> >> > ant
>> > > > > > >>> >> >> > > > > > work).
>> > > > > > >>> >> >> > > > > > > > >
>> > > > > > >>> >> >> > > > > > > > > Even if the branch 0.7.0 has already
>> been
>> > > > > > created,
>> > > > > > >>> I
>> > > > > > >>> >> >> assumed
>> > > > > > >>> >> >> > > this
>> > > > > > >>> >> >> > > > > new
>> > > > > > >>> >> >> > > > > > > > pac4j
>> > > > > > >>> >> >> > > > > > > > > provider will go into this version
>> 0.7.0
>> > > > > > >>> (dependency on
>> > > > > > >>> >> the
>> > > > > > >>> >> >> > > > > > > > 0.7.0-SNAPSHOT
>> > > > > > >>> >> >> > > > > > > > > parent version).
>> > > > > > >>> >> >> > > > > > > > >
>> > > > > > >>> >> >> > > > > > > > > Just let me know if everything is ok
>> and
>> > > when
>> > > > > > it's
>> > > > > > >>> >> goind to
>> > > > > > >>> >> >> > be
>> > > > > > >>> >> >> > > > > > merged.
>> > > > > > >>> >> >> > > > > > > > >
>> > > > > > >>> >> >> > > > > > > > > Thanks.
>> > > > > > >>> >> >> > > > > > > > > Best regards,
>> > > > > > >>> >> >> > > > > > > > > Jérôme
>> > > > > > >>> >> >> > > > > > > > >
>> > > > > > >>> >> >> > > > > > > > >
>> > > > > > >>> >> >> > > > > > > > >
>> > > > > > >>> >> >> > > > > > > > >
>> > > > > > >>> >> >> > > > > > > > > 2015-12-04 14:20 GMT+01:00 larry
>> mccay <
>> > > > > > >>> >> >> > larry.mccay@gmail.com
>> > > > > > >>> >> >> > > >:
>> > > > > > >>> >> >> > > > > > > > >
>> > > > > > >>> >> >> > > > > > > > > > That ability to configure multiple
>> > > > mechanisms
>> > > > > > >>> based on
>> > > > > > >>> >> >> > > > clientName
>> > > > > > >>> >> >> > > > > > is
>> > > > > > >>> >> >> > > > > > > > > really
>> > > > > > >>> >> >> > > > > > > > > > interesting for Knox.
>> > > > > > >>> >> >> > > > > > > > > > Currently, we require separate
>> > topologies
>> > > > per
>> > > > > > >>> >> >> > authentication
>> > > > > > >>> >> >> > > > > > > mechanism.
>> > > > > > >>> >> >> > > > > > > > > > The ability to configure them all in
>> > one
>> > > is
>> > > > > > >>> really
>> > > > > > >>> >> great.
>> > > > > > >>> >> >> > > > > > > > > >
>> > > > > > >>> >> >> > > > > > > > > > We would need to think through the
>> best
>> > > way
>> > > > > to
>> > > > > > >>> provide
>> > > > > > >>> >> >> the
>> > > > > > >>> >> >> > > > > > clientName
>> > > > > > >>> >> >> > > > > > > > > > parameter.
>> > > > > > >>> >> >> > > > > > > > > > Since this is targeting KnoxSSO it
>> can
>> > > > > actually
>> > > > > > >>> be
>> > > > > > >>> >> added
>> > > > > > >>> >> >> to
>> > > > > > >>> >> >> > > the
>> > > > > > >>> >> >> > > > > > > > > providerURL
>> > > > > > >>> >> >> > > > > > > > > > used to redirect from the
>> participating
>> > > > > > >>> application.
>> > > > > > >>> >> >> > > > > > > > > > Regardless of the authentication
>> > > mechanism
>> > > > > used
>> > > > > > >>> each
>> > > > > > >>> >> >> > > > application
>> > > > > > >>> >> >> > > > > > will
>> > > > > > >>> >> >> > > > > > > > > still
>> > > > > > >>> >> >> > > > > > > > > > get the same JWT based cookie.
>> > > > > > >>> >> >> > > > > > > > > >
>> > > > > > >>> >> >> > > > > > > > > > I think that should work really
>> nicely.
>> > > > > > >>> >> >> > > > > > > > > >
>> > > > > > >>> >> >> > > > > > > > > >
>> > > > > > >>> >> >> > > > > > > > > > On Fri, Dec 4, 2015 at 7:17 AM,
>> larry
>> > > > mccay <
>> > > > > > >>> >> >> > > > > larry.mccay@gmail.com
>> > > > > > >>> >> >> > > > > > >
>> > > > > > >>> >> >> > > > > > > > > wrote:
>> > > > > > >>> >> >> > > > > > > > > >
>> > > > > > >>> >> >> > > > > > > > > > > Excellent, Jérôme.
>> > > > > > >>> >> >> > > > > > > > > > > Thanks!
>> > > > > > >>> >> >> > > > > > > > > > >
>> > > > > > >>> >> >> > > > > > > > > > > On Fri, Dec 4, 2015 at 2:40 AM,
>> > Jérôme
>> > > > > LELEU
>> > > > > > <
>> > > > > > >>> >> >> > > > leleuj@gmail.com
>> > > > > > >>> >> >> > > > > >
>> > > > > > >>> >> >> > > > > > > > wrote:
>> > > > > > >>> >> >> > > > > > > > > > >
>> > > > > > >>> >> >> > > > > > > > > > >> Hi,
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >> I will write how to configure the
>> > > pac4j
>> > > > > > >>> provider in
>> > > > > > >>> >> >> the
>> > > > > > >>> >> >> > > > > > > > documentation,
>> > > > > > >>> >> >> > > > > > > > > > but
>> > > > > > >>> >> >> > > > > > > > > > >> I can already give you some
>> > insights.
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >> My main goal is always to respect
>> > the
>> > > > key
>> > > > > > >>> design
>> > > > > > >>> >> >> > > principles
>> > > > > > >>> >> >> > > > of
>> > > > > > >>> >> >> > > > > > > pac4j
>> > > > > > >>> >> >> > > > > > > > > > >> whatever the environment /
>> framework
>> > > in
>> > > > > > which
>> > > > > > >>> it is
>> > > > > > >>> >> >> > > > > implemented.
>> > > > > > >>> >> >> > > > > > > For
>> > > > > > >>> >> >> > > > > > > > > > Knox,
>> > > > > > >>> >> >> > > > > > > > > > >> I'm pretty happy with the use of
>> the
>> > > > > > j2e-pac4j
>> > > > > > >>> >> >> library,
>> > > > > > >>> >> >> > > > which
>> > > > > > >>> >> >> > > > > > > means
>> > > > > > >>> >> >> > > > > > > > > that
>> > > > > > >>> >> >> > > > > > > > > > >> almost all the pac4j features are
>> > > > > available,
>> > > > > > >>> >> >> especially
>> > > > > > >>> >> >> > > both
>> > > > > > >>> >> >> > > > > > > direct
>> > > > > > >>> >> >> > > > > > > > > and
>> > > > > > >>> >> >> > > > > > > > > > >> indirect clients. So it can do
>> what
>> > > > Shiro
>> > > > > > >>> already
>> > > > > > >>> >> does
>> > > > > > >>> >> >> > but
>> > > > > > >>> >> >> > > > > also,
>> > > > > > >>> >> >> > > > > > > as
>> > > > > > >>> >> >> > > > > > > > we
>> > > > > > >>> >> >> > > > > > > > > > >> agreed together, supports remote
>> > > > > > >>> authentications.
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >> It is only limited by what you
>> can
>> > > > > currently
>> > > > > > >>> >> >> configure.
>> > > > > > >>> >> >> > > And
>> > > > > > >>> >> >> > > > > even
>> > > > > > >>> >> >> > > > > > > > > > >> configuration is a pac4j feature
>> as
>> > > the
>> > > > > CAS
>> > > > > > >>> server
>> > > > > > >>> >> has
>> > > > > > >>> >> >> > the
>> > > > > > >>> >> >> > > > > same
>> > > > > > >>> >> >> > > > > > > > need.
>> > > > > > >>> >> >> > > > > > > > > > >> Everything happens in this class:
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > >
>> > > > > > >>> >> >> > > > > > > > >
>> > > > > > >>> >> >> > > > > > > >
>> > > > > > >>> >> >> > > > > > >
>> > > > > > >>> >> >> > > > > >
>> > > > > > >>> >> >> > > > >
>> > > > > > >>> >> >> > > >
>> > > > > > >>> >> >> > >
>> > > > > > >>> >> >> >
>> > > > > > >>> >> >>
>> > > > > > >>> >>
>> > > > > > >>>
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java
>> > > > > > >>> >> >> > > > > > > > > > >> ,
>> > > > > > >>> >> >> > > > > > > > > > >> which allows you to configure
>> > > Facebook,
>> > > > > > >>> Twitter, a
>> > > > > > >>> >> CAS
>> > > > > > >>> >> >> > > > > server, a
>> > > > > > >>> >> >> > > > > > > > SAML
>> > > > > > >>> >> >> > > > > > > > > > IdP
>> > > > > > >>> >> >> > > > > > > > > > >> or an OpenID Connect provider.
>> All
>> > the
>> > > > > > >>> provided
>> > > > > > >>> >> >> > parameters
>> > > > > > >>> >> >> > > > to
>> > > > > > >>> >> >> > > > > > the
>> > > > > > >>> >> >> > > > > > > > > pac4j
>> > > > > > >>> >> >> > > > > > > > > > >> provider are put into a Map and
>> the
>> > > > > > >>> >> >> > > ConfigPropertiesFactory
>> > > > > > >>> >> >> > > > is
>> > > > > > >>> >> >> > > > > > > built
>> > > > > > >>> >> >> > > > > > > > > > with
>> > > > > > >>> >> >> > > > > > > > > > >> this Map to return the built
>> client
>> > (=
>> > > > > > >>> >> authentication
>> > > > > > >>> >> >> > > > > > mechanism).
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >> You have one more specific option
>> > for
>> > > > Knox
>> > > > > > as
>> > > > > > >>> a
>> > > > > > >>> >> basic
>> > > > > > >>> >> >> > > > > > > authentication
>> > > > > > >>> >> >> > > > > > > > > > popup
>> > > > > > >>> >> >> > > > > > > > > > >> where the username must match the
>> > > > > password,
>> > > > > > >>> you can
>> > > > > > >>> >> >> > define
>> > > > > > >>> >> >> > > > > that
>> > > > > > >>> >> >> > > > > > > by:
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >> <param>
>> > > > > > >>> >> >> > > > > > > > > > >> <name>clientName</name>
>> > > > > > >>> >> >> > > > > > > > > > >> <value>testBasicAuth</value>
>> > > > > > >>> >> >> > > > > > > > > > >> </param>
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >> It's for testing only.
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >> For a CAS server:
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >> <param>
>> > > > > > >>> >> >> > > > > > > > > > >> <name>cas.loginUrl</name>
>> > > > > > >>> >> >> > > > > > > > > > >> <value>
>> > > > > > >>> >> https://casserverpac4j.herokuapp.com/login
>> > > > > > >>> >> >> > > </value>
>> > > > > > >>> >> >> > > > > > > > > > >> </param>
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >> Here are all the properties
>> > available
>> > > > for
>> > > > > > >>> building
>> > > > > > >>> >> >> > clients
>> > > > > > >>> >> >> > > > > > (their
>> > > > > > >>> >> >> > > > > > > > > > meaning
>> > > > > > >>> >> >> > > > > > > > > > >> is obvious):
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >> facebook.id
>> > > > > > >>> >> >> > > > > > > > > > >> facebook.secret
>> > > > > > >>> >> >> > > > > > > > > > >> facebook.scope
>> > > > > > >>> >> >> > > > > > > > > > >> facebook.fields
>> > > > > > >>> >> >> > > > > > > > > > >> twitter.id
>> > > > > > >>> >> >> > > > > > > > > > >> twitter.secret
>> > > > > > >>> >> >> > > > > > > > > > >> saml.keystorePassword
>> > > > > > >>> >> >> > > > > > > > > > >> saml.privateKeyPassword
>> > > > > > >>> >> >> > > > > > > > > > >> saml.keystorePath
>> > > > > > >>> >> >> > > > > > > > > > >> saml.identityProviderMetadataPath
>> > > > > > >>> >> >> > > > > > > > > > >>
>> saml.maximumAuthenticationLifetime
>> > > > > > >>> >> >> > > > > > > > > > >> saml.serviceProviderEntityId
>> > > > > > >>> >> >> > > > > > > > > > >> saml.serviceProviderMetadataPath
>> > > > > > >>> >> >> > > > > > > > > > >> cas.loginUrl
>> > > > > > >>> >> >> > > > > > > > > > >> cas.protocol
>> > > > > > >>> >> >> > > > > > > > > > >> oidc.id
>> > > > > > >>> >> >> > > > > > > > > > >> oidc.secret
>> > > > > > >>> >> >> > > > > > > > > > >> oidc.discoveryUri
>> > > > > > >>> >> >> > > > > > > > > > >> oidc.customParamKey1
>> > > > > > >>> >> >> > > > > > > > > > >> oidc.customParamValue1
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >> If you define multiple clients,
>> the
>> > > > first
>> > > > > > one
>> > > > > > >>> will
>> > > > > > >>> >> be
>> > > > > > >>> >> >> > used
>> > > > > > >>> >> >> > > > for
>> > > > > > >>> >> >> > > > > > > > > > >> authentication, but you can
>> > explicitly
>> > > > > > choose
>> > > > > > >>> the
>> > > > > > >>> >> >> client
>> > > > > > >>> >> >> > > you
>> > > > > > >>> >> >> > > > > > want
>> > > > > > >>> >> >> > > > > > > to
>> > > > > > >>> >> >> > > > > > > > > use
>> > > > > > >>> >> >> > > > > > > > > > >> via the clientName parameter,
>> > assuming
>> > > > you
>> > > > > > >>> want to
>> > > > > > >>> >> >> > switch
>> > > > > > >>> >> >> > > > from
>> > > > > > >>> >> >> > > > > > > > client
>> > > > > > >>> >> >> > > > > > > > > > >> depending on environment for
>> > example.
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >> So if you want to add some new
>> > > > > > authentication
>> > > > > > >>> >> >> mechanism,
>> > > > > > >>> >> >> > > you
>> > > > > > >>> >> >> > > > > > must
>> > > > > > >>> >> >> > > > > > > > > first
>> > > > > > >>> >> >> > > > > > > > > > >> check that it is available in
>> pac4j
>> > > (if
>> > > > > it's
>> > > > > > >>> not,
>> > > > > > >>> >> it's
>> > > > > > >>> >> >> > > > another
>> > > > > > >>> >> >> > > > > > > > > > discussion,
>> > > > > > >>> >> >> > > > > > > > > > >> but generally, it is). Then,
>> you'll
>> > > need
>> > > > > to
>> > > > > > >>> upgrade
>> > > > > > >>> >> >> the
>> > > > > > >>> >> >> > > > > > > > > > >> ConfigPropertiesFactory by
>> > submitting
>> > > a
>> > > > > new
>> > > > > > >>> pull
>> > > > > > >>> >> >> request
>> > > > > > >>> >> >> > > to
>> > > > > > >>> >> >> > > > > the
>> > > > > > >>> >> >> > > > > > > > pac4j
>> > > > > > >>> >> >> > > > > > > > > > >> project (I can do it myself, but
>> I'm
>> > > > sure
>> > > > > > you
>> > > > > > >>> >> could do
>> > > > > > >>> >> >> > > that
>> > > > > > >>> >> >> > > > > > > easily),
>> > > > > > >>> >> >> > > > > > > > > > >> finally wait for the new pac4j
>> > release
>> > > > and
>> > > > > > >>> switch
>> > > > > > >>> >> >> pac4j
>> > > > > > >>> >> >> > > > > versions
>> > > > > > >>> >> >> > > > > > > in
>> > > > > > >>> >> >> > > > > > > > > Knox
>> > > > > > >>> >> >> > > > > > > > > > >> to
>> > > > > > >>> >> >> > > > > > > > > > >> benefit from the new feature.
>> > > > > > >>> >> >> > > > > > > > > > >> The good thing is that if someone
>> > > > related
>> > > > > to
>> > > > > > >>> the
>> > > > > > >>> >> CAS
>> > > > > > >>> >> >> > > server
>> > > > > > >>> >> >> > > > > does
>> > > > > > >>> >> >> > > > > > > the
>> > > > > > >>> >> >> > > > > > > > > > same
>> > > > > > >>> >> >> > > > > > > > > > >> thing for CAS (in pac4j), you
>> will
>> > > > > > >>> automatically
>> > > > > > >>> >> get
>> > > > > > >>> >> >> it
>> > > > > > >>> >> >> > > when
>> > > > > > >>> >> >> > > > > > > you'll
>> > > > > > >>> >> >> > > > > > > > > > >> upgrade
>> > > > > > >>> >> >> > > > > > > > > > >> pac4j.
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >> To go even further, replacing
>> LDAP
>> > > Shiro
>> > > > > > >>> >> >> authentication
>> > > > > > >>> >> >> > is
>> > > > > > >>> >> >> > > > > just
>> > > > > > >>> >> >> > > > > > a
>> > > > > > >>> >> >> > > > > > > > > matter
>> > > > > > >>> >> >> > > > > > > > > > >> of
>> > > > > > >>> >> >> > > > > > > > > > >> making pac4j LDAP authentication
>> > > > available
>> > > > > > via
>> > > > > > >>> >> >> > > configuration
>> > > > > > >>> >> >> > > > > > > > > parameters.
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >> I hope it was clear enough.
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >> Thanks.
>> > > > > > >>> >> >> > > > > > > > > > >> Best regards,
>> > > > > > >>> >> >> > > > > > > > > > >> Jérôme
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >> 2015-12-03 20:45 GMT+01:00 larry
>> > > mccay <
>> > > > > > >>> >> >> > > > larry.mccay@gmail.com
>> > > > > > >>> >> >> > > > > >:
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >> > Excellent!
>> > > > > > >>> >> >> > > > > > > > > > >> >
>> > > > > > >>> >> >> > > > > > > > > > >> > I will carve out some time to
>> do
>> > > code
>> > > > > > >>> review.
>> > > > > > >>> >> >> > > > > > > > > > >> > We will need to get some
>> insights
>> > > into
>> > > > > how
>> > > > > > >>> to go
>> > > > > > >>> >> >> about
>> > > > > > >>> >> >> > > > > > testing:
>> > > > > > >>> >> >> > > > > > > > > > >> >
>> > > > > > >>> >> >> > > > > > > > > > >> > * is the CAS server going to be
>> > > > > available
>> > > > > > >>> for
>> > > > > > >>> >> >> testing?
>> > > > > > >>> >> >> > > > > > > > > > >> > * what are the specific and
>> > > > > > >>> generic/standard (if
>> > > > > > >>> >> >> any)
>> > > > > > >>> >> >> > > > > > > > authentication
>> > > > > > >>> >> >> > > > > > > > > > >> > mechanisms available - for
>> > instance:
>> > > > > > >>> >> >> > > > > > > > > > >> > - Facebook, Google,
>> LinkedIn
>> > and
>> > > > CAS
>> > > > > > are
>> > > > > > >>> >> >> specifics
>> > > > > > >>> >> >> > > > > > > > > > >> > - OAuth 2, OpenID Connect,
>> > SAML
>> > > > are
>> > > > > > >>> >> >> > > generic/standards
>> > > > > > >>> >> >> > > > -
>> > > > > > >>> >> >> > > > > > that
>> > > > > > >>> >> >> > > > > > > > may
>> > > > > > >>> >> >> > > > > > > > > > be
>> > > > > > >>> >> >> > > > > > > > > > >> > used for the above specifics...
>> > > > > > >>> >> >> > > > > > > > > > >> > * how do we test things other
>> than
>> > > > CAS -
>> > > > > > in
>> > > > > > >>> >> terms of
>> > > > > > >>> >> >> > > > getting
>> > > > > > >>> >> >> > > > > > > > > > >> credentials,
>> > > > > > >>> >> >> > > > > > > > > > >> > configuration, etc
>> > > > > > >>> >> >> > > > > > > > > > >> >
>> > > > > > >>> >> >> > > > > > > > > > >> > We could certainly do this is
>> > phases
>> > > > as
>> > > > > > >>> well.
>> > > > > > >>> >> >> > > > > > > > > > >> >
>> > > > > > >>> >> >> > > > > > > > > > >> > If you can enumerate the things
>> > that
>> > > > > > should
>> > > > > > >>> work
>> > > > > > >>> >> and
>> > > > > > >>> >> >> > > > provide
>> > > > > > >>> >> >> > > > > > > some
>> > > > > > >>> >> >> > > > > > > > > > >> testing
>> > > > > > >>> >> >> > > > > > > > > > >> > details for CAS or as many as
>> > > possible
>> > > > > and
>> > > > > > >>> OpenID
>> > > > > > >>> >> >> > > Connect
>> > > > > > >>> >> >> > > > > then
>> > > > > > >>> >> >> > > > > > > we
>> > > > > > >>> >> >> > > > > > > > > can
>> > > > > > >>> >> >> > > > > > > > > > >> test
>> > > > > > >>> >> >> > > > > > > > > > >> > the specific implementations
>> that
>> > > you
>> > > > > > >>> provide and
>> > > > > > >>> >> >> > enable
>> > > > > > >>> >> >> > > > the
>> > > > > > >>> >> >> > > > > > > > testing
>> > > > > > >>> >> >> > > > > > > > > > of
>> > > > > > >>> >> >> > > > > > > > > > >> > another OpenID Connect effort
>> that
>> > > is
>> > > > in
>> > > > > > the
>> > > > > > >>> >> works
>> > > > > > >>> >> >> in
>> > > > > > >>> >> >> > > the
>> > > > > > >>> >> >> > > > > > > > community.
>> > > > > > >>> >> >> > > > > > > > > > >> >
>> > > > > > >>> >> >> > > > > > > > > > >> > I'm not sure whether we want to
>> > > commit
>> > > > > > >>> >> contributions
>> > > > > > >>> >> >> > > that
>> > > > > > >>> >> >> > > > > are
>> > > > > > >>> >> >> > > > > > > > > > dependent
>> > > > > > >>> >> >> > > > > > > > > > >> on
>> > > > > > >>> >> >> > > > > > > > > > >> > snapshots - we certainly can't
>> > > release
>> > > > > > with
>> > > > > > >>> any
>> > > > > > >>> >> such
>> > > > > > >>> >> >> > > > > > > dependencies.
>> > > > > > >>> >> >> > > > > > > > > > >> > I would hate to add a cleanup
>> task
>> > > to
>> > > > a
>> > > > > > >>> release
>> > > > > > >>> >> to
>> > > > > > >>> >> >> > make
>> > > > > > >>> >> >> > > > sure
>> > > > > > >>> >> >> > > > > > > there
>> > > > > > >>> >> >> > > > > > > > > are
>> > > > > > >>> >> >> > > > > > > > > > >> no
>> > > > > > >>> >> >> > > > > > > > > > >> > snapshots in there.
>> > > > > > >>> >> >> > > > > > > > > > >> > We will probably wait until
>> after
>> > > the
>> > > > > > pac4j
>> > > > > > >>> >> releases
>> > > > > > >>> >> >> > to
>> > > > > > >>> >> >> > > > > > commit.
>> > > > > > >>> >> >> > > > > > > > > > >> >
>> > > > > > >>> >> >> > > > > > > > > > >> > I am really happy that this
>> > > > integration
>> > > > > is
>> > > > > > >>> >> happening
>> > > > > > >>> >> >> > and
>> > > > > > >>> >> >> > > > > that
>> > > > > > >>> >> >> > > > > > it
>> > > > > > >>> >> >> > > > > > > > > went
>> > > > > > >>> >> >> > > > > > > > > > >> > rather smoothly.
>> > > > > > >>> >> >> > > > > > > > > > >> > These sorts of authentication
>> > > > protocols
>> > > > > > are
>> > > > > > >>> >> complex
>> > > > > > >>> >> >> > and
>> > > > > > >>> >> >> > > I
>> > > > > > >>> >> >> > > > > > think
>> > > > > > >>> >> >> > > > > > > we
>> > > > > > >>> >> >> > > > > > > > > > >> lined up
>> > > > > > >>> >> >> > > > > > > > > > >> > pretty well overall.
>> > > > > > >>> >> >> > > > > > > > > > >> >
>> > > > > > >>> >> >> > > > > > > > > > >> > Thanks for your work!
>> > > > > > >>> >> >> > > > > > > > > > >> >
>> > > > > > >>> >> >> > > > > > > > > > >> > On Thu, Dec 3, 2015 at 2:28 PM,
>> > > Jérôme
>> > > > > > >>> LELEU <
>> > > > > > >>> >> >> > > > > > leleuj@gmail.com>
>> > > > > > >>> >> >> > > > > > > > > > wrote:
>> > > > > > >>> >> >> > > > > > > > > > >> >
>> > > > > > >>> >> >> > > > > > > > > > >> > > Hi,
>> > > > > > >>> >> >> > > > > > > > > > >> > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > I just sync'ed with master,
>> > > cleaned
>> > > > > > >>> >> dependencies
>> > > > > > >>> >> >> and
>> > > > > > >>> >> >> > > > added
>> > > > > > >>> >> >> > > > > > > > missing
>> > > > > > >>> >> >> > > > > > > > > > >> > > Javadocs. Everything works
>> > > correctly
>> > > > > > now.
>> > > > > > >>> Many
>> > > > > > >>> >> >> > thanks.
>> > > > > > >>> >> >> > > > > > > > > > >> > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > The pull request is ready
>> for a
>> > > full
>> > > > > > code
>> > > > > > >>> >> review:
>> > > > > > >>> >> >> > > > > > > > > > >> > >
>> > > > https://github.com/apache/knox/pull/2
>> > > > > > >>> >> >> > > > > > > > > > >> > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > I'll write the documentation
>> > after
>> > > > the
>> > > > > > >>> pac4j
>> > > > > > >>> >> >> > releases
>> > > > > > >>> >> >> > > (I
>> > > > > > >>> >> >> > > > > > hope
>> > > > > > >>> >> >> > > > > > > > next
>> > > > > > >>> >> >> > > > > > > > > > >> week).
>> > > > > > >>> >> >> > > > > > > > > > >> > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > Thanks.
>> > > > > > >>> >> >> > > > > > > > > > >> > > Best regards,
>> > > > > > >>> >> >> > > > > > > > > > >> > > Jérôme
>> > > > > > >>> >> >> > > > > > > > > > >> > >
>> > > > > > >>> >> >> > > > > > > > > > >> > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > 2015-12-02 19:18 GMT+01:00
>> larry
>> > > > > mccay <
>> > > > > > >>> >> >> > > > > > larry.mccay@gmail.com
>> > > > > > >>> >> >> > > > > > > >:
>> > > > > > >>> >> >> > > > > > > > > > >> > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > Fixed in
>> > > > > > >>> >> >> > > > https://issues.apache.org/jira/browse/KNOX-636
>> > > > > > >>> >> >> > > > > .
>> > > > > > >>> >> >> > > > > > > > > > >> > > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > On Wed, Dec 2, 2015 at
>> 12:42
>> > PM,
>> > > > > larry
>> > > > > > >>> mccay
>> > > > > > >>> >> <
>> > > > > > >>> >> >> > > > > > > > > > larry.mccay@gmail.com
>> > > > > > >>> >> >> > > > > > > > > > >> >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > wrote:
>> > > > > > >>> >> >> > > > > > > > > > >> > > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > > Sure - I can file a JIRA
>> and
>> > > > > commit
>> > > > > > a
>> > > > > > >>> fix.
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > > The secret generation
>> should
>> > > be
>> > > > > done
>> > > > > > >>> in one
>> > > > > > >>> >> >> > > instance
>> > > > > > >>> >> >> > > > > and
>> > > > > > >>> >> >> > > > > > > > > > >> replicated
>> > > > > > >>> >> >> > > > > > > > > > >> > > > across
>> > > > > > >>> >> >> > > > > > > > > > >> > > > > others.
>> > > > > > >>> >> >> > > > > > > > > > >> > > > > This
>> replication/management
>> > of
>> > > > the
>> > > > > > >>> >> credential
>> > > > > > >>> >> >> > > stores
>> > > > > > >>> >> >> > > > > is
>> > > > > > >>> >> >> > > > > > > > > outside
>> > > > > > >>> >> >> > > > > > > > > > of
>> > > > > > >>> >> >> > > > > > > > > > >> > the
>> > > > > > >>> >> >> > > > > > > > > > >> > > > > scope of Knox itself as
>> of
>> > > now.
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > > Documentation is done in
>> > > > markdown
>> > > > > > and
>> > > > > > >>> is
>> > > > > > >>> >> >> > > > contributing
>> > > > > > >>> >> >> > > > > > > > details
>> > > > > > >>> >> >> > > > > > > > > > are
>> > > > > > >>> >> >> > > > > > > > > > >> > > > > available at:
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > >
>> > > > > > >>> >> >> > > > > > > > > > >> > >
>> > > > > > >>> >> >> > > > > > > > > > >> >
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > >
>> > > > > > >>> >> >> > > > > > > > >
>> > > > > > >>> >> >> > > > > > > >
>> > > > > > >>> >> >> > > > > > >
>> > > > > > >>> >> >> > > > > >
>> > > > > > >>> >> >> > > > >
>> > > > > > >>> >> >> > > >
>> > > > > > >>> >> >> > >
>> > > > > > >>> >> >> >
>> > > > > > >>> >> >>
>> > > > > > >>> >>
>> > > > > > >>>
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > > Which should give you a
>> > > general
>> > > > > > idea.
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > > Find an example like:
>> > > > > > >>> ./trunk/books/0.7.0/
>> > > > > > >>> >> >> > > > > > > > > > >> > >
>> config_preauth_sso_provider.md
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > > For an example of typical
>> > > > content
>> > > > > > and
>> > > > > > >>> >> format.
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > > Here is how that example
>> > > > renders:
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > >
>> > > > > > >>> >> >> > > > > > > > > > >> > >
>> > > > > > >>> >> >> > > > > > > > > > >> >
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > >
>> > > > > > >>> >> >> > > > > > > > >
>> > > > > > >>> >> >> > > > > > > >
>> > > > > > >>> >> >> > > > > > >
>> > > > > > >>> >> >> > > > > >
>> > > > > > >>> >> >> > > > >
>> > > > > > >>> >> >> > > >
>> > > > > > >>> >> >> > >
>> > > > > > >>> >> >> >
>> > > > > > >>> >> >>
>> > > > > > >>> >>
>> > > > > > >>>
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > > You'll need to tie it
>> into
>> > the
>> > > > > rest
>> > > > > > >>> of the
>> > > > > > >>> >> >> book
>> > > > > > >>> >> >> > -
>> > > > > > >>> >> >> > > > just
>> > > > > > >>> >> >> > > > > > > grep
>> > > > > > >>> >> >> > > > > > > > > for
>> > > > > > >>> >> >> > > > > > > > > > >> where
>> > > > > > >>> >> >> > > > > > > > > > >> > > > that
>> > > > > > >>> >> >> > > > > > > > > > >> > > > > filename is referenced.
>> > > > > > >>> >> >> > > > > > > > > > >> > > > > To test how it renders
>> build
>> > > the
>> > > > > > site
>> > > > > > >>> with:
>> > > > > > >>> >> >> > "ant"
>> > > > > > >>> >> >> > > > and
>> > > > > > >>> >> >> > > > > > note
>> > > > > > >>> >> >> > > > > > > > the
>> > > > > > >>> >> >> > > > > > > > > > >> url to
>> > > > > > >>> >> >> > > > > > > > > > >> > > the
>> > > > > > >>> >> >> > > > > > > > > > >> > > > > 0.7.0 book.
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > > On Wed, Dec 2, 2015 at
>> 12:12
>> > > PM,
>> > > > > > >>> Jérôme
>> > > > > > >>> >> LELEU
>> > > > > > >>> >> >> <
>> > > > > > >>> >> >> > > > > > > > > leleuj@gmail.com
>> > > > > > >>> >> >> > > > > > > > > > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > wrote:
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> Hi,
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> Why it doesn't work for
>> > pac4j
>> > > > > while
>> > > > > > >>> it
>> > > > > > >>> >> works
>> > > > > > >>> >> >> > for
>> > > > > > >>> >> >> > > > > others
>> > > > > > >>> >> >> > > > > > > is
>> > > > > > >>> >> >> > > > > > > > a
>> > > > > > >>> >> >> > > > > > > > > > bit
>> > > > > > >>> >> >> > > > > > > > > > >> > > strange
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> to
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> me, but if you have the
>> > patch
>> > > > in
>> > > > > > >>> front of
>> > > > > > >>> >> >> your
>> > > > > > >>> >> >> > > > eyes,
>> > > > > > >>> >> >> > > > > > I'd
>> > > > > > >>> >> >> > > > > > > > > rather
>> > > > > > >>> >> >> > > > > > > > > > >> > prefer
>> > > > > > >>> >> >> > > > > > > > > > >> > > > you
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> to commit it. In all
>> cases,
>> > > > I'll
>> > > > > > >>> sync with
>> > > > > > >>> >> >> the
>> > > > > > >>> >> >> > > > > master.
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> There was one question
>> you
>> > > > didn't
>> > > > > > >>> answer
>> > > > > > >>> >> >> > > > previously:
>> > > > > > >>> >> >> > > > > is
>> > > > > > >>> >> >> > > > > > > the
>> > > > > > >>> >> >> > > > > > > > > > >> password
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> generated for the pac4j
>> > > > provider
>> > > > > > the
>> > > > > > >>> same
>> > > > > > >>> >> >> > across
>> > > > > > >>> >> >> > > > all
>> > > > > > >>> >> >> > > > > > > > gateway
>> > > > > > >>> >> >> > > > > > > > > > >> > > instances?
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> Because I expect to have
>> > the
>> > > > same
>> > > > > > >>> value
>> > > > > > >>> >> as I
>> > > > > > >>> >> >> > use
>> > > > > > >>> >> >> > > it
>> > > > > > >>> >> >> > > > > to
>> > > > > > >>> >> >> > > > > > > > > encrypt
>> > > > > > >>> >> >> > > > > > > > > > /
>> > > > > > >>> >> >> > > > > > > > > > >> > > decrypt
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> data.
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> I will add the Javadoc.
>> > After
>> > > > > that,
>> > > > > > >>> you
>> > > > > > >>> >> can
>> > > > > > >>> >> >> > > review
>> > > > > > >>> >> >> > > > > the
>> > > > > > >>> >> >> > > > > > > pull
>> > > > > > >>> >> >> > > > > > > > > > >> request
>> > > > > > >>> >> >> > > > > > > > > > >> > > more
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> completely.
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> What do you expect for
>> the
>> > > > > > >>> documentation?
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> Notice that pac4j
>> > > dependencies
>> > > > > are
>> > > > > > >>> still
>> > > > > > >>> >> >> > > snapshots,
>> > > > > > >>> >> >> > > > > but
>> > > > > > >>> >> >> > > > > > > > they
>> > > > > > >>> >> >> > > > > > > > > > >> will be
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> released in a week or
>> two.
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> Thanks.
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> Best regards,
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> Jérôme
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> 2015-12-02 17:51
>> GMT+01:00
>> > > > larry
>> > > > > > >>> mccay <
>> > > > > > >>> >> >> > > > > > > > > larry.mccay@gmail.com
>> > > > > > >>> >> >> > > > > > > > > > >:
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > Jérôme -
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > If you would like to
>> add
>> > > that
>> > > > > > >>> change as
>> > > > > > >>> >> >> part
>> > > > > > >>> >> >> > of
>> > > > > > >>> >> >> > > > > your
>> > > > > > >>> >> >> > > > > > > > patch
>> > > > > > >>> >> >> > > > > > > > > or
>> > > > > > >>> >> >> > > > > > > > > > >> as a
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > separately filed JIRA
>> to
>> > > fix
>> > > > a
>> > > > > > bug
>> > > > > > >>> that
>> > > > > > >>> >> >> would
>> > > > > > >>> >> >> > > > > > certainly
>> > > > > > >>> >> >> > > > > > > > be
>> > > > > > >>> >> >> > > > > > > > > > >> > welcomed.
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > Otherwise, I can do
>> it.
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > Let me know.
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > thanks,
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > --larry
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > On Wed, Dec 2, 2015 at
>> > > 11:44
>> > > > > AM,
>> > > > > > >>> larry
>> > > > > > >>> >> >> mccay
>> > > > > > >>> >> >> > <
>> > > > > > >>> >> >> > > > > > > > > > >> > larry.mccay@gmail.com
>> > > > > > >>> >> >> > > > > > > > > > >> > > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > wrote:
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > > Okay - I had to add
>> an
>> > > > > override
>> > > > > > >>> of
>> > > > > > >>> >> >> > > > > > getUserPrincipal()
>> > > > > > >>> >> >> > > > > > > > to
>> > > > > > >>> >> >> > > > > > > > > > the
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >
>> > > > > > >>> >> IdentityAsserterHttpServletRequestWrapper
>> > > > > > >>> >> >> > and
>> > > > > > >>> >> >> > > > > > return
>> > > > > > >>> >> >> > > > > > > > the
>> > > > > > >>> >> >> > > > > > > > > > >> member
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> variable
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > > username and it
>> works
>> > > like
>> > > > a
>> > > > > > >>> charm.
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > > Why I haven't seen
>> this
>> > > > same
>> > > > > > >>> behavior
>> > > > > > >>> >> >> with
>> > > > > > >>> >> >> > > > other
>> > > > > > >>> >> >> > > > > > > > > providers
>> > > > > > >>> >> >> > > > > > > > > > >> is a
>> > > > > > >>> >> >> > > > > > > > > > >> > > bit
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> of a
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > > mystery but they
>> must
>> > be
>> > > > > adding
>> > > > > > >>> other
>> > > > > > >>> >> >> > > wrappers
>> > > > > > >>> >> >> > > > > that
>> > > > > > >>> >> >> > > > > > > > > handle
>> > > > > > >>> >> >> > > > > > > > > > >> it.
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > > This is quite cool,
>> > > Jérôme!
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > > On Wed, Dec 2, 2015
>> at
>> > > > 10:41
>> > > > > > AM,
>> > > > > > >>> larry
>> > > > > > >>> >> >> > mccay
>> > > > > > >>> >> >> > > <
>> > > > > > >>> >> >> > > > > > > > > > >> > > larry.mccay@gmail.com
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > > wrote:
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >> That was it -
>> thanks!
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >> On Wed, Dec 2,
>> 2015 at
>> > > > 10:20
>> > > > > > AM,
>> > > > > > >>> >> Jérôme
>> > > > > > >>> >> >> > > LELEU
>> > > > > > >>> >> >> > > > <
>> > > > > > >>> >> >> > > > > > > > > > >> > leleuj@gmail.com>
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> wrote:
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> This is my exact
>> > > command
>> > > > > > line:
>> > > > > > >>> mvn
>> > > > > > >>> >> >> > > -Prelease
>> > > > > > >>> >> >> > > > > > clean
>> > > > > > >>> >> >> > > > > > > > > > install
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> -DskipTests
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> You use an
>> internal
>> > > Maven
>> > > > > > >>> >> repository to
>> > > > > > >>> >> >> > > fetch
>> > > > > > >>> >> >> > > > > > > > > > dependencies
>> > > > > > >>> >> >> > > > > > > > > > >> > from
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > internet:
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
>> > > > > > >>> >> >> > > > > > > > > > >> > >
>> > > > > > >>> >> >> > > > > > > >
>> > > > > > >>> >> >> > >
>> > > > > > >>>
>> > > http://nexus-private.hortonworks.com/nexus/content/groups/public/
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> Does this
>> repository
>> > > have
>> > > > > > >>> access to
>> > > > > > >>> >> the
>> > > > > > >>> >> >> > > > remote
>> > > > > > >>> >> >> > > > > > > > > Snapshots
>> > > > > > >>> >> >> > > > > > > > > > >> > > Sonatype
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> repo?
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> 2015-12-02 16:16
>> > > > GMT+01:00
>> > > > > > >>> larry
>> > > > > > >>> >> mccay
>> > > > > > >>> >> >> <
>> > > > > > >>> >> >> > > > > > > > > > >> larry.mccay@gmail.com
>> > > > > > >>> >> >> > > > > > > > > > >> > >:
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > hmmm - I used:
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > mvn clean
>> install
>> > > > > > >>> -DskipTests=true
>> > > > > > >>> >> >> > > > -Prelease
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > The repository
>> > entry
>> > > is
>> > > > > in
>> > > > > > >>> there
>> > > > > > >>> >> >> > already.
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > No worky.
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > On Wed, Dec 2,
>> 2015
>> > > at
>> > > > > > 10:12
>> > > > > > >>> AM,
>> > > > > > >>> >> >> Jérôme
>> > > > > > >>> >> >> > > > > LELEU <
>> > > > > > >>> >> >> > > > > > > > > > >> > > leleuj@gmail.com
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> wrote:
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Hi,
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > You need the
>> > > > j2e-pac4j
>> > > > > > >>> >> dependencies
>> > > > > > >>> >> >> > as
>> > > > > > >>> >> >> > > > well
>> > > > > > >>> >> >> > > > > > as
>> > > > > > >>> >> >> > > > > > > > the
>> > > > > > >>> >> >> > > > > > > > > > >> pac4j-*
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> dependencies,
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > but you don't
>> > need
>> > > to
>> > > > > > >>> build them
>> > > > > > >>> >> >> > > locally
>> > > > > > >>> >> >> > > > > > > > > (hopefully).
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > But you need a
>> > > > > dependency
>> > > > > > >>> on the
>> > > > > > >>> >> >> > > Sonatype
>> > > > > > >>> >> >> > > > > > > > snapshots
>> > > > > > >>> >> >> > > > > > > > > > >> > > repository
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> (where the
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > snapshot
>> versions
>> > > are
>> > > > > > >>> hosted),
>> > > > > > >>> >> >> which
>> > > > > > >>> >> >> > is
>> > > > > > >>> >> >> > > > > added
>> > > > > > >>> >> >> > > > > > > for
>> > > > > > >>> >> >> > > > > > > > > > >> Maven in
>> > > > > > >>> >> >> > > > > > > > > > >> > > the
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> root
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > pom.xml:
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >> > > >
>> > > > > > >>> >> >> > > > > > > > > > >> > >
>> > > > > > >>> >> >> > > > > > > > > > >> >
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > >
>> > > > > > >>> >> >> > > > > > > > >
>> > > > > > >>> >> >> > > > > > > >
>> > > > > > >>> >> >> > > > > > >
>> > > > > > >>> >> >> > > > > >
>> > > > > > >>> >> >> > > > >
>> > > > > > >>> >> >> > > >
>> > > > > > >>> >> >> > >
>> > > > > > >>> >> >> >
>> > > > > > >>> >> >>
>> > > > > > >>> >>
>> > > > > > >>>
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > If you use Ant
>> > for
>> > > > the
>> > > > > > >>> build,
>> > > > > > >>> >> there
>> > > > > > >>> >> >> > is
>> > > > > > >>> >> >> > > > > maybe
>> > > > > > >>> >> >> > > > > > a
>> > > > > > >>> >> >> > > > > > > > > glitch
>> > > > > > >>> >> >> > > > > > > > > > >> to
>> > > > > > >>> >> >> > > > > > > > > > >> > > find
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> the
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > Sonatype
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Maven repo.
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Thanks.
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Best regards,
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Jérôme
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > 2015-12-02
>> 16:06
>> > > > > > GMT+01:00
>> > > > > > >>> larry
>> > > > > > >>> >> >> > mccay
>> > > > > > >>> >> >> > > <
>> > > > > > >>> >> >> > > > > > > > > > >> > > larry.mccay@gmail.com
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >:
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > 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.mccay@gmail.com>
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > wrote:
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > >
>> > > > > > >>> >> gateway-provider-security-pac4j
>> > > > > > >>> >> >> > > > doesn't
>> > > > > > >>> >> >> > > > > > > > build -
>> > > > > > >>> >> >> > > > > > > > > > do
>> > > > > > >>> >> >> > > > > > > > > > >> you
>> > > > > > >>> >> >> > > > > > > > > > >> > > > have
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> a
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> pending
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > > change for
>> > your
>> > > > > > >>> pom.xml or
>> > > > > > >>> >> >> > > something?
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >> >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > > >
>> > > > > > >>> >> >> > > > > > > > > > >> > > >
>> > > > > > >>> >> >> > > > > > > > > > >> > >
>> > > > > > >>> >> >> > > > > > > > > > >> >
>> > > > > > >>> >> >> > > > > > > > > > >>
>> > > > > > >>> >> >> > > > > > > > > > >
>> > > > > > >>> >> >> > > > > > > > > > >
>> > > > > > >>> >> >> > > > > > > > > >
>> > > > > > >>> >> >> > > > > > > > >
>> > > > > > >>> >> >> > > > > > > >
>> > > > > > >>> >> >> > > > > > >
>> > > > > > >>> >> >> > > > > >
>> > > > > > >>> >> >> > > > >
>> > > > > > >>> >> >> > > >
>> > > > > > >>> >> >> > >
>> > > > > > >>> >> >> >
>> > > > > > >>> >> >>
>> > > > > > >>> >>
>> > > > > > >>>
>> > > > > > >>
>> > > > > > >>
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: pac4j and Apache Knox
Posted by larry mccay <lm...@apache.org>.
Okay - got past that now....
We are getting closer!
On Fri, Jan 15, 2016 at 10:56 AM, Jérôme LELEU <le...@gmail.com> wrote:
> Hi,
>
> We have one callback url (the KnoxSSO url) and multiple identity providers
> so to distinguish between all clients, pac4j uses the callback url + the
> client_name parameter (Clients.DEFAULT_CLIENT_NAME_PARAMETER).
>
> The redirection url generated to the identity provider has this client_name
> parameter: this is why it works well with the CAS server which redirects
> the user (after a successfull url) to the originally provided url.
>
> For Okta, on server side, the redirection relies on the defined url. *So
> you must define the callback url in Okta as your KnoxSSO url + the
> client_name parameter = SAML2Client*.
>
> I myself have
> https://127.0.0.1:8443/gateway/idp/api/v1/websso?client_name=SAML2Client
> for my Okta app. And the logic of the pac4j gateway provider is based on
> this client_name parameter to know if it's a callback or an access call.
> Hence the infinite loop in your case.
>
> I guess we need to add a warning in the documentation for that. Just let
> met know how you want to proceed.
>
> Thanks.
> Best regards,
> Jérôme
>
>
>
>
>
> 2016-01-15 16:38 GMT+01:00 larry mccay <lm...@apache.org>:
>
> > Hi Jérôme -
> >
> > Thanks for the updated docs - I will take a look today.
> >
> > I am currently still trying to test okta and stuck in a redirect loop.
> > Did you have to change anything in order to get the
> > request.getParameter(Clients.DEFAULT_CLIENT_NAME_PARAMETER)
> > set for the callbacks from okta? It is null in my environment and
> therefore
> > it moves on to the following:
> >
> > // otherwise just apply security and requires authentication
> >
> > // apply RequiresAuthenticationFilter
> >
> > requiresAuthenticationFilter.doFilter(servletRequest,
> > servletResponse, filterChain);
> >
> > which obviously results in the redirect loop.
> >
> > Curious whether you ran into that...
> >
> > thanks,
> >
> > --larry
> >
> > On Fri, Jan 15, 2016 at 4:00 AM, Jérôme LELEU <le...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > I just uploaded a new patch for the documentation with the links
> pointing
> > > to the pac4j wiki. It should be clearer.
> > >
> > > Thanks.
> > > Best regards,
> > > Jérôme
> > >
> > >
> > > 2016-01-14 13:20 GMT+01:00 larry mccay <lm...@apache.org>:
> > >
> > > > That sounds pretty reasonable.
> > > > I will likely document a few of the integrations that are possible in
> > > > blogs/tutorials anyway.
> > > >
> > > > I don't want testing of Knox at release time to have to jump around
> to
> > > much
> > > > in order to be able to test.
> > > > I think we can make that all good though.
> > > >
> > > > I will see what I can do with okta today.
> > > >
> > > > On Thu, Jan 14, 2016 at 5:00 AM, Jérôme LELEU <le...@gmail.com>
> > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Yes, the documentation is a bit too light. But you guessed it
> right:
> > we
> > > > > need to have a keystore for encryption.
> > > > >
> > > > > The saml.identityProviderMetadataPath can point to a local resource
> > or
> > > > to a
> > > > > remote one, using the right prefix: resource:, file: or an url (by
> > > > default,
> > > > > it is a file path). This must be documented though.
> > > > >
> > > > > With Okta, I used the defined url (Single Sign On URL = Recipient
> > URL =
> > > > > Destination URL) for the serviceProviderEntityId, but I think it
> may
> > > > > depends on IdP as well. Reading the spec, it must be an URI, but
> I'm
> > > not
> > > > > sure if the SP metadata should be really available on this url. For
> > > Okta,
> > > > > it doesn't matter.
> > > > >
> > > > > According to your SAML configuration, the SP metadata will be
> > generated
> > > > > somewhere and this somewhere can be defined via the
> > > > > serviceProviderMetadataPath parameter. You generally need to update
> > > your
> > > > > metadata to the IdP (not required for Okta though). Both the SP and
> > IdP
> > > > > must know each other.
> > > > >
> > > > > When writing the documentation, I went fast on these parameters
> with
> > > the
> > > > > feeling they were regular ones, but indeed, the description in the
> > Knox
> > > > > manual is not enough. This is somehow a bit normal as the real
> > > > > documentation for SAML is on the SAML wiki:
> > > > >
> https://github.com/pac4j/pac4j/wiki/Clients#details-for-saml-support
> > > > >
> > > > > So I propose to keep the Knox documentation mostly "as is", but add
> > > links
> > > > > to the pac4j wiki (where I could more easily made updates). All
> pac4j
> > > > > integrations need this documentation so it's better to centralize
> it,
> > > > from
> > > > > my point of view. What do you think?
> > > > >
> > > > > Thanks.
> > > > > Best regards,
> > > > > Jérôme
> > > > >
> > > > >
> > > > >
> > > > > 2016-01-13 19:37 GMT+01:00 larry mccay <lm...@apache.org>:
> > > > >
> > > > > > Hi Jérôme -
> > > > > >
> > > > > > I'm trying to configure the pac4j provider for an okta
> > "application"
> > > > > that I
> > > > > > created.
> > > > > > The following (from KNOX-642 docs patch) isn't quite enough to
> make
> > > it
> > > > > > clear to me how to go about doing so:
> > > > > >
> > > > > > +saml.keystorePassword | Password of the keystore
> > > (storepass)
> > > > > > +saml.privateKeyPassword | Password for the private key
> > > > > (keypass)
> > > > > > +saml.keystorePath | Path of the keystore
> > > > > > +saml.identityProviderMetadataPath | Path of the
> identity
> > > > > > provider metadata
> > > > > > +saml.maximumAuthenticationLifetime | Maximum lifetime
> > for
> > > > > > authentication
> > > > > > +saml.serviceProviderEntityId | Identifier of the
> service
> > > > > > provider
> > > > > > +saml.serviceProviderMetadataPath | Path of the service
> > > > > provider
> > > > > > metadata
> > > > > >
> > > > > > I assume that I can use the gateway.jks keystore and the
> > > > gateway-identity
> > > > > > keypair to do the request signing and that that information is
> what
> > > is
> > > > > > needed for the first 3 params. Unfortunately, I don't see any use
> > of
> > > > > > gateway services to get the master secret therefore it needs to
> be
> > in
> > > > > clear
> > > > > > text here. This won't work - but may not be a show stopper for
> > > > committing
> > > > > > to master as long as we follow up with a fix.
> > > > > >
> > > > > > Can saml.identityProviderMetadataPath point to a remote location
> or
> > > > does
> > > > > it
> > > > > > have to be local to the SP application. This would likely require
> > it
> > > to
> > > > > be
> > > > > > on the local filesystem, provisioned by the contributor into the
> > > > > generated
> > > > > > web app or in some central location via NFS or something like
> that.
> > > > > >
> > > > > > The okta application that I created is called KnoxSSO - is that
> the
> > > > value
> > > > > > for saml.serviceProviderEntityId?
> > > > > >
> > > > > > The saml.serviceProviderMetadataPath has the same questions as
> the
> > > > > metadata
> > > > > > for the IDP. In addition, is there a sample metadata file that we
> > can
> > > > > > provide for the use of pac4j with KnoxSSO?
> > > > > >
> > > > > > I think that getting this working and clean (no clear text
> > passwords)
> > > > > will
> > > > > > make a great feature and blog for featuring pac4j provider and
> the
> > > > 0.8.0
> > > > > > release. So, let's try and iron this out clearly.
> > > > > >
> > > > > > I would really like to get this working and committed in the next
> > > > couple
> > > > > > days to free us up for follow up items. In particular we need
> time
> > to
> > > > > > figure out whether the identity assertion providers that we
> > currently
> > > > > have
> > > > > > will suffice for an apache release that is featuring this new
> > > > > > functionality.
> > > > > >
> > > > > > I will also add the above comments/questions to the JIRA for
> > > > visibility.
> > > > > >
> > > > > > thanks,
> > > > > >
> > > > > > --larry
> > > > > >
> > > > > > On Fri, Jan 8, 2016 at 12:40 PM, larry mccay <lm...@apache.org>
> > > > wrote:
> > > > > >
> > > > > > > Jérôme -
> > > > > > >
> > > > > > > My testing of OpenID Connect is blocked.
> > > > > > > Can you see the comments in KNOX-641?
> > > > > > >
> > > > > > > thanks,
> > > > > > >
> > > > > > > --larry
> > > > > > >
> > > > > > > On Wed, Jan 6, 2016 at 2:30 PM, larry mccay <
> > larry.mccay@gmail.com
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > >> Jérôme -
> > > > > > >>
> > > > > > >> Please see the comments on KNOX-641.
> > > > > > >>
> > > > > > >> thanks,
> > > > > > >>
> > > > > > >> --larry
> > > > > > >>
> > > > > > >> On Wed, Jan 6, 2016 at 11:24 AM, Kevin Minder <
> > > > > > >> kevin.minder@hortonworks.com> wrote:
> > > > > > >>
> > > > > > >>> I can certainly appreciate the issue of including external
> > > > resources
> > > > > in
> > > > > > >>> automated tests. Nothing has driven me more crazy over the
> > > years.
> > > > > The
> > > > > > >>> flip side of this of course is not finding out about a
> breakage
> > > > until
> > > > > > >>> someone is willing to go through the manual testing which
> will
> > > > > > typically
> > > > > > >>> happen just before a release. Also the implication is that
> > these
> > > > > > testing
> > > > > > >>> procedures must be very will documented so that they can be
> > > > continue
> > > > > > to be
> > > > > > >>> run once any of us are no longer active in the project.
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> On 1/6/16, 2:12 AM, "Jérôme LELEU" <le...@gmail.com> wrote:
> > > > > > >>>
> > > > > > >>> >Hi,
> > > > > > >>> >
> > > > > > >>> >Yes, you can hit the CAS server at Heroku. Notice it's a
> > Heroku
> > > > free
> > > > > > >>> server
> > > > > > >>> >so it needs to be re-activated first (it takes a couple of
> > > > seconds).
> > > > > > So
> > > > > > >>> for
> > > > > > >>> >a UI test, you should first hit it, wait 30 seconds and then
> > > > perform
> > > > > > the
> > > > > > >>> >test.
> > > > > > >>> >
> > > > > > >>> >Just my 2 cents:
> > > > > > >>> >Using automated UI tests was my first strategy for pac4j
> but
> > I
> > > > > > finally
> > > > > > >>> >gave up because public providers change very often, at least
> > > > enough
> > > > > to
> > > > > > >>> make
> > > > > > >>> >the maintenance tests a nightmare. Currently, I'm using
> manual
> > > > tests
> > > > > > >>> (the
> > > > > > >>> >same for all demos), it takes me around 5 minutes to play
> them
> > > all
> > > > > by
> > > > > > >>> hand
> > > > > > >>> >(for a demo) and I launched manually the UI tests I have for
> > > every
> > > > > > major
> > > > > > >>> >pac4j release. Just to say UI tests are not that easy. For a
> > CAS
> > > > > > server,
> > > > > > >>> >it's fairly feasible as the CAS server and protocol change
> > > rarely.
> > > > > > >>> >That's why for Knox, I did some compromise with a simulated
> > web
> > > > test
> > > > > > >>> (based
> > > > > > >>> >on the basic auth). See:
> > > > > > >>> >
> > > > > > >>>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/knox/pull/2/files#diff-d0c880ca71b310dbe57975c577535e97R47
> > > > > > >>> >
> > > > > > >>> >Thanks.
> > > > > > >>> >Best regards,
> > > > > > >>> >Jérôme
> > > > > > >>> >
> > > > > > >>> >
> > > > > > >>> >
> > > > > > >>> >2016-01-05 21:20 GMT+01:00 Kevin Minder <
> > > > > kevin.minder@hortonworks.com
> > > > > > >:
> > > > > > >>> >
> > > > > > >>> >> From my perspective it would be ideal if there were some
> > > > > automatable
> > > > > > >>> >> functional tests for this. I’m not advocating that these
> be
> > > > > > something
> > > > > > >>> >> included in “mvn clean install” as that is running too
> long
> > as
> > > > it
> > > > > > is.
> > > > > > >>> >> Given that I don’t have as much context as Larry, I have
> > some
> > > > > > >>> questions
> > > > > > >>> >> about what this would take. Lets say we had permission to
> > hit
> > > > > > >>> >> https://casserverpac4j.herokuapp.com/login as part of
> some
> > > low
> > > > > > >>> frequency
> > > > > > >>> >> automated tests (e.g. Once nighty). What static
> credentials
> > > and
> > > > > > >>> other test
> > > > > > >>> >> automation infrastructure would need to be implemented in
> > > > support
> > > > > of
> > > > > > >>> this?
> > > > > > >>> >> I understand that the test suite would require at a
> minimum
> > > > > > >>> >> 1) a test driver
> > > > > > >>> >> 2) a protected mock UI and
> > > > > > >>> >> 3) an appropriately configured Knox
> > > > > > >>> >> 4) a profile enabled maven module
> > > > > > >>> >> 5) an Apache jenkins job
> > > > > > >>> >> but I’m sure I’m missing other things. I’m certainly
> > willing
> > > to
> > > > > > help
> > > > > > >>> >> setup the skeleton infrastructure (e.g. test driver, mock
> > UI,
> > > > > maven
> > > > > > >>> module,
> > > > > > >>> >> jenkins job)
> > > > > > >>> >>
> > > > > > >>> >>
> > > > > > >>> >>
> > > > > > >>> >> On 1/5/16, 2:54 PM, "larry mccay" <la...@gmail.com>
> > > > wrote:
> > > > > > >>> >>
> > > > > > >>> >> >Okay, very good.
> > > > > > >>> >> >I've used TestShib for the picketlink provider - thanks
> for
> > > the
> > > > > > >>> pointers!
> > > > > > >>> >> >
> > > > > > >>> >> >On Tue, Jan 5, 2016 at 1:38 PM, Jérôme LELEU <
> > > leleuj@gmail.com
> > > > >
> > > > > > >>> wrote:
> > > > > > >>> >> >
> > > > > > >>> >> >> The online CAS server (
> > > > > > https://casserverpac4j.herokuapp.com/login)
> > > > > > >>> uses
> > > > > > >>> >> >> the
> > > > > > >>> >> >> CAS protocol. SAML support can be tested using some
> > online
> > > > IdP
> > > > > > like
> > > > > > >>> >> Okta,
> > > > > > >>> >> >> TestShib, OpenFeide, Ssocircle...
> > > > > > >>> >> >>
> > > > > > >>> >> >>
> > > > > > >>> >> >> 2016-01-05 17:32 GMT+01:00 larry mccay <
> > > > larry.mccay@gmail.com
> > > > > >:
> > > > > > >>> >> >>
> > > > > > >>> >> >> > Great - thanks for that pointer!
> > > > > > >>> >> >> >
> > > > > > >>> >> >> > I will take a look at that and help drive the release
> > > > related
> > > > > > >>> testing.
> > > > > > >>> >> >> > Merge testing will be gated on CAS server (is this
> SAML
> > > or
> > > > > CAS
> > > > > > >>> >> protocol?)
> > > > > > >>> >> >> > and testBasicAuth.
> > > > > > >>> >> >> >
> > > > > > >>> >> >> > On Tue, Jan 5, 2016 at 10:52 AM, Jérôme LELEU <
> > > > > > leleuj@gmail.com>
> > > > > > >>> >> wrote:
> > > > > > >>> >> >> >
> > > > > > >>> >> >> > > Hi,
> > > > > > >>> >> >> > >
> > > > > > >>> >> >> > > Glad to hear back from you!
> > > > > > >>> >> >> > >
> > > > > > >>> >> >> > > The core pac4j project is fully tested by unit
> tests
> > > (and
> > > > > > some
> > > > > > >>> >> >> > integration
> > > > > > >>> >> >> > > tests I run for major version), then all pac4j
> > > > > > implementations
> > > > > > >>> are
> > > > > > >>> >> each
> > > > > > >>> >> >> > > tested by the appropriate demo: j2e-pac4j-demo
> tests
> > > > > > j2e-pac4j,
> > > > > > >>> >> >> > > spring-webmvc-pac4j-demo tests spring-webmvc-pac4j,
> > > etc.
> > > > > > >>> >> >> > >
> > > > > > >>> >> >> > > So if you take a look at:
> > > > > > >>> >> >> > >
> > > > > > >>> >> >> > >
> > > > > > >>> >> >> >
> > > > > > >>> >> >>
> > > > > > >>> >>
> > > > > > >>>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/pac4j/j2e-pac4j-demo/blob/master/src/main/java/org/pac4j/demo/j2e/config/DemoConfigFactory.java#L27
> > > > > > >>> >> >> > > (for example), you have all the required
> information
> > to
> > > > > test.
> > > > > > >>> >> >> > >
> > > > > > >>> >> >> > > I can do that on my own, but it can be good for the
> > > Knox
> > > > > > >>> community
> > > > > > >>> >> to
> > > > > > >>> >> >> > start
> > > > > > >>> >> >> > > working / testing the pac4j support. It's up to
> yoy.
> > > > > > >>> >> >> > >
> > > > > > >>> >> >> > > Thanks.
> > > > > > >>> >> >> > > Best regards,
> > > > > > >>> >> >> > > Jérôme
> > > > > > >>> >> >> > >
> > > > > > >>> >> >> > >
> > > > > > >>> >> >> > > 2016-01-05 16:11 GMT+01:00 larry mccay <
> > > > > > larry.mccay@gmail.com
> > > > > > >>> >:
> > > > > > >>> >> >> > >
> > > > > > >>> >> >> > > > Hello Jérôme -
> > > > > > >>> >> >> > > >
> > > > > > >>> >> >> > > > Happy New Year!
> > > > > > >>> >> >> > > >
> > > > > > >>> >> >> > > > I am going to start reviewing your updates today,
> > > > > > hopefully.
> > > > > > >>> >> >> > > > I was thinking that we need to start discussions
> on
> > > > what
> > > > > > the
> > > > > > >>> key
> > > > > > >>> >> >> > usecases
> > > > > > >>> >> >> > > > are and how to go about testing them.
> > > > > > >>> >> >> > > > We can certainly test the testBasicAuth and
> against
> > > the
> > > > > > >>> hosted CAS
> > > > > > >>> >> >> > server
> > > > > > >>> >> >> > > > but what about FB, openid, OAuth, etc?
> > > > > > >>> >> >> > > >
> > > > > > >>> >> >> > > > I'm not sure that FB would be a key feature but
> > > OpenID
> > > > > > >>> Connect and
> > > > > > >>> >> >> > OAuth
> > > > > > >>> >> >> > > > would be - as is SAML.
> > > > > > >>> >> >> > > > I think CAS buys us SAML testing - assuming that
> > the
> > > > > > >>> >> configuration of
> > > > > > >>> >> >> > the
> > > > > > >>> >> >> > > > hosted server is actually a SAML 2 instance.
> > > > > > >>> >> >> > > >
> > > > > > >>> >> >> > > > What about the others?
> > > > > > >>> >> >> > > >
> > > > > > >>> >> >> > > > I don't know that we need to be able to test them
> > all
> > > > > > before
> > > > > > >>> merge
> > > > > > >>> >> >> but
> > > > > > >>> >> >> > > some
> > > > > > >>> >> >> > > > sort of manual verification would be great.
> > > > > > >>> >> >> > > > We would need to be able to test them before the
> > next
> > > > > > release
> > > > > > >>> >> which
> > > > > > >>> >> >> > would
> > > > > > >>> >> >> > > > be featuring the pac4j functionality.
> > > > > > >>> >> >> > > >
> > > > > > >>> >> >> > > > Maybe you can describe how you go about testing
> > such
> > > > > things
> > > > > > >>> for
> > > > > > >>> >> the
> > > > > > >>> >> >> > pac4j
> > > > > > >>> >> >> > > > project itself?
> > > > > > >>> >> >> > > >
> > > > > > >>> >> >> > > > thanks,
> > > > > > >>> >> >> > > >
> > > > > > >>> >> >> > > > --larry
> > > > > > >>> >> >> > > >
> > > > > > >>> >> >> > > >
> > > > > > >>> >> >> > > > On Tue, Jan 5, 2016 at 9:55 AM, Jérôme LELEU <
> > > > > > >>> leleuj@gmail.com>
> > > > > > >>> >> >> wrote:
> > > > > > >>> >> >> > > >
> > > > > > >>> >> >> > > > > Hi,
> > > > > > >>> >> >> > > > >
> > > > > > >>> >> >> > > > > Happy new year!
> > > > > > >>> >> >> > > > >
> > > > > > >>> >> >> > > > > A few days ago, I updated my patch of the pac4j
> > > > gateway
> > > > > > >>> provider
> > > > > > >>> >> >> > > > according
> > > > > > >>> >> >> > > > > to all comments on
> > > > > > >>> >> https://issues.apache.org/jira/browse/KNOX-641
> > > > > > >>> >> >> as
> > > > > > >>> >> >> > > > well
> > > > > > >>> >> >> > > > > as the documentation on KNOX-642.
> > > > > > >>> >> >> > > > >
> > > > > > >>> >> >> > > > > Is everything ok for the merge?
> > > > > > >>> >> >> > > > >
> > > > > > >>> >> >> > > > > Thanks.
> > > > > > >>> >> >> > > > > Best regards,
> > > > > > >>> >> >> > > > > Jérôme
> > > > > > >>> >> >> > > > >
> > > > > > >>> >> >> > > > >
> > > > > > >>> >> >> > > > > 2015-12-14 15:28 GMT+01:00 larry mccay <
> > > > > > >>> larry.mccay@gmail.com>:
> > > > > > >>> >> >> > > > >
> > > > > > >>> >> >> > > > > > Hi Jérôme -
> > > > > > >>> >> >> > > > > >
> > > > > > >>> >> >> > > > > > Not sure if you saw but I added review
> comments
> > > to
> > > > > > >>> KNOX-641.
> > > > > > >>> >> >> > > > > >
> > > > > > >>> >> >> > > > > > I think that we need to determine whether we
> > want
> > > > the
> > > > > > >>> >> >> testBasicAuth
> > > > > > >>> >> >> > > in
> > > > > > >>> >> >> > > > > the
> > > > > > >>> >> >> > > > > > provider itself.
> > > > > > >>> >> >> > > > > >
> > > > > > >>> >> >> > > > > > Let's follow up on the JIRA.
> > > > > > >>> >> >> > > > > >
> > > > > > >>> >> >> > > > > > thanks,
> > > > > > >>> >> >> > > > > >
> > > > > > >>> >> >> > > > > > --larry
> > > > > > >>> >> >> > > > > >
> > > > > > >>> >> >> > > > > > On Fri, Dec 11, 2015 at 8:44 AM, Jérôme
> LELEU <
> > > > > > >>> >> leleuj@gmail.com>
> > > > > > >>> >> >> > > > wrote:
> > > > > > >>> >> >> > > > > >
> > > > > > >>> >> >> > > > > > > Hi,
> > > > > > >>> >> >> > > > > > >
> > > > > > >>> >> >> > > > > > > No problem. It can go into a version 0.8.0
> if
> > > > > needed.
> > > > > > >>> The
> > > > > > >>> >> truth
> > > > > > >>> >> >> > is
> > > > > > >>> >> >> > > > that
> > > > > > >>> >> >> > > > > > > there is only one change outside the new
> > pac4j
> > > > > > module,
> > > > > > >>> so I
> > > > > > >>> >> >> think
> > > > > > >>> >> >> > > > risks
> > > > > > >>> >> >> > > > > > are
> > > > > > >>> >> >> > > > > > > extremly limited.
> > > > > > >>> >> >> > > > > > >
> > > > > > >>> >> >> > > > > > > Just let met know.
> > > > > > >>> >> >> > > > > > >
> > > > > > >>> >> >> > > > > > > Thanks.
> > > > > > >>> >> >> > > > > > > Best regards,
> > > > > > >>> >> >> > > > > > > Jérôme
> > > > > > >>> >> >> > > > > > >
> > > > > > >>> >> >> > > > > > >
> > > > > > >>> >> >> > > > > > > 2015-12-11 14:23 GMT+01:00 larry mccay <
> > > > > > >>> >> larry.mccay@gmail.com
> > > > > > >>> >> >> >:
> > > > > > >>> >> >> > > > > > >
> > > > > > >>> >> >> > > > > > > > Hi Jérôme -
> > > > > > >>> >> >> > > > > > > >
> > > > > > >>> >> >> > > > > > > > I have unfortunately not had a chance to
> > > pull,
> > > > > > >>> review and
> > > > > > >>> >> >> test
> > > > > > >>> >> >> > it
> > > > > > >>> >> >> > > > yet
> > > > > > >>> >> >> > > > > > and
> > > > > > >>> >> >> > > > > > > > have intended to do that today.
> > > > > > >>> >> >> > > > > > > > I apologize for the delay.
> > > > > > >>> >> >> > > > > > > >
> > > > > > >>> >> >> > > > > > > > I was actually thinking that this would
> go
> > > > into a
> > > > > > >>> follow
> > > > > > >>> >> up
> > > > > > >>> >> >> > > release
> > > > > > >>> >> >> > > > > > that
> > > > > > >>> >> >> > > > > > > we
> > > > > > >>> >> >> > > > > > > > would try and get done rapidly after the
> > > 0.7.0
> > > > > > >>> release
> > > > > > >>> >> but we
> > > > > > >>> >> >> > can
> > > > > > >>> >> >> > > > > > discuss
> > > > > > >>> >> >> > > > > > > > the target and its chances of
> destabilizing
> > > > > 0.7.0.
> > > > > > >>> >> >> > > > > > > >
> > > > > > >>> >> >> > > > > > > > I believe that it is rather
> self-contained
> > > with
> > > > > > only
> > > > > > >>> a few
> > > > > > >>> >> >> > > changes
> > > > > > >>> >> >> > > > to
> > > > > > >>> >> >> > > > > > > > external modules.
> > > > > > >>> >> >> > > > > > > >
> > > > > > >>> >> >> > > > > > > > Opening the JIRAs is perfect and I was
> > going
> > > to
> > > > > do
> > > > > > >>> that
> > > > > > >>> >> once
> > > > > > >>> >> >> I
> > > > > > >>> >> >> > > > > started
> > > > > > >>> >> >> > > > > > > the
> > > > > > >>> >> >> > > > > > > > review.
> > > > > > >>> >> >> > > > > > > >
> > > > > > >>> >> >> > > > > > > > Let's continue review comments and
> > > > collaboration
> > > > > on
> > > > > > >>> those
> > > > > > >>> >> >> > JIRAs.
> > > > > > >>> >> >> > > > > > > > I will add you to the contributors list
> so
> > > that
> > > > > we
> > > > > > >>> can
> > > > > > >>> >> assign
> > > > > > >>> >> >> > > them
> > > > > > >>> >> >> > > > to
> > > > > > >>> >> >> > > > > > > you.
> > > > > > >>> >> >> > > > > > > >
> > > > > > >>> >> >> > > > > > > > Thank you for your contributions and your
> > > > > patience,
> > > > > > >>> >> Jérôme!
> > > > > > >>> >> >> > > > > > > >
> > > > > > >>> >> >> > > > > > > > --larry
> > > > > > >>> >> >> > > > > > > >
> > > > > > >>> >> >> > > > > > > > On Fri, Dec 11, 2015 at 3:00 AM, Jérôme
> > > LELEU <
> > > > > > >>> >> >> > leleuj@gmail.com>
> > > > > > >>> >> >> > > > > > wrote:
> > > > > > >>> >> >> > > > > > > >
> > > > > > >>> >> >> > > > > > > > > Hi,
> > > > > > >>> >> >> > > > > > > > >
> > > > > > >>> >> >> > > > > > > > > I didn't get any new feedback on the
> pull
> > > > > request
> > > > > > >>> so I
> > > > > > >>> >> >> assume
> > > > > > >>> >> >> > > > > > > everything
> > > > > > >>> >> >> > > > > > > > is
> > > > > > >>> >> >> > > > > > > > > ok from your point of view.
> > > > > > >>> >> >> > > > > > > > >
> > > > > > >>> >> >> > > > > > > > > I released pac4j v1.8.1 and j2e-pac4j
> > > v1.2.1
> > > > > so I
> > > > > > >>> >> updated
> > > > > > >>> >> >> the
> > > > > > >>> >> >> > > > pull
> > > > > > >>> >> >> > > > > > > > request
> > > > > > >>> >> >> > > > > > > > > to use them and successfully re-tested
> > > > > > everything.
> > > > > > >>> >> >> > > > > > > > >
> > > > > > >>> >> >> > > > > > > > > I opened KNOX-641 and submitted the
> > > > > corresponding
> > > > > > >>> patch.
> > > > > > >>> >> >> > > > > > > > >
> > > > > > >>> >> >> > > > > > > > > I also wrote the documentation, opened
> > > > KNOX-642
> > > > > > and
> > > > > > >>> >> >> submitted
> > > > > > >>> >> >> > > the
> > > > > > >>> >> >> > > > > > > > > corresponding patch (just to let you
> know
> > > > that
> > > > > it
> > > > > > >>> >> doesn't
> > > > > > >>> >> >> > work
> > > > > > >>> >> >> > > > out
> > > > > > >>> >> >> > > > > of
> > > > > > >>> >> >> > > > > > > the
> > > > > > >>> >> >> > > > > > > > > box in Windows, I had to replace
> mvn.bat
> > by
> > > > > > >>> mvn.cmd to
> > > > > > >>> >> make
> > > > > > >>> >> >> > ant
> > > > > > >>> >> >> > > > > > work).
> > > > > > >>> >> >> > > > > > > > >
> > > > > > >>> >> >> > > > > > > > > Even if the branch 0.7.0 has already
> been
> > > > > > created,
> > > > > > >>> I
> > > > > > >>> >> >> assumed
> > > > > > >>> >> >> > > this
> > > > > > >>> >> >> > > > > new
> > > > > > >>> >> >> > > > > > > > pac4j
> > > > > > >>> >> >> > > > > > > > > provider will go into this version
> 0.7.0
> > > > > > >>> (dependency on
> > > > > > >>> >> the
> > > > > > >>> >> >> > > > > > > > 0.7.0-SNAPSHOT
> > > > > > >>> >> >> > > > > > > > > parent version).
> > > > > > >>> >> >> > > > > > > > >
> > > > > > >>> >> >> > > > > > > > > Just let me know if everything is ok
> and
> > > when
> > > > > > it's
> > > > > > >>> >> goind to
> > > > > > >>> >> >> > be
> > > > > > >>> >> >> > > > > > merged.
> > > > > > >>> >> >> > > > > > > > >
> > > > > > >>> >> >> > > > > > > > > Thanks.
> > > > > > >>> >> >> > > > > > > > > Best regards,
> > > > > > >>> >> >> > > > > > > > > Jérôme
> > > > > > >>> >> >> > > > > > > > >
> > > > > > >>> >> >> > > > > > > > >
> > > > > > >>> >> >> > > > > > > > >
> > > > > > >>> >> >> > > > > > > > >
> > > > > > >>> >> >> > > > > > > > > 2015-12-04 14:20 GMT+01:00 larry mccay
> <
> > > > > > >>> >> >> > larry.mccay@gmail.com
> > > > > > >>> >> >> > > >:
> > > > > > >>> >> >> > > > > > > > >
> > > > > > >>> >> >> > > > > > > > > > That ability to configure multiple
> > > > mechanisms
> > > > > > >>> based on
> > > > > > >>> >> >> > > > clientName
> > > > > > >>> >> >> > > > > > is
> > > > > > >>> >> >> > > > > > > > > really
> > > > > > >>> >> >> > > > > > > > > > interesting for Knox.
> > > > > > >>> >> >> > > > > > > > > > Currently, we require separate
> > topologies
> > > > per
> > > > > > >>> >> >> > authentication
> > > > > > >>> >> >> > > > > > > mechanism.
> > > > > > >>> >> >> > > > > > > > > > The ability to configure them all in
> > one
> > > is
> > > > > > >>> really
> > > > > > >>> >> great.
> > > > > > >>> >> >> > > > > > > > > >
> > > > > > >>> >> >> > > > > > > > > > We would need to think through the
> best
> > > way
> > > > > to
> > > > > > >>> provide
> > > > > > >>> >> >> the
> > > > > > >>> >> >> > > > > > clientName
> > > > > > >>> >> >> > > > > > > > > > parameter.
> > > > > > >>> >> >> > > > > > > > > > Since this is targeting KnoxSSO it
> can
> > > > > actually
> > > > > > >>> be
> > > > > > >>> >> added
> > > > > > >>> >> >> to
> > > > > > >>> >> >> > > the
> > > > > > >>> >> >> > > > > > > > > providerURL
> > > > > > >>> >> >> > > > > > > > > > used to redirect from the
> participating
> > > > > > >>> application.
> > > > > > >>> >> >> > > > > > > > > > Regardless of the authentication
> > > mechanism
> > > > > used
> > > > > > >>> each
> > > > > > >>> >> >> > > > application
> > > > > > >>> >> >> > > > > > will
> > > > > > >>> >> >> > > > > > > > > still
> > > > > > >>> >> >> > > > > > > > > > get the same JWT based cookie.
> > > > > > >>> >> >> > > > > > > > > >
> > > > > > >>> >> >> > > > > > > > > > I think that should work really
> nicely.
> > > > > > >>> >> >> > > > > > > > > >
> > > > > > >>> >> >> > > > > > > > > >
> > > > > > >>> >> >> > > > > > > > > > On Fri, Dec 4, 2015 at 7:17 AM, larry
> > > > mccay <
> > > > > > >>> >> >> > > > > larry.mccay@gmail.com
> > > > > > >>> >> >> > > > > > >
> > > > > > >>> >> >> > > > > > > > > wrote:
> > > > > > >>> >> >> > > > > > > > > >
> > > > > > >>> >> >> > > > > > > > > > > Excellent, Jérôme.
> > > > > > >>> >> >> > > > > > > > > > > Thanks!
> > > > > > >>> >> >> > > > > > > > > > >
> > > > > > >>> >> >> > > > > > > > > > > On Fri, Dec 4, 2015 at 2:40 AM,
> > Jérôme
> > > > > LELEU
> > > > > > <
> > > > > > >>> >> >> > > > leleuj@gmail.com
> > > > > > >>> >> >> > > > > >
> > > > > > >>> >> >> > > > > > > > wrote:
> > > > > > >>> >> >> > > > > > > > > > >
> > > > > > >>> >> >> > > > > > > > > > >> Hi,
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > > >> I will write how to configure the
> > > pac4j
> > > > > > >>> provider in
> > > > > > >>> >> >> the
> > > > > > >>> >> >> > > > > > > > documentation,
> > > > > > >>> >> >> > > > > > > > > > but
> > > > > > >>> >> >> > > > > > > > > > >> I can already give you some
> > insights.
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > > >> My main goal is always to respect
> > the
> > > > key
> > > > > > >>> design
> > > > > > >>> >> >> > > principles
> > > > > > >>> >> >> > > > of
> > > > > > >>> >> >> > > > > > > pac4j
> > > > > > >>> >> >> > > > > > > > > > >> whatever the environment /
> framework
> > > in
> > > > > > which
> > > > > > >>> it is
> > > > > > >>> >> >> > > > > implemented.
> > > > > > >>> >> >> > > > > > > For
> > > > > > >>> >> >> > > > > > > > > > Knox,
> > > > > > >>> >> >> > > > > > > > > > >> I'm pretty happy with the use of
> the
> > > > > > j2e-pac4j
> > > > > > >>> >> >> library,
> > > > > > >>> >> >> > > > which
> > > > > > >>> >> >> > > > > > > means
> > > > > > >>> >> >> > > > > > > > > that
> > > > > > >>> >> >> > > > > > > > > > >> almost all the pac4j features are
> > > > > available,
> > > > > > >>> >> >> especially
> > > > > > >>> >> >> > > both
> > > > > > >>> >> >> > > > > > > direct
> > > > > > >>> >> >> > > > > > > > > and
> > > > > > >>> >> >> > > > > > > > > > >> indirect clients. So it can do
> what
> > > > Shiro
> > > > > > >>> already
> > > > > > >>> >> does
> > > > > > >>> >> >> > but
> > > > > > >>> >> >> > > > > also,
> > > > > > >>> >> >> > > > > > > as
> > > > > > >>> >> >> > > > > > > > we
> > > > > > >>> >> >> > > > > > > > > > >> agreed together, supports remote
> > > > > > >>> authentications.
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > > >> It is only limited by what you can
> > > > > currently
> > > > > > >>> >> >> configure.
> > > > > > >>> >> >> > > And
> > > > > > >>> >> >> > > > > even
> > > > > > >>> >> >> > > > > > > > > > >> configuration is a pac4j feature
> as
> > > the
> > > > > CAS
> > > > > > >>> server
> > > > > > >>> >> has
> > > > > > >>> >> >> > the
> > > > > > >>> >> >> > > > > same
> > > > > > >>> >> >> > > > > > > > need.
> > > > > > >>> >> >> > > > > > > > > > >> Everything happens in this class:
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > >
> > > > > > >>> >> >> > > > > > > > >
> > > > > > >>> >> >> > > > > > > >
> > > > > > >>> >> >> > > > > > >
> > > > > > >>> >> >> > > > > >
> > > > > > >>> >> >> > > > >
> > > > > > >>> >> >> > > >
> > > > > > >>> >> >> > >
> > > > > > >>> >> >> >
> > > > > > >>> >> >>
> > > > > > >>> >>
> > > > > > >>>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java
> > > > > > >>> >> >> > > > > > > > > > >> ,
> > > > > > >>> >> >> > > > > > > > > > >> which allows you to configure
> > > Facebook,
> > > > > > >>> Twitter, a
> > > > > > >>> >> CAS
> > > > > > >>> >> >> > > > > server, a
> > > > > > >>> >> >> > > > > > > > SAML
> > > > > > >>> >> >> > > > > > > > > > IdP
> > > > > > >>> >> >> > > > > > > > > > >> or an OpenID Connect provider. All
> > the
> > > > > > >>> provided
> > > > > > >>> >> >> > parameters
> > > > > > >>> >> >> > > > to
> > > > > > >>> >> >> > > > > > the
> > > > > > >>> >> >> > > > > > > > > pac4j
> > > > > > >>> >> >> > > > > > > > > > >> provider are put into a Map and
> the
> > > > > > >>> >> >> > > ConfigPropertiesFactory
> > > > > > >>> >> >> > > > is
> > > > > > >>> >> >> > > > > > > built
> > > > > > >>> >> >> > > > > > > > > > with
> > > > > > >>> >> >> > > > > > > > > > >> this Map to return the built
> client
> > (=
> > > > > > >>> >> authentication
> > > > > > >>> >> >> > > > > > mechanism).
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > > >> You have one more specific option
> > for
> > > > Knox
> > > > > > as
> > > > > > >>> a
> > > > > > >>> >> basic
> > > > > > >>> >> >> > > > > > > authentication
> > > > > > >>> >> >> > > > > > > > > > popup
> > > > > > >>> >> >> > > > > > > > > > >> where the username must match the
> > > > > password,
> > > > > > >>> you can
> > > > > > >>> >> >> > define
> > > > > > >>> >> >> > > > > that
> > > > > > >>> >> >> > > > > > > by:
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > > >> <param>
> > > > > > >>> >> >> > > > > > > > > > >> <name>clientName</name>
> > > > > > >>> >> >> > > > > > > > > > >> <value>testBasicAuth</value>
> > > > > > >>> >> >> > > > > > > > > > >> </param>
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > > >> It's for testing only.
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > > >> For a CAS server:
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > > >> <param>
> > > > > > >>> >> >> > > > > > > > > > >> <name>cas.loginUrl</name>
> > > > > > >>> >> >> > > > > > > > > > >> <value>
> > > > > > >>> >> https://casserverpac4j.herokuapp.com/login
> > > > > > >>> >> >> > > </value>
> > > > > > >>> >> >> > > > > > > > > > >> </param>
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > > >> Here are all the properties
> > available
> > > > for
> > > > > > >>> building
> > > > > > >>> >> >> > clients
> > > > > > >>> >> >> > > > > > (their
> > > > > > >>> >> >> > > > > > > > > > meaning
> > > > > > >>> >> >> > > > > > > > > > >> is obvious):
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > > >> facebook.id
> > > > > > >>> >> >> > > > > > > > > > >> facebook.secret
> > > > > > >>> >> >> > > > > > > > > > >> facebook.scope
> > > > > > >>> >> >> > > > > > > > > > >> facebook.fields
> > > > > > >>> >> >> > > > > > > > > > >> twitter.id
> > > > > > >>> >> >> > > > > > > > > > >> twitter.secret
> > > > > > >>> >> >> > > > > > > > > > >> saml.keystorePassword
> > > > > > >>> >> >> > > > > > > > > > >> saml.privateKeyPassword
> > > > > > >>> >> >> > > > > > > > > > >> saml.keystorePath
> > > > > > >>> >> >> > > > > > > > > > >> saml.identityProviderMetadataPath
> > > > > > >>> >> >> > > > > > > > > > >> saml.maximumAuthenticationLifetime
> > > > > > >>> >> >> > > > > > > > > > >> saml.serviceProviderEntityId
> > > > > > >>> >> >> > > > > > > > > > >> saml.serviceProviderMetadataPath
> > > > > > >>> >> >> > > > > > > > > > >> cas.loginUrl
> > > > > > >>> >> >> > > > > > > > > > >> cas.protocol
> > > > > > >>> >> >> > > > > > > > > > >> oidc.id
> > > > > > >>> >> >> > > > > > > > > > >> oidc.secret
> > > > > > >>> >> >> > > > > > > > > > >> oidc.discoveryUri
> > > > > > >>> >> >> > > > > > > > > > >> oidc.customParamKey1
> > > > > > >>> >> >> > > > > > > > > > >> oidc.customParamValue1
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > > >> If you define multiple clients,
> the
> > > > first
> > > > > > one
> > > > > > >>> will
> > > > > > >>> >> be
> > > > > > >>> >> >> > used
> > > > > > >>> >> >> > > > for
> > > > > > >>> >> >> > > > > > > > > > >> authentication, but you can
> > explicitly
> > > > > > choose
> > > > > > >>> the
> > > > > > >>> >> >> client
> > > > > > >>> >> >> > > you
> > > > > > >>> >> >> > > > > > want
> > > > > > >>> >> >> > > > > > > to
> > > > > > >>> >> >> > > > > > > > > use
> > > > > > >>> >> >> > > > > > > > > > >> via the clientName parameter,
> > assuming
> > > > you
> > > > > > >>> want to
> > > > > > >>> >> >> > switch
> > > > > > >>> >> >> > > > from
> > > > > > >>> >> >> > > > > > > > client
> > > > > > >>> >> >> > > > > > > > > > >> depending on environment for
> > example.
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > > >> So if you want to add some new
> > > > > > authentication
> > > > > > >>> >> >> mechanism,
> > > > > > >>> >> >> > > you
> > > > > > >>> >> >> > > > > > must
> > > > > > >>> >> >> > > > > > > > > first
> > > > > > >>> >> >> > > > > > > > > > >> check that it is available in
> pac4j
> > > (if
> > > > > it's
> > > > > > >>> not,
> > > > > > >>> >> it's
> > > > > > >>> >> >> > > > another
> > > > > > >>> >> >> > > > > > > > > > discussion,
> > > > > > >>> >> >> > > > > > > > > > >> but generally, it is). Then,
> you'll
> > > need
> > > > > to
> > > > > > >>> upgrade
> > > > > > >>> >> >> the
> > > > > > >>> >> >> > > > > > > > > > >> ConfigPropertiesFactory by
> > submitting
> > > a
> > > > > new
> > > > > > >>> pull
> > > > > > >>> >> >> request
> > > > > > >>> >> >> > > to
> > > > > > >>> >> >> > > > > the
> > > > > > >>> >> >> > > > > > > > pac4j
> > > > > > >>> >> >> > > > > > > > > > >> project (I can do it myself, but
> I'm
> > > > sure
> > > > > > you
> > > > > > >>> >> could do
> > > > > > >>> >> >> > > that
> > > > > > >>> >> >> > > > > > > easily),
> > > > > > >>> >> >> > > > > > > > > > >> finally wait for the new pac4j
> > release
> > > > and
> > > > > > >>> switch
> > > > > > >>> >> >> pac4j
> > > > > > >>> >> >> > > > > versions
> > > > > > >>> >> >> > > > > > > in
> > > > > > >>> >> >> > > > > > > > > Knox
> > > > > > >>> >> >> > > > > > > > > > >> to
> > > > > > >>> >> >> > > > > > > > > > >> benefit from the new feature.
> > > > > > >>> >> >> > > > > > > > > > >> The good thing is that if someone
> > > > related
> > > > > to
> > > > > > >>> the
> > > > > > >>> >> CAS
> > > > > > >>> >> >> > > server
> > > > > > >>> >> >> > > > > does
> > > > > > >>> >> >> > > > > > > the
> > > > > > >>> >> >> > > > > > > > > > same
> > > > > > >>> >> >> > > > > > > > > > >> thing for CAS (in pac4j), you will
> > > > > > >>> automatically
> > > > > > >>> >> get
> > > > > > >>> >> >> it
> > > > > > >>> >> >> > > when
> > > > > > >>> >> >> > > > > > > you'll
> > > > > > >>> >> >> > > > > > > > > > >> upgrade
> > > > > > >>> >> >> > > > > > > > > > >> pac4j.
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > > >> To go even further, replacing LDAP
> > > Shiro
> > > > > > >>> >> >> authentication
> > > > > > >>> >> >> > is
> > > > > > >>> >> >> > > > > just
> > > > > > >>> >> >> > > > > > a
> > > > > > >>> >> >> > > > > > > > > matter
> > > > > > >>> >> >> > > > > > > > > > >> of
> > > > > > >>> >> >> > > > > > > > > > >> making pac4j LDAP authentication
> > > > available
> > > > > > via
> > > > > > >>> >> >> > > configuration
> > > > > > >>> >> >> > > > > > > > > parameters.
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > > >> I hope it was clear enough.
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > > >> Thanks.
> > > > > > >>> >> >> > > > > > > > > > >> Best regards,
> > > > > > >>> >> >> > > > > > > > > > >> Jérôme
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > > >> 2015-12-03 20:45 GMT+01:00 larry
> > > mccay <
> > > > > > >>> >> >> > > > larry.mccay@gmail.com
> > > > > > >>> >> >> > > > > >:
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > > >> > Excellent!
> > > > > > >>> >> >> > > > > > > > > > >> >
> > > > > > >>> >> >> > > > > > > > > > >> > I will carve out some time to do
> > > code
> > > > > > >>> review.
> > > > > > >>> >> >> > > > > > > > > > >> > We will need to get some
> insights
> > > into
> > > > > how
> > > > > > >>> to go
> > > > > > >>> >> >> about
> > > > > > >>> >> >> > > > > > testing:
> > > > > > >>> >> >> > > > > > > > > > >> >
> > > > > > >>> >> >> > > > > > > > > > >> > * is the CAS server going to be
> > > > > available
> > > > > > >>> for
> > > > > > >>> >> >> testing?
> > > > > > >>> >> >> > > > > > > > > > >> > * what are the specific and
> > > > > > >>> generic/standard (if
> > > > > > >>> >> >> any)
> > > > > > >>> >> >> > > > > > > > authentication
> > > > > > >>> >> >> > > > > > > > > > >> > mechanisms available - for
> > instance:
> > > > > > >>> >> >> > > > > > > > > > >> > - Facebook, Google, LinkedIn
> > and
> > > > CAS
> > > > > > are
> > > > > > >>> >> >> specifics
> > > > > > >>> >> >> > > > > > > > > > >> > - OAuth 2, OpenID Connect,
> > SAML
> > > > are
> > > > > > >>> >> >> > > generic/standards
> > > > > > >>> >> >> > > > -
> > > > > > >>> >> >> > > > > > that
> > > > > > >>> >> >> > > > > > > > may
> > > > > > >>> >> >> > > > > > > > > > be
> > > > > > >>> >> >> > > > > > > > > > >> > used for the above specifics...
> > > > > > >>> >> >> > > > > > > > > > >> > * how do we test things other
> than
> > > > CAS -
> > > > > > in
> > > > > > >>> >> terms of
> > > > > > >>> >> >> > > > getting
> > > > > > >>> >> >> > > > > > > > > > >> credentials,
> > > > > > >>> >> >> > > > > > > > > > >> > configuration, etc
> > > > > > >>> >> >> > > > > > > > > > >> >
> > > > > > >>> >> >> > > > > > > > > > >> > We could certainly do this is
> > phases
> > > > as
> > > > > > >>> well.
> > > > > > >>> >> >> > > > > > > > > > >> >
> > > > > > >>> >> >> > > > > > > > > > >> > If you can enumerate the things
> > that
> > > > > > should
> > > > > > >>> work
> > > > > > >>> >> and
> > > > > > >>> >> >> > > > provide
> > > > > > >>> >> >> > > > > > > some
> > > > > > >>> >> >> > > > > > > > > > >> testing
> > > > > > >>> >> >> > > > > > > > > > >> > details for CAS or as many as
> > > possible
> > > > > and
> > > > > > >>> OpenID
> > > > > > >>> >> >> > > Connect
> > > > > > >>> >> >> > > > > then
> > > > > > >>> >> >> > > > > > > we
> > > > > > >>> >> >> > > > > > > > > can
> > > > > > >>> >> >> > > > > > > > > > >> test
> > > > > > >>> >> >> > > > > > > > > > >> > the specific implementations
> that
> > > you
> > > > > > >>> provide and
> > > > > > >>> >> >> > enable
> > > > > > >>> >> >> > > > the
> > > > > > >>> >> >> > > > > > > > testing
> > > > > > >>> >> >> > > > > > > > > > of
> > > > > > >>> >> >> > > > > > > > > > >> > another OpenID Connect effort
> that
> > > is
> > > > in
> > > > > > the
> > > > > > >>> >> works
> > > > > > >>> >> >> in
> > > > > > >>> >> >> > > the
> > > > > > >>> >> >> > > > > > > > community.
> > > > > > >>> >> >> > > > > > > > > > >> >
> > > > > > >>> >> >> > > > > > > > > > >> > I'm not sure whether we want to
> > > commit
> > > > > > >>> >> contributions
> > > > > > >>> >> >> > > that
> > > > > > >>> >> >> > > > > are
> > > > > > >>> >> >> > > > > > > > > > dependent
> > > > > > >>> >> >> > > > > > > > > > >> on
> > > > > > >>> >> >> > > > > > > > > > >> > snapshots - we certainly can't
> > > release
> > > > > > with
> > > > > > >>> any
> > > > > > >>> >> such
> > > > > > >>> >> >> > > > > > > dependencies.
> > > > > > >>> >> >> > > > > > > > > > >> > I would hate to add a cleanup
> task
> > > to
> > > > a
> > > > > > >>> release
> > > > > > >>> >> to
> > > > > > >>> >> >> > make
> > > > > > >>> >> >> > > > sure
> > > > > > >>> >> >> > > > > > > there
> > > > > > >>> >> >> > > > > > > > > are
> > > > > > >>> >> >> > > > > > > > > > >> no
> > > > > > >>> >> >> > > > > > > > > > >> > snapshots in there.
> > > > > > >>> >> >> > > > > > > > > > >> > We will probably wait until
> after
> > > the
> > > > > > pac4j
> > > > > > >>> >> releases
> > > > > > >>> >> >> > to
> > > > > > >>> >> >> > > > > > commit.
> > > > > > >>> >> >> > > > > > > > > > >> >
> > > > > > >>> >> >> > > > > > > > > > >> > I am really happy that this
> > > > integration
> > > > > is
> > > > > > >>> >> happening
> > > > > > >>> >> >> > and
> > > > > > >>> >> >> > > > > that
> > > > > > >>> >> >> > > > > > it
> > > > > > >>> >> >> > > > > > > > > went
> > > > > > >>> >> >> > > > > > > > > > >> > rather smoothly.
> > > > > > >>> >> >> > > > > > > > > > >> > These sorts of authentication
> > > > protocols
> > > > > > are
> > > > > > >>> >> complex
> > > > > > >>> >> >> > and
> > > > > > >>> >> >> > > I
> > > > > > >>> >> >> > > > > > think
> > > > > > >>> >> >> > > > > > > we
> > > > > > >>> >> >> > > > > > > > > > >> lined up
> > > > > > >>> >> >> > > > > > > > > > >> > pretty well overall.
> > > > > > >>> >> >> > > > > > > > > > >> >
> > > > > > >>> >> >> > > > > > > > > > >> > Thanks for your work!
> > > > > > >>> >> >> > > > > > > > > > >> >
> > > > > > >>> >> >> > > > > > > > > > >> > On Thu, Dec 3, 2015 at 2:28 PM,
> > > Jérôme
> > > > > > >>> LELEU <
> > > > > > >>> >> >> > > > > > leleuj@gmail.com>
> > > > > > >>> >> >> > > > > > > > > > wrote:
> > > > > > >>> >> >> > > > > > > > > > >> >
> > > > > > >>> >> >> > > > > > > > > > >> > > Hi,
> > > > > > >>> >> >> > > > > > > > > > >> > >
> > > > > > >>> >> >> > > > > > > > > > >> > > I just sync'ed with master,
> > > cleaned
> > > > > > >>> >> dependencies
> > > > > > >>> >> >> and
> > > > > > >>> >> >> > > > added
> > > > > > >>> >> >> > > > > > > > missing
> > > > > > >>> >> >> > > > > > > > > > >> > > Javadocs. Everything works
> > > correctly
> > > > > > now.
> > > > > > >>> Many
> > > > > > >>> >> >> > thanks.
> > > > > > >>> >> >> > > > > > > > > > >> > >
> > > > > > >>> >> >> > > > > > > > > > >> > > The pull request is ready for
> a
> > > full
> > > > > > code
> > > > > > >>> >> review:
> > > > > > >>> >> >> > > > > > > > > > >> > >
> > > > https://github.com/apache/knox/pull/2
> > > > > > >>> >> >> > > > > > > > > > >> > >
> > > > > > >>> >> >> > > > > > > > > > >> > > I'll write the documentation
> > after
> > > > the
> > > > > > >>> pac4j
> > > > > > >>> >> >> > releases
> > > > > > >>> >> >> > > (I
> > > > > > >>> >> >> > > > > > hope
> > > > > > >>> >> >> > > > > > > > next
> > > > > > >>> >> >> > > > > > > > > > >> week).
> > > > > > >>> >> >> > > > > > > > > > >> > >
> > > > > > >>> >> >> > > > > > > > > > >> > > Thanks.
> > > > > > >>> >> >> > > > > > > > > > >> > > Best regards,
> > > > > > >>> >> >> > > > > > > > > > >> > > Jérôme
> > > > > > >>> >> >> > > > > > > > > > >> > >
> > > > > > >>> >> >> > > > > > > > > > >> > >
> > > > > > >>> >> >> > > > > > > > > > >> > > 2015-12-02 19:18 GMT+01:00
> larry
> > > > > mccay <
> > > > > > >>> >> >> > > > > > larry.mccay@gmail.com
> > > > > > >>> >> >> > > > > > > >:
> > > > > > >>> >> >> > > > > > > > > > >> > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > Fixed in
> > > > > > >>> >> >> > > > https://issues.apache.org/jira/browse/KNOX-636
> > > > > > >>> >> >> > > > > .
> > > > > > >>> >> >> > > > > > > > > > >> > > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > On Wed, Dec 2, 2015 at 12:42
> > PM,
> > > > > larry
> > > > > > >>> mccay
> > > > > > >>> >> <
> > > > > > >>> >> >> > > > > > > > > > larry.mccay@gmail.com
> > > > > > >>> >> >> > > > > > > > > > >> >
> > > > > > >>> >> >> > > > > > > > > > >> > > > wrote:
> > > > > > >>> >> >> > > > > > > > > > >> > > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > > Sure - I can file a JIRA
> and
> > > > > commit
> > > > > > a
> > > > > > >>> fix.
> > > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > > The secret generation
> should
> > > be
> > > > > done
> > > > > > >>> in one
> > > > > > >>> >> >> > > instance
> > > > > > >>> >> >> > > > > and
> > > > > > >>> >> >> > > > > > > > > > >> replicated
> > > > > > >>> >> >> > > > > > > > > > >> > > > across
> > > > > > >>> >> >> > > > > > > > > > >> > > > > others.
> > > > > > >>> >> >> > > > > > > > > > >> > > > > This
> replication/management
> > of
> > > > the
> > > > > > >>> >> credential
> > > > > > >>> >> >> > > stores
> > > > > > >>> >> >> > > > > is
> > > > > > >>> >> >> > > > > > > > > outside
> > > > > > >>> >> >> > > > > > > > > > of
> > > > > > >>> >> >> > > > > > > > > > >> > the
> > > > > > >>> >> >> > > > > > > > > > >> > > > > scope of Knox itself as of
> > > now.
> > > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > > Documentation is done in
> > > > markdown
> > > > > > and
> > > > > > >>> is
> > > > > > >>> >> >> > > > contributing
> > > > > > >>> >> >> > > > > > > > details
> > > > > > >>> >> >> > > > > > > > > > are
> > > > > > >>> >> >> > > > > > > > > > >> > > > > available at:
> > > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > > >>> >> >> > > > > > > > > > >> > > >
> > > > > > >>> >> >> > > > > > > > > > >> > >
> > > > > > >>> >> >> > > > > > > > > > >> >
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > >
> > > > > > >>> >> >> > > > > > > > >
> > > > > > >>> >> >> > > > > > > >
> > > > > > >>> >> >> > > > > > >
> > > > > > >>> >> >> > > > > >
> > > > > > >>> >> >> > > > >
> > > > > > >>> >> >> > > >
> > > > > > >>> >> >> > >
> > > > > > >>> >> >> >
> > > > > > >>> >> >>
> > > > > > >>> >>
> > > > > > >>>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
> > > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > > Which should give you a
> > > general
> > > > > > idea.
> > > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > > Find an example like:
> > > > > > >>> ./trunk/books/0.7.0/
> > > > > > >>> >> >> > > > > > > > > > >> > >
> config_preauth_sso_provider.md
> > > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > > For an example of typical
> > > > content
> > > > > > and
> > > > > > >>> >> format.
> > > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > > Here is how that example
> > > > renders:
> > > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > > >>> >> >> > > > > > > > > > >> > > >
> > > > > > >>> >> >> > > > > > > > > > >> > >
> > > > > > >>> >> >> > > > > > > > > > >> >
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > >
> > > > > > >>> >> >> > > > > > > > >
> > > > > > >>> >> >> > > > > > > >
> > > > > > >>> >> >> > > > > > >
> > > > > > >>> >> >> > > > > >
> > > > > > >>> >> >> > > > >
> > > > > > >>> >> >> > > >
> > > > > > >>> >> >> > >
> > > > > > >>> >> >> >
> > > > > > >>> >> >>
> > > > > > >>> >>
> > > > > > >>>
> > > > > >
> > > > >
> > > >
> > >
> >
> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
> > > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > > You'll need to tie it into
> > the
> > > > > rest
> > > > > > >>> of the
> > > > > > >>> >> >> book
> > > > > > >>> >> >> > -
> > > > > > >>> >> >> > > > just
> > > > > > >>> >> >> > > > > > > grep
> > > > > > >>> >> >> > > > > > > > > for
> > > > > > >>> >> >> > > > > > > > > > >> where
> > > > > > >>> >> >> > > > > > > > > > >> > > > that
> > > > > > >>> >> >> > > > > > > > > > >> > > > > filename is referenced.
> > > > > > >>> >> >> > > > > > > > > > >> > > > > To test how it renders
> build
> > > the
> > > > > > site
> > > > > > >>> with:
> > > > > > >>> >> >> > "ant"
> > > > > > >>> >> >> > > > and
> > > > > > >>> >> >> > > > > > note
> > > > > > >>> >> >> > > > > > > > the
> > > > > > >>> >> >> > > > > > > > > > >> url to
> > > > > > >>> >> >> > > > > > > > > > >> > > the
> > > > > > >>> >> >> > > > > > > > > > >> > > > > 0.7.0 book.
> > > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > > On Wed, Dec 2, 2015 at
> 12:12
> > > PM,
> > > > > > >>> Jérôme
> > > > > > >>> >> LELEU
> > > > > > >>> >> >> <
> > > > > > >>> >> >> > > > > > > > > leleuj@gmail.com
> > > > > > >>> >> >> > > > > > > > > > >
> > > > > > >>> >> >> > > > > > > > > > >> > > wrote:
> > > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> Hi,
> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> Why it doesn't work for
> > pac4j
> > > > > while
> > > > > > >>> it
> > > > > > >>> >> works
> > > > > > >>> >> >> > for
> > > > > > >>> >> >> > > > > others
> > > > > > >>> >> >> > > > > > > is
> > > > > > >>> >> >> > > > > > > > a
> > > > > > >>> >> >> > > > > > > > > > bit
> > > > > > >>> >> >> > > > > > > > > > >> > > strange
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> to
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> me, but if you have the
> > patch
> > > > in
> > > > > > >>> front of
> > > > > > >>> >> >> your
> > > > > > >>> >> >> > > > eyes,
> > > > > > >>> >> >> > > > > > I'd
> > > > > > >>> >> >> > > > > > > > > rather
> > > > > > >>> >> >> > > > > > > > > > >> > prefer
> > > > > > >>> >> >> > > > > > > > > > >> > > > you
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> to commit it. In all
> cases,
> > > > I'll
> > > > > > >>> sync with
> > > > > > >>> >> >> the
> > > > > > >>> >> >> > > > > master.
> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> There was one question
> you
> > > > didn't
> > > > > > >>> answer
> > > > > > >>> >> >> > > > previously:
> > > > > > >>> >> >> > > > > is
> > > > > > >>> >> >> > > > > > > the
> > > > > > >>> >> >> > > > > > > > > > >> password
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> generated for the pac4j
> > > > provider
> > > > > > the
> > > > > > >>> same
> > > > > > >>> >> >> > across
> > > > > > >>> >> >> > > > all
> > > > > > >>> >> >> > > > > > > > gateway
> > > > > > >>> >> >> > > > > > > > > > >> > > instances?
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> Because I expect to have
> > the
> > > > same
> > > > > > >>> value
> > > > > > >>> >> as I
> > > > > > >>> >> >> > use
> > > > > > >>> >> >> > > it
> > > > > > >>> >> >> > > > > to
> > > > > > >>> >> >> > > > > > > > > encrypt
> > > > > > >>> >> >> > > > > > > > > > /
> > > > > > >>> >> >> > > > > > > > > > >> > > decrypt
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> data.
> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> I will add the Javadoc.
> > After
> > > > > that,
> > > > > > >>> you
> > > > > > >>> >> can
> > > > > > >>> >> >> > > review
> > > > > > >>> >> >> > > > > the
> > > > > > >>> >> >> > > > > > > pull
> > > > > > >>> >> >> > > > > > > > > > >> request
> > > > > > >>> >> >> > > > > > > > > > >> > > more
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> completely.
> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> What do you expect for
> the
> > > > > > >>> documentation?
> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> Notice that pac4j
> > > dependencies
> > > > > are
> > > > > > >>> still
> > > > > > >>> >> >> > > snapshots,
> > > > > > >>> >> >> > > > > but
> > > > > > >>> >> >> > > > > > > > they
> > > > > > >>> >> >> > > > > > > > > > >> will be
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> released in a week or
> two.
> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> Thanks.
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> Best regards,
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> Jérôme
> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> 2015-12-02 17:51
> GMT+01:00
> > > > larry
> > > > > > >>> mccay <
> > > > > > >>> >> >> > > > > > > > > larry.mccay@gmail.com
> > > > > > >>> >> >> > > > > > > > > > >:
> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > Jérôme -
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > If you would like to
> add
> > > that
> > > > > > >>> change as
> > > > > > >>> >> >> part
> > > > > > >>> >> >> > of
> > > > > > >>> >> >> > > > > your
> > > > > > >>> >> >> > > > > > > > patch
> > > > > > >>> >> >> > > > > > > > > or
> > > > > > >>> >> >> > > > > > > > > > >> as a
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > separately filed JIRA
> to
> > > fix
> > > > a
> > > > > > bug
> > > > > > >>> that
> > > > > > >>> >> >> would
> > > > > > >>> >> >> > > > > > certainly
> > > > > > >>> >> >> > > > > > > > be
> > > > > > >>> >> >> > > > > > > > > > >> > welcomed.
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > Otherwise, I can do it.
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > Let me know.
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > thanks,
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > --larry
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > On Wed, Dec 2, 2015 at
> > > 11:44
> > > > > AM,
> > > > > > >>> larry
> > > > > > >>> >> >> mccay
> > > > > > >>> >> >> > <
> > > > > > >>> >> >> > > > > > > > > > >> > larry.mccay@gmail.com
> > > > > > >>> >> >> > > > > > > > > > >> > > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > wrote:
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > > Okay - I had to add
> an
> > > > > override
> > > > > > >>> of
> > > > > > >>> >> >> > > > > > getUserPrincipal()
> > > > > > >>> >> >> > > > > > > > to
> > > > > > >>> >> >> > > > > > > > > > the
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >
> > > > > > >>> >> IdentityAsserterHttpServletRequestWrapper
> > > > > > >>> >> >> > and
> > > > > > >>> >> >> > > > > > return
> > > > > > >>> >> >> > > > > > > > the
> > > > > > >>> >> >> > > > > > > > > > >> member
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> variable
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > > username and it works
> > > like
> > > > a
> > > > > > >>> charm.
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > > Why I haven't seen
> this
> > > > same
> > > > > > >>> behavior
> > > > > > >>> >> >> with
> > > > > > >>> >> >> > > > other
> > > > > > >>> >> >> > > > > > > > > providers
> > > > > > >>> >> >> > > > > > > > > > >> is a
> > > > > > >>> >> >> > > > > > > > > > >> > > bit
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> of a
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > > mystery but they must
> > be
> > > > > adding
> > > > > > >>> other
> > > > > > >>> >> >> > > wrappers
> > > > > > >>> >> >> > > > > that
> > > > > > >>> >> >> > > > > > > > > handle
> > > > > > >>> >> >> > > > > > > > > > >> it.
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > > This is quite cool,
> > > Jérôme!
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > > On Wed, Dec 2, 2015
> at
> > > > 10:41
> > > > > > AM,
> > > > > > >>> larry
> > > > > > >>> >> >> > mccay
> > > > > > >>> >> >> > > <
> > > > > > >>> >> >> > > > > > > > > > >> > > larry.mccay@gmail.com
> > > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > > wrote:
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >> That was it -
> thanks!
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >> On Wed, Dec 2, 2015
> at
> > > > 10:20
> > > > > > AM,
> > > > > > >>> >> Jérôme
> > > > > > >>> >> >> > > LELEU
> > > > > > >>> >> >> > > > <
> > > > > > >>> >> >> > > > > > > > > > >> > leleuj@gmail.com>
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> wrote:
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> This is my exact
> > > command
> > > > > > line:
> > > > > > >>> mvn
> > > > > > >>> >> >> > > -Prelease
> > > > > > >>> >> >> > > > > > clean
> > > > > > >>> >> >> > > > > > > > > > install
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> -DskipTests
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> You use an internal
> > > Maven
> > > > > > >>> >> repository to
> > > > > > >>> >> >> > > fetch
> > > > > > >>> >> >> > > > > > > > > > dependencies
> > > > > > >>> >> >> > > > > > > > > > >> > from
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > internet:
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > > > > >>> >> >> > > > > > > > > > >> > >
> > > > > > >>> >> >> > > > > > > >
> > > > > > >>> >> >> > >
> > > > > > >>>
> > > http://nexus-private.hortonworks.com/nexus/content/groups/public/
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> Does this
> repository
> > > have
> > > > > > >>> access to
> > > > > > >>> >> the
> > > > > > >>> >> >> > > > remote
> > > > > > >>> >> >> > > > > > > > > Snapshots
> > > > > > >>> >> >> > > > > > > > > > >> > > Sonatype
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> repo?
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> 2015-12-02 16:16
> > > > GMT+01:00
> > > > > > >>> larry
> > > > > > >>> >> mccay
> > > > > > >>> >> >> <
> > > > > > >>> >> >> > > > > > > > > > >> larry.mccay@gmail.com
> > > > > > >>> >> >> > > > > > > > > > >> > >:
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > hmmm - I used:
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > mvn clean install
> > > > > > >>> -DskipTests=true
> > > > > > >>> >> >> > > > -Prelease
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > The repository
> > entry
> > > is
> > > > > in
> > > > > > >>> there
> > > > > > >>> >> >> > already.
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > No worky.
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > On Wed, Dec 2,
> 2015
> > > at
> > > > > > 10:12
> > > > > > >>> AM,
> > > > > > >>> >> >> Jérôme
> > > > > > >>> >> >> > > > > LELEU <
> > > > > > >>> >> >> > > > > > > > > > >> > > leleuj@gmail.com
> > > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> wrote:
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Hi,
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > You need the
> > > > j2e-pac4j
> > > > > > >>> >> dependencies
> > > > > > >>> >> >> > as
> > > > > > >>> >> >> > > > well
> > > > > > >>> >> >> > > > > > as
> > > > > > >>> >> >> > > > > > > > the
> > > > > > >>> >> >> > > > > > > > > > >> pac4j-*
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> dependencies,
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > but you don't
> > need
> > > to
> > > > > > >>> build them
> > > > > > >>> >> >> > > locally
> > > > > > >>> >> >> > > > > > > > > (hopefully).
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > But you need a
> > > > > dependency
> > > > > > >>> on the
> > > > > > >>> >> >> > > Sonatype
> > > > > > >>> >> >> > > > > > > > snapshots
> > > > > > >>> >> >> > > > > > > > > > >> > > repository
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> (where the
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > snapshot
> versions
> > > are
> > > > > > >>> hosted),
> > > > > > >>> >> >> which
> > > > > > >>> >> >> > is
> > > > > > >>> >> >> > > > > added
> > > > > > >>> >> >> > > > > > > for
> > > > > > >>> >> >> > > > > > > > > > >> Maven in
> > > > > > >>> >> >> > > > > > > > > > >> > > the
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> root
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > pom.xml:
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > > > >>> >> >> > > > > > > > > > >> > > >
> > > > > > >>> >> >> > > > > > > > > > >> > >
> > > > > > >>> >> >> > > > > > > > > > >> >
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > >
> > > > > > >>> >> >> > > > > > > > >
> > > > > > >>> >> >> > > > > > > >
> > > > > > >>> >> >> > > > > > >
> > > > > > >>> >> >> > > > > >
> > > > > > >>> >> >> > > > >
> > > > > > >>> >> >> > > >
> > > > > > >>> >> >> > >
> > > > > > >>> >> >> >
> > > > > > >>> >> >>
> > > > > > >>> >>
> > > > > > >>>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > If you use Ant
> > for
> > > > the
> > > > > > >>> build,
> > > > > > >>> >> there
> > > > > > >>> >> >> > is
> > > > > > >>> >> >> > > > > maybe
> > > > > > >>> >> >> > > > > > a
> > > > > > >>> >> >> > > > > > > > > glitch
> > > > > > >>> >> >> > > > > > > > > > >> to
> > > > > > >>> >> >> > > > > > > > > > >> > > find
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> the
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > Sonatype
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Maven repo.
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Thanks.
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Best regards,
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Jérôme
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > 2015-12-02
> 16:06
> > > > > > GMT+01:00
> > > > > > >>> larry
> > > > > > >>> >> >> > mccay
> > > > > > >>> >> >> > > <
> > > > > > >>> >> >> > > > > > > > > > >> > > larry.mccay@gmail.com
> > > > > > >>> >> >> > > > > > > > > > >> > > > >:
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > 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.mccay@gmail.com>
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > wrote:
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > >
> > > > > > >>> >> gateway-provider-security-pac4j
> > > > > > >>> >> >> > > > doesn't
> > > > > > >>> >> >> > > > > > > > build -
> > > > > > >>> >> >> > > > > > > > > > do
> > > > > > >>> >> >> > > > > > > > > > >> you
> > > > > > >>> >> >> > > > > > > > > > >> > > > have
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> a
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> pending
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > > change for
> > your
> > > > > > >>> pom.xml or
> > > > > > >>> >> >> > > something?
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > > >>> >> >> > > > > > > > > > >> > > >
> > > > > > >>> >> >> > > > > > > > > > >> > >
> > > > > > >>> >> >> > > > > > > > > > >> >
> > > > > > >>> >> >> > > > > > > > > > >>
> > > > > > >>> >> >> > > > > > > > > > >
> > > > > > >>> >> >> > > > > > > > > > >
> > > > > > >>> >> >> > > > > > > > > >
> > > > > > >>> >> >> > > > > > > > >
> > > > > > >>> >> >> > > > > > > >
> > > > > > >>> >> >> > > > > > >
> > > > > > >>> >> >> > > > > >
> > > > > > >>> >> >> > > > >
> > > > > > >>> >> >> > > >
> > > > > > >>> >> >> > >
> > > > > > >>> >> >> >
> > > > > > >>> >> >>
> > > > > > >>> >>
> > > > > > >>>
> > > > > > >>
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Hi,
We have one callback url (the KnoxSSO url) and multiple identity providers
so to distinguish between all clients, pac4j uses the callback url + the
client_name parameter (Clients.DEFAULT_CLIENT_NAME_PARAMETER).
The redirection url generated to the identity provider has this client_name
parameter: this is why it works well with the CAS server which redirects
the user (after a successfull url) to the originally provided url.
For Okta, on server side, the redirection relies on the defined url. *So
you must define the callback url in Okta as your KnoxSSO url + the
client_name parameter = SAML2Client*.
I myself have
https://127.0.0.1:8443/gateway/idp/api/v1/websso?client_name=SAML2Client
for my Okta app. And the logic of the pac4j gateway provider is based on
this client_name parameter to know if it's a callback or an access call.
Hence the infinite loop in your case.
I guess we need to add a warning in the documentation for that. Just let
met know how you want to proceed.
Thanks.
Best regards,
Jérôme
2016-01-15 16:38 GMT+01:00 larry mccay <lm...@apache.org>:
> Hi Jérôme -
>
> Thanks for the updated docs - I will take a look today.
>
> I am currently still trying to test okta and stuck in a redirect loop.
> Did you have to change anything in order to get the
> request.getParameter(Clients.DEFAULT_CLIENT_NAME_PARAMETER)
> set for the callbacks from okta? It is null in my environment and therefore
> it moves on to the following:
>
> // otherwise just apply security and requires authentication
>
> // apply RequiresAuthenticationFilter
>
> requiresAuthenticationFilter.doFilter(servletRequest,
> servletResponse, filterChain);
>
> which obviously results in the redirect loop.
>
> Curious whether you ran into that...
>
> thanks,
>
> --larry
>
> On Fri, Jan 15, 2016 at 4:00 AM, Jérôme LELEU <le...@gmail.com> wrote:
>
> > Hi,
> >
> > I just uploaded a new patch for the documentation with the links pointing
> > to the pac4j wiki. It should be clearer.
> >
> > Thanks.
> > Best regards,
> > Jérôme
> >
> >
> > 2016-01-14 13:20 GMT+01:00 larry mccay <lm...@apache.org>:
> >
> > > That sounds pretty reasonable.
> > > I will likely document a few of the integrations that are possible in
> > > blogs/tutorials anyway.
> > >
> > > I don't want testing of Knox at release time to have to jump around to
> > much
> > > in order to be able to test.
> > > I think we can make that all good though.
> > >
> > > I will see what I can do with okta today.
> > >
> > > On Thu, Jan 14, 2016 at 5:00 AM, Jérôme LELEU <le...@gmail.com>
> wrote:
> > >
> > > > Hi,
> > > >
> > > > Yes, the documentation is a bit too light. But you guessed it right:
> we
> > > > need to have a keystore for encryption.
> > > >
> > > > The saml.identityProviderMetadataPath can point to a local resource
> or
> > > to a
> > > > remote one, using the right prefix: resource:, file: or an url (by
> > > default,
> > > > it is a file path). This must be documented though.
> > > >
> > > > With Okta, I used the defined url (Single Sign On URL = Recipient
> URL =
> > > > Destination URL) for the serviceProviderEntityId, but I think it may
> > > > depends on IdP as well. Reading the spec, it must be an URI, but I'm
> > not
> > > > sure if the SP metadata should be really available on this url. For
> > Okta,
> > > > it doesn't matter.
> > > >
> > > > According to your SAML configuration, the SP metadata will be
> generated
> > > > somewhere and this somewhere can be defined via the
> > > > serviceProviderMetadataPath parameter. You generally need to update
> > your
> > > > metadata to the IdP (not required for Okta though). Both the SP and
> IdP
> > > > must know each other.
> > > >
> > > > When writing the documentation, I went fast on these parameters with
> > the
> > > > feeling they were regular ones, but indeed, the description in the
> Knox
> > > > manual is not enough. This is somehow a bit normal as the real
> > > > documentation for SAML is on the SAML wiki:
> > > > https://github.com/pac4j/pac4j/wiki/Clients#details-for-saml-support
> > > >
> > > > So I propose to keep the Knox documentation mostly "as is", but add
> > links
> > > > to the pac4j wiki (where I could more easily made updates). All pac4j
> > > > integrations need this documentation so it's better to centralize it,
> > > from
> > > > my point of view. What do you think?
> > > >
> > > > Thanks.
> > > > Best regards,
> > > > Jérôme
> > > >
> > > >
> > > >
> > > > 2016-01-13 19:37 GMT+01:00 larry mccay <lm...@apache.org>:
> > > >
> > > > > Hi Jérôme -
> > > > >
> > > > > I'm trying to configure the pac4j provider for an okta
> "application"
> > > > that I
> > > > > created.
> > > > > The following (from KNOX-642 docs patch) isn't quite enough to make
> > it
> > > > > clear to me how to go about doing so:
> > > > >
> > > > > +saml.keystorePassword | Password of the keystore
> > (storepass)
> > > > > +saml.privateKeyPassword | Password for the private key
> > > > (keypass)
> > > > > +saml.keystorePath | Path of the keystore
> > > > > +saml.identityProviderMetadataPath | Path of the identity
> > > > > provider metadata
> > > > > +saml.maximumAuthenticationLifetime | Maximum lifetime
> for
> > > > > authentication
> > > > > +saml.serviceProviderEntityId | Identifier of the service
> > > > > provider
> > > > > +saml.serviceProviderMetadataPath | Path of the service
> > > > provider
> > > > > metadata
> > > > >
> > > > > I assume that I can use the gateway.jks keystore and the
> > > gateway-identity
> > > > > keypair to do the request signing and that that information is what
> > is
> > > > > needed for the first 3 params. Unfortunately, I don't see any use
> of
> > > > > gateway services to get the master secret therefore it needs to be
> in
> > > > clear
> > > > > text here. This won't work - but may not be a show stopper for
> > > committing
> > > > > to master as long as we follow up with a fix.
> > > > >
> > > > > Can saml.identityProviderMetadataPath point to a remote location or
> > > does
> > > > it
> > > > > have to be local to the SP application. This would likely require
> it
> > to
> > > > be
> > > > > on the local filesystem, provisioned by the contributor into the
> > > > generated
> > > > > web app or in some central location via NFS or something like that.
> > > > >
> > > > > The okta application that I created is called KnoxSSO - is that the
> > > value
> > > > > for saml.serviceProviderEntityId?
> > > > >
> > > > > The saml.serviceProviderMetadataPath has the same questions as the
> > > > metadata
> > > > > for the IDP. In addition, is there a sample metadata file that we
> can
> > > > > provide for the use of pac4j with KnoxSSO?
> > > > >
> > > > > I think that getting this working and clean (no clear text
> passwords)
> > > > will
> > > > > make a great feature and blog for featuring pac4j provider and the
> > > 0.8.0
> > > > > release. So, let's try and iron this out clearly.
> > > > >
> > > > > I would really like to get this working and committed in the next
> > > couple
> > > > > days to free us up for follow up items. In particular we need time
> to
> > > > > figure out whether the identity assertion providers that we
> currently
> > > > have
> > > > > will suffice for an apache release that is featuring this new
> > > > > functionality.
> > > > >
> > > > > I will also add the above comments/questions to the JIRA for
> > > visibility.
> > > > >
> > > > > thanks,
> > > > >
> > > > > --larry
> > > > >
> > > > > On Fri, Jan 8, 2016 at 12:40 PM, larry mccay <lm...@apache.org>
> > > wrote:
> > > > >
> > > > > > Jérôme -
> > > > > >
> > > > > > My testing of OpenID Connect is blocked.
> > > > > > Can you see the comments in KNOX-641?
> > > > > >
> > > > > > thanks,
> > > > > >
> > > > > > --larry
> > > > > >
> > > > > > On Wed, Jan 6, 2016 at 2:30 PM, larry mccay <
> larry.mccay@gmail.com
> > >
> > > > > wrote:
> > > > > >
> > > > > >> Jérôme -
> > > > > >>
> > > > > >> Please see the comments on KNOX-641.
> > > > > >>
> > > > > >> thanks,
> > > > > >>
> > > > > >> --larry
> > > > > >>
> > > > > >> On Wed, Jan 6, 2016 at 11:24 AM, Kevin Minder <
> > > > > >> kevin.minder@hortonworks.com> wrote:
> > > > > >>
> > > > > >>> I can certainly appreciate the issue of including external
> > > resources
> > > > in
> > > > > >>> automated tests. Nothing has driven me more crazy over the
> > years.
> > > > The
> > > > > >>> flip side of this of course is not finding out about a breakage
> > > until
> > > > > >>> someone is willing to go through the manual testing which will
> > > > > typically
> > > > > >>> happen just before a release. Also the implication is that
> these
> > > > > testing
> > > > > >>> procedures must be very will documented so that they can be
> > > continue
> > > > > to be
> > > > > >>> run once any of us are no longer active in the project.
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>> On 1/6/16, 2:12 AM, "Jérôme LELEU" <le...@gmail.com> wrote:
> > > > > >>>
> > > > > >>> >Hi,
> > > > > >>> >
> > > > > >>> >Yes, you can hit the CAS server at Heroku. Notice it's a
> Heroku
> > > free
> > > > > >>> server
> > > > > >>> >so it needs to be re-activated first (it takes a couple of
> > > seconds).
> > > > > So
> > > > > >>> for
> > > > > >>> >a UI test, you should first hit it, wait 30 seconds and then
> > > perform
> > > > > the
> > > > > >>> >test.
> > > > > >>> >
> > > > > >>> >Just my 2 cents:
> > > > > >>> >Using automated UI tests was my first strategy for pac4j but
> I
> > > > > finally
> > > > > >>> >gave up because public providers change very often, at least
> > > enough
> > > > to
> > > > > >>> make
> > > > > >>> >the maintenance tests a nightmare. Currently, I'm using manual
> > > tests
> > > > > >>> (the
> > > > > >>> >same for all demos), it takes me around 5 minutes to play them
> > all
> > > > by
> > > > > >>> hand
> > > > > >>> >(for a demo) and I launched manually the UI tests I have for
> > every
> > > > > major
> > > > > >>> >pac4j release. Just to say UI tests are not that easy. For a
> CAS
> > > > > server,
> > > > > >>> >it's fairly feasible as the CAS server and protocol change
> > rarely.
> > > > > >>> >That's why for Knox, I did some compromise with a simulated
> web
> > > test
> > > > > >>> (based
> > > > > >>> >on the basic auth). See:
> > > > > >>> >
> > > > > >>>
> > > > >
> > > >
> > >
> >
> https://github.com/apache/knox/pull/2/files#diff-d0c880ca71b310dbe57975c577535e97R47
> > > > > >>> >
> > > > > >>> >Thanks.
> > > > > >>> >Best regards,
> > > > > >>> >Jérôme
> > > > > >>> >
> > > > > >>> >
> > > > > >>> >
> > > > > >>> >2016-01-05 21:20 GMT+01:00 Kevin Minder <
> > > > kevin.minder@hortonworks.com
> > > > > >:
> > > > > >>> >
> > > > > >>> >> From my perspective it would be ideal if there were some
> > > > automatable
> > > > > >>> >> functional tests for this. I’m not advocating that these be
> > > > > something
> > > > > >>> >> included in “mvn clean install” as that is running too long
> as
> > > it
> > > > > is.
> > > > > >>> >> Given that I don’t have as much context as Larry, I have
> some
> > > > > >>> questions
> > > > > >>> >> about what this would take. Lets say we had permission to
> hit
> > > > > >>> >> https://casserverpac4j.herokuapp.com/login as part of some
> > low
> > > > > >>> frequency
> > > > > >>> >> automated tests (e.g. Once nighty). What static credentials
> > and
> > > > > >>> other test
> > > > > >>> >> automation infrastructure would need to be implemented in
> > > support
> > > > of
> > > > > >>> this?
> > > > > >>> >> I understand that the test suite would require at a minimum
> > > > > >>> >> 1) a test driver
> > > > > >>> >> 2) a protected mock UI and
> > > > > >>> >> 3) an appropriately configured Knox
> > > > > >>> >> 4) a profile enabled maven module
> > > > > >>> >> 5) an Apache jenkins job
> > > > > >>> >> but I’m sure I’m missing other things. I’m certainly
> willing
> > to
> > > > > help
> > > > > >>> >> setup the skeleton infrastructure (e.g. test driver, mock
> UI,
> > > > maven
> > > > > >>> module,
> > > > > >>> >> jenkins job)
> > > > > >>> >>
> > > > > >>> >>
> > > > > >>> >>
> > > > > >>> >> On 1/5/16, 2:54 PM, "larry mccay" <la...@gmail.com>
> > > wrote:
> > > > > >>> >>
> > > > > >>> >> >Okay, very good.
> > > > > >>> >> >I've used TestShib for the picketlink provider - thanks for
> > the
> > > > > >>> pointers!
> > > > > >>> >> >
> > > > > >>> >> >On Tue, Jan 5, 2016 at 1:38 PM, Jérôme LELEU <
> > leleuj@gmail.com
> > > >
> > > > > >>> wrote:
> > > > > >>> >> >
> > > > > >>> >> >> The online CAS server (
> > > > > https://casserverpac4j.herokuapp.com/login)
> > > > > >>> uses
> > > > > >>> >> >> the
> > > > > >>> >> >> CAS protocol. SAML support can be tested using some
> online
> > > IdP
> > > > > like
> > > > > >>> >> Okta,
> > > > > >>> >> >> TestShib, OpenFeide, Ssocircle...
> > > > > >>> >> >>
> > > > > >>> >> >>
> > > > > >>> >> >> 2016-01-05 17:32 GMT+01:00 larry mccay <
> > > larry.mccay@gmail.com
> > > > >:
> > > > > >>> >> >>
> > > > > >>> >> >> > Great - thanks for that pointer!
> > > > > >>> >> >> >
> > > > > >>> >> >> > I will take a look at that and help drive the release
> > > related
> > > > > >>> testing.
> > > > > >>> >> >> > Merge testing will be gated on CAS server (is this SAML
> > or
> > > > CAS
> > > > > >>> >> protocol?)
> > > > > >>> >> >> > and testBasicAuth.
> > > > > >>> >> >> >
> > > > > >>> >> >> > On Tue, Jan 5, 2016 at 10:52 AM, Jérôme LELEU <
> > > > > leleuj@gmail.com>
> > > > > >>> >> wrote:
> > > > > >>> >> >> >
> > > > > >>> >> >> > > Hi,
> > > > > >>> >> >> > >
> > > > > >>> >> >> > > Glad to hear back from you!
> > > > > >>> >> >> > >
> > > > > >>> >> >> > > The core pac4j project is fully tested by unit tests
> > (and
> > > > > some
> > > > > >>> >> >> > integration
> > > > > >>> >> >> > > tests I run for major version), then all pac4j
> > > > > implementations
> > > > > >>> are
> > > > > >>> >> each
> > > > > >>> >> >> > > tested by the appropriate demo: j2e-pac4j-demo tests
> > > > > j2e-pac4j,
> > > > > >>> >> >> > > spring-webmvc-pac4j-demo tests spring-webmvc-pac4j,
> > etc.
> > > > > >>> >> >> > >
> > > > > >>> >> >> > > So if you take a look at:
> > > > > >>> >> >> > >
> > > > > >>> >> >> > >
> > > > > >>> >> >> >
> > > > > >>> >> >>
> > > > > >>> >>
> > > > > >>>
> > > > >
> > > >
> > >
> >
> https://github.com/pac4j/j2e-pac4j-demo/blob/master/src/main/java/org/pac4j/demo/j2e/config/DemoConfigFactory.java#L27
> > > > > >>> >> >> > > (for example), you have all the required information
> to
> > > > test.
> > > > > >>> >> >> > >
> > > > > >>> >> >> > > I can do that on my own, but it can be good for the
> > Knox
> > > > > >>> community
> > > > > >>> >> to
> > > > > >>> >> >> > start
> > > > > >>> >> >> > > working / testing the pac4j support. It's up to yoy.
> > > > > >>> >> >> > >
> > > > > >>> >> >> > > Thanks.
> > > > > >>> >> >> > > Best regards,
> > > > > >>> >> >> > > Jérôme
> > > > > >>> >> >> > >
> > > > > >>> >> >> > >
> > > > > >>> >> >> > > 2016-01-05 16:11 GMT+01:00 larry mccay <
> > > > > larry.mccay@gmail.com
> > > > > >>> >:
> > > > > >>> >> >> > >
> > > > > >>> >> >> > > > Hello Jérôme -
> > > > > >>> >> >> > > >
> > > > > >>> >> >> > > > Happy New Year!
> > > > > >>> >> >> > > >
> > > > > >>> >> >> > > > I am going to start reviewing your updates today,
> > > > > hopefully.
> > > > > >>> >> >> > > > I was thinking that we need to start discussions on
> > > what
> > > > > the
> > > > > >>> key
> > > > > >>> >> >> > usecases
> > > > > >>> >> >> > > > are and how to go about testing them.
> > > > > >>> >> >> > > > We can certainly test the testBasicAuth and against
> > the
> > > > > >>> hosted CAS
> > > > > >>> >> >> > server
> > > > > >>> >> >> > > > but what about FB, openid, OAuth, etc?
> > > > > >>> >> >> > > >
> > > > > >>> >> >> > > > I'm not sure that FB would be a key feature but
> > OpenID
> > > > > >>> Connect and
> > > > > >>> >> >> > OAuth
> > > > > >>> >> >> > > > would be - as is SAML.
> > > > > >>> >> >> > > > I think CAS buys us SAML testing - assuming that
> the
> > > > > >>> >> configuration of
> > > > > >>> >> >> > the
> > > > > >>> >> >> > > > hosted server is actually a SAML 2 instance.
> > > > > >>> >> >> > > >
> > > > > >>> >> >> > > > What about the others?
> > > > > >>> >> >> > > >
> > > > > >>> >> >> > > > I don't know that we need to be able to test them
> all
> > > > > before
> > > > > >>> merge
> > > > > >>> >> >> but
> > > > > >>> >> >> > > some
> > > > > >>> >> >> > > > sort of manual verification would be great.
> > > > > >>> >> >> > > > We would need to be able to test them before the
> next
> > > > > release
> > > > > >>> >> which
> > > > > >>> >> >> > would
> > > > > >>> >> >> > > > be featuring the pac4j functionality.
> > > > > >>> >> >> > > >
> > > > > >>> >> >> > > > Maybe you can describe how you go about testing
> such
> > > > things
> > > > > >>> for
> > > > > >>> >> the
> > > > > >>> >> >> > pac4j
> > > > > >>> >> >> > > > project itself?
> > > > > >>> >> >> > > >
> > > > > >>> >> >> > > > thanks,
> > > > > >>> >> >> > > >
> > > > > >>> >> >> > > > --larry
> > > > > >>> >> >> > > >
> > > > > >>> >> >> > > >
> > > > > >>> >> >> > > > On Tue, Jan 5, 2016 at 9:55 AM, Jérôme LELEU <
> > > > > >>> leleuj@gmail.com>
> > > > > >>> >> >> wrote:
> > > > > >>> >> >> > > >
> > > > > >>> >> >> > > > > Hi,
> > > > > >>> >> >> > > > >
> > > > > >>> >> >> > > > > Happy new year!
> > > > > >>> >> >> > > > >
> > > > > >>> >> >> > > > > A few days ago, I updated my patch of the pac4j
> > > gateway
> > > > > >>> provider
> > > > > >>> >> >> > > > according
> > > > > >>> >> >> > > > > to all comments on
> > > > > >>> >> https://issues.apache.org/jira/browse/KNOX-641
> > > > > >>> >> >> as
> > > > > >>> >> >> > > > well
> > > > > >>> >> >> > > > > as the documentation on KNOX-642.
> > > > > >>> >> >> > > > >
> > > > > >>> >> >> > > > > Is everything ok for the merge?
> > > > > >>> >> >> > > > >
> > > > > >>> >> >> > > > > Thanks.
> > > > > >>> >> >> > > > > Best regards,
> > > > > >>> >> >> > > > > Jérôme
> > > > > >>> >> >> > > > >
> > > > > >>> >> >> > > > >
> > > > > >>> >> >> > > > > 2015-12-14 15:28 GMT+01:00 larry mccay <
> > > > > >>> larry.mccay@gmail.com>:
> > > > > >>> >> >> > > > >
> > > > > >>> >> >> > > > > > Hi Jérôme -
> > > > > >>> >> >> > > > > >
> > > > > >>> >> >> > > > > > Not sure if you saw but I added review comments
> > to
> > > > > >>> KNOX-641.
> > > > > >>> >> >> > > > > >
> > > > > >>> >> >> > > > > > I think that we need to determine whether we
> want
> > > the
> > > > > >>> >> >> testBasicAuth
> > > > > >>> >> >> > > in
> > > > > >>> >> >> > > > > the
> > > > > >>> >> >> > > > > > provider itself.
> > > > > >>> >> >> > > > > >
> > > > > >>> >> >> > > > > > Let's follow up on the JIRA.
> > > > > >>> >> >> > > > > >
> > > > > >>> >> >> > > > > > thanks,
> > > > > >>> >> >> > > > > >
> > > > > >>> >> >> > > > > > --larry
> > > > > >>> >> >> > > > > >
> > > > > >>> >> >> > > > > > On Fri, Dec 11, 2015 at 8:44 AM, Jérôme LELEU <
> > > > > >>> >> leleuj@gmail.com>
> > > > > >>> >> >> > > > wrote:
> > > > > >>> >> >> > > > > >
> > > > > >>> >> >> > > > > > > Hi,
> > > > > >>> >> >> > > > > > >
> > > > > >>> >> >> > > > > > > No problem. It can go into a version 0.8.0 if
> > > > needed.
> > > > > >>> The
> > > > > >>> >> truth
> > > > > >>> >> >> > is
> > > > > >>> >> >> > > > that
> > > > > >>> >> >> > > > > > > there is only one change outside the new
> pac4j
> > > > > module,
> > > > > >>> so I
> > > > > >>> >> >> think
> > > > > >>> >> >> > > > risks
> > > > > >>> >> >> > > > > > are
> > > > > >>> >> >> > > > > > > extremly limited.
> > > > > >>> >> >> > > > > > >
> > > > > >>> >> >> > > > > > > Just let met know.
> > > > > >>> >> >> > > > > > >
> > > > > >>> >> >> > > > > > > Thanks.
> > > > > >>> >> >> > > > > > > Best regards,
> > > > > >>> >> >> > > > > > > Jérôme
> > > > > >>> >> >> > > > > > >
> > > > > >>> >> >> > > > > > >
> > > > > >>> >> >> > > > > > > 2015-12-11 14:23 GMT+01:00 larry mccay <
> > > > > >>> >> larry.mccay@gmail.com
> > > > > >>> >> >> >:
> > > > > >>> >> >> > > > > > >
> > > > > >>> >> >> > > > > > > > Hi Jérôme -
> > > > > >>> >> >> > > > > > > >
> > > > > >>> >> >> > > > > > > > I have unfortunately not had a chance to
> > pull,
> > > > > >>> review and
> > > > > >>> >> >> test
> > > > > >>> >> >> > it
> > > > > >>> >> >> > > > yet
> > > > > >>> >> >> > > > > > and
> > > > > >>> >> >> > > > > > > > have intended to do that today.
> > > > > >>> >> >> > > > > > > > I apologize for the delay.
> > > > > >>> >> >> > > > > > > >
> > > > > >>> >> >> > > > > > > > I was actually thinking that this would go
> > > into a
> > > > > >>> follow
> > > > > >>> >> up
> > > > > >>> >> >> > > release
> > > > > >>> >> >> > > > > > that
> > > > > >>> >> >> > > > > > > we
> > > > > >>> >> >> > > > > > > > would try and get done rapidly after the
> > 0.7.0
> > > > > >>> release
> > > > > >>> >> but we
> > > > > >>> >> >> > can
> > > > > >>> >> >> > > > > > discuss
> > > > > >>> >> >> > > > > > > > the target and its chances of destabilizing
> > > > 0.7.0.
> > > > > >>> >> >> > > > > > > >
> > > > > >>> >> >> > > > > > > > I believe that it is rather self-contained
> > with
> > > > > only
> > > > > >>> a few
> > > > > >>> >> >> > > changes
> > > > > >>> >> >> > > > to
> > > > > >>> >> >> > > > > > > > external modules.
> > > > > >>> >> >> > > > > > > >
> > > > > >>> >> >> > > > > > > > Opening the JIRAs is perfect and I was
> going
> > to
> > > > do
> > > > > >>> that
> > > > > >>> >> once
> > > > > >>> >> >> I
> > > > > >>> >> >> > > > > started
> > > > > >>> >> >> > > > > > > the
> > > > > >>> >> >> > > > > > > > review.
> > > > > >>> >> >> > > > > > > >
> > > > > >>> >> >> > > > > > > > Let's continue review comments and
> > > collaboration
> > > > on
> > > > > >>> those
> > > > > >>> >> >> > JIRAs.
> > > > > >>> >> >> > > > > > > > I will add you to the contributors list so
> > that
> > > > we
> > > > > >>> can
> > > > > >>> >> assign
> > > > > >>> >> >> > > them
> > > > > >>> >> >> > > > to
> > > > > >>> >> >> > > > > > > you.
> > > > > >>> >> >> > > > > > > >
> > > > > >>> >> >> > > > > > > > Thank you for your contributions and your
> > > > patience,
> > > > > >>> >> Jérôme!
> > > > > >>> >> >> > > > > > > >
> > > > > >>> >> >> > > > > > > > --larry
> > > > > >>> >> >> > > > > > > >
> > > > > >>> >> >> > > > > > > > On Fri, Dec 11, 2015 at 3:00 AM, Jérôme
> > LELEU <
> > > > > >>> >> >> > leleuj@gmail.com>
> > > > > >>> >> >> > > > > > wrote:
> > > > > >>> >> >> > > > > > > >
> > > > > >>> >> >> > > > > > > > > Hi,
> > > > > >>> >> >> > > > > > > > >
> > > > > >>> >> >> > > > > > > > > I didn't get any new feedback on the pull
> > > > request
> > > > > >>> so I
> > > > > >>> >> >> assume
> > > > > >>> >> >> > > > > > > everything
> > > > > >>> >> >> > > > > > > > is
> > > > > >>> >> >> > > > > > > > > ok from your point of view.
> > > > > >>> >> >> > > > > > > > >
> > > > > >>> >> >> > > > > > > > > I released pac4j v1.8.1 and j2e-pac4j
> > v1.2.1
> > > > so I
> > > > > >>> >> updated
> > > > > >>> >> >> the
> > > > > >>> >> >> > > > pull
> > > > > >>> >> >> > > > > > > > request
> > > > > >>> >> >> > > > > > > > > to use them and successfully re-tested
> > > > > everything.
> > > > > >>> >> >> > > > > > > > >
> > > > > >>> >> >> > > > > > > > > I opened KNOX-641 and submitted the
> > > > corresponding
> > > > > >>> patch.
> > > > > >>> >> >> > > > > > > > >
> > > > > >>> >> >> > > > > > > > > I also wrote the documentation, opened
> > > KNOX-642
> > > > > and
> > > > > >>> >> >> submitted
> > > > > >>> >> >> > > the
> > > > > >>> >> >> > > > > > > > > corresponding patch (just to let you know
> > > that
> > > > it
> > > > > >>> >> doesn't
> > > > > >>> >> >> > work
> > > > > >>> >> >> > > > out
> > > > > >>> >> >> > > > > of
> > > > > >>> >> >> > > > > > > the
> > > > > >>> >> >> > > > > > > > > box in Windows, I had to replace mvn.bat
> by
> > > > > >>> mvn.cmd to
> > > > > >>> >> make
> > > > > >>> >> >> > ant
> > > > > >>> >> >> > > > > > work).
> > > > > >>> >> >> > > > > > > > >
> > > > > >>> >> >> > > > > > > > > Even if the branch 0.7.0 has already been
> > > > > created,
> > > > > >>> I
> > > > > >>> >> >> assumed
> > > > > >>> >> >> > > this
> > > > > >>> >> >> > > > > new
> > > > > >>> >> >> > > > > > > > pac4j
> > > > > >>> >> >> > > > > > > > > provider will go into this version 0.7.0
> > > > > >>> (dependency on
> > > > > >>> >> the
> > > > > >>> >> >> > > > > > > > 0.7.0-SNAPSHOT
> > > > > >>> >> >> > > > > > > > > parent version).
> > > > > >>> >> >> > > > > > > > >
> > > > > >>> >> >> > > > > > > > > Just let me know if everything is ok and
> > when
> > > > > it's
> > > > > >>> >> goind to
> > > > > >>> >> >> > be
> > > > > >>> >> >> > > > > > merged.
> > > > > >>> >> >> > > > > > > > >
> > > > > >>> >> >> > > > > > > > > Thanks.
> > > > > >>> >> >> > > > > > > > > Best regards,
> > > > > >>> >> >> > > > > > > > > Jérôme
> > > > > >>> >> >> > > > > > > > >
> > > > > >>> >> >> > > > > > > > >
> > > > > >>> >> >> > > > > > > > >
> > > > > >>> >> >> > > > > > > > >
> > > > > >>> >> >> > > > > > > > > 2015-12-04 14:20 GMT+01:00 larry mccay <
> > > > > >>> >> >> > larry.mccay@gmail.com
> > > > > >>> >> >> > > >:
> > > > > >>> >> >> > > > > > > > >
> > > > > >>> >> >> > > > > > > > > > That ability to configure multiple
> > > mechanisms
> > > > > >>> based on
> > > > > >>> >> >> > > > clientName
> > > > > >>> >> >> > > > > > is
> > > > > >>> >> >> > > > > > > > > really
> > > > > >>> >> >> > > > > > > > > > interesting for Knox.
> > > > > >>> >> >> > > > > > > > > > Currently, we require separate
> topologies
> > > per
> > > > > >>> >> >> > authentication
> > > > > >>> >> >> > > > > > > mechanism.
> > > > > >>> >> >> > > > > > > > > > The ability to configure them all in
> one
> > is
> > > > > >>> really
> > > > > >>> >> great.
> > > > > >>> >> >> > > > > > > > > >
> > > > > >>> >> >> > > > > > > > > > We would need to think through the best
> > way
> > > > to
> > > > > >>> provide
> > > > > >>> >> >> the
> > > > > >>> >> >> > > > > > clientName
> > > > > >>> >> >> > > > > > > > > > parameter.
> > > > > >>> >> >> > > > > > > > > > Since this is targeting KnoxSSO it can
> > > > actually
> > > > > >>> be
> > > > > >>> >> added
> > > > > >>> >> >> to
> > > > > >>> >> >> > > the
> > > > > >>> >> >> > > > > > > > > providerURL
> > > > > >>> >> >> > > > > > > > > > used to redirect from the participating
> > > > > >>> application.
> > > > > >>> >> >> > > > > > > > > > Regardless of the authentication
> > mechanism
> > > > used
> > > > > >>> each
> > > > > >>> >> >> > > > application
> > > > > >>> >> >> > > > > > will
> > > > > >>> >> >> > > > > > > > > still
> > > > > >>> >> >> > > > > > > > > > get the same JWT based cookie.
> > > > > >>> >> >> > > > > > > > > >
> > > > > >>> >> >> > > > > > > > > > I think that should work really nicely.
> > > > > >>> >> >> > > > > > > > > >
> > > > > >>> >> >> > > > > > > > > >
> > > > > >>> >> >> > > > > > > > > > On Fri, Dec 4, 2015 at 7:17 AM, larry
> > > mccay <
> > > > > >>> >> >> > > > > larry.mccay@gmail.com
> > > > > >>> >> >> > > > > > >
> > > > > >>> >> >> > > > > > > > > wrote:
> > > > > >>> >> >> > > > > > > > > >
> > > > > >>> >> >> > > > > > > > > > > Excellent, Jérôme.
> > > > > >>> >> >> > > > > > > > > > > Thanks!
> > > > > >>> >> >> > > > > > > > > > >
> > > > > >>> >> >> > > > > > > > > > > On Fri, Dec 4, 2015 at 2:40 AM,
> Jérôme
> > > > LELEU
> > > > > <
> > > > > >>> >> >> > > > leleuj@gmail.com
> > > > > >>> >> >> > > > > >
> > > > > >>> >> >> > > > > > > > wrote:
> > > > > >>> >> >> > > > > > > > > > >
> > > > > >>> >> >> > > > > > > > > > >> Hi,
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > > >> I will write how to configure the
> > pac4j
> > > > > >>> provider in
> > > > > >>> >> >> the
> > > > > >>> >> >> > > > > > > > documentation,
> > > > > >>> >> >> > > > > > > > > > but
> > > > > >>> >> >> > > > > > > > > > >> I can already give you some
> insights.
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > > >> My main goal is always to respect
> the
> > > key
> > > > > >>> design
> > > > > >>> >> >> > > principles
> > > > > >>> >> >> > > > of
> > > > > >>> >> >> > > > > > > pac4j
> > > > > >>> >> >> > > > > > > > > > >> whatever the environment / framework
> > in
> > > > > which
> > > > > >>> it is
> > > > > >>> >> >> > > > > implemented.
> > > > > >>> >> >> > > > > > > For
> > > > > >>> >> >> > > > > > > > > > Knox,
> > > > > >>> >> >> > > > > > > > > > >> I'm pretty happy with the use of the
> > > > > j2e-pac4j
> > > > > >>> >> >> library,
> > > > > >>> >> >> > > > which
> > > > > >>> >> >> > > > > > > means
> > > > > >>> >> >> > > > > > > > > that
> > > > > >>> >> >> > > > > > > > > > >> almost all the pac4j features are
> > > > available,
> > > > > >>> >> >> especially
> > > > > >>> >> >> > > both
> > > > > >>> >> >> > > > > > > direct
> > > > > >>> >> >> > > > > > > > > and
> > > > > >>> >> >> > > > > > > > > > >> indirect clients. So it can do what
> > > Shiro
> > > > > >>> already
> > > > > >>> >> does
> > > > > >>> >> >> > but
> > > > > >>> >> >> > > > > also,
> > > > > >>> >> >> > > > > > > as
> > > > > >>> >> >> > > > > > > > we
> > > > > >>> >> >> > > > > > > > > > >> agreed together, supports remote
> > > > > >>> authentications.
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > > >> It is only limited by what you can
> > > > currently
> > > > > >>> >> >> configure.
> > > > > >>> >> >> > > And
> > > > > >>> >> >> > > > > even
> > > > > >>> >> >> > > > > > > > > > >> configuration is a pac4j feature as
> > the
> > > > CAS
> > > > > >>> server
> > > > > >>> >> has
> > > > > >>> >> >> > the
> > > > > >>> >> >> > > > > same
> > > > > >>> >> >> > > > > > > > need.
> > > > > >>> >> >> > > > > > > > > > >> Everything happens in this class:
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > >
> > > > > >>> >> >> > > > > > > > >
> > > > > >>> >> >> > > > > > > >
> > > > > >>> >> >> > > > > > >
> > > > > >>> >> >> > > > > >
> > > > > >>> >> >> > > > >
> > > > > >>> >> >> > > >
> > > > > >>> >> >> > >
> > > > > >>> >> >> >
> > > > > >>> >> >>
> > > > > >>> >>
> > > > > >>>
> > > > >
> > > >
> > >
> >
> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java
> > > > > >>> >> >> > > > > > > > > > >> ,
> > > > > >>> >> >> > > > > > > > > > >> which allows you to configure
> > Facebook,
> > > > > >>> Twitter, a
> > > > > >>> >> CAS
> > > > > >>> >> >> > > > > server, a
> > > > > >>> >> >> > > > > > > > SAML
> > > > > >>> >> >> > > > > > > > > > IdP
> > > > > >>> >> >> > > > > > > > > > >> or an OpenID Connect provider. All
> the
> > > > > >>> provided
> > > > > >>> >> >> > parameters
> > > > > >>> >> >> > > > to
> > > > > >>> >> >> > > > > > the
> > > > > >>> >> >> > > > > > > > > pac4j
> > > > > >>> >> >> > > > > > > > > > >> provider are put into a Map and the
> > > > > >>> >> >> > > ConfigPropertiesFactory
> > > > > >>> >> >> > > > is
> > > > > >>> >> >> > > > > > > built
> > > > > >>> >> >> > > > > > > > > > with
> > > > > >>> >> >> > > > > > > > > > >> this Map to return the built client
> (=
> > > > > >>> >> authentication
> > > > > >>> >> >> > > > > > mechanism).
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > > >> You have one more specific option
> for
> > > Knox
> > > > > as
> > > > > >>> a
> > > > > >>> >> basic
> > > > > >>> >> >> > > > > > > authentication
> > > > > >>> >> >> > > > > > > > > > popup
> > > > > >>> >> >> > > > > > > > > > >> where the username must match the
> > > > password,
> > > > > >>> you can
> > > > > >>> >> >> > define
> > > > > >>> >> >> > > > > that
> > > > > >>> >> >> > > > > > > by:
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > > >> <param>
> > > > > >>> >> >> > > > > > > > > > >> <name>clientName</name>
> > > > > >>> >> >> > > > > > > > > > >> <value>testBasicAuth</value>
> > > > > >>> >> >> > > > > > > > > > >> </param>
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > > >> It's for testing only.
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > > >> For a CAS server:
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > > >> <param>
> > > > > >>> >> >> > > > > > > > > > >> <name>cas.loginUrl</name>
> > > > > >>> >> >> > > > > > > > > > >> <value>
> > > > > >>> >> https://casserverpac4j.herokuapp.com/login
> > > > > >>> >> >> > > </value>
> > > > > >>> >> >> > > > > > > > > > >> </param>
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > > >> Here are all the properties
> available
> > > for
> > > > > >>> building
> > > > > >>> >> >> > clients
> > > > > >>> >> >> > > > > > (their
> > > > > >>> >> >> > > > > > > > > > meaning
> > > > > >>> >> >> > > > > > > > > > >> is obvious):
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > > >> facebook.id
> > > > > >>> >> >> > > > > > > > > > >> facebook.secret
> > > > > >>> >> >> > > > > > > > > > >> facebook.scope
> > > > > >>> >> >> > > > > > > > > > >> facebook.fields
> > > > > >>> >> >> > > > > > > > > > >> twitter.id
> > > > > >>> >> >> > > > > > > > > > >> twitter.secret
> > > > > >>> >> >> > > > > > > > > > >> saml.keystorePassword
> > > > > >>> >> >> > > > > > > > > > >> saml.privateKeyPassword
> > > > > >>> >> >> > > > > > > > > > >> saml.keystorePath
> > > > > >>> >> >> > > > > > > > > > >> saml.identityProviderMetadataPath
> > > > > >>> >> >> > > > > > > > > > >> saml.maximumAuthenticationLifetime
> > > > > >>> >> >> > > > > > > > > > >> saml.serviceProviderEntityId
> > > > > >>> >> >> > > > > > > > > > >> saml.serviceProviderMetadataPath
> > > > > >>> >> >> > > > > > > > > > >> cas.loginUrl
> > > > > >>> >> >> > > > > > > > > > >> cas.protocol
> > > > > >>> >> >> > > > > > > > > > >> oidc.id
> > > > > >>> >> >> > > > > > > > > > >> oidc.secret
> > > > > >>> >> >> > > > > > > > > > >> oidc.discoveryUri
> > > > > >>> >> >> > > > > > > > > > >> oidc.customParamKey1
> > > > > >>> >> >> > > > > > > > > > >> oidc.customParamValue1
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > > >> If you define multiple clients, the
> > > first
> > > > > one
> > > > > >>> will
> > > > > >>> >> be
> > > > > >>> >> >> > used
> > > > > >>> >> >> > > > for
> > > > > >>> >> >> > > > > > > > > > >> authentication, but you can
> explicitly
> > > > > choose
> > > > > >>> the
> > > > > >>> >> >> client
> > > > > >>> >> >> > > you
> > > > > >>> >> >> > > > > > want
> > > > > >>> >> >> > > > > > > to
> > > > > >>> >> >> > > > > > > > > use
> > > > > >>> >> >> > > > > > > > > > >> via the clientName parameter,
> assuming
> > > you
> > > > > >>> want to
> > > > > >>> >> >> > switch
> > > > > >>> >> >> > > > from
> > > > > >>> >> >> > > > > > > > client
> > > > > >>> >> >> > > > > > > > > > >> depending on environment for
> example.
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > > >> So if you want to add some new
> > > > > authentication
> > > > > >>> >> >> mechanism,
> > > > > >>> >> >> > > you
> > > > > >>> >> >> > > > > > must
> > > > > >>> >> >> > > > > > > > > first
> > > > > >>> >> >> > > > > > > > > > >> check that it is available in pac4j
> > (if
> > > > it's
> > > > > >>> not,
> > > > > >>> >> it's
> > > > > >>> >> >> > > > another
> > > > > >>> >> >> > > > > > > > > > discussion,
> > > > > >>> >> >> > > > > > > > > > >> but generally, it is). Then, you'll
> > need
> > > > to
> > > > > >>> upgrade
> > > > > >>> >> >> the
> > > > > >>> >> >> > > > > > > > > > >> ConfigPropertiesFactory by
> submitting
> > a
> > > > new
> > > > > >>> pull
> > > > > >>> >> >> request
> > > > > >>> >> >> > > to
> > > > > >>> >> >> > > > > the
> > > > > >>> >> >> > > > > > > > pac4j
> > > > > >>> >> >> > > > > > > > > > >> project (I can do it myself, but I'm
> > > sure
> > > > > you
> > > > > >>> >> could do
> > > > > >>> >> >> > > that
> > > > > >>> >> >> > > > > > > easily),
> > > > > >>> >> >> > > > > > > > > > >> finally wait for the new pac4j
> release
> > > and
> > > > > >>> switch
> > > > > >>> >> >> pac4j
> > > > > >>> >> >> > > > > versions
> > > > > >>> >> >> > > > > > > in
> > > > > >>> >> >> > > > > > > > > Knox
> > > > > >>> >> >> > > > > > > > > > >> to
> > > > > >>> >> >> > > > > > > > > > >> benefit from the new feature.
> > > > > >>> >> >> > > > > > > > > > >> The good thing is that if someone
> > > related
> > > > to
> > > > > >>> the
> > > > > >>> >> CAS
> > > > > >>> >> >> > > server
> > > > > >>> >> >> > > > > does
> > > > > >>> >> >> > > > > > > the
> > > > > >>> >> >> > > > > > > > > > same
> > > > > >>> >> >> > > > > > > > > > >> thing for CAS (in pac4j), you will
> > > > > >>> automatically
> > > > > >>> >> get
> > > > > >>> >> >> it
> > > > > >>> >> >> > > when
> > > > > >>> >> >> > > > > > > you'll
> > > > > >>> >> >> > > > > > > > > > >> upgrade
> > > > > >>> >> >> > > > > > > > > > >> pac4j.
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > > >> To go even further, replacing LDAP
> > Shiro
> > > > > >>> >> >> authentication
> > > > > >>> >> >> > is
> > > > > >>> >> >> > > > > just
> > > > > >>> >> >> > > > > > a
> > > > > >>> >> >> > > > > > > > > matter
> > > > > >>> >> >> > > > > > > > > > >> of
> > > > > >>> >> >> > > > > > > > > > >> making pac4j LDAP authentication
> > > available
> > > > > via
> > > > > >>> >> >> > > configuration
> > > > > >>> >> >> > > > > > > > > parameters.
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > > >> I hope it was clear enough.
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > > >> Thanks.
> > > > > >>> >> >> > > > > > > > > > >> Best regards,
> > > > > >>> >> >> > > > > > > > > > >> Jérôme
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > > >> 2015-12-03 20:45 GMT+01:00 larry
> > mccay <
> > > > > >>> >> >> > > > larry.mccay@gmail.com
> > > > > >>> >> >> > > > > >:
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > > >> > Excellent!
> > > > > >>> >> >> > > > > > > > > > >> >
> > > > > >>> >> >> > > > > > > > > > >> > I will carve out some time to do
> > code
> > > > > >>> review.
> > > > > >>> >> >> > > > > > > > > > >> > We will need to get some insights
> > into
> > > > how
> > > > > >>> to go
> > > > > >>> >> >> about
> > > > > >>> >> >> > > > > > testing:
> > > > > >>> >> >> > > > > > > > > > >> >
> > > > > >>> >> >> > > > > > > > > > >> > * is the CAS server going to be
> > > > available
> > > > > >>> for
> > > > > >>> >> >> testing?
> > > > > >>> >> >> > > > > > > > > > >> > * what are the specific and
> > > > > >>> generic/standard (if
> > > > > >>> >> >> any)
> > > > > >>> >> >> > > > > > > > authentication
> > > > > >>> >> >> > > > > > > > > > >> > mechanisms available - for
> instance:
> > > > > >>> >> >> > > > > > > > > > >> > - Facebook, Google, LinkedIn
> and
> > > CAS
> > > > > are
> > > > > >>> >> >> specifics
> > > > > >>> >> >> > > > > > > > > > >> > - OAuth 2, OpenID Connect,
> SAML
> > > are
> > > > > >>> >> >> > > generic/standards
> > > > > >>> >> >> > > > -
> > > > > >>> >> >> > > > > > that
> > > > > >>> >> >> > > > > > > > may
> > > > > >>> >> >> > > > > > > > > > be
> > > > > >>> >> >> > > > > > > > > > >> > used for the above specifics...
> > > > > >>> >> >> > > > > > > > > > >> > * how do we test things other than
> > > CAS -
> > > > > in
> > > > > >>> >> terms of
> > > > > >>> >> >> > > > getting
> > > > > >>> >> >> > > > > > > > > > >> credentials,
> > > > > >>> >> >> > > > > > > > > > >> > configuration, etc
> > > > > >>> >> >> > > > > > > > > > >> >
> > > > > >>> >> >> > > > > > > > > > >> > We could certainly do this is
> phases
> > > as
> > > > > >>> well.
> > > > > >>> >> >> > > > > > > > > > >> >
> > > > > >>> >> >> > > > > > > > > > >> > If you can enumerate the things
> that
> > > > > should
> > > > > >>> work
> > > > > >>> >> and
> > > > > >>> >> >> > > > provide
> > > > > >>> >> >> > > > > > > some
> > > > > >>> >> >> > > > > > > > > > >> testing
> > > > > >>> >> >> > > > > > > > > > >> > details for CAS or as many as
> > possible
> > > > and
> > > > > >>> OpenID
> > > > > >>> >> >> > > Connect
> > > > > >>> >> >> > > > > then
> > > > > >>> >> >> > > > > > > we
> > > > > >>> >> >> > > > > > > > > can
> > > > > >>> >> >> > > > > > > > > > >> test
> > > > > >>> >> >> > > > > > > > > > >> > the specific implementations that
> > you
> > > > > >>> provide and
> > > > > >>> >> >> > enable
> > > > > >>> >> >> > > > the
> > > > > >>> >> >> > > > > > > > testing
> > > > > >>> >> >> > > > > > > > > > of
> > > > > >>> >> >> > > > > > > > > > >> > another OpenID Connect effort that
> > is
> > > in
> > > > > the
> > > > > >>> >> works
> > > > > >>> >> >> in
> > > > > >>> >> >> > > the
> > > > > >>> >> >> > > > > > > > community.
> > > > > >>> >> >> > > > > > > > > > >> >
> > > > > >>> >> >> > > > > > > > > > >> > I'm not sure whether we want to
> > commit
> > > > > >>> >> contributions
> > > > > >>> >> >> > > that
> > > > > >>> >> >> > > > > are
> > > > > >>> >> >> > > > > > > > > > dependent
> > > > > >>> >> >> > > > > > > > > > >> on
> > > > > >>> >> >> > > > > > > > > > >> > snapshots - we certainly can't
> > release
> > > > > with
> > > > > >>> any
> > > > > >>> >> such
> > > > > >>> >> >> > > > > > > dependencies.
> > > > > >>> >> >> > > > > > > > > > >> > I would hate to add a cleanup task
> > to
> > > a
> > > > > >>> release
> > > > > >>> >> to
> > > > > >>> >> >> > make
> > > > > >>> >> >> > > > sure
> > > > > >>> >> >> > > > > > > there
> > > > > >>> >> >> > > > > > > > > are
> > > > > >>> >> >> > > > > > > > > > >> no
> > > > > >>> >> >> > > > > > > > > > >> > snapshots in there.
> > > > > >>> >> >> > > > > > > > > > >> > We will probably wait until after
> > the
> > > > > pac4j
> > > > > >>> >> releases
> > > > > >>> >> >> > to
> > > > > >>> >> >> > > > > > commit.
> > > > > >>> >> >> > > > > > > > > > >> >
> > > > > >>> >> >> > > > > > > > > > >> > I am really happy that this
> > > integration
> > > > is
> > > > > >>> >> happening
> > > > > >>> >> >> > and
> > > > > >>> >> >> > > > > that
> > > > > >>> >> >> > > > > > it
> > > > > >>> >> >> > > > > > > > > went
> > > > > >>> >> >> > > > > > > > > > >> > rather smoothly.
> > > > > >>> >> >> > > > > > > > > > >> > These sorts of authentication
> > > protocols
> > > > > are
> > > > > >>> >> complex
> > > > > >>> >> >> > and
> > > > > >>> >> >> > > I
> > > > > >>> >> >> > > > > > think
> > > > > >>> >> >> > > > > > > we
> > > > > >>> >> >> > > > > > > > > > >> lined up
> > > > > >>> >> >> > > > > > > > > > >> > pretty well overall.
> > > > > >>> >> >> > > > > > > > > > >> >
> > > > > >>> >> >> > > > > > > > > > >> > Thanks for your work!
> > > > > >>> >> >> > > > > > > > > > >> >
> > > > > >>> >> >> > > > > > > > > > >> > On Thu, Dec 3, 2015 at 2:28 PM,
> > Jérôme
> > > > > >>> LELEU <
> > > > > >>> >> >> > > > > > leleuj@gmail.com>
> > > > > >>> >> >> > > > > > > > > > wrote:
> > > > > >>> >> >> > > > > > > > > > >> >
> > > > > >>> >> >> > > > > > > > > > >> > > Hi,
> > > > > >>> >> >> > > > > > > > > > >> > >
> > > > > >>> >> >> > > > > > > > > > >> > > I just sync'ed with master,
> > cleaned
> > > > > >>> >> dependencies
> > > > > >>> >> >> and
> > > > > >>> >> >> > > > added
> > > > > >>> >> >> > > > > > > > missing
> > > > > >>> >> >> > > > > > > > > > >> > > Javadocs. Everything works
> > correctly
> > > > > now.
> > > > > >>> Many
> > > > > >>> >> >> > thanks.
> > > > > >>> >> >> > > > > > > > > > >> > >
> > > > > >>> >> >> > > > > > > > > > >> > > The pull request is ready for a
> > full
> > > > > code
> > > > > >>> >> review:
> > > > > >>> >> >> > > > > > > > > > >> > >
> > > https://github.com/apache/knox/pull/2
> > > > > >>> >> >> > > > > > > > > > >> > >
> > > > > >>> >> >> > > > > > > > > > >> > > I'll write the documentation
> after
> > > the
> > > > > >>> pac4j
> > > > > >>> >> >> > releases
> > > > > >>> >> >> > > (I
> > > > > >>> >> >> > > > > > hope
> > > > > >>> >> >> > > > > > > > next
> > > > > >>> >> >> > > > > > > > > > >> week).
> > > > > >>> >> >> > > > > > > > > > >> > >
> > > > > >>> >> >> > > > > > > > > > >> > > Thanks.
> > > > > >>> >> >> > > > > > > > > > >> > > Best regards,
> > > > > >>> >> >> > > > > > > > > > >> > > Jérôme
> > > > > >>> >> >> > > > > > > > > > >> > >
> > > > > >>> >> >> > > > > > > > > > >> > >
> > > > > >>> >> >> > > > > > > > > > >> > > 2015-12-02 19:18 GMT+01:00 larry
> > > > mccay <
> > > > > >>> >> >> > > > > > larry.mccay@gmail.com
> > > > > >>> >> >> > > > > > > >:
> > > > > >>> >> >> > > > > > > > > > >> > >
> > > > > >>> >> >> > > > > > > > > > >> > > > Fixed in
> > > > > >>> >> >> > > > https://issues.apache.org/jira/browse/KNOX-636
> > > > > >>> >> >> > > > > .
> > > > > >>> >> >> > > > > > > > > > >> > > >
> > > > > >>> >> >> > > > > > > > > > >> > > > On Wed, Dec 2, 2015 at 12:42
> PM,
> > > > larry
> > > > > >>> mccay
> > > > > >>> >> <
> > > > > >>> >> >> > > > > > > > > > larry.mccay@gmail.com
> > > > > >>> >> >> > > > > > > > > > >> >
> > > > > >>> >> >> > > > > > > > > > >> > > > wrote:
> > > > > >>> >> >> > > > > > > > > > >> > > >
> > > > > >>> >> >> > > > > > > > > > >> > > > > Sure - I can file a JIRA and
> > > > commit
> > > > > a
> > > > > >>> fix.
> > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > >>> >> >> > > > > > > > > > >> > > > > The secret generation should
> > be
> > > > done
> > > > > >>> in one
> > > > > >>> >> >> > > instance
> > > > > >>> >> >> > > > > and
> > > > > >>> >> >> > > > > > > > > > >> replicated
> > > > > >>> >> >> > > > > > > > > > >> > > > across
> > > > > >>> >> >> > > > > > > > > > >> > > > > others.
> > > > > >>> >> >> > > > > > > > > > >> > > > > This replication/management
> of
> > > the
> > > > > >>> >> credential
> > > > > >>> >> >> > > stores
> > > > > >>> >> >> > > > > is
> > > > > >>> >> >> > > > > > > > > outside
> > > > > >>> >> >> > > > > > > > > > of
> > > > > >>> >> >> > > > > > > > > > >> > the
> > > > > >>> >> >> > > > > > > > > > >> > > > > scope of Knox itself as of
> > now.
> > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > >>> >> >> > > > > > > > > > >> > > > > Documentation is done in
> > > markdown
> > > > > and
> > > > > >>> is
> > > > > >>> >> >> > > > contributing
> > > > > >>> >> >> > > > > > > > details
> > > > > >>> >> >> > > > > > > > > > are
> > > > > >>> >> >> > > > > > > > > > >> > > > > available at:
> > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > >>> >> >> > > > > > > > > > >> > > >
> > > > > >>> >> >> > > > > > > > > > >> > >
> > > > > >>> >> >> > > > > > > > > > >> >
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > >
> > > > > >>> >> >> > > > > > > > >
> > > > > >>> >> >> > > > > > > >
> > > > > >>> >> >> > > > > > >
> > > > > >>> >> >> > > > > >
> > > > > >>> >> >> > > > >
> > > > > >>> >> >> > > >
> > > > > >>> >> >> > >
> > > > > >>> >> >> >
> > > > > >>> >> >>
> > > > > >>> >>
> > > > > >>>
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
> > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > >>> >> >> > > > > > > > > > >> > > > > Which should give you a
> > general
> > > > > idea.
> > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > >>> >> >> > > > > > > > > > >> > > > > Find an example like:
> > > > > >>> ./trunk/books/0.7.0/
> > > > > >>> >> >> > > > > > > > > > >> > > config_preauth_sso_provider.md
> > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > >>> >> >> > > > > > > > > > >> > > > > For an example of typical
> > > content
> > > > > and
> > > > > >>> >> format.
> > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > >>> >> >> > > > > > > > > > >> > > > > Here is how that example
> > > renders:
> > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > >>> >> >> > > > > > > > > > >> > > >
> > > > > >>> >> >> > > > > > > > > > >> > >
> > > > > >>> >> >> > > > > > > > > > >> >
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > >
> > > > > >>> >> >> > > > > > > > >
> > > > > >>> >> >> > > > > > > >
> > > > > >>> >> >> > > > > > >
> > > > > >>> >> >> > > > > >
> > > > > >>> >> >> > > > >
> > > > > >>> >> >> > > >
> > > > > >>> >> >> > >
> > > > > >>> >> >> >
> > > > > >>> >> >>
> > > > > >>> >>
> > > > > >>>
> > > > >
> > > >
> > >
> >
> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
> > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > >>> >> >> > > > > > > > > > >> > > > > You'll need to tie it into
> the
> > > > rest
> > > > > >>> of the
> > > > > >>> >> >> book
> > > > > >>> >> >> > -
> > > > > >>> >> >> > > > just
> > > > > >>> >> >> > > > > > > grep
> > > > > >>> >> >> > > > > > > > > for
> > > > > >>> >> >> > > > > > > > > > >> where
> > > > > >>> >> >> > > > > > > > > > >> > > > that
> > > > > >>> >> >> > > > > > > > > > >> > > > > filename is referenced.
> > > > > >>> >> >> > > > > > > > > > >> > > > > To test how it renders build
> > the
> > > > > site
> > > > > >>> with:
> > > > > >>> >> >> > "ant"
> > > > > >>> >> >> > > > and
> > > > > >>> >> >> > > > > > note
> > > > > >>> >> >> > > > > > > > the
> > > > > >>> >> >> > > > > > > > > > >> url to
> > > > > >>> >> >> > > > > > > > > > >> > > the
> > > > > >>> >> >> > > > > > > > > > >> > > > > 0.7.0 book.
> > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > >>> >> >> > > > > > > > > > >> > > > > On Wed, Dec 2, 2015 at 12:12
> > PM,
> > > > > >>> Jérôme
> > > > > >>> >> LELEU
> > > > > >>> >> >> <
> > > > > >>> >> >> > > > > > > > > leleuj@gmail.com
> > > > > >>> >> >> > > > > > > > > > >
> > > > > >>> >> >> > > > > > > > > > >> > > wrote:
> > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> Hi,
> > > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > > >>> >> >> > > > > > > > > > >> > > > >> Why it doesn't work for
> pac4j
> > > > while
> > > > > >>> it
> > > > > >>> >> works
> > > > > >>> >> >> > for
> > > > > >>> >> >> > > > > others
> > > > > >>> >> >> > > > > > > is
> > > > > >>> >> >> > > > > > > > a
> > > > > >>> >> >> > > > > > > > > > bit
> > > > > >>> >> >> > > > > > > > > > >> > > strange
> > > > > >>> >> >> > > > > > > > > > >> > > > >> to
> > > > > >>> >> >> > > > > > > > > > >> > > > >> me, but if you have the
> patch
> > > in
> > > > > >>> front of
> > > > > >>> >> >> your
> > > > > >>> >> >> > > > eyes,
> > > > > >>> >> >> > > > > > I'd
> > > > > >>> >> >> > > > > > > > > rather
> > > > > >>> >> >> > > > > > > > > > >> > prefer
> > > > > >>> >> >> > > > > > > > > > >> > > > you
> > > > > >>> >> >> > > > > > > > > > >> > > > >> to commit it. In all cases,
> > > I'll
> > > > > >>> sync with
> > > > > >>> >> >> the
> > > > > >>> >> >> > > > > master.
> > > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > > >>> >> >> > > > > > > > > > >> > > > >> There was one question you
> > > didn't
> > > > > >>> answer
> > > > > >>> >> >> > > > previously:
> > > > > >>> >> >> > > > > is
> > > > > >>> >> >> > > > > > > the
> > > > > >>> >> >> > > > > > > > > > >> password
> > > > > >>> >> >> > > > > > > > > > >> > > > >> generated for the pac4j
> > > provider
> > > > > the
> > > > > >>> same
> > > > > >>> >> >> > across
> > > > > >>> >> >> > > > all
> > > > > >>> >> >> > > > > > > > gateway
> > > > > >>> >> >> > > > > > > > > > >> > > instances?
> > > > > >>> >> >> > > > > > > > > > >> > > > >> Because I expect to have
> the
> > > same
> > > > > >>> value
> > > > > >>> >> as I
> > > > > >>> >> >> > use
> > > > > >>> >> >> > > it
> > > > > >>> >> >> > > > > to
> > > > > >>> >> >> > > > > > > > > encrypt
> > > > > >>> >> >> > > > > > > > > > /
> > > > > >>> >> >> > > > > > > > > > >> > > decrypt
> > > > > >>> >> >> > > > > > > > > > >> > > > >> data.
> > > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > > >>> >> >> > > > > > > > > > >> > > > >> I will add the Javadoc.
> After
> > > > that,
> > > > > >>> you
> > > > > >>> >> can
> > > > > >>> >> >> > > review
> > > > > >>> >> >> > > > > the
> > > > > >>> >> >> > > > > > > pull
> > > > > >>> >> >> > > > > > > > > > >> request
> > > > > >>> >> >> > > > > > > > > > >> > > more
> > > > > >>> >> >> > > > > > > > > > >> > > > >> completely.
> > > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > > >>> >> >> > > > > > > > > > >> > > > >> What do you expect for the
> > > > > >>> documentation?
> > > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > > >>> >> >> > > > > > > > > > >> > > > >> Notice that pac4j
> > dependencies
> > > > are
> > > > > >>> still
> > > > > >>> >> >> > > snapshots,
> > > > > >>> >> >> > > > > but
> > > > > >>> >> >> > > > > > > > they
> > > > > >>> >> >> > > > > > > > > > >> will be
> > > > > >>> >> >> > > > > > > > > > >> > > > >> released in a week or two.
> > > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > > >>> >> >> > > > > > > > > > >> > > > >> Thanks.
> > > > > >>> >> >> > > > > > > > > > >> > > > >> Best regards,
> > > > > >>> >> >> > > > > > > > > > >> > > > >> Jérôme
> > > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > > >>> >> >> > > > > > > > > > >> > > > >> 2015-12-02 17:51 GMT+01:00
> > > larry
> > > > > >>> mccay <
> > > > > >>> >> >> > > > > > > > > larry.mccay@gmail.com
> > > > > >>> >> >> > > > > > > > > > >:
> > > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > Jérôme -
> > > > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > If you would like to add
> > that
> > > > > >>> change as
> > > > > >>> >> >> part
> > > > > >>> >> >> > of
> > > > > >>> >> >> > > > > your
> > > > > >>> >> >> > > > > > > > patch
> > > > > >>> >> >> > > > > > > > > or
> > > > > >>> >> >> > > > > > > > > > >> as a
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > separately filed JIRA to
> > fix
> > > a
> > > > > bug
> > > > > >>> that
> > > > > >>> >> >> would
> > > > > >>> >> >> > > > > > certainly
> > > > > >>> >> >> > > > > > > > be
> > > > > >>> >> >> > > > > > > > > > >> > welcomed.
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > Otherwise, I can do it.
> > > > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > Let me know.
> > > > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > thanks,
> > > > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > --larry
> > > > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > On Wed, Dec 2, 2015 at
> > 11:44
> > > > AM,
> > > > > >>> larry
> > > > > >>> >> >> mccay
> > > > > >>> >> >> > <
> > > > > >>> >> >> > > > > > > > > > >> > larry.mccay@gmail.com
> > > > > >>> >> >> > > > > > > > > > >> > > >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > wrote:
> > > > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > > Okay - I had to add an
> > > > override
> > > > > >>> of
> > > > > >>> >> >> > > > > > getUserPrincipal()
> > > > > >>> >> >> > > > > > > > to
> > > > > >>> >> >> > > > > > > > > > the
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >
> > > > > >>> >> IdentityAsserterHttpServletRequestWrapper
> > > > > >>> >> >> > and
> > > > > >>> >> >> > > > > > return
> > > > > >>> >> >> > > > > > > > the
> > > > > >>> >> >> > > > > > > > > > >> member
> > > > > >>> >> >> > > > > > > > > > >> > > > >> variable
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > > username and it works
> > like
> > > a
> > > > > >>> charm.
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > > Why I haven't seen this
> > > same
> > > > > >>> behavior
> > > > > >>> >> >> with
> > > > > >>> >> >> > > > other
> > > > > >>> >> >> > > > > > > > > providers
> > > > > >>> >> >> > > > > > > > > > >> is a
> > > > > >>> >> >> > > > > > > > > > >> > > bit
> > > > > >>> >> >> > > > > > > > > > >> > > > >> of a
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > > mystery but they must
> be
> > > > adding
> > > > > >>> other
> > > > > >>> >> >> > > wrappers
> > > > > >>> >> >> > > > > that
> > > > > >>> >> >> > > > > > > > > handle
> > > > > >>> >> >> > > > > > > > > > >> it.
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > > This is quite cool,
> > Jérôme!
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > > On Wed, Dec 2, 2015 at
> > > 10:41
> > > > > AM,
> > > > > >>> larry
> > > > > >>> >> >> > mccay
> > > > > >>> >> >> > > <
> > > > > >>> >> >> > > > > > > > > > >> > > larry.mccay@gmail.com
> > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > > wrote:
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >> That was it - thanks!
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >> On Wed, Dec 2, 2015 at
> > > 10:20
> > > > > AM,
> > > > > >>> >> Jérôme
> > > > > >>> >> >> > > LELEU
> > > > > >>> >> >> > > > <
> > > > > >>> >> >> > > > > > > > > > >> > leleuj@gmail.com>
> > > > > >>> >> >> > > > > > > > > > >> > > > >> wrote:
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> This is my exact
> > command
> > > > > line:
> > > > > >>> mvn
> > > > > >>> >> >> > > -Prelease
> > > > > >>> >> >> > > > > > clean
> > > > > >>> >> >> > > > > > > > > > install
> > > > > >>> >> >> > > > > > > > > > >> > > > >> -DskipTests
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> You use an internal
> > Maven
> > > > > >>> >> repository to
> > > > > >>> >> >> > > fetch
> > > > > >>> >> >> > > > > > > > > > dependencies
> > > > > >>> >> >> > > > > > > > > > >> > from
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > internet:
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > > > >>> >> >> > > > > > > > > > >> > >
> > > > > >>> >> >> > > > > > > >
> > > > > >>> >> >> > >
> > > > > >>>
> > http://nexus-private.hortonworks.com/nexus/content/groups/public/
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> Does this repository
> > have
> > > > > >>> access to
> > > > > >>> >> the
> > > > > >>> >> >> > > > remote
> > > > > >>> >> >> > > > > > > > > Snapshots
> > > > > >>> >> >> > > > > > > > > > >> > > Sonatype
> > > > > >>> >> >> > > > > > > > > > >> > > > >> repo?
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> 2015-12-02 16:16
> > > GMT+01:00
> > > > > >>> larry
> > > > > >>> >> mccay
> > > > > >>> >> >> <
> > > > > >>> >> >> > > > > > > > > > >> larry.mccay@gmail.com
> > > > > >>> >> >> > > > > > > > > > >> > >:
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > hmmm - I used:
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > mvn clean install
> > > > > >>> -DskipTests=true
> > > > > >>> >> >> > > > -Prelease
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > The repository
> entry
> > is
> > > > in
> > > > > >>> there
> > > > > >>> >> >> > already.
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > No worky.
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > On Wed, Dec 2, 2015
> > at
> > > > > 10:12
> > > > > >>> AM,
> > > > > >>> >> >> Jérôme
> > > > > >>> >> >> > > > > LELEU <
> > > > > >>> >> >> > > > > > > > > > >> > > leleuj@gmail.com
> > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> wrote:
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Hi,
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > You need the
> > > j2e-pac4j
> > > > > >>> >> dependencies
> > > > > >>> >> >> > as
> > > > > >>> >> >> > > > well
> > > > > >>> >> >> > > > > > as
> > > > > >>> >> >> > > > > > > > the
> > > > > >>> >> >> > > > > > > > > > >> pac4j-*
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> dependencies,
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > but you don't
> need
> > to
> > > > > >>> build them
> > > > > >>> >> >> > > locally
> > > > > >>> >> >> > > > > > > > > (hopefully).
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > But you need a
> > > > dependency
> > > > > >>> on the
> > > > > >>> >> >> > > Sonatype
> > > > > >>> >> >> > > > > > > > snapshots
> > > > > >>> >> >> > > > > > > > > > >> > > repository
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> (where the
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > snapshot versions
> > are
> > > > > >>> hosted),
> > > > > >>> >> >> which
> > > > > >>> >> >> > is
> > > > > >>> >> >> > > > > added
> > > > > >>> >> >> > > > > > > for
> > > > > >>> >> >> > > > > > > > > > >> Maven in
> > > > > >>> >> >> > > > > > > > > > >> > > the
> > > > > >>> >> >> > > > > > > > > > >> > > > >> root
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > pom.xml:
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > > >>> >> >> > > > > > > > > > >> > > >
> > > > > >>> >> >> > > > > > > > > > >> > >
> > > > > >>> >> >> > > > > > > > > > >> >
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > >
> > > > > >>> >> >> > > > > > > > >
> > > > > >>> >> >> > > > > > > >
> > > > > >>> >> >> > > > > > >
> > > > > >>> >> >> > > > > >
> > > > > >>> >> >> > > > >
> > > > > >>> >> >> > > >
> > > > > >>> >> >> > >
> > > > > >>> >> >> >
> > > > > >>> >> >>
> > > > > >>> >>
> > > > > >>>
> > > > >
> > > >
> > >
> >
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > If you use Ant
> for
> > > the
> > > > > >>> build,
> > > > > >>> >> there
> > > > > >>> >> >> > is
> > > > > >>> >> >> > > > > maybe
> > > > > >>> >> >> > > > > > a
> > > > > >>> >> >> > > > > > > > > glitch
> > > > > >>> >> >> > > > > > > > > > >> to
> > > > > >>> >> >> > > > > > > > > > >> > > find
> > > > > >>> >> >> > > > > > > > > > >> > > > >> the
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > Sonatype
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Maven repo.
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Thanks.
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Best regards,
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Jérôme
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > 2015-12-02 16:06
> > > > > GMT+01:00
> > > > > >>> larry
> > > > > >>> >> >> > mccay
> > > > > >>> >> >> > > <
> > > > > >>> >> >> > > > > > > > > > >> > > larry.mccay@gmail.com
> > > > > >>> >> >> > > > > > > > > > >> > > > >:
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > 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.mccay@gmail.com>
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > wrote:
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > >
> > > > > >>> >> gateway-provider-security-pac4j
> > > > > >>> >> >> > > > doesn't
> > > > > >>> >> >> > > > > > > > build -
> > > > > >>> >> >> > > > > > > > > > do
> > > > > >>> >> >> > > > > > > > > > >> you
> > > > > >>> >> >> > > > > > > > > > >> > > > have
> > > > > >>> >> >> > > > > > > > > > >> > > > >> a
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> pending
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > > change for
> your
> > > > > >>> pom.xml or
> > > > > >>> >> >> > > something?
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >>
> > > > > >>> >> >> > > > > > > > > > >> > > > >> > >
> > > > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > > >>> >> >> > > > > > > > > > >> > > >
> > > > > >>> >> >> > > > > > > > > > >> > >
> > > > > >>> >> >> > > > > > > > > > >> >
> > > > > >>> >> >> > > > > > > > > > >>
> > > > > >>> >> >> > > > > > > > > > >
> > > > > >>> >> >> > > > > > > > > > >
> > > > > >>> >> >> > > > > > > > > >
> > > > > >>> >> >> > > > > > > > >
> > > > > >>> >> >> > > > > > > >
> > > > > >>> >> >> > > > > > >
> > > > > >>> >> >> > > > > >
> > > > > >>> >> >> > > > >
> > > > > >>> >> >> > > >
> > > > > >>> >> >> > >
> > > > > >>> >> >> >
> > > > > >>> >> >>
> > > > > >>> >>
> > > > > >>>
> > > > > >>
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by larry mccay <lm...@apache.org>.
Hi Jérôme -
Thanks for the updated docs - I will take a look today.
I am currently still trying to test okta and stuck in a redirect loop.
Did you have to change anything in order to get the
request.getParameter(Clients.DEFAULT_CLIENT_NAME_PARAMETER)
set for the callbacks from okta? It is null in my environment and therefore
it moves on to the following:
// otherwise just apply security and requires authentication
// apply RequiresAuthenticationFilter
requiresAuthenticationFilter.doFilter(servletRequest,
servletResponse, filterChain);
which obviously results in the redirect loop.
Curious whether you ran into that...
thanks,
--larry
On Fri, Jan 15, 2016 at 4:00 AM, Jérôme LELEU <le...@gmail.com> wrote:
> Hi,
>
> I just uploaded a new patch for the documentation with the links pointing
> to the pac4j wiki. It should be clearer.
>
> Thanks.
> Best regards,
> Jérôme
>
>
> 2016-01-14 13:20 GMT+01:00 larry mccay <lm...@apache.org>:
>
> > That sounds pretty reasonable.
> > I will likely document a few of the integrations that are possible in
> > blogs/tutorials anyway.
> >
> > I don't want testing of Knox at release time to have to jump around to
> much
> > in order to be able to test.
> > I think we can make that all good though.
> >
> > I will see what I can do with okta today.
> >
> > On Thu, Jan 14, 2016 at 5:00 AM, Jérôme LELEU <le...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > Yes, the documentation is a bit too light. But you guessed it right: we
> > > need to have a keystore for encryption.
> > >
> > > The saml.identityProviderMetadataPath can point to a local resource or
> > to a
> > > remote one, using the right prefix: resource:, file: or an url (by
> > default,
> > > it is a file path). This must be documented though.
> > >
> > > With Okta, I used the defined url (Single Sign On URL = Recipient URL =
> > > Destination URL) for the serviceProviderEntityId, but I think it may
> > > depends on IdP as well. Reading the spec, it must be an URI, but I'm
> not
> > > sure if the SP metadata should be really available on this url. For
> Okta,
> > > it doesn't matter.
> > >
> > > According to your SAML configuration, the SP metadata will be generated
> > > somewhere and this somewhere can be defined via the
> > > serviceProviderMetadataPath parameter. You generally need to update
> your
> > > metadata to the IdP (not required for Okta though). Both the SP and IdP
> > > must know each other.
> > >
> > > When writing the documentation, I went fast on these parameters with
> the
> > > feeling they were regular ones, but indeed, the description in the Knox
> > > manual is not enough. This is somehow a bit normal as the real
> > > documentation for SAML is on the SAML wiki:
> > > https://github.com/pac4j/pac4j/wiki/Clients#details-for-saml-support
> > >
> > > So I propose to keep the Knox documentation mostly "as is", but add
> links
> > > to the pac4j wiki (where I could more easily made updates). All pac4j
> > > integrations need this documentation so it's better to centralize it,
> > from
> > > my point of view. What do you think?
> > >
> > > Thanks.
> > > Best regards,
> > > Jérôme
> > >
> > >
> > >
> > > 2016-01-13 19:37 GMT+01:00 larry mccay <lm...@apache.org>:
> > >
> > > > Hi Jérôme -
> > > >
> > > > I'm trying to configure the pac4j provider for an okta "application"
> > > that I
> > > > created.
> > > > The following (from KNOX-642 docs patch) isn't quite enough to make
> it
> > > > clear to me how to go about doing so:
> > > >
> > > > +saml.keystorePassword | Password of the keystore
> (storepass)
> > > > +saml.privateKeyPassword | Password for the private key
> > > (keypass)
> > > > +saml.keystorePath | Path of the keystore
> > > > +saml.identityProviderMetadataPath | Path of the identity
> > > > provider metadata
> > > > +saml.maximumAuthenticationLifetime | Maximum lifetime for
> > > > authentication
> > > > +saml.serviceProviderEntityId | Identifier of the service
> > > > provider
> > > > +saml.serviceProviderMetadataPath | Path of the service
> > > provider
> > > > metadata
> > > >
> > > > I assume that I can use the gateway.jks keystore and the
> > gateway-identity
> > > > keypair to do the request signing and that that information is what
> is
> > > > needed for the first 3 params. Unfortunately, I don't see any use of
> > > > gateway services to get the master secret therefore it needs to be in
> > > clear
> > > > text here. This won't work - but may not be a show stopper for
> > committing
> > > > to master as long as we follow up with a fix.
> > > >
> > > > Can saml.identityProviderMetadataPath point to a remote location or
> > does
> > > it
> > > > have to be local to the SP application. This would likely require it
> to
> > > be
> > > > on the local filesystem, provisioned by the contributor into the
> > > generated
> > > > web app or in some central location via NFS or something like that.
> > > >
> > > > The okta application that I created is called KnoxSSO - is that the
> > value
> > > > for saml.serviceProviderEntityId?
> > > >
> > > > The saml.serviceProviderMetadataPath has the same questions as the
> > > metadata
> > > > for the IDP. In addition, is there a sample metadata file that we can
> > > > provide for the use of pac4j with KnoxSSO?
> > > >
> > > > I think that getting this working and clean (no clear text passwords)
> > > will
> > > > make a great feature and blog for featuring pac4j provider and the
> > 0.8.0
> > > > release. So, let's try and iron this out clearly.
> > > >
> > > > I would really like to get this working and committed in the next
> > couple
> > > > days to free us up for follow up items. In particular we need time to
> > > > figure out whether the identity assertion providers that we currently
> > > have
> > > > will suffice for an apache release that is featuring this new
> > > > functionality.
> > > >
> > > > I will also add the above comments/questions to the JIRA for
> > visibility.
> > > >
> > > > thanks,
> > > >
> > > > --larry
> > > >
> > > > On Fri, Jan 8, 2016 at 12:40 PM, larry mccay <lm...@apache.org>
> > wrote:
> > > >
> > > > > Jérôme -
> > > > >
> > > > > My testing of OpenID Connect is blocked.
> > > > > Can you see the comments in KNOX-641?
> > > > >
> > > > > thanks,
> > > > >
> > > > > --larry
> > > > >
> > > > > On Wed, Jan 6, 2016 at 2:30 PM, larry mccay <larry.mccay@gmail.com
> >
> > > > wrote:
> > > > >
> > > > >> Jérôme -
> > > > >>
> > > > >> Please see the comments on KNOX-641.
> > > > >>
> > > > >> thanks,
> > > > >>
> > > > >> --larry
> > > > >>
> > > > >> On Wed, Jan 6, 2016 at 11:24 AM, Kevin Minder <
> > > > >> kevin.minder@hortonworks.com> wrote:
> > > > >>
> > > > >>> I can certainly appreciate the issue of including external
> > resources
> > > in
> > > > >>> automated tests. Nothing has driven me more crazy over the
> years.
> > > The
> > > > >>> flip side of this of course is not finding out about a breakage
> > until
> > > > >>> someone is willing to go through the manual testing which will
> > > > typically
> > > > >>> happen just before a release. Also the implication is that these
> > > > testing
> > > > >>> procedures must be very will documented so that they can be
> > continue
> > > > to be
> > > > >>> run once any of us are no longer active in the project.
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> On 1/6/16, 2:12 AM, "Jérôme LELEU" <le...@gmail.com> wrote:
> > > > >>>
> > > > >>> >Hi,
> > > > >>> >
> > > > >>> >Yes, you can hit the CAS server at Heroku. Notice it's a Heroku
> > free
> > > > >>> server
> > > > >>> >so it needs to be re-activated first (it takes a couple of
> > seconds).
> > > > So
> > > > >>> for
> > > > >>> >a UI test, you should first hit it, wait 30 seconds and then
> > perform
> > > > the
> > > > >>> >test.
> > > > >>> >
> > > > >>> >Just my 2 cents:
> > > > >>> >Using automated UI tests was my first strategy for pac4j but I
> > > > finally
> > > > >>> >gave up because public providers change very often, at least
> > enough
> > > to
> > > > >>> make
> > > > >>> >the maintenance tests a nightmare. Currently, I'm using manual
> > tests
> > > > >>> (the
> > > > >>> >same for all demos), it takes me around 5 minutes to play them
> all
> > > by
> > > > >>> hand
> > > > >>> >(for a demo) and I launched manually the UI tests I have for
> every
> > > > major
> > > > >>> >pac4j release. Just to say UI tests are not that easy. For a CAS
> > > > server,
> > > > >>> >it's fairly feasible as the CAS server and protocol change
> rarely.
> > > > >>> >That's why for Knox, I did some compromise with a simulated web
> > test
> > > > >>> (based
> > > > >>> >on the basic auth). See:
> > > > >>> >
> > > > >>>
> > > >
> > >
> >
> https://github.com/apache/knox/pull/2/files#diff-d0c880ca71b310dbe57975c577535e97R47
> > > > >>> >
> > > > >>> >Thanks.
> > > > >>> >Best regards,
> > > > >>> >Jérôme
> > > > >>> >
> > > > >>> >
> > > > >>> >
> > > > >>> >2016-01-05 21:20 GMT+01:00 Kevin Minder <
> > > kevin.minder@hortonworks.com
> > > > >:
> > > > >>> >
> > > > >>> >> From my perspective it would be ideal if there were some
> > > automatable
> > > > >>> >> functional tests for this. I’m not advocating that these be
> > > > something
> > > > >>> >> included in “mvn clean install” as that is running too long as
> > it
> > > > is.
> > > > >>> >> Given that I don’t have as much context as Larry, I have some
> > > > >>> questions
> > > > >>> >> about what this would take. Lets say we had permission to hit
> > > > >>> >> https://casserverpac4j.herokuapp.com/login as part of some
> low
> > > > >>> frequency
> > > > >>> >> automated tests (e.g. Once nighty). What static credentials
> and
> > > > >>> other test
> > > > >>> >> automation infrastructure would need to be implemented in
> > support
> > > of
> > > > >>> this?
> > > > >>> >> I understand that the test suite would require at a minimum
> > > > >>> >> 1) a test driver
> > > > >>> >> 2) a protected mock UI and
> > > > >>> >> 3) an appropriately configured Knox
> > > > >>> >> 4) a profile enabled maven module
> > > > >>> >> 5) an Apache jenkins job
> > > > >>> >> but I’m sure I’m missing other things. I’m certainly willing
> to
> > > > help
> > > > >>> >> setup the skeleton infrastructure (e.g. test driver, mock UI,
> > > maven
> > > > >>> module,
> > > > >>> >> jenkins job)
> > > > >>> >>
> > > > >>> >>
> > > > >>> >>
> > > > >>> >> On 1/5/16, 2:54 PM, "larry mccay" <la...@gmail.com>
> > wrote:
> > > > >>> >>
> > > > >>> >> >Okay, very good.
> > > > >>> >> >I've used TestShib for the picketlink provider - thanks for
> the
> > > > >>> pointers!
> > > > >>> >> >
> > > > >>> >> >On Tue, Jan 5, 2016 at 1:38 PM, Jérôme LELEU <
> leleuj@gmail.com
> > >
> > > > >>> wrote:
> > > > >>> >> >
> > > > >>> >> >> The online CAS server (
> > > > https://casserverpac4j.herokuapp.com/login)
> > > > >>> uses
> > > > >>> >> >> the
> > > > >>> >> >> CAS protocol. SAML support can be tested using some online
> > IdP
> > > > like
> > > > >>> >> Okta,
> > > > >>> >> >> TestShib, OpenFeide, Ssocircle...
> > > > >>> >> >>
> > > > >>> >> >>
> > > > >>> >> >> 2016-01-05 17:32 GMT+01:00 larry mccay <
> > larry.mccay@gmail.com
> > > >:
> > > > >>> >> >>
> > > > >>> >> >> > Great - thanks for that pointer!
> > > > >>> >> >> >
> > > > >>> >> >> > I will take a look at that and help drive the release
> > related
> > > > >>> testing.
> > > > >>> >> >> > Merge testing will be gated on CAS server (is this SAML
> or
> > > CAS
> > > > >>> >> protocol?)
> > > > >>> >> >> > and testBasicAuth.
> > > > >>> >> >> >
> > > > >>> >> >> > On Tue, Jan 5, 2016 at 10:52 AM, Jérôme LELEU <
> > > > leleuj@gmail.com>
> > > > >>> >> wrote:
> > > > >>> >> >> >
> > > > >>> >> >> > > Hi,
> > > > >>> >> >> > >
> > > > >>> >> >> > > Glad to hear back from you!
> > > > >>> >> >> > >
> > > > >>> >> >> > > The core pac4j project is fully tested by unit tests
> (and
> > > > some
> > > > >>> >> >> > integration
> > > > >>> >> >> > > tests I run for major version), then all pac4j
> > > > implementations
> > > > >>> are
> > > > >>> >> each
> > > > >>> >> >> > > tested by the appropriate demo: j2e-pac4j-demo tests
> > > > j2e-pac4j,
> > > > >>> >> >> > > spring-webmvc-pac4j-demo tests spring-webmvc-pac4j,
> etc.
> > > > >>> >> >> > >
> > > > >>> >> >> > > So if you take a look at:
> > > > >>> >> >> > >
> > > > >>> >> >> > >
> > > > >>> >> >> >
> > > > >>> >> >>
> > > > >>> >>
> > > > >>>
> > > >
> > >
> >
> https://github.com/pac4j/j2e-pac4j-demo/blob/master/src/main/java/org/pac4j/demo/j2e/config/DemoConfigFactory.java#L27
> > > > >>> >> >> > > (for example), you have all the required information to
> > > test.
> > > > >>> >> >> > >
> > > > >>> >> >> > > I can do that on my own, but it can be good for the
> Knox
> > > > >>> community
> > > > >>> >> to
> > > > >>> >> >> > start
> > > > >>> >> >> > > working / testing the pac4j support. It's up to yoy.
> > > > >>> >> >> > >
> > > > >>> >> >> > > Thanks.
> > > > >>> >> >> > > Best regards,
> > > > >>> >> >> > > Jérôme
> > > > >>> >> >> > >
> > > > >>> >> >> > >
> > > > >>> >> >> > > 2016-01-05 16:11 GMT+01:00 larry mccay <
> > > > larry.mccay@gmail.com
> > > > >>> >:
> > > > >>> >> >> > >
> > > > >>> >> >> > > > Hello Jérôme -
> > > > >>> >> >> > > >
> > > > >>> >> >> > > > Happy New Year!
> > > > >>> >> >> > > >
> > > > >>> >> >> > > > I am going to start reviewing your updates today,
> > > > hopefully.
> > > > >>> >> >> > > > I was thinking that we need to start discussions on
> > what
> > > > the
> > > > >>> key
> > > > >>> >> >> > usecases
> > > > >>> >> >> > > > are and how to go about testing them.
> > > > >>> >> >> > > > We can certainly test the testBasicAuth and against
> the
> > > > >>> hosted CAS
> > > > >>> >> >> > server
> > > > >>> >> >> > > > but what about FB, openid, OAuth, etc?
> > > > >>> >> >> > > >
> > > > >>> >> >> > > > I'm not sure that FB would be a key feature but
> OpenID
> > > > >>> Connect and
> > > > >>> >> >> > OAuth
> > > > >>> >> >> > > > would be - as is SAML.
> > > > >>> >> >> > > > I think CAS buys us SAML testing - assuming that the
> > > > >>> >> configuration of
> > > > >>> >> >> > the
> > > > >>> >> >> > > > hosted server is actually a SAML 2 instance.
> > > > >>> >> >> > > >
> > > > >>> >> >> > > > What about the others?
> > > > >>> >> >> > > >
> > > > >>> >> >> > > > I don't know that we need to be able to test them all
> > > > before
> > > > >>> merge
> > > > >>> >> >> but
> > > > >>> >> >> > > some
> > > > >>> >> >> > > > sort of manual verification would be great.
> > > > >>> >> >> > > > We would need to be able to test them before the next
> > > > release
> > > > >>> >> which
> > > > >>> >> >> > would
> > > > >>> >> >> > > > be featuring the pac4j functionality.
> > > > >>> >> >> > > >
> > > > >>> >> >> > > > Maybe you can describe how you go about testing such
> > > things
> > > > >>> for
> > > > >>> >> the
> > > > >>> >> >> > pac4j
> > > > >>> >> >> > > > project itself?
> > > > >>> >> >> > > >
> > > > >>> >> >> > > > thanks,
> > > > >>> >> >> > > >
> > > > >>> >> >> > > > --larry
> > > > >>> >> >> > > >
> > > > >>> >> >> > > >
> > > > >>> >> >> > > > On Tue, Jan 5, 2016 at 9:55 AM, Jérôme LELEU <
> > > > >>> leleuj@gmail.com>
> > > > >>> >> >> wrote:
> > > > >>> >> >> > > >
> > > > >>> >> >> > > > > Hi,
> > > > >>> >> >> > > > >
> > > > >>> >> >> > > > > Happy new year!
> > > > >>> >> >> > > > >
> > > > >>> >> >> > > > > A few days ago, I updated my patch of the pac4j
> > gateway
> > > > >>> provider
> > > > >>> >> >> > > > according
> > > > >>> >> >> > > > > to all comments on
> > > > >>> >> https://issues.apache.org/jira/browse/KNOX-641
> > > > >>> >> >> as
> > > > >>> >> >> > > > well
> > > > >>> >> >> > > > > as the documentation on KNOX-642.
> > > > >>> >> >> > > > >
> > > > >>> >> >> > > > > Is everything ok for the merge?
> > > > >>> >> >> > > > >
> > > > >>> >> >> > > > > Thanks.
> > > > >>> >> >> > > > > Best regards,
> > > > >>> >> >> > > > > Jérôme
> > > > >>> >> >> > > > >
> > > > >>> >> >> > > > >
> > > > >>> >> >> > > > > 2015-12-14 15:28 GMT+01:00 larry mccay <
> > > > >>> larry.mccay@gmail.com>:
> > > > >>> >> >> > > > >
> > > > >>> >> >> > > > > > Hi Jérôme -
> > > > >>> >> >> > > > > >
> > > > >>> >> >> > > > > > Not sure if you saw but I added review comments
> to
> > > > >>> KNOX-641.
> > > > >>> >> >> > > > > >
> > > > >>> >> >> > > > > > I think that we need to determine whether we want
> > the
> > > > >>> >> >> testBasicAuth
> > > > >>> >> >> > > in
> > > > >>> >> >> > > > > the
> > > > >>> >> >> > > > > > provider itself.
> > > > >>> >> >> > > > > >
> > > > >>> >> >> > > > > > Let's follow up on the JIRA.
> > > > >>> >> >> > > > > >
> > > > >>> >> >> > > > > > thanks,
> > > > >>> >> >> > > > > >
> > > > >>> >> >> > > > > > --larry
> > > > >>> >> >> > > > > >
> > > > >>> >> >> > > > > > On Fri, Dec 11, 2015 at 8:44 AM, Jérôme LELEU <
> > > > >>> >> leleuj@gmail.com>
> > > > >>> >> >> > > > wrote:
> > > > >>> >> >> > > > > >
> > > > >>> >> >> > > > > > > Hi,
> > > > >>> >> >> > > > > > >
> > > > >>> >> >> > > > > > > No problem. It can go into a version 0.8.0 if
> > > needed.
> > > > >>> The
> > > > >>> >> truth
> > > > >>> >> >> > is
> > > > >>> >> >> > > > that
> > > > >>> >> >> > > > > > > there is only one change outside the new pac4j
> > > > module,
> > > > >>> so I
> > > > >>> >> >> think
> > > > >>> >> >> > > > risks
> > > > >>> >> >> > > > > > are
> > > > >>> >> >> > > > > > > extremly limited.
> > > > >>> >> >> > > > > > >
> > > > >>> >> >> > > > > > > Just let met know.
> > > > >>> >> >> > > > > > >
> > > > >>> >> >> > > > > > > Thanks.
> > > > >>> >> >> > > > > > > Best regards,
> > > > >>> >> >> > > > > > > Jérôme
> > > > >>> >> >> > > > > > >
> > > > >>> >> >> > > > > > >
> > > > >>> >> >> > > > > > > 2015-12-11 14:23 GMT+01:00 larry mccay <
> > > > >>> >> larry.mccay@gmail.com
> > > > >>> >> >> >:
> > > > >>> >> >> > > > > > >
> > > > >>> >> >> > > > > > > > Hi Jérôme -
> > > > >>> >> >> > > > > > > >
> > > > >>> >> >> > > > > > > > I have unfortunately not had a chance to
> pull,
> > > > >>> review and
> > > > >>> >> >> test
> > > > >>> >> >> > it
> > > > >>> >> >> > > > yet
> > > > >>> >> >> > > > > > and
> > > > >>> >> >> > > > > > > > have intended to do that today.
> > > > >>> >> >> > > > > > > > I apologize for the delay.
> > > > >>> >> >> > > > > > > >
> > > > >>> >> >> > > > > > > > I was actually thinking that this would go
> > into a
> > > > >>> follow
> > > > >>> >> up
> > > > >>> >> >> > > release
> > > > >>> >> >> > > > > > that
> > > > >>> >> >> > > > > > > we
> > > > >>> >> >> > > > > > > > would try and get done rapidly after the
> 0.7.0
> > > > >>> release
> > > > >>> >> but we
> > > > >>> >> >> > can
> > > > >>> >> >> > > > > > discuss
> > > > >>> >> >> > > > > > > > the target and its chances of destabilizing
> > > 0.7.0.
> > > > >>> >> >> > > > > > > >
> > > > >>> >> >> > > > > > > > I believe that it is rather self-contained
> with
> > > > only
> > > > >>> a few
> > > > >>> >> >> > > changes
> > > > >>> >> >> > > > to
> > > > >>> >> >> > > > > > > > external modules.
> > > > >>> >> >> > > > > > > >
> > > > >>> >> >> > > > > > > > Opening the JIRAs is perfect and I was going
> to
> > > do
> > > > >>> that
> > > > >>> >> once
> > > > >>> >> >> I
> > > > >>> >> >> > > > > started
> > > > >>> >> >> > > > > > > the
> > > > >>> >> >> > > > > > > > review.
> > > > >>> >> >> > > > > > > >
> > > > >>> >> >> > > > > > > > Let's continue review comments and
> > collaboration
> > > on
> > > > >>> those
> > > > >>> >> >> > JIRAs.
> > > > >>> >> >> > > > > > > > I will add you to the contributors list so
> that
> > > we
> > > > >>> can
> > > > >>> >> assign
> > > > >>> >> >> > > them
> > > > >>> >> >> > > > to
> > > > >>> >> >> > > > > > > you.
> > > > >>> >> >> > > > > > > >
> > > > >>> >> >> > > > > > > > Thank you for your contributions and your
> > > patience,
> > > > >>> >> Jérôme!
> > > > >>> >> >> > > > > > > >
> > > > >>> >> >> > > > > > > > --larry
> > > > >>> >> >> > > > > > > >
> > > > >>> >> >> > > > > > > > On Fri, Dec 11, 2015 at 3:00 AM, Jérôme
> LELEU <
> > > > >>> >> >> > leleuj@gmail.com>
> > > > >>> >> >> > > > > > wrote:
> > > > >>> >> >> > > > > > > >
> > > > >>> >> >> > > > > > > > > Hi,
> > > > >>> >> >> > > > > > > > >
> > > > >>> >> >> > > > > > > > > I didn't get any new feedback on the pull
> > > request
> > > > >>> so I
> > > > >>> >> >> assume
> > > > >>> >> >> > > > > > > everything
> > > > >>> >> >> > > > > > > > is
> > > > >>> >> >> > > > > > > > > ok from your point of view.
> > > > >>> >> >> > > > > > > > >
> > > > >>> >> >> > > > > > > > > I released pac4j v1.8.1 and j2e-pac4j
> v1.2.1
> > > so I
> > > > >>> >> updated
> > > > >>> >> >> the
> > > > >>> >> >> > > > pull
> > > > >>> >> >> > > > > > > > request
> > > > >>> >> >> > > > > > > > > to use them and successfully re-tested
> > > > everything.
> > > > >>> >> >> > > > > > > > >
> > > > >>> >> >> > > > > > > > > I opened KNOX-641 and submitted the
> > > corresponding
> > > > >>> patch.
> > > > >>> >> >> > > > > > > > >
> > > > >>> >> >> > > > > > > > > I also wrote the documentation, opened
> > KNOX-642
> > > > and
> > > > >>> >> >> submitted
> > > > >>> >> >> > > the
> > > > >>> >> >> > > > > > > > > corresponding patch (just to let you know
> > that
> > > it
> > > > >>> >> doesn't
> > > > >>> >> >> > work
> > > > >>> >> >> > > > out
> > > > >>> >> >> > > > > of
> > > > >>> >> >> > > > > > > the
> > > > >>> >> >> > > > > > > > > box in Windows, I had to replace mvn.bat by
> > > > >>> mvn.cmd to
> > > > >>> >> make
> > > > >>> >> >> > ant
> > > > >>> >> >> > > > > > work).
> > > > >>> >> >> > > > > > > > >
> > > > >>> >> >> > > > > > > > > Even if the branch 0.7.0 has already been
> > > > created,
> > > > >>> I
> > > > >>> >> >> assumed
> > > > >>> >> >> > > this
> > > > >>> >> >> > > > > new
> > > > >>> >> >> > > > > > > > pac4j
> > > > >>> >> >> > > > > > > > > provider will go into this version 0.7.0
> > > > >>> (dependency on
> > > > >>> >> the
> > > > >>> >> >> > > > > > > > 0.7.0-SNAPSHOT
> > > > >>> >> >> > > > > > > > > parent version).
> > > > >>> >> >> > > > > > > > >
> > > > >>> >> >> > > > > > > > > Just let me know if everything is ok and
> when
> > > > it's
> > > > >>> >> goind to
> > > > >>> >> >> > be
> > > > >>> >> >> > > > > > merged.
> > > > >>> >> >> > > > > > > > >
> > > > >>> >> >> > > > > > > > > Thanks.
> > > > >>> >> >> > > > > > > > > Best regards,
> > > > >>> >> >> > > > > > > > > Jérôme
> > > > >>> >> >> > > > > > > > >
> > > > >>> >> >> > > > > > > > >
> > > > >>> >> >> > > > > > > > >
> > > > >>> >> >> > > > > > > > >
> > > > >>> >> >> > > > > > > > > 2015-12-04 14:20 GMT+01:00 larry mccay <
> > > > >>> >> >> > larry.mccay@gmail.com
> > > > >>> >> >> > > >:
> > > > >>> >> >> > > > > > > > >
> > > > >>> >> >> > > > > > > > > > That ability to configure multiple
> > mechanisms
> > > > >>> based on
> > > > >>> >> >> > > > clientName
> > > > >>> >> >> > > > > > is
> > > > >>> >> >> > > > > > > > > really
> > > > >>> >> >> > > > > > > > > > interesting for Knox.
> > > > >>> >> >> > > > > > > > > > Currently, we require separate topologies
> > per
> > > > >>> >> >> > authentication
> > > > >>> >> >> > > > > > > mechanism.
> > > > >>> >> >> > > > > > > > > > The ability to configure them all in one
> is
> > > > >>> really
> > > > >>> >> great.
> > > > >>> >> >> > > > > > > > > >
> > > > >>> >> >> > > > > > > > > > We would need to think through the best
> way
> > > to
> > > > >>> provide
> > > > >>> >> >> the
> > > > >>> >> >> > > > > > clientName
> > > > >>> >> >> > > > > > > > > > parameter.
> > > > >>> >> >> > > > > > > > > > Since this is targeting KnoxSSO it can
> > > actually
> > > > >>> be
> > > > >>> >> added
> > > > >>> >> >> to
> > > > >>> >> >> > > the
> > > > >>> >> >> > > > > > > > > providerURL
> > > > >>> >> >> > > > > > > > > > used to redirect from the participating
> > > > >>> application.
> > > > >>> >> >> > > > > > > > > > Regardless of the authentication
> mechanism
> > > used
> > > > >>> each
> > > > >>> >> >> > > > application
> > > > >>> >> >> > > > > > will
> > > > >>> >> >> > > > > > > > > still
> > > > >>> >> >> > > > > > > > > > get the same JWT based cookie.
> > > > >>> >> >> > > > > > > > > >
> > > > >>> >> >> > > > > > > > > > I think that should work really nicely.
> > > > >>> >> >> > > > > > > > > >
> > > > >>> >> >> > > > > > > > > >
> > > > >>> >> >> > > > > > > > > > On Fri, Dec 4, 2015 at 7:17 AM, larry
> > mccay <
> > > > >>> >> >> > > > > larry.mccay@gmail.com
> > > > >>> >> >> > > > > > >
> > > > >>> >> >> > > > > > > > > wrote:
> > > > >>> >> >> > > > > > > > > >
> > > > >>> >> >> > > > > > > > > > > Excellent, Jérôme.
> > > > >>> >> >> > > > > > > > > > > Thanks!
> > > > >>> >> >> > > > > > > > > > >
> > > > >>> >> >> > > > > > > > > > > On Fri, Dec 4, 2015 at 2:40 AM, Jérôme
> > > LELEU
> > > > <
> > > > >>> >> >> > > > leleuj@gmail.com
> > > > >>> >> >> > > > > >
> > > > >>> >> >> > > > > > > > wrote:
> > > > >>> >> >> > > > > > > > > > >
> > > > >>> >> >> > > > > > > > > > >> Hi,
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > > >> I will write how to configure the
> pac4j
> > > > >>> provider in
> > > > >>> >> >> the
> > > > >>> >> >> > > > > > > > documentation,
> > > > >>> >> >> > > > > > > > > > but
> > > > >>> >> >> > > > > > > > > > >> I can already give you some insights.
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > > >> My main goal is always to respect the
> > key
> > > > >>> design
> > > > >>> >> >> > > principles
> > > > >>> >> >> > > > of
> > > > >>> >> >> > > > > > > pac4j
> > > > >>> >> >> > > > > > > > > > >> whatever the environment / framework
> in
> > > > which
> > > > >>> it is
> > > > >>> >> >> > > > > implemented.
> > > > >>> >> >> > > > > > > For
> > > > >>> >> >> > > > > > > > > > Knox,
> > > > >>> >> >> > > > > > > > > > >> I'm pretty happy with the use of the
> > > > j2e-pac4j
> > > > >>> >> >> library,
> > > > >>> >> >> > > > which
> > > > >>> >> >> > > > > > > means
> > > > >>> >> >> > > > > > > > > that
> > > > >>> >> >> > > > > > > > > > >> almost all the pac4j features are
> > > available,
> > > > >>> >> >> especially
> > > > >>> >> >> > > both
> > > > >>> >> >> > > > > > > direct
> > > > >>> >> >> > > > > > > > > and
> > > > >>> >> >> > > > > > > > > > >> indirect clients. So it can do what
> > Shiro
> > > > >>> already
> > > > >>> >> does
> > > > >>> >> >> > but
> > > > >>> >> >> > > > > also,
> > > > >>> >> >> > > > > > > as
> > > > >>> >> >> > > > > > > > we
> > > > >>> >> >> > > > > > > > > > >> agreed together, supports remote
> > > > >>> authentications.
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > > >> It is only limited by what you can
> > > currently
> > > > >>> >> >> configure.
> > > > >>> >> >> > > And
> > > > >>> >> >> > > > > even
> > > > >>> >> >> > > > > > > > > > >> configuration is a pac4j feature as
> the
> > > CAS
> > > > >>> server
> > > > >>> >> has
> > > > >>> >> >> > the
> > > > >>> >> >> > > > > same
> > > > >>> >> >> > > > > > > > need.
> > > > >>> >> >> > > > > > > > > > >> Everything happens in this class:
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > >
> > > > >>> >> >> > > > > > > > >
> > > > >>> >> >> > > > > > > >
> > > > >>> >> >> > > > > > >
> > > > >>> >> >> > > > > >
> > > > >>> >> >> > > > >
> > > > >>> >> >> > > >
> > > > >>> >> >> > >
> > > > >>> >> >> >
> > > > >>> >> >>
> > > > >>> >>
> > > > >>>
> > > >
> > >
> >
> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java
> > > > >>> >> >> > > > > > > > > > >> ,
> > > > >>> >> >> > > > > > > > > > >> which allows you to configure
> Facebook,
> > > > >>> Twitter, a
> > > > >>> >> CAS
> > > > >>> >> >> > > > > server, a
> > > > >>> >> >> > > > > > > > SAML
> > > > >>> >> >> > > > > > > > > > IdP
> > > > >>> >> >> > > > > > > > > > >> or an OpenID Connect provider. All the
> > > > >>> provided
> > > > >>> >> >> > parameters
> > > > >>> >> >> > > > to
> > > > >>> >> >> > > > > > the
> > > > >>> >> >> > > > > > > > > pac4j
> > > > >>> >> >> > > > > > > > > > >> provider are put into a Map and the
> > > > >>> >> >> > > ConfigPropertiesFactory
> > > > >>> >> >> > > > is
> > > > >>> >> >> > > > > > > built
> > > > >>> >> >> > > > > > > > > > with
> > > > >>> >> >> > > > > > > > > > >> this Map to return the built client (=
> > > > >>> >> authentication
> > > > >>> >> >> > > > > > mechanism).
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > > >> You have one more specific option for
> > Knox
> > > > as
> > > > >>> a
> > > > >>> >> basic
> > > > >>> >> >> > > > > > > authentication
> > > > >>> >> >> > > > > > > > > > popup
> > > > >>> >> >> > > > > > > > > > >> where the username must match the
> > > password,
> > > > >>> you can
> > > > >>> >> >> > define
> > > > >>> >> >> > > > > that
> > > > >>> >> >> > > > > > > by:
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > > >> <param>
> > > > >>> >> >> > > > > > > > > > >> <name>clientName</name>
> > > > >>> >> >> > > > > > > > > > >> <value>testBasicAuth</value>
> > > > >>> >> >> > > > > > > > > > >> </param>
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > > >> It's for testing only.
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > > >> For a CAS server:
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > > >> <param>
> > > > >>> >> >> > > > > > > > > > >> <name>cas.loginUrl</name>
> > > > >>> >> >> > > > > > > > > > >> <value>
> > > > >>> >> https://casserverpac4j.herokuapp.com/login
> > > > >>> >> >> > > </value>
> > > > >>> >> >> > > > > > > > > > >> </param>
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > > >> Here are all the properties available
> > for
> > > > >>> building
> > > > >>> >> >> > clients
> > > > >>> >> >> > > > > > (their
> > > > >>> >> >> > > > > > > > > > meaning
> > > > >>> >> >> > > > > > > > > > >> is obvious):
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > > >> facebook.id
> > > > >>> >> >> > > > > > > > > > >> facebook.secret
> > > > >>> >> >> > > > > > > > > > >> facebook.scope
> > > > >>> >> >> > > > > > > > > > >> facebook.fields
> > > > >>> >> >> > > > > > > > > > >> twitter.id
> > > > >>> >> >> > > > > > > > > > >> twitter.secret
> > > > >>> >> >> > > > > > > > > > >> saml.keystorePassword
> > > > >>> >> >> > > > > > > > > > >> saml.privateKeyPassword
> > > > >>> >> >> > > > > > > > > > >> saml.keystorePath
> > > > >>> >> >> > > > > > > > > > >> saml.identityProviderMetadataPath
> > > > >>> >> >> > > > > > > > > > >> saml.maximumAuthenticationLifetime
> > > > >>> >> >> > > > > > > > > > >> saml.serviceProviderEntityId
> > > > >>> >> >> > > > > > > > > > >> saml.serviceProviderMetadataPath
> > > > >>> >> >> > > > > > > > > > >> cas.loginUrl
> > > > >>> >> >> > > > > > > > > > >> cas.protocol
> > > > >>> >> >> > > > > > > > > > >> oidc.id
> > > > >>> >> >> > > > > > > > > > >> oidc.secret
> > > > >>> >> >> > > > > > > > > > >> oidc.discoveryUri
> > > > >>> >> >> > > > > > > > > > >> oidc.customParamKey1
> > > > >>> >> >> > > > > > > > > > >> oidc.customParamValue1
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > > >> If you define multiple clients, the
> > first
> > > > one
> > > > >>> will
> > > > >>> >> be
> > > > >>> >> >> > used
> > > > >>> >> >> > > > for
> > > > >>> >> >> > > > > > > > > > >> authentication, but you can explicitly
> > > > choose
> > > > >>> the
> > > > >>> >> >> client
> > > > >>> >> >> > > you
> > > > >>> >> >> > > > > > want
> > > > >>> >> >> > > > > > > to
> > > > >>> >> >> > > > > > > > > use
> > > > >>> >> >> > > > > > > > > > >> via the clientName parameter, assuming
> > you
> > > > >>> want to
> > > > >>> >> >> > switch
> > > > >>> >> >> > > > from
> > > > >>> >> >> > > > > > > > client
> > > > >>> >> >> > > > > > > > > > >> depending on environment for example.
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > > >> So if you want to add some new
> > > > authentication
> > > > >>> >> >> mechanism,
> > > > >>> >> >> > > you
> > > > >>> >> >> > > > > > must
> > > > >>> >> >> > > > > > > > > first
> > > > >>> >> >> > > > > > > > > > >> check that it is available in pac4j
> (if
> > > it's
> > > > >>> not,
> > > > >>> >> it's
> > > > >>> >> >> > > > another
> > > > >>> >> >> > > > > > > > > > discussion,
> > > > >>> >> >> > > > > > > > > > >> but generally, it is). Then, you'll
> need
> > > to
> > > > >>> upgrade
> > > > >>> >> >> the
> > > > >>> >> >> > > > > > > > > > >> ConfigPropertiesFactory by submitting
> a
> > > new
> > > > >>> pull
> > > > >>> >> >> request
> > > > >>> >> >> > > to
> > > > >>> >> >> > > > > the
> > > > >>> >> >> > > > > > > > pac4j
> > > > >>> >> >> > > > > > > > > > >> project (I can do it myself, but I'm
> > sure
> > > > you
> > > > >>> >> could do
> > > > >>> >> >> > > that
> > > > >>> >> >> > > > > > > easily),
> > > > >>> >> >> > > > > > > > > > >> finally wait for the new pac4j release
> > and
> > > > >>> switch
> > > > >>> >> >> pac4j
> > > > >>> >> >> > > > > versions
> > > > >>> >> >> > > > > > > in
> > > > >>> >> >> > > > > > > > > Knox
> > > > >>> >> >> > > > > > > > > > >> to
> > > > >>> >> >> > > > > > > > > > >> benefit from the new feature.
> > > > >>> >> >> > > > > > > > > > >> The good thing is that if someone
> > related
> > > to
> > > > >>> the
> > > > >>> >> CAS
> > > > >>> >> >> > > server
> > > > >>> >> >> > > > > does
> > > > >>> >> >> > > > > > > the
> > > > >>> >> >> > > > > > > > > > same
> > > > >>> >> >> > > > > > > > > > >> thing for CAS (in pac4j), you will
> > > > >>> automatically
> > > > >>> >> get
> > > > >>> >> >> it
> > > > >>> >> >> > > when
> > > > >>> >> >> > > > > > > you'll
> > > > >>> >> >> > > > > > > > > > >> upgrade
> > > > >>> >> >> > > > > > > > > > >> pac4j.
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > > >> To go even further, replacing LDAP
> Shiro
> > > > >>> >> >> authentication
> > > > >>> >> >> > is
> > > > >>> >> >> > > > > just
> > > > >>> >> >> > > > > > a
> > > > >>> >> >> > > > > > > > > matter
> > > > >>> >> >> > > > > > > > > > >> of
> > > > >>> >> >> > > > > > > > > > >> making pac4j LDAP authentication
> > available
> > > > via
> > > > >>> >> >> > > configuration
> > > > >>> >> >> > > > > > > > > parameters.
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > > >> I hope it was clear enough.
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > > >> Thanks.
> > > > >>> >> >> > > > > > > > > > >> Best regards,
> > > > >>> >> >> > > > > > > > > > >> Jérôme
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > > >> 2015-12-03 20:45 GMT+01:00 larry
> mccay <
> > > > >>> >> >> > > > larry.mccay@gmail.com
> > > > >>> >> >> > > > > >:
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > > >> > Excellent!
> > > > >>> >> >> > > > > > > > > > >> >
> > > > >>> >> >> > > > > > > > > > >> > I will carve out some time to do
> code
> > > > >>> review.
> > > > >>> >> >> > > > > > > > > > >> > We will need to get some insights
> into
> > > how
> > > > >>> to go
> > > > >>> >> >> about
> > > > >>> >> >> > > > > > testing:
> > > > >>> >> >> > > > > > > > > > >> >
> > > > >>> >> >> > > > > > > > > > >> > * is the CAS server going to be
> > > available
> > > > >>> for
> > > > >>> >> >> testing?
> > > > >>> >> >> > > > > > > > > > >> > * what are the specific and
> > > > >>> generic/standard (if
> > > > >>> >> >> any)
> > > > >>> >> >> > > > > > > > authentication
> > > > >>> >> >> > > > > > > > > > >> > mechanisms available - for instance:
> > > > >>> >> >> > > > > > > > > > >> > - Facebook, Google, LinkedIn and
> > CAS
> > > > are
> > > > >>> >> >> specifics
> > > > >>> >> >> > > > > > > > > > >> > - OAuth 2, OpenID Connect, SAML
> > are
> > > > >>> >> >> > > generic/standards
> > > > >>> >> >> > > > -
> > > > >>> >> >> > > > > > that
> > > > >>> >> >> > > > > > > > may
> > > > >>> >> >> > > > > > > > > > be
> > > > >>> >> >> > > > > > > > > > >> > used for the above specifics...
> > > > >>> >> >> > > > > > > > > > >> > * how do we test things other than
> > CAS -
> > > > in
> > > > >>> >> terms of
> > > > >>> >> >> > > > getting
> > > > >>> >> >> > > > > > > > > > >> credentials,
> > > > >>> >> >> > > > > > > > > > >> > configuration, etc
> > > > >>> >> >> > > > > > > > > > >> >
> > > > >>> >> >> > > > > > > > > > >> > We could certainly do this is phases
> > as
> > > > >>> well.
> > > > >>> >> >> > > > > > > > > > >> >
> > > > >>> >> >> > > > > > > > > > >> > If you can enumerate the things that
> > > > should
> > > > >>> work
> > > > >>> >> and
> > > > >>> >> >> > > > provide
> > > > >>> >> >> > > > > > > some
> > > > >>> >> >> > > > > > > > > > >> testing
> > > > >>> >> >> > > > > > > > > > >> > details for CAS or as many as
> possible
> > > and
> > > > >>> OpenID
> > > > >>> >> >> > > Connect
> > > > >>> >> >> > > > > then
> > > > >>> >> >> > > > > > > we
> > > > >>> >> >> > > > > > > > > can
> > > > >>> >> >> > > > > > > > > > >> test
> > > > >>> >> >> > > > > > > > > > >> > the specific implementations that
> you
> > > > >>> provide and
> > > > >>> >> >> > enable
> > > > >>> >> >> > > > the
> > > > >>> >> >> > > > > > > > testing
> > > > >>> >> >> > > > > > > > > > of
> > > > >>> >> >> > > > > > > > > > >> > another OpenID Connect effort that
> is
> > in
> > > > the
> > > > >>> >> works
> > > > >>> >> >> in
> > > > >>> >> >> > > the
> > > > >>> >> >> > > > > > > > community.
> > > > >>> >> >> > > > > > > > > > >> >
> > > > >>> >> >> > > > > > > > > > >> > I'm not sure whether we want to
> commit
> > > > >>> >> contributions
> > > > >>> >> >> > > that
> > > > >>> >> >> > > > > are
> > > > >>> >> >> > > > > > > > > > dependent
> > > > >>> >> >> > > > > > > > > > >> on
> > > > >>> >> >> > > > > > > > > > >> > snapshots - we certainly can't
> release
> > > > with
> > > > >>> any
> > > > >>> >> such
> > > > >>> >> >> > > > > > > dependencies.
> > > > >>> >> >> > > > > > > > > > >> > I would hate to add a cleanup task
> to
> > a
> > > > >>> release
> > > > >>> >> to
> > > > >>> >> >> > make
> > > > >>> >> >> > > > sure
> > > > >>> >> >> > > > > > > there
> > > > >>> >> >> > > > > > > > > are
> > > > >>> >> >> > > > > > > > > > >> no
> > > > >>> >> >> > > > > > > > > > >> > snapshots in there.
> > > > >>> >> >> > > > > > > > > > >> > We will probably wait until after
> the
> > > > pac4j
> > > > >>> >> releases
> > > > >>> >> >> > to
> > > > >>> >> >> > > > > > commit.
> > > > >>> >> >> > > > > > > > > > >> >
> > > > >>> >> >> > > > > > > > > > >> > I am really happy that this
> > integration
> > > is
> > > > >>> >> happening
> > > > >>> >> >> > and
> > > > >>> >> >> > > > > that
> > > > >>> >> >> > > > > > it
> > > > >>> >> >> > > > > > > > > went
> > > > >>> >> >> > > > > > > > > > >> > rather smoothly.
> > > > >>> >> >> > > > > > > > > > >> > These sorts of authentication
> > protocols
> > > > are
> > > > >>> >> complex
> > > > >>> >> >> > and
> > > > >>> >> >> > > I
> > > > >>> >> >> > > > > > think
> > > > >>> >> >> > > > > > > we
> > > > >>> >> >> > > > > > > > > > >> lined up
> > > > >>> >> >> > > > > > > > > > >> > pretty well overall.
> > > > >>> >> >> > > > > > > > > > >> >
> > > > >>> >> >> > > > > > > > > > >> > Thanks for your work!
> > > > >>> >> >> > > > > > > > > > >> >
> > > > >>> >> >> > > > > > > > > > >> > On Thu, Dec 3, 2015 at 2:28 PM,
> Jérôme
> > > > >>> LELEU <
> > > > >>> >> >> > > > > > leleuj@gmail.com>
> > > > >>> >> >> > > > > > > > > > wrote:
> > > > >>> >> >> > > > > > > > > > >> >
> > > > >>> >> >> > > > > > > > > > >> > > Hi,
> > > > >>> >> >> > > > > > > > > > >> > >
> > > > >>> >> >> > > > > > > > > > >> > > I just sync'ed with master,
> cleaned
> > > > >>> >> dependencies
> > > > >>> >> >> and
> > > > >>> >> >> > > > added
> > > > >>> >> >> > > > > > > > missing
> > > > >>> >> >> > > > > > > > > > >> > > Javadocs. Everything works
> correctly
> > > > now.
> > > > >>> Many
> > > > >>> >> >> > thanks.
> > > > >>> >> >> > > > > > > > > > >> > >
> > > > >>> >> >> > > > > > > > > > >> > > The pull request is ready for a
> full
> > > > code
> > > > >>> >> review:
> > > > >>> >> >> > > > > > > > > > >> > >
> > https://github.com/apache/knox/pull/2
> > > > >>> >> >> > > > > > > > > > >> > >
> > > > >>> >> >> > > > > > > > > > >> > > I'll write the documentation after
> > the
> > > > >>> pac4j
> > > > >>> >> >> > releases
> > > > >>> >> >> > > (I
> > > > >>> >> >> > > > > > hope
> > > > >>> >> >> > > > > > > > next
> > > > >>> >> >> > > > > > > > > > >> week).
> > > > >>> >> >> > > > > > > > > > >> > >
> > > > >>> >> >> > > > > > > > > > >> > > Thanks.
> > > > >>> >> >> > > > > > > > > > >> > > Best regards,
> > > > >>> >> >> > > > > > > > > > >> > > Jérôme
> > > > >>> >> >> > > > > > > > > > >> > >
> > > > >>> >> >> > > > > > > > > > >> > >
> > > > >>> >> >> > > > > > > > > > >> > > 2015-12-02 19:18 GMT+01:00 larry
> > > mccay <
> > > > >>> >> >> > > > > > larry.mccay@gmail.com
> > > > >>> >> >> > > > > > > >:
> > > > >>> >> >> > > > > > > > > > >> > >
> > > > >>> >> >> > > > > > > > > > >> > > > Fixed in
> > > > >>> >> >> > > > https://issues.apache.org/jira/browse/KNOX-636
> > > > >>> >> >> > > > > .
> > > > >>> >> >> > > > > > > > > > >> > > >
> > > > >>> >> >> > > > > > > > > > >> > > > On Wed, Dec 2, 2015 at 12:42 PM,
> > > larry
> > > > >>> mccay
> > > > >>> >> <
> > > > >>> >> >> > > > > > > > > > larry.mccay@gmail.com
> > > > >>> >> >> > > > > > > > > > >> >
> > > > >>> >> >> > > > > > > > > > >> > > > wrote:
> > > > >>> >> >> > > > > > > > > > >> > > >
> > > > >>> >> >> > > > > > > > > > >> > > > > Sure - I can file a JIRA and
> > > commit
> > > > a
> > > > >>> fix.
> > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > >>> >> >> > > > > > > > > > >> > > > > The secret generation should
> be
> > > done
> > > > >>> in one
> > > > >>> >> >> > > instance
> > > > >>> >> >> > > > > and
> > > > >>> >> >> > > > > > > > > > >> replicated
> > > > >>> >> >> > > > > > > > > > >> > > > across
> > > > >>> >> >> > > > > > > > > > >> > > > > others.
> > > > >>> >> >> > > > > > > > > > >> > > > > This replication/management of
> > the
> > > > >>> >> credential
> > > > >>> >> >> > > stores
> > > > >>> >> >> > > > > is
> > > > >>> >> >> > > > > > > > > outside
> > > > >>> >> >> > > > > > > > > > of
> > > > >>> >> >> > > > > > > > > > >> > the
> > > > >>> >> >> > > > > > > > > > >> > > > > scope of Knox itself as of
> now.
> > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > >>> >> >> > > > > > > > > > >> > > > > Documentation is done in
> > markdown
> > > > and
> > > > >>> is
> > > > >>> >> >> > > > contributing
> > > > >>> >> >> > > > > > > > details
> > > > >>> >> >> > > > > > > > > > are
> > > > >>> >> >> > > > > > > > > > >> > > > > available at:
> > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > >>> >> >> > > > > > > > > > >> > > >
> > > > >>> >> >> > > > > > > > > > >> > >
> > > > >>> >> >> > > > > > > > > > >> >
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > >
> > > > >>> >> >> > > > > > > > >
> > > > >>> >> >> > > > > > > >
> > > > >>> >> >> > > > > > >
> > > > >>> >> >> > > > > >
> > > > >>> >> >> > > > >
> > > > >>> >> >> > > >
> > > > >>> >> >> > >
> > > > >>> >> >> >
> > > > >>> >> >>
> > > > >>> >>
> > > > >>>
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
> > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > >>> >> >> > > > > > > > > > >> > > > > Which should give you a
> general
> > > > idea.
> > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > >>> >> >> > > > > > > > > > >> > > > > Find an example like:
> > > > >>> ./trunk/books/0.7.0/
> > > > >>> >> >> > > > > > > > > > >> > > config_preauth_sso_provider.md
> > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > >>> >> >> > > > > > > > > > >> > > > > For an example of typical
> > content
> > > > and
> > > > >>> >> format.
> > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > >>> >> >> > > > > > > > > > >> > > > > Here is how that example
> > renders:
> > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > >>> >> >> > > > > > > > > > >> > > >
> > > > >>> >> >> > > > > > > > > > >> > >
> > > > >>> >> >> > > > > > > > > > >> >
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > >
> > > > >>> >> >> > > > > > > > >
> > > > >>> >> >> > > > > > > >
> > > > >>> >> >> > > > > > >
> > > > >>> >> >> > > > > >
> > > > >>> >> >> > > > >
> > > > >>> >> >> > > >
> > > > >>> >> >> > >
> > > > >>> >> >> >
> > > > >>> >> >>
> > > > >>> >>
> > > > >>>
> > > >
> > >
> >
> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
> > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > >>> >> >> > > > > > > > > > >> > > > > You'll need to tie it into the
> > > rest
> > > > >>> of the
> > > > >>> >> >> book
> > > > >>> >> >> > -
> > > > >>> >> >> > > > just
> > > > >>> >> >> > > > > > > grep
> > > > >>> >> >> > > > > > > > > for
> > > > >>> >> >> > > > > > > > > > >> where
> > > > >>> >> >> > > > > > > > > > >> > > > that
> > > > >>> >> >> > > > > > > > > > >> > > > > filename is referenced.
> > > > >>> >> >> > > > > > > > > > >> > > > > To test how it renders build
> the
> > > > site
> > > > >>> with:
> > > > >>> >> >> > "ant"
> > > > >>> >> >> > > > and
> > > > >>> >> >> > > > > > note
> > > > >>> >> >> > > > > > > > the
> > > > >>> >> >> > > > > > > > > > >> url to
> > > > >>> >> >> > > > > > > > > > >> > > the
> > > > >>> >> >> > > > > > > > > > >> > > > > 0.7.0 book.
> > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > >>> >> >> > > > > > > > > > >> > > > > On Wed, Dec 2, 2015 at 12:12
> PM,
> > > > >>> Jérôme
> > > > >>> >> LELEU
> > > > >>> >> >> <
> > > > >>> >> >> > > > > > > > > leleuj@gmail.com
> > > > >>> >> >> > > > > > > > > > >
> > > > >>> >> >> > > > > > > > > > >> > > wrote:
> > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > >>> >> >> > > > > > > > > > >> > > > >> Hi,
> > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > >>> >> >> > > > > > > > > > >> > > > >> Why it doesn't work for pac4j
> > > while
> > > > >>> it
> > > > >>> >> works
> > > > >>> >> >> > for
> > > > >>> >> >> > > > > others
> > > > >>> >> >> > > > > > > is
> > > > >>> >> >> > > > > > > > a
> > > > >>> >> >> > > > > > > > > > bit
> > > > >>> >> >> > > > > > > > > > >> > > strange
> > > > >>> >> >> > > > > > > > > > >> > > > >> to
> > > > >>> >> >> > > > > > > > > > >> > > > >> me, but if you have the patch
> > in
> > > > >>> front of
> > > > >>> >> >> your
> > > > >>> >> >> > > > eyes,
> > > > >>> >> >> > > > > > I'd
> > > > >>> >> >> > > > > > > > > rather
> > > > >>> >> >> > > > > > > > > > >> > prefer
> > > > >>> >> >> > > > > > > > > > >> > > > you
> > > > >>> >> >> > > > > > > > > > >> > > > >> to commit it. In all cases,
> > I'll
> > > > >>> sync with
> > > > >>> >> >> the
> > > > >>> >> >> > > > > master.
> > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > >>> >> >> > > > > > > > > > >> > > > >> There was one question you
> > didn't
> > > > >>> answer
> > > > >>> >> >> > > > previously:
> > > > >>> >> >> > > > > is
> > > > >>> >> >> > > > > > > the
> > > > >>> >> >> > > > > > > > > > >> password
> > > > >>> >> >> > > > > > > > > > >> > > > >> generated for the pac4j
> > provider
> > > > the
> > > > >>> same
> > > > >>> >> >> > across
> > > > >>> >> >> > > > all
> > > > >>> >> >> > > > > > > > gateway
> > > > >>> >> >> > > > > > > > > > >> > > instances?
> > > > >>> >> >> > > > > > > > > > >> > > > >> Because I expect to have the
> > same
> > > > >>> value
> > > > >>> >> as I
> > > > >>> >> >> > use
> > > > >>> >> >> > > it
> > > > >>> >> >> > > > > to
> > > > >>> >> >> > > > > > > > > encrypt
> > > > >>> >> >> > > > > > > > > > /
> > > > >>> >> >> > > > > > > > > > >> > > decrypt
> > > > >>> >> >> > > > > > > > > > >> > > > >> data.
> > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > >>> >> >> > > > > > > > > > >> > > > >> I will add the Javadoc. After
> > > that,
> > > > >>> you
> > > > >>> >> can
> > > > >>> >> >> > > review
> > > > >>> >> >> > > > > the
> > > > >>> >> >> > > > > > > pull
> > > > >>> >> >> > > > > > > > > > >> request
> > > > >>> >> >> > > > > > > > > > >> > > more
> > > > >>> >> >> > > > > > > > > > >> > > > >> completely.
> > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > >>> >> >> > > > > > > > > > >> > > > >> What do you expect for the
> > > > >>> documentation?
> > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > >>> >> >> > > > > > > > > > >> > > > >> Notice that pac4j
> dependencies
> > > are
> > > > >>> still
> > > > >>> >> >> > > snapshots,
> > > > >>> >> >> > > > > but
> > > > >>> >> >> > > > > > > > they
> > > > >>> >> >> > > > > > > > > > >> will be
> > > > >>> >> >> > > > > > > > > > >> > > > >> released in a week or two.
> > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > >>> >> >> > > > > > > > > > >> > > > >> Thanks.
> > > > >>> >> >> > > > > > > > > > >> > > > >> Best regards,
> > > > >>> >> >> > > > > > > > > > >> > > > >> Jérôme
> > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > >>> >> >> > > > > > > > > > >> > > > >> 2015-12-02 17:51 GMT+01:00
> > larry
> > > > >>> mccay <
> > > > >>> >> >> > > > > > > > > larry.mccay@gmail.com
> > > > >>> >> >> > > > > > > > > > >:
> > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > >>> >> >> > > > > > > > > > >> > > > >> > Jérôme -
> > > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > If you would like to add
> that
> > > > >>> change as
> > > > >>> >> >> part
> > > > >>> >> >> > of
> > > > >>> >> >> > > > > your
> > > > >>> >> >> > > > > > > > patch
> > > > >>> >> >> > > > > > > > > or
> > > > >>> >> >> > > > > > > > > > >> as a
> > > > >>> >> >> > > > > > > > > > >> > > > >> > separately filed JIRA to
> fix
> > a
> > > > bug
> > > > >>> that
> > > > >>> >> >> would
> > > > >>> >> >> > > > > > certainly
> > > > >>> >> >> > > > > > > > be
> > > > >>> >> >> > > > > > > > > > >> > welcomed.
> > > > >>> >> >> > > > > > > > > > >> > > > >> > Otherwise, I can do it.
> > > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > Let me know.
> > > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > thanks,
> > > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > --larry
> > > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > On Wed, Dec 2, 2015 at
> 11:44
> > > AM,
> > > > >>> larry
> > > > >>> >> >> mccay
> > > > >>> >> >> > <
> > > > >>> >> >> > > > > > > > > > >> > larry.mccay@gmail.com
> > > > >>> >> >> > > > > > > > > > >> > > >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > wrote:
> > > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > > Okay - I had to add an
> > > override
> > > > >>> of
> > > > >>> >> >> > > > > > getUserPrincipal()
> > > > >>> >> >> > > > > > > > to
> > > > >>> >> >> > > > > > > > > > the
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >
> > > > >>> >> IdentityAsserterHttpServletRequestWrapper
> > > > >>> >> >> > and
> > > > >>> >> >> > > > > > return
> > > > >>> >> >> > > > > > > > the
> > > > >>> >> >> > > > > > > > > > >> member
> > > > >>> >> >> > > > > > > > > > >> > > > >> variable
> > > > >>> >> >> > > > > > > > > > >> > > > >> > > username and it works
> like
> > a
> > > > >>> charm.
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > > Why I haven't seen this
> > same
> > > > >>> behavior
> > > > >>> >> >> with
> > > > >>> >> >> > > > other
> > > > >>> >> >> > > > > > > > > providers
> > > > >>> >> >> > > > > > > > > > >> is a
> > > > >>> >> >> > > > > > > > > > >> > > bit
> > > > >>> >> >> > > > > > > > > > >> > > > >> of a
> > > > >>> >> >> > > > > > > > > > >> > > > >> > > mystery but they must be
> > > adding
> > > > >>> other
> > > > >>> >> >> > > wrappers
> > > > >>> >> >> > > > > that
> > > > >>> >> >> > > > > > > > > handle
> > > > >>> >> >> > > > > > > > > > >> it.
> > > > >>> >> >> > > > > > > > > > >> > > > >> > > This is quite cool,
> Jérôme!
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > > On Wed, Dec 2, 2015 at
> > 10:41
> > > > AM,
> > > > >>> larry
> > > > >>> >> >> > mccay
> > > > >>> >> >> > > <
> > > > >>> >> >> > > > > > > > > > >> > > larry.mccay@gmail.com
> > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > > wrote:
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >> That was it - thanks!
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >> On Wed, Dec 2, 2015 at
> > 10:20
> > > > AM,
> > > > >>> >> Jérôme
> > > > >>> >> >> > > LELEU
> > > > >>> >> >> > > > <
> > > > >>> >> >> > > > > > > > > > >> > leleuj@gmail.com>
> > > > >>> >> >> > > > > > > > > > >> > > > >> wrote:
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> This is my exact
> command
> > > > line:
> > > > >>> mvn
> > > > >>> >> >> > > -Prelease
> > > > >>> >> >> > > > > > clean
> > > > >>> >> >> > > > > > > > > > install
> > > > >>> >> >> > > > > > > > > > >> > > > >> -DskipTests
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> You use an internal
> Maven
> > > > >>> >> repository to
> > > > >>> >> >> > > fetch
> > > > >>> >> >> > > > > > > > > > dependencies
> > > > >>> >> >> > > > > > > > > > >> > from
> > > > >>> >> >> > > > > > > > > > >> > > > >> > internet:
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > > >>> >> >> > > > > > > > > > >> > >
> > > > >>> >> >> > > > > > > >
> > > > >>> >> >> > >
> > > > >>>
> http://nexus-private.hortonworks.com/nexus/content/groups/public/
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> Does this repository
> have
> > > > >>> access to
> > > > >>> >> the
> > > > >>> >> >> > > > remote
> > > > >>> >> >> > > > > > > > > Snapshots
> > > > >>> >> >> > > > > > > > > > >> > > Sonatype
> > > > >>> >> >> > > > > > > > > > >> > > > >> repo?
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> 2015-12-02 16:16
> > GMT+01:00
> > > > >>> larry
> > > > >>> >> mccay
> > > > >>> >> >> <
> > > > >>> >> >> > > > > > > > > > >> larry.mccay@gmail.com
> > > > >>> >> >> > > > > > > > > > >> > >:
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > hmmm - I used:
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > mvn clean install
> > > > >>> -DskipTests=true
> > > > >>> >> >> > > > -Prelease
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > The repository entry
> is
> > > in
> > > > >>> there
> > > > >>> >> >> > already.
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > No worky.
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > On Wed, Dec 2, 2015
> at
> > > > 10:12
> > > > >>> AM,
> > > > >>> >> >> Jérôme
> > > > >>> >> >> > > > > LELEU <
> > > > >>> >> >> > > > > > > > > > >> > > leleuj@gmail.com
> > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> wrote:
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Hi,
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > You need the
> > j2e-pac4j
> > > > >>> >> dependencies
> > > > >>> >> >> > as
> > > > >>> >> >> > > > well
> > > > >>> >> >> > > > > > as
> > > > >>> >> >> > > > > > > > the
> > > > >>> >> >> > > > > > > > > > >> pac4j-*
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> dependencies,
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > but you don't need
> to
> > > > >>> build them
> > > > >>> >> >> > > locally
> > > > >>> >> >> > > > > > > > > (hopefully).
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > But you need a
> > > dependency
> > > > >>> on the
> > > > >>> >> >> > > Sonatype
> > > > >>> >> >> > > > > > > > snapshots
> > > > >>> >> >> > > > > > > > > > >> > > repository
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> (where the
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > snapshot versions
> are
> > > > >>> hosted),
> > > > >>> >> >> which
> > > > >>> >> >> > is
> > > > >>> >> >> > > > > added
> > > > >>> >> >> > > > > > > for
> > > > >>> >> >> > > > > > > > > > >> Maven in
> > > > >>> >> >> > > > > > > > > > >> > > the
> > > > >>> >> >> > > > > > > > > > >> > > > >> root
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > pom.xml:
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > >>> >> >> > > > > > > > > > >> > > >
> > > > >>> >> >> > > > > > > > > > >> > >
> > > > >>> >> >> > > > > > > > > > >> >
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > >
> > > > >>> >> >> > > > > > > > >
> > > > >>> >> >> > > > > > > >
> > > > >>> >> >> > > > > > >
> > > > >>> >> >> > > > > >
> > > > >>> >> >> > > > >
> > > > >>> >> >> > > >
> > > > >>> >> >> > >
> > > > >>> >> >> >
> > > > >>> >> >>
> > > > >>> >>
> > > > >>>
> > > >
> > >
> >
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > If you use Ant for
> > the
> > > > >>> build,
> > > > >>> >> there
> > > > >>> >> >> > is
> > > > >>> >> >> > > > > maybe
> > > > >>> >> >> > > > > > a
> > > > >>> >> >> > > > > > > > > glitch
> > > > >>> >> >> > > > > > > > > > >> to
> > > > >>> >> >> > > > > > > > > > >> > > find
> > > > >>> >> >> > > > > > > > > > >> > > > >> the
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > Sonatype
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Maven repo.
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Thanks.
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Best regards,
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Jérôme
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > 2015-12-02 16:06
> > > > GMT+01:00
> > > > >>> larry
> > > > >>> >> >> > mccay
> > > > >>> >> >> > > <
> > > > >>> >> >> > > > > > > > > > >> > > larry.mccay@gmail.com
> > > > >>> >> >> > > > > > > > > > >> > > > >:
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > 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.mccay@gmail.com>
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > wrote:
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > >
> > > > >>> >> gateway-provider-security-pac4j
> > > > >>> >> >> > > > doesn't
> > > > >>> >> >> > > > > > > > build -
> > > > >>> >> >> > > > > > > > > > do
> > > > >>> >> >> > > > > > > > > > >> you
> > > > >>> >> >> > > > > > > > > > >> > > > have
> > > > >>> >> >> > > > > > > > > > >> > > > >> a
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> pending
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > > change for your
> > > > >>> pom.xml or
> > > > >>> >> >> > > something?
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >>
> > > > >>> >> >> > > > > > > > > > >> > > > >> > >
> > > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > > >>> >> >> > > > > > > > > > >> > > > >>
> > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > >>> >> >> > > > > > > > > > >> > > > >
> > > > >>> >> >> > > > > > > > > > >> > > >
> > > > >>> >> >> > > > > > > > > > >> > >
> > > > >>> >> >> > > > > > > > > > >> >
> > > > >>> >> >> > > > > > > > > > >>
> > > > >>> >> >> > > > > > > > > > >
> > > > >>> >> >> > > > > > > > > > >
> > > > >>> >> >> > > > > > > > > >
> > > > >>> >> >> > > > > > > > >
> > > > >>> >> >> > > > > > > >
> > > > >>> >> >> > > > > > >
> > > > >>> >> >> > > > > >
> > > > >>> >> >> > > > >
> > > > >>> >> >> > > >
> > > > >>> >> >> > >
> > > > >>> >> >> >
> > > > >>> >> >>
> > > > >>> >>
> > > > >>>
> > > > >>
> > > > >>
> > > > >
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Hi,
I just uploaded a new patch for the documentation with the links pointing
to the pac4j wiki. It should be clearer.
Thanks.
Best regards,
Jérôme
2016-01-14 13:20 GMT+01:00 larry mccay <lm...@apache.org>:
> That sounds pretty reasonable.
> I will likely document a few of the integrations that are possible in
> blogs/tutorials anyway.
>
> I don't want testing of Knox at release time to have to jump around to much
> in order to be able to test.
> I think we can make that all good though.
>
> I will see what I can do with okta today.
>
> On Thu, Jan 14, 2016 at 5:00 AM, Jérôme LELEU <le...@gmail.com> wrote:
>
> > Hi,
> >
> > Yes, the documentation is a bit too light. But you guessed it right: we
> > need to have a keystore for encryption.
> >
> > The saml.identityProviderMetadataPath can point to a local resource or
> to a
> > remote one, using the right prefix: resource:, file: or an url (by
> default,
> > it is a file path). This must be documented though.
> >
> > With Okta, I used the defined url (Single Sign On URL = Recipient URL =
> > Destination URL) for the serviceProviderEntityId, but I think it may
> > depends on IdP as well. Reading the spec, it must be an URI, but I'm not
> > sure if the SP metadata should be really available on this url. For Okta,
> > it doesn't matter.
> >
> > According to your SAML configuration, the SP metadata will be generated
> > somewhere and this somewhere can be defined via the
> > serviceProviderMetadataPath parameter. You generally need to update your
> > metadata to the IdP (not required for Okta though). Both the SP and IdP
> > must know each other.
> >
> > When writing the documentation, I went fast on these parameters with the
> > feeling they were regular ones, but indeed, the description in the Knox
> > manual is not enough. This is somehow a bit normal as the real
> > documentation for SAML is on the SAML wiki:
> > https://github.com/pac4j/pac4j/wiki/Clients#details-for-saml-support
> >
> > So I propose to keep the Knox documentation mostly "as is", but add links
> > to the pac4j wiki (where I could more easily made updates). All pac4j
> > integrations need this documentation so it's better to centralize it,
> from
> > my point of view. What do you think?
> >
> > Thanks.
> > Best regards,
> > Jérôme
> >
> >
> >
> > 2016-01-13 19:37 GMT+01:00 larry mccay <lm...@apache.org>:
> >
> > > Hi Jérôme -
> > >
> > > I'm trying to configure the pac4j provider for an okta "application"
> > that I
> > > created.
> > > The following (from KNOX-642 docs patch) isn't quite enough to make it
> > > clear to me how to go about doing so:
> > >
> > > +saml.keystorePassword | Password of the keystore (storepass)
> > > +saml.privateKeyPassword | Password for the private key
> > (keypass)
> > > +saml.keystorePath | Path of the keystore
> > > +saml.identityProviderMetadataPath | Path of the identity
> > > provider metadata
> > > +saml.maximumAuthenticationLifetime | Maximum lifetime for
> > > authentication
> > > +saml.serviceProviderEntityId | Identifier of the service
> > > provider
> > > +saml.serviceProviderMetadataPath | Path of the service
> > provider
> > > metadata
> > >
> > > I assume that I can use the gateway.jks keystore and the
> gateway-identity
> > > keypair to do the request signing and that that information is what is
> > > needed for the first 3 params. Unfortunately, I don't see any use of
> > > gateway services to get the master secret therefore it needs to be in
> > clear
> > > text here. This won't work - but may not be a show stopper for
> committing
> > > to master as long as we follow up with a fix.
> > >
> > > Can saml.identityProviderMetadataPath point to a remote location or
> does
> > it
> > > have to be local to the SP application. This would likely require it to
> > be
> > > on the local filesystem, provisioned by the contributor into the
> > generated
> > > web app or in some central location via NFS or something like that.
> > >
> > > The okta application that I created is called KnoxSSO - is that the
> value
> > > for saml.serviceProviderEntityId?
> > >
> > > The saml.serviceProviderMetadataPath has the same questions as the
> > metadata
> > > for the IDP. In addition, is there a sample metadata file that we can
> > > provide for the use of pac4j with KnoxSSO?
> > >
> > > I think that getting this working and clean (no clear text passwords)
> > will
> > > make a great feature and blog for featuring pac4j provider and the
> 0.8.0
> > > release. So, let's try and iron this out clearly.
> > >
> > > I would really like to get this working and committed in the next
> couple
> > > days to free us up for follow up items. In particular we need time to
> > > figure out whether the identity assertion providers that we currently
> > have
> > > will suffice for an apache release that is featuring this new
> > > functionality.
> > >
> > > I will also add the above comments/questions to the JIRA for
> visibility.
> > >
> > > thanks,
> > >
> > > --larry
> > >
> > > On Fri, Jan 8, 2016 at 12:40 PM, larry mccay <lm...@apache.org>
> wrote:
> > >
> > > > Jérôme -
> > > >
> > > > My testing of OpenID Connect is blocked.
> > > > Can you see the comments in KNOX-641?
> > > >
> > > > thanks,
> > > >
> > > > --larry
> > > >
> > > > On Wed, Jan 6, 2016 at 2:30 PM, larry mccay <la...@gmail.com>
> > > wrote:
> > > >
> > > >> Jérôme -
> > > >>
> > > >> Please see the comments on KNOX-641.
> > > >>
> > > >> thanks,
> > > >>
> > > >> --larry
> > > >>
> > > >> On Wed, Jan 6, 2016 at 11:24 AM, Kevin Minder <
> > > >> kevin.minder@hortonworks.com> wrote:
> > > >>
> > > >>> I can certainly appreciate the issue of including external
> resources
> > in
> > > >>> automated tests. Nothing has driven me more crazy over the years.
> > The
> > > >>> flip side of this of course is not finding out about a breakage
> until
> > > >>> someone is willing to go through the manual testing which will
> > > typically
> > > >>> happen just before a release. Also the implication is that these
> > > testing
> > > >>> procedures must be very will documented so that they can be
> continue
> > > to be
> > > >>> run once any of us are no longer active in the project.
> > > >>>
> > > >>>
> > > >>>
> > > >>> On 1/6/16, 2:12 AM, "Jérôme LELEU" <le...@gmail.com> wrote:
> > > >>>
> > > >>> >Hi,
> > > >>> >
> > > >>> >Yes, you can hit the CAS server at Heroku. Notice it's a Heroku
> free
> > > >>> server
> > > >>> >so it needs to be re-activated first (it takes a couple of
> seconds).
> > > So
> > > >>> for
> > > >>> >a UI test, you should first hit it, wait 30 seconds and then
> perform
> > > the
> > > >>> >test.
> > > >>> >
> > > >>> >Just my 2 cents:
> > > >>> >Using automated UI tests was my first strategy for pac4j but I
> > > finally
> > > >>> >gave up because public providers change very often, at least
> enough
> > to
> > > >>> make
> > > >>> >the maintenance tests a nightmare. Currently, I'm using manual
> tests
> > > >>> (the
> > > >>> >same for all demos), it takes me around 5 minutes to play them all
> > by
> > > >>> hand
> > > >>> >(for a demo) and I launched manually the UI tests I have for every
> > > major
> > > >>> >pac4j release. Just to say UI tests are not that easy. For a CAS
> > > server,
> > > >>> >it's fairly feasible as the CAS server and protocol change rarely.
> > > >>> >That's why for Knox, I did some compromise with a simulated web
> test
> > > >>> (based
> > > >>> >on the basic auth). See:
> > > >>> >
> > > >>>
> > >
> >
> https://github.com/apache/knox/pull/2/files#diff-d0c880ca71b310dbe57975c577535e97R47
> > > >>> >
> > > >>> >Thanks.
> > > >>> >Best regards,
> > > >>> >Jérôme
> > > >>> >
> > > >>> >
> > > >>> >
> > > >>> >2016-01-05 21:20 GMT+01:00 Kevin Minder <
> > kevin.minder@hortonworks.com
> > > >:
> > > >>> >
> > > >>> >> From my perspective it would be ideal if there were some
> > automatable
> > > >>> >> functional tests for this. I’m not advocating that these be
> > > something
> > > >>> >> included in “mvn clean install” as that is running too long as
> it
> > > is.
> > > >>> >> Given that I don’t have as much context as Larry, I have some
> > > >>> questions
> > > >>> >> about what this would take. Lets say we had permission to hit
> > > >>> >> https://casserverpac4j.herokuapp.com/login as part of some low
> > > >>> frequency
> > > >>> >> automated tests (e.g. Once nighty). What static credentials and
> > > >>> other test
> > > >>> >> automation infrastructure would need to be implemented in
> support
> > of
> > > >>> this?
> > > >>> >> I understand that the test suite would require at a minimum
> > > >>> >> 1) a test driver
> > > >>> >> 2) a protected mock UI and
> > > >>> >> 3) an appropriately configured Knox
> > > >>> >> 4) a profile enabled maven module
> > > >>> >> 5) an Apache jenkins job
> > > >>> >> but I’m sure I’m missing other things. I’m certainly willing to
> > > help
> > > >>> >> setup the skeleton infrastructure (e.g. test driver, mock UI,
> > maven
> > > >>> module,
> > > >>> >> jenkins job)
> > > >>> >>
> > > >>> >>
> > > >>> >>
> > > >>> >> On 1/5/16, 2:54 PM, "larry mccay" <la...@gmail.com>
> wrote:
> > > >>> >>
> > > >>> >> >Okay, very good.
> > > >>> >> >I've used TestShib for the picketlink provider - thanks for the
> > > >>> pointers!
> > > >>> >> >
> > > >>> >> >On Tue, Jan 5, 2016 at 1:38 PM, Jérôme LELEU <leleuj@gmail.com
> >
> > > >>> wrote:
> > > >>> >> >
> > > >>> >> >> The online CAS server (
> > > https://casserverpac4j.herokuapp.com/login)
> > > >>> uses
> > > >>> >> >> the
> > > >>> >> >> CAS protocol. SAML support can be tested using some online
> IdP
> > > like
> > > >>> >> Okta,
> > > >>> >> >> TestShib, OpenFeide, Ssocircle...
> > > >>> >> >>
> > > >>> >> >>
> > > >>> >> >> 2016-01-05 17:32 GMT+01:00 larry mccay <
> larry.mccay@gmail.com
> > >:
> > > >>> >> >>
> > > >>> >> >> > Great - thanks for that pointer!
> > > >>> >> >> >
> > > >>> >> >> > I will take a look at that and help drive the release
> related
> > > >>> testing.
> > > >>> >> >> > Merge testing will be gated on CAS server (is this SAML or
> > CAS
> > > >>> >> protocol?)
> > > >>> >> >> > and testBasicAuth.
> > > >>> >> >> >
> > > >>> >> >> > On Tue, Jan 5, 2016 at 10:52 AM, Jérôme LELEU <
> > > leleuj@gmail.com>
> > > >>> >> wrote:
> > > >>> >> >> >
> > > >>> >> >> > > Hi,
> > > >>> >> >> > >
> > > >>> >> >> > > Glad to hear back from you!
> > > >>> >> >> > >
> > > >>> >> >> > > The core pac4j project is fully tested by unit tests (and
> > > some
> > > >>> >> >> > integration
> > > >>> >> >> > > tests I run for major version), then all pac4j
> > > implementations
> > > >>> are
> > > >>> >> each
> > > >>> >> >> > > tested by the appropriate demo: j2e-pac4j-demo tests
> > > j2e-pac4j,
> > > >>> >> >> > > spring-webmvc-pac4j-demo tests spring-webmvc-pac4j, etc.
> > > >>> >> >> > >
> > > >>> >> >> > > So if you take a look at:
> > > >>> >> >> > >
> > > >>> >> >> > >
> > > >>> >> >> >
> > > >>> >> >>
> > > >>> >>
> > > >>>
> > >
> >
> https://github.com/pac4j/j2e-pac4j-demo/blob/master/src/main/java/org/pac4j/demo/j2e/config/DemoConfigFactory.java#L27
> > > >>> >> >> > > (for example), you have all the required information to
> > test.
> > > >>> >> >> > >
> > > >>> >> >> > > I can do that on my own, but it can be good for the Knox
> > > >>> community
> > > >>> >> to
> > > >>> >> >> > start
> > > >>> >> >> > > working / testing the pac4j support. It's up to yoy.
> > > >>> >> >> > >
> > > >>> >> >> > > Thanks.
> > > >>> >> >> > > Best regards,
> > > >>> >> >> > > Jérôme
> > > >>> >> >> > >
> > > >>> >> >> > >
> > > >>> >> >> > > 2016-01-05 16:11 GMT+01:00 larry mccay <
> > > larry.mccay@gmail.com
> > > >>> >:
> > > >>> >> >> > >
> > > >>> >> >> > > > Hello Jérôme -
> > > >>> >> >> > > >
> > > >>> >> >> > > > Happy New Year!
> > > >>> >> >> > > >
> > > >>> >> >> > > > I am going to start reviewing your updates today,
> > > hopefully.
> > > >>> >> >> > > > I was thinking that we need to start discussions on
> what
> > > the
> > > >>> key
> > > >>> >> >> > usecases
> > > >>> >> >> > > > are and how to go about testing them.
> > > >>> >> >> > > > We can certainly test the testBasicAuth and against the
> > > >>> hosted CAS
> > > >>> >> >> > server
> > > >>> >> >> > > > but what about FB, openid, OAuth, etc?
> > > >>> >> >> > > >
> > > >>> >> >> > > > I'm not sure that FB would be a key feature but OpenID
> > > >>> Connect and
> > > >>> >> >> > OAuth
> > > >>> >> >> > > > would be - as is SAML.
> > > >>> >> >> > > > I think CAS buys us SAML testing - assuming that the
> > > >>> >> configuration of
> > > >>> >> >> > the
> > > >>> >> >> > > > hosted server is actually a SAML 2 instance.
> > > >>> >> >> > > >
> > > >>> >> >> > > > What about the others?
> > > >>> >> >> > > >
> > > >>> >> >> > > > I don't know that we need to be able to test them all
> > > before
> > > >>> merge
> > > >>> >> >> but
> > > >>> >> >> > > some
> > > >>> >> >> > > > sort of manual verification would be great.
> > > >>> >> >> > > > We would need to be able to test them before the next
> > > release
> > > >>> >> which
> > > >>> >> >> > would
> > > >>> >> >> > > > be featuring the pac4j functionality.
> > > >>> >> >> > > >
> > > >>> >> >> > > > Maybe you can describe how you go about testing such
> > things
> > > >>> for
> > > >>> >> the
> > > >>> >> >> > pac4j
> > > >>> >> >> > > > project itself?
> > > >>> >> >> > > >
> > > >>> >> >> > > > thanks,
> > > >>> >> >> > > >
> > > >>> >> >> > > > --larry
> > > >>> >> >> > > >
> > > >>> >> >> > > >
> > > >>> >> >> > > > On Tue, Jan 5, 2016 at 9:55 AM, Jérôme LELEU <
> > > >>> leleuj@gmail.com>
> > > >>> >> >> wrote:
> > > >>> >> >> > > >
> > > >>> >> >> > > > > Hi,
> > > >>> >> >> > > > >
> > > >>> >> >> > > > > Happy new year!
> > > >>> >> >> > > > >
> > > >>> >> >> > > > > A few days ago, I updated my patch of the pac4j
> gateway
> > > >>> provider
> > > >>> >> >> > > > according
> > > >>> >> >> > > > > to all comments on
> > > >>> >> https://issues.apache.org/jira/browse/KNOX-641
> > > >>> >> >> as
> > > >>> >> >> > > > well
> > > >>> >> >> > > > > as the documentation on KNOX-642.
> > > >>> >> >> > > > >
> > > >>> >> >> > > > > Is everything ok for the merge?
> > > >>> >> >> > > > >
> > > >>> >> >> > > > > Thanks.
> > > >>> >> >> > > > > Best regards,
> > > >>> >> >> > > > > Jérôme
> > > >>> >> >> > > > >
> > > >>> >> >> > > > >
> > > >>> >> >> > > > > 2015-12-14 15:28 GMT+01:00 larry mccay <
> > > >>> larry.mccay@gmail.com>:
> > > >>> >> >> > > > >
> > > >>> >> >> > > > > > Hi Jérôme -
> > > >>> >> >> > > > > >
> > > >>> >> >> > > > > > Not sure if you saw but I added review comments to
> > > >>> KNOX-641.
> > > >>> >> >> > > > > >
> > > >>> >> >> > > > > > I think that we need to determine whether we want
> the
> > > >>> >> >> testBasicAuth
> > > >>> >> >> > > in
> > > >>> >> >> > > > > the
> > > >>> >> >> > > > > > provider itself.
> > > >>> >> >> > > > > >
> > > >>> >> >> > > > > > Let's follow up on the JIRA.
> > > >>> >> >> > > > > >
> > > >>> >> >> > > > > > thanks,
> > > >>> >> >> > > > > >
> > > >>> >> >> > > > > > --larry
> > > >>> >> >> > > > > >
> > > >>> >> >> > > > > > On Fri, Dec 11, 2015 at 8:44 AM, Jérôme LELEU <
> > > >>> >> leleuj@gmail.com>
> > > >>> >> >> > > > wrote:
> > > >>> >> >> > > > > >
> > > >>> >> >> > > > > > > Hi,
> > > >>> >> >> > > > > > >
> > > >>> >> >> > > > > > > No problem. It can go into a version 0.8.0 if
> > needed.
> > > >>> The
> > > >>> >> truth
> > > >>> >> >> > is
> > > >>> >> >> > > > that
> > > >>> >> >> > > > > > > there is only one change outside the new pac4j
> > > module,
> > > >>> so I
> > > >>> >> >> think
> > > >>> >> >> > > > risks
> > > >>> >> >> > > > > > are
> > > >>> >> >> > > > > > > extremly limited.
> > > >>> >> >> > > > > > >
> > > >>> >> >> > > > > > > Just let met know.
> > > >>> >> >> > > > > > >
> > > >>> >> >> > > > > > > Thanks.
> > > >>> >> >> > > > > > > Best regards,
> > > >>> >> >> > > > > > > Jérôme
> > > >>> >> >> > > > > > >
> > > >>> >> >> > > > > > >
> > > >>> >> >> > > > > > > 2015-12-11 14:23 GMT+01:00 larry mccay <
> > > >>> >> larry.mccay@gmail.com
> > > >>> >> >> >:
> > > >>> >> >> > > > > > >
> > > >>> >> >> > > > > > > > Hi Jérôme -
> > > >>> >> >> > > > > > > >
> > > >>> >> >> > > > > > > > I have unfortunately not had a chance to pull,
> > > >>> review and
> > > >>> >> >> test
> > > >>> >> >> > it
> > > >>> >> >> > > > yet
> > > >>> >> >> > > > > > and
> > > >>> >> >> > > > > > > > have intended to do that today.
> > > >>> >> >> > > > > > > > I apologize for the delay.
> > > >>> >> >> > > > > > > >
> > > >>> >> >> > > > > > > > I was actually thinking that this would go
> into a
> > > >>> follow
> > > >>> >> up
> > > >>> >> >> > > release
> > > >>> >> >> > > > > > that
> > > >>> >> >> > > > > > > we
> > > >>> >> >> > > > > > > > would try and get done rapidly after the 0.7.0
> > > >>> release
> > > >>> >> but we
> > > >>> >> >> > can
> > > >>> >> >> > > > > > discuss
> > > >>> >> >> > > > > > > > the target and its chances of destabilizing
> > 0.7.0.
> > > >>> >> >> > > > > > > >
> > > >>> >> >> > > > > > > > I believe that it is rather self-contained with
> > > only
> > > >>> a few
> > > >>> >> >> > > changes
> > > >>> >> >> > > > to
> > > >>> >> >> > > > > > > > external modules.
> > > >>> >> >> > > > > > > >
> > > >>> >> >> > > > > > > > Opening the JIRAs is perfect and I was going to
> > do
> > > >>> that
> > > >>> >> once
> > > >>> >> >> I
> > > >>> >> >> > > > > started
> > > >>> >> >> > > > > > > the
> > > >>> >> >> > > > > > > > review.
> > > >>> >> >> > > > > > > >
> > > >>> >> >> > > > > > > > Let's continue review comments and
> collaboration
> > on
> > > >>> those
> > > >>> >> >> > JIRAs.
> > > >>> >> >> > > > > > > > I will add you to the contributors list so that
> > we
> > > >>> can
> > > >>> >> assign
> > > >>> >> >> > > them
> > > >>> >> >> > > > to
> > > >>> >> >> > > > > > > you.
> > > >>> >> >> > > > > > > >
> > > >>> >> >> > > > > > > > Thank you for your contributions and your
> > patience,
> > > >>> >> Jérôme!
> > > >>> >> >> > > > > > > >
> > > >>> >> >> > > > > > > > --larry
> > > >>> >> >> > > > > > > >
> > > >>> >> >> > > > > > > > On Fri, Dec 11, 2015 at 3:00 AM, Jérôme LELEU <
> > > >>> >> >> > leleuj@gmail.com>
> > > >>> >> >> > > > > > wrote:
> > > >>> >> >> > > > > > > >
> > > >>> >> >> > > > > > > > > Hi,
> > > >>> >> >> > > > > > > > >
> > > >>> >> >> > > > > > > > > I didn't get any new feedback on the pull
> > request
> > > >>> so I
> > > >>> >> >> assume
> > > >>> >> >> > > > > > > everything
> > > >>> >> >> > > > > > > > is
> > > >>> >> >> > > > > > > > > ok from your point of view.
> > > >>> >> >> > > > > > > > >
> > > >>> >> >> > > > > > > > > I released pac4j v1.8.1 and j2e-pac4j v1.2.1
> > so I
> > > >>> >> updated
> > > >>> >> >> the
> > > >>> >> >> > > > pull
> > > >>> >> >> > > > > > > > request
> > > >>> >> >> > > > > > > > > to use them and successfully re-tested
> > > everything.
> > > >>> >> >> > > > > > > > >
> > > >>> >> >> > > > > > > > > I opened KNOX-641 and submitted the
> > corresponding
> > > >>> patch.
> > > >>> >> >> > > > > > > > >
> > > >>> >> >> > > > > > > > > I also wrote the documentation, opened
> KNOX-642
> > > and
> > > >>> >> >> submitted
> > > >>> >> >> > > the
> > > >>> >> >> > > > > > > > > corresponding patch (just to let you know
> that
> > it
> > > >>> >> doesn't
> > > >>> >> >> > work
> > > >>> >> >> > > > out
> > > >>> >> >> > > > > of
> > > >>> >> >> > > > > > > the
> > > >>> >> >> > > > > > > > > box in Windows, I had to replace mvn.bat by
> > > >>> mvn.cmd to
> > > >>> >> make
> > > >>> >> >> > ant
> > > >>> >> >> > > > > > work).
> > > >>> >> >> > > > > > > > >
> > > >>> >> >> > > > > > > > > Even if the branch 0.7.0 has already been
> > > created,
> > > >>> I
> > > >>> >> >> assumed
> > > >>> >> >> > > this
> > > >>> >> >> > > > > new
> > > >>> >> >> > > > > > > > pac4j
> > > >>> >> >> > > > > > > > > provider will go into this version 0.7.0
> > > >>> (dependency on
> > > >>> >> the
> > > >>> >> >> > > > > > > > 0.7.0-SNAPSHOT
> > > >>> >> >> > > > > > > > > parent version).
> > > >>> >> >> > > > > > > > >
> > > >>> >> >> > > > > > > > > Just let me know if everything is ok and when
> > > it's
> > > >>> >> goind to
> > > >>> >> >> > be
> > > >>> >> >> > > > > > merged.
> > > >>> >> >> > > > > > > > >
> > > >>> >> >> > > > > > > > > Thanks.
> > > >>> >> >> > > > > > > > > Best regards,
> > > >>> >> >> > > > > > > > > Jérôme
> > > >>> >> >> > > > > > > > >
> > > >>> >> >> > > > > > > > >
> > > >>> >> >> > > > > > > > >
> > > >>> >> >> > > > > > > > >
> > > >>> >> >> > > > > > > > > 2015-12-04 14:20 GMT+01:00 larry mccay <
> > > >>> >> >> > larry.mccay@gmail.com
> > > >>> >> >> > > >:
> > > >>> >> >> > > > > > > > >
> > > >>> >> >> > > > > > > > > > That ability to configure multiple
> mechanisms
> > > >>> based on
> > > >>> >> >> > > > clientName
> > > >>> >> >> > > > > > is
> > > >>> >> >> > > > > > > > > really
> > > >>> >> >> > > > > > > > > > interesting for Knox.
> > > >>> >> >> > > > > > > > > > Currently, we require separate topologies
> per
> > > >>> >> >> > authentication
> > > >>> >> >> > > > > > > mechanism.
> > > >>> >> >> > > > > > > > > > The ability to configure them all in one is
> > > >>> really
> > > >>> >> great.
> > > >>> >> >> > > > > > > > > >
> > > >>> >> >> > > > > > > > > > We would need to think through the best way
> > to
> > > >>> provide
> > > >>> >> >> the
> > > >>> >> >> > > > > > clientName
> > > >>> >> >> > > > > > > > > > parameter.
> > > >>> >> >> > > > > > > > > > Since this is targeting KnoxSSO it can
> > actually
> > > >>> be
> > > >>> >> added
> > > >>> >> >> to
> > > >>> >> >> > > the
> > > >>> >> >> > > > > > > > > providerURL
> > > >>> >> >> > > > > > > > > > used to redirect from the participating
> > > >>> application.
> > > >>> >> >> > > > > > > > > > Regardless of the authentication mechanism
> > used
> > > >>> each
> > > >>> >> >> > > > application
> > > >>> >> >> > > > > > will
> > > >>> >> >> > > > > > > > > still
> > > >>> >> >> > > > > > > > > > get the same JWT based cookie.
> > > >>> >> >> > > > > > > > > >
> > > >>> >> >> > > > > > > > > > I think that should work really nicely.
> > > >>> >> >> > > > > > > > > >
> > > >>> >> >> > > > > > > > > >
> > > >>> >> >> > > > > > > > > > On Fri, Dec 4, 2015 at 7:17 AM, larry
> mccay <
> > > >>> >> >> > > > > larry.mccay@gmail.com
> > > >>> >> >> > > > > > >
> > > >>> >> >> > > > > > > > > wrote:
> > > >>> >> >> > > > > > > > > >
> > > >>> >> >> > > > > > > > > > > Excellent, Jérôme.
> > > >>> >> >> > > > > > > > > > > Thanks!
> > > >>> >> >> > > > > > > > > > >
> > > >>> >> >> > > > > > > > > > > On Fri, Dec 4, 2015 at 2:40 AM, Jérôme
> > LELEU
> > > <
> > > >>> >> >> > > > leleuj@gmail.com
> > > >>> >> >> > > > > >
> > > >>> >> >> > > > > > > > wrote:
> > > >>> >> >> > > > > > > > > > >
> > > >>> >> >> > > > > > > > > > >> Hi,
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > > >> I will write how to configure the pac4j
> > > >>> provider in
> > > >>> >> >> the
> > > >>> >> >> > > > > > > > documentation,
> > > >>> >> >> > > > > > > > > > but
> > > >>> >> >> > > > > > > > > > >> I can already give you some insights.
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > > >> My main goal is always to respect the
> key
> > > >>> design
> > > >>> >> >> > > principles
> > > >>> >> >> > > > of
> > > >>> >> >> > > > > > > pac4j
> > > >>> >> >> > > > > > > > > > >> whatever the environment / framework in
> > > which
> > > >>> it is
> > > >>> >> >> > > > > implemented.
> > > >>> >> >> > > > > > > For
> > > >>> >> >> > > > > > > > > > Knox,
> > > >>> >> >> > > > > > > > > > >> I'm pretty happy with the use of the
> > > j2e-pac4j
> > > >>> >> >> library,
> > > >>> >> >> > > > which
> > > >>> >> >> > > > > > > means
> > > >>> >> >> > > > > > > > > that
> > > >>> >> >> > > > > > > > > > >> almost all the pac4j features are
> > available,
> > > >>> >> >> especially
> > > >>> >> >> > > both
> > > >>> >> >> > > > > > > direct
> > > >>> >> >> > > > > > > > > and
> > > >>> >> >> > > > > > > > > > >> indirect clients. So it can do what
> Shiro
> > > >>> already
> > > >>> >> does
> > > >>> >> >> > but
> > > >>> >> >> > > > > also,
> > > >>> >> >> > > > > > > as
> > > >>> >> >> > > > > > > > we
> > > >>> >> >> > > > > > > > > > >> agreed together, supports remote
> > > >>> authentications.
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > > >> It is only limited by what you can
> > currently
> > > >>> >> >> configure.
> > > >>> >> >> > > And
> > > >>> >> >> > > > > even
> > > >>> >> >> > > > > > > > > > >> configuration is a pac4j feature as the
> > CAS
> > > >>> server
> > > >>> >> has
> > > >>> >> >> > the
> > > >>> >> >> > > > > same
> > > >>> >> >> > > > > > > > need.
> > > >>> >> >> > > > > > > > > > >> Everything happens in this class:
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > >
> > > >>> >> >> > > > > > > > >
> > > >>> >> >> > > > > > > >
> > > >>> >> >> > > > > > >
> > > >>> >> >> > > > > >
> > > >>> >> >> > > > >
> > > >>> >> >> > > >
> > > >>> >> >> > >
> > > >>> >> >> >
> > > >>> >> >>
> > > >>> >>
> > > >>>
> > >
> >
> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java
> > > >>> >> >> > > > > > > > > > >> ,
> > > >>> >> >> > > > > > > > > > >> which allows you to configure Facebook,
> > > >>> Twitter, a
> > > >>> >> CAS
> > > >>> >> >> > > > > server, a
> > > >>> >> >> > > > > > > > SAML
> > > >>> >> >> > > > > > > > > > IdP
> > > >>> >> >> > > > > > > > > > >> or an OpenID Connect provider. All the
> > > >>> provided
> > > >>> >> >> > parameters
> > > >>> >> >> > > > to
> > > >>> >> >> > > > > > the
> > > >>> >> >> > > > > > > > > pac4j
> > > >>> >> >> > > > > > > > > > >> provider are put into a Map and the
> > > >>> >> >> > > ConfigPropertiesFactory
> > > >>> >> >> > > > is
> > > >>> >> >> > > > > > > built
> > > >>> >> >> > > > > > > > > > with
> > > >>> >> >> > > > > > > > > > >> this Map to return the built client (=
> > > >>> >> authentication
> > > >>> >> >> > > > > > mechanism).
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > > >> You have one more specific option for
> Knox
> > > as
> > > >>> a
> > > >>> >> basic
> > > >>> >> >> > > > > > > authentication
> > > >>> >> >> > > > > > > > > > popup
> > > >>> >> >> > > > > > > > > > >> where the username must match the
> > password,
> > > >>> you can
> > > >>> >> >> > define
> > > >>> >> >> > > > > that
> > > >>> >> >> > > > > > > by:
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > > >> <param>
> > > >>> >> >> > > > > > > > > > >> <name>clientName</name>
> > > >>> >> >> > > > > > > > > > >> <value>testBasicAuth</value>
> > > >>> >> >> > > > > > > > > > >> </param>
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > > >> It's for testing only.
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > > >> For a CAS server:
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > > >> <param>
> > > >>> >> >> > > > > > > > > > >> <name>cas.loginUrl</name>
> > > >>> >> >> > > > > > > > > > >> <value>
> > > >>> >> https://casserverpac4j.herokuapp.com/login
> > > >>> >> >> > > </value>
> > > >>> >> >> > > > > > > > > > >> </param>
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > > >> Here are all the properties available
> for
> > > >>> building
> > > >>> >> >> > clients
> > > >>> >> >> > > > > > (their
> > > >>> >> >> > > > > > > > > > meaning
> > > >>> >> >> > > > > > > > > > >> is obvious):
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > > >> facebook.id
> > > >>> >> >> > > > > > > > > > >> facebook.secret
> > > >>> >> >> > > > > > > > > > >> facebook.scope
> > > >>> >> >> > > > > > > > > > >> facebook.fields
> > > >>> >> >> > > > > > > > > > >> twitter.id
> > > >>> >> >> > > > > > > > > > >> twitter.secret
> > > >>> >> >> > > > > > > > > > >> saml.keystorePassword
> > > >>> >> >> > > > > > > > > > >> saml.privateKeyPassword
> > > >>> >> >> > > > > > > > > > >> saml.keystorePath
> > > >>> >> >> > > > > > > > > > >> saml.identityProviderMetadataPath
> > > >>> >> >> > > > > > > > > > >> saml.maximumAuthenticationLifetime
> > > >>> >> >> > > > > > > > > > >> saml.serviceProviderEntityId
> > > >>> >> >> > > > > > > > > > >> saml.serviceProviderMetadataPath
> > > >>> >> >> > > > > > > > > > >> cas.loginUrl
> > > >>> >> >> > > > > > > > > > >> cas.protocol
> > > >>> >> >> > > > > > > > > > >> oidc.id
> > > >>> >> >> > > > > > > > > > >> oidc.secret
> > > >>> >> >> > > > > > > > > > >> oidc.discoveryUri
> > > >>> >> >> > > > > > > > > > >> oidc.customParamKey1
> > > >>> >> >> > > > > > > > > > >> oidc.customParamValue1
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > > >> If you define multiple clients, the
> first
> > > one
> > > >>> will
> > > >>> >> be
> > > >>> >> >> > used
> > > >>> >> >> > > > for
> > > >>> >> >> > > > > > > > > > >> authentication, but you can explicitly
> > > choose
> > > >>> the
> > > >>> >> >> client
> > > >>> >> >> > > you
> > > >>> >> >> > > > > > want
> > > >>> >> >> > > > > > > to
> > > >>> >> >> > > > > > > > > use
> > > >>> >> >> > > > > > > > > > >> via the clientName parameter, assuming
> you
> > > >>> want to
> > > >>> >> >> > switch
> > > >>> >> >> > > > from
> > > >>> >> >> > > > > > > > client
> > > >>> >> >> > > > > > > > > > >> depending on environment for example.
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > > >> So if you want to add some new
> > > authentication
> > > >>> >> >> mechanism,
> > > >>> >> >> > > you
> > > >>> >> >> > > > > > must
> > > >>> >> >> > > > > > > > > first
> > > >>> >> >> > > > > > > > > > >> check that it is available in pac4j (if
> > it's
> > > >>> not,
> > > >>> >> it's
> > > >>> >> >> > > > another
> > > >>> >> >> > > > > > > > > > discussion,
> > > >>> >> >> > > > > > > > > > >> but generally, it is). Then, you'll need
> > to
> > > >>> upgrade
> > > >>> >> >> the
> > > >>> >> >> > > > > > > > > > >> ConfigPropertiesFactory by submitting a
> > new
> > > >>> pull
> > > >>> >> >> request
> > > >>> >> >> > > to
> > > >>> >> >> > > > > the
> > > >>> >> >> > > > > > > > pac4j
> > > >>> >> >> > > > > > > > > > >> project (I can do it myself, but I'm
> sure
> > > you
> > > >>> >> could do
> > > >>> >> >> > > that
> > > >>> >> >> > > > > > > easily),
> > > >>> >> >> > > > > > > > > > >> finally wait for the new pac4j release
> and
> > > >>> switch
> > > >>> >> >> pac4j
> > > >>> >> >> > > > > versions
> > > >>> >> >> > > > > > > in
> > > >>> >> >> > > > > > > > > Knox
> > > >>> >> >> > > > > > > > > > >> to
> > > >>> >> >> > > > > > > > > > >> benefit from the new feature.
> > > >>> >> >> > > > > > > > > > >> The good thing is that if someone
> related
> > to
> > > >>> the
> > > >>> >> CAS
> > > >>> >> >> > > server
> > > >>> >> >> > > > > does
> > > >>> >> >> > > > > > > the
> > > >>> >> >> > > > > > > > > > same
> > > >>> >> >> > > > > > > > > > >> thing for CAS (in pac4j), you will
> > > >>> automatically
> > > >>> >> get
> > > >>> >> >> it
> > > >>> >> >> > > when
> > > >>> >> >> > > > > > > you'll
> > > >>> >> >> > > > > > > > > > >> upgrade
> > > >>> >> >> > > > > > > > > > >> pac4j.
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > > >> To go even further, replacing LDAP Shiro
> > > >>> >> >> authentication
> > > >>> >> >> > is
> > > >>> >> >> > > > > just
> > > >>> >> >> > > > > > a
> > > >>> >> >> > > > > > > > > matter
> > > >>> >> >> > > > > > > > > > >> of
> > > >>> >> >> > > > > > > > > > >> making pac4j LDAP authentication
> available
> > > via
> > > >>> >> >> > > configuration
> > > >>> >> >> > > > > > > > > parameters.
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > > >> I hope it was clear enough.
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > > >> Thanks.
> > > >>> >> >> > > > > > > > > > >> Best regards,
> > > >>> >> >> > > > > > > > > > >> Jérôme
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > > >> 2015-12-03 20:45 GMT+01:00 larry mccay <
> > > >>> >> >> > > > larry.mccay@gmail.com
> > > >>> >> >> > > > > >:
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > > >> > Excellent!
> > > >>> >> >> > > > > > > > > > >> >
> > > >>> >> >> > > > > > > > > > >> > I will carve out some time to do code
> > > >>> review.
> > > >>> >> >> > > > > > > > > > >> > We will need to get some insights into
> > how
> > > >>> to go
> > > >>> >> >> about
> > > >>> >> >> > > > > > testing:
> > > >>> >> >> > > > > > > > > > >> >
> > > >>> >> >> > > > > > > > > > >> > * is the CAS server going to be
> > available
> > > >>> for
> > > >>> >> >> testing?
> > > >>> >> >> > > > > > > > > > >> > * what are the specific and
> > > >>> generic/standard (if
> > > >>> >> >> any)
> > > >>> >> >> > > > > > > > authentication
> > > >>> >> >> > > > > > > > > > >> > mechanisms available - for instance:
> > > >>> >> >> > > > > > > > > > >> > - Facebook, Google, LinkedIn and
> CAS
> > > are
> > > >>> >> >> specifics
> > > >>> >> >> > > > > > > > > > >> > - OAuth 2, OpenID Connect, SAML
> are
> > > >>> >> >> > > generic/standards
> > > >>> >> >> > > > -
> > > >>> >> >> > > > > > that
> > > >>> >> >> > > > > > > > may
> > > >>> >> >> > > > > > > > > > be
> > > >>> >> >> > > > > > > > > > >> > used for the above specifics...
> > > >>> >> >> > > > > > > > > > >> > * how do we test things other than
> CAS -
> > > in
> > > >>> >> terms of
> > > >>> >> >> > > > getting
> > > >>> >> >> > > > > > > > > > >> credentials,
> > > >>> >> >> > > > > > > > > > >> > configuration, etc
> > > >>> >> >> > > > > > > > > > >> >
> > > >>> >> >> > > > > > > > > > >> > We could certainly do this is phases
> as
> > > >>> well.
> > > >>> >> >> > > > > > > > > > >> >
> > > >>> >> >> > > > > > > > > > >> > If you can enumerate the things that
> > > should
> > > >>> work
> > > >>> >> and
> > > >>> >> >> > > > provide
> > > >>> >> >> > > > > > > some
> > > >>> >> >> > > > > > > > > > >> testing
> > > >>> >> >> > > > > > > > > > >> > details for CAS or as many as possible
> > and
> > > >>> OpenID
> > > >>> >> >> > > Connect
> > > >>> >> >> > > > > then
> > > >>> >> >> > > > > > > we
> > > >>> >> >> > > > > > > > > can
> > > >>> >> >> > > > > > > > > > >> test
> > > >>> >> >> > > > > > > > > > >> > the specific implementations that you
> > > >>> provide and
> > > >>> >> >> > enable
> > > >>> >> >> > > > the
> > > >>> >> >> > > > > > > > testing
> > > >>> >> >> > > > > > > > > > of
> > > >>> >> >> > > > > > > > > > >> > another OpenID Connect effort that is
> in
> > > the
> > > >>> >> works
> > > >>> >> >> in
> > > >>> >> >> > > the
> > > >>> >> >> > > > > > > > community.
> > > >>> >> >> > > > > > > > > > >> >
> > > >>> >> >> > > > > > > > > > >> > I'm not sure whether we want to commit
> > > >>> >> contributions
> > > >>> >> >> > > that
> > > >>> >> >> > > > > are
> > > >>> >> >> > > > > > > > > > dependent
> > > >>> >> >> > > > > > > > > > >> on
> > > >>> >> >> > > > > > > > > > >> > snapshots - we certainly can't release
> > > with
> > > >>> any
> > > >>> >> such
> > > >>> >> >> > > > > > > dependencies.
> > > >>> >> >> > > > > > > > > > >> > I would hate to add a cleanup task to
> a
> > > >>> release
> > > >>> >> to
> > > >>> >> >> > make
> > > >>> >> >> > > > sure
> > > >>> >> >> > > > > > > there
> > > >>> >> >> > > > > > > > > are
> > > >>> >> >> > > > > > > > > > >> no
> > > >>> >> >> > > > > > > > > > >> > snapshots in there.
> > > >>> >> >> > > > > > > > > > >> > We will probably wait until after the
> > > pac4j
> > > >>> >> releases
> > > >>> >> >> > to
> > > >>> >> >> > > > > > commit.
> > > >>> >> >> > > > > > > > > > >> >
> > > >>> >> >> > > > > > > > > > >> > I am really happy that this
> integration
> > is
> > > >>> >> happening
> > > >>> >> >> > and
> > > >>> >> >> > > > > that
> > > >>> >> >> > > > > > it
> > > >>> >> >> > > > > > > > > went
> > > >>> >> >> > > > > > > > > > >> > rather smoothly.
> > > >>> >> >> > > > > > > > > > >> > These sorts of authentication
> protocols
> > > are
> > > >>> >> complex
> > > >>> >> >> > and
> > > >>> >> >> > > I
> > > >>> >> >> > > > > > think
> > > >>> >> >> > > > > > > we
> > > >>> >> >> > > > > > > > > > >> lined up
> > > >>> >> >> > > > > > > > > > >> > pretty well overall.
> > > >>> >> >> > > > > > > > > > >> >
> > > >>> >> >> > > > > > > > > > >> > Thanks for your work!
> > > >>> >> >> > > > > > > > > > >> >
> > > >>> >> >> > > > > > > > > > >> > On Thu, Dec 3, 2015 at 2:28 PM, Jérôme
> > > >>> LELEU <
> > > >>> >> >> > > > > > leleuj@gmail.com>
> > > >>> >> >> > > > > > > > > > wrote:
> > > >>> >> >> > > > > > > > > > >> >
> > > >>> >> >> > > > > > > > > > >> > > Hi,
> > > >>> >> >> > > > > > > > > > >> > >
> > > >>> >> >> > > > > > > > > > >> > > I just sync'ed with master, cleaned
> > > >>> >> dependencies
> > > >>> >> >> and
> > > >>> >> >> > > > added
> > > >>> >> >> > > > > > > > missing
> > > >>> >> >> > > > > > > > > > >> > > Javadocs. Everything works correctly
> > > now.
> > > >>> Many
> > > >>> >> >> > thanks.
> > > >>> >> >> > > > > > > > > > >> > >
> > > >>> >> >> > > > > > > > > > >> > > The pull request is ready for a full
> > > code
> > > >>> >> review:
> > > >>> >> >> > > > > > > > > > >> > >
> https://github.com/apache/knox/pull/2
> > > >>> >> >> > > > > > > > > > >> > >
> > > >>> >> >> > > > > > > > > > >> > > I'll write the documentation after
> the
> > > >>> pac4j
> > > >>> >> >> > releases
> > > >>> >> >> > > (I
> > > >>> >> >> > > > > > hope
> > > >>> >> >> > > > > > > > next
> > > >>> >> >> > > > > > > > > > >> week).
> > > >>> >> >> > > > > > > > > > >> > >
> > > >>> >> >> > > > > > > > > > >> > > Thanks.
> > > >>> >> >> > > > > > > > > > >> > > Best regards,
> > > >>> >> >> > > > > > > > > > >> > > Jérôme
> > > >>> >> >> > > > > > > > > > >> > >
> > > >>> >> >> > > > > > > > > > >> > >
> > > >>> >> >> > > > > > > > > > >> > > 2015-12-02 19:18 GMT+01:00 larry
> > mccay <
> > > >>> >> >> > > > > > larry.mccay@gmail.com
> > > >>> >> >> > > > > > > >:
> > > >>> >> >> > > > > > > > > > >> > >
> > > >>> >> >> > > > > > > > > > >> > > > Fixed in
> > > >>> >> >> > > > https://issues.apache.org/jira/browse/KNOX-636
> > > >>> >> >> > > > > .
> > > >>> >> >> > > > > > > > > > >> > > >
> > > >>> >> >> > > > > > > > > > >> > > > On Wed, Dec 2, 2015 at 12:42 PM,
> > larry
> > > >>> mccay
> > > >>> >> <
> > > >>> >> >> > > > > > > > > > larry.mccay@gmail.com
> > > >>> >> >> > > > > > > > > > >> >
> > > >>> >> >> > > > > > > > > > >> > > > wrote:
> > > >>> >> >> > > > > > > > > > >> > > >
> > > >>> >> >> > > > > > > > > > >> > > > > Sure - I can file a JIRA and
> > commit
> > > a
> > > >>> fix.
> > > >>> >> >> > > > > > > > > > >> > > > >
> > > >>> >> >> > > > > > > > > > >> > > > > The secret generation should be
> > done
> > > >>> in one
> > > >>> >> >> > > instance
> > > >>> >> >> > > > > and
> > > >>> >> >> > > > > > > > > > >> replicated
> > > >>> >> >> > > > > > > > > > >> > > > across
> > > >>> >> >> > > > > > > > > > >> > > > > others.
> > > >>> >> >> > > > > > > > > > >> > > > > This replication/management of
> the
> > > >>> >> credential
> > > >>> >> >> > > stores
> > > >>> >> >> > > > > is
> > > >>> >> >> > > > > > > > > outside
> > > >>> >> >> > > > > > > > > > of
> > > >>> >> >> > > > > > > > > > >> > the
> > > >>> >> >> > > > > > > > > > >> > > > > scope of Knox itself as of now.
> > > >>> >> >> > > > > > > > > > >> > > > >
> > > >>> >> >> > > > > > > > > > >> > > > > Documentation is done in
> markdown
> > > and
> > > >>> is
> > > >>> >> >> > > > contributing
> > > >>> >> >> > > > > > > > details
> > > >>> >> >> > > > > > > > > > are
> > > >>> >> >> > > > > > > > > > >> > > > > available at:
> > > >>> >> >> > > > > > > > > > >> > > > >
> > > >>> >> >> > > > > > > > > > >> > > >
> > > >>> >> >> > > > > > > > > > >> > >
> > > >>> >> >> > > > > > > > > > >> >
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > >
> > > >>> >> >> > > > > > > > >
> > > >>> >> >> > > > > > > >
> > > >>> >> >> > > > > > >
> > > >>> >> >> > > > > >
> > > >>> >> >> > > > >
> > > >>> >> >> > > >
> > > >>> >> >> > >
> > > >>> >> >> >
> > > >>> >> >>
> > > >>> >>
> > > >>>
> > >
> >
> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
> > > >>> >> >> > > > > > > > > > >> > > > >
> > > >>> >> >> > > > > > > > > > >> > > > > Which should give you a general
> > > idea.
> > > >>> >> >> > > > > > > > > > >> > > > >
> > > >>> >> >> > > > > > > > > > >> > > > > Find an example like:
> > > >>> ./trunk/books/0.7.0/
> > > >>> >> >> > > > > > > > > > >> > > config_preauth_sso_provider.md
> > > >>> >> >> > > > > > > > > > >> > > > >
> > > >>> >> >> > > > > > > > > > >> > > > > For an example of typical
> content
> > > and
> > > >>> >> format.
> > > >>> >> >> > > > > > > > > > >> > > > >
> > > >>> >> >> > > > > > > > > > >> > > > > Here is how that example
> renders:
> > > >>> >> >> > > > > > > > > > >> > > > >
> > > >>> >> >> > > > > > > > > > >> > > >
> > > >>> >> >> > > > > > > > > > >> > >
> > > >>> >> >> > > > > > > > > > >> >
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > >
> > > >>> >> >> > > > > > > > >
> > > >>> >> >> > > > > > > >
> > > >>> >> >> > > > > > >
> > > >>> >> >> > > > > >
> > > >>> >> >> > > > >
> > > >>> >> >> > > >
> > > >>> >> >> > >
> > > >>> >> >> >
> > > >>> >> >>
> > > >>> >>
> > > >>>
> > >
> >
> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
> > > >>> >> >> > > > > > > > > > >> > > > >
> > > >>> >> >> > > > > > > > > > >> > > > > You'll need to tie it into the
> > rest
> > > >>> of the
> > > >>> >> >> book
> > > >>> >> >> > -
> > > >>> >> >> > > > just
> > > >>> >> >> > > > > > > grep
> > > >>> >> >> > > > > > > > > for
> > > >>> >> >> > > > > > > > > > >> where
> > > >>> >> >> > > > > > > > > > >> > > > that
> > > >>> >> >> > > > > > > > > > >> > > > > filename is referenced.
> > > >>> >> >> > > > > > > > > > >> > > > > To test how it renders build the
> > > site
> > > >>> with:
> > > >>> >> >> > "ant"
> > > >>> >> >> > > > and
> > > >>> >> >> > > > > > note
> > > >>> >> >> > > > > > > > the
> > > >>> >> >> > > > > > > > > > >> url to
> > > >>> >> >> > > > > > > > > > >> > > the
> > > >>> >> >> > > > > > > > > > >> > > > > 0.7.0 book.
> > > >>> >> >> > > > > > > > > > >> > > > >
> > > >>> >> >> > > > > > > > > > >> > > > >
> > > >>> >> >> > > > > > > > > > >> > > > > On Wed, Dec 2, 2015 at 12:12 PM,
> > > >>> Jérôme
> > > >>> >> LELEU
> > > >>> >> >> <
> > > >>> >> >> > > > > > > > > leleuj@gmail.com
> > > >>> >> >> > > > > > > > > > >
> > > >>> >> >> > > > > > > > > > >> > > wrote:
> > > >>> >> >> > > > > > > > > > >> > > > >
> > > >>> >> >> > > > > > > > > > >> > > > >> Hi,
> > > >>> >> >> > > > > > > > > > >> > > > >>
> > > >>> >> >> > > > > > > > > > >> > > > >> Why it doesn't work for pac4j
> > while
> > > >>> it
> > > >>> >> works
> > > >>> >> >> > for
> > > >>> >> >> > > > > others
> > > >>> >> >> > > > > > > is
> > > >>> >> >> > > > > > > > a
> > > >>> >> >> > > > > > > > > > bit
> > > >>> >> >> > > > > > > > > > >> > > strange
> > > >>> >> >> > > > > > > > > > >> > > > >> to
> > > >>> >> >> > > > > > > > > > >> > > > >> me, but if you have the patch
> in
> > > >>> front of
> > > >>> >> >> your
> > > >>> >> >> > > > eyes,
> > > >>> >> >> > > > > > I'd
> > > >>> >> >> > > > > > > > > rather
> > > >>> >> >> > > > > > > > > > >> > prefer
> > > >>> >> >> > > > > > > > > > >> > > > you
> > > >>> >> >> > > > > > > > > > >> > > > >> to commit it. In all cases,
> I'll
> > > >>> sync with
> > > >>> >> >> the
> > > >>> >> >> > > > > master.
> > > >>> >> >> > > > > > > > > > >> > > > >>
> > > >>> >> >> > > > > > > > > > >> > > > >> There was one question you
> didn't
> > > >>> answer
> > > >>> >> >> > > > previously:
> > > >>> >> >> > > > > is
> > > >>> >> >> > > > > > > the
> > > >>> >> >> > > > > > > > > > >> password
> > > >>> >> >> > > > > > > > > > >> > > > >> generated for the pac4j
> provider
> > > the
> > > >>> same
> > > >>> >> >> > across
> > > >>> >> >> > > > all
> > > >>> >> >> > > > > > > > gateway
> > > >>> >> >> > > > > > > > > > >> > > instances?
> > > >>> >> >> > > > > > > > > > >> > > > >> Because I expect to have the
> same
> > > >>> value
> > > >>> >> as I
> > > >>> >> >> > use
> > > >>> >> >> > > it
> > > >>> >> >> > > > > to
> > > >>> >> >> > > > > > > > > encrypt
> > > >>> >> >> > > > > > > > > > /
> > > >>> >> >> > > > > > > > > > >> > > decrypt
> > > >>> >> >> > > > > > > > > > >> > > > >> data.
> > > >>> >> >> > > > > > > > > > >> > > > >>
> > > >>> >> >> > > > > > > > > > >> > > > >> I will add the Javadoc. After
> > that,
> > > >>> you
> > > >>> >> can
> > > >>> >> >> > > review
> > > >>> >> >> > > > > the
> > > >>> >> >> > > > > > > pull
> > > >>> >> >> > > > > > > > > > >> request
> > > >>> >> >> > > > > > > > > > >> > > more
> > > >>> >> >> > > > > > > > > > >> > > > >> completely.
> > > >>> >> >> > > > > > > > > > >> > > > >>
> > > >>> >> >> > > > > > > > > > >> > > > >> What do you expect for the
> > > >>> documentation?
> > > >>> >> >> > > > > > > > > > >> > > > >>
> > > >>> >> >> > > > > > > > > > >> > > > >> Notice that pac4j dependencies
> > are
> > > >>> still
> > > >>> >> >> > > snapshots,
> > > >>> >> >> > > > > but
> > > >>> >> >> > > > > > > > they
> > > >>> >> >> > > > > > > > > > >> will be
> > > >>> >> >> > > > > > > > > > >> > > > >> released in a week or two.
> > > >>> >> >> > > > > > > > > > >> > > > >>
> > > >>> >> >> > > > > > > > > > >> > > > >> Thanks.
> > > >>> >> >> > > > > > > > > > >> > > > >> Best regards,
> > > >>> >> >> > > > > > > > > > >> > > > >> Jérôme
> > > >>> >> >> > > > > > > > > > >> > > > >>
> > > >>> >> >> > > > > > > > > > >> > > > >>
> > > >>> >> >> > > > > > > > > > >> > > > >> 2015-12-02 17:51 GMT+01:00
> larry
> > > >>> mccay <
> > > >>> >> >> > > > > > > > > larry.mccay@gmail.com
> > > >>> >> >> > > > > > > > > > >:
> > > >>> >> >> > > > > > > > > > >> > > > >>
> > > >>> >> >> > > > > > > > > > >> > > > >> > Jérôme -
> > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > >>> >> >> > > > > > > > > > >> > > > >> > If you would like to add that
> > > >>> change as
> > > >>> >> >> part
> > > >>> >> >> > of
> > > >>> >> >> > > > > your
> > > >>> >> >> > > > > > > > patch
> > > >>> >> >> > > > > > > > > or
> > > >>> >> >> > > > > > > > > > >> as a
> > > >>> >> >> > > > > > > > > > >> > > > >> > separately filed JIRA to fix
> a
> > > bug
> > > >>> that
> > > >>> >> >> would
> > > >>> >> >> > > > > > certainly
> > > >>> >> >> > > > > > > > be
> > > >>> >> >> > > > > > > > > > >> > welcomed.
> > > >>> >> >> > > > > > > > > > >> > > > >> > Otherwise, I can do it.
> > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > >>> >> >> > > > > > > > > > >> > > > >> > Let me know.
> > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > >>> >> >> > > > > > > > > > >> > > > >> > thanks,
> > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > >>> >> >> > > > > > > > > > >> > > > >> > --larry
> > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > >>> >> >> > > > > > > > > > >> > > > >> > On Wed, Dec 2, 2015 at 11:44
> > AM,
> > > >>> larry
> > > >>> >> >> mccay
> > > >>> >> >> > <
> > > >>> >> >> > > > > > > > > > >> > larry.mccay@gmail.com
> > > >>> >> >> > > > > > > > > > >> > > >
> > > >>> >> >> > > > > > > > > > >> > > > >> > wrote:
> > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > >>> >> >> > > > > > > > > > >> > > > >> > > Okay - I had to add an
> > override
> > > >>> of
> > > >>> >> >> > > > > > getUserPrincipal()
> > > >>> >> >> > > > > > > > to
> > > >>> >> >> > > > > > > > > > the
> > > >>> >> >> > > > > > > > > > >> > > > >> > >
> > > >>> >> IdentityAsserterHttpServletRequestWrapper
> > > >>> >> >> > and
> > > >>> >> >> > > > > > return
> > > >>> >> >> > > > > > > > the
> > > >>> >> >> > > > > > > > > > >> member
> > > >>> >> >> > > > > > > > > > >> > > > >> variable
> > > >>> >> >> > > > > > > > > > >> > > > >> > > username and it works like
> a
> > > >>> charm.
> > > >>> >> >> > > > > > > > > > >> > > > >> > >
> > > >>> >> >> > > > > > > > > > >> > > > >> > > Why I haven't seen this
> same
> > > >>> behavior
> > > >>> >> >> with
> > > >>> >> >> > > > other
> > > >>> >> >> > > > > > > > > providers
> > > >>> >> >> > > > > > > > > > >> is a
> > > >>> >> >> > > > > > > > > > >> > > bit
> > > >>> >> >> > > > > > > > > > >> > > > >> of a
> > > >>> >> >> > > > > > > > > > >> > > > >> > > mystery but they must be
> > adding
> > > >>> other
> > > >>> >> >> > > wrappers
> > > >>> >> >> > > > > that
> > > >>> >> >> > > > > > > > > handle
> > > >>> >> >> > > > > > > > > > >> it.
> > > >>> >> >> > > > > > > > > > >> > > > >> > > This is quite cool, Jérôme!
> > > >>> >> >> > > > > > > > > > >> > > > >> > >
> > > >>> >> >> > > > > > > > > > >> > > > >> > > On Wed, Dec 2, 2015 at
> 10:41
> > > AM,
> > > >>> larry
> > > >>> >> >> > mccay
> > > >>> >> >> > > <
> > > >>> >> >> > > > > > > > > > >> > > larry.mccay@gmail.com
> > > >>> >> >> > > > > > > > > > >> > > > >
> > > >>> >> >> > > > > > > > > > >> > > > >> > > wrote:
> > > >>> >> >> > > > > > > > > > >> > > > >> > >
> > > >>> >> >> > > > > > > > > > >> > > > >> > >> That was it - thanks!
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>
> > > >>> >> >> > > > > > > > > > >> > > > >> > >> On Wed, Dec 2, 2015 at
> 10:20
> > > AM,
> > > >>> >> Jérôme
> > > >>> >> >> > > LELEU
> > > >>> >> >> > > > <
> > > >>> >> >> > > > > > > > > > >> > leleuj@gmail.com>
> > > >>> >> >> > > > > > > > > > >> > > > >> wrote:
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> This is my exact command
> > > line:
> > > >>> mvn
> > > >>> >> >> > > -Prelease
> > > >>> >> >> > > > > > clean
> > > >>> >> >> > > > > > > > > > install
> > > >>> >> >> > > > > > > > > > >> > > > >> -DskipTests
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> You use an internal Maven
> > > >>> >> repository to
> > > >>> >> >> > > fetch
> > > >>> >> >> > > > > > > > > > dependencies
> > > >>> >> >> > > > > > > > > > >> > from
> > > >>> >> >> > > > > > > > > > >> > > > >> > internet:
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > >>> >> >> > > > > > > > > > >> > >
> > > >>> >> >> > > > > > > >
> > > >>> >> >> > >
> > > >>> http://nexus-private.hortonworks.com/nexus/content/groups/public/
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> Does this repository have
> > > >>> access to
> > > >>> >> the
> > > >>> >> >> > > > remote
> > > >>> >> >> > > > > > > > > Snapshots
> > > >>> >> >> > > > > > > > > > >> > > Sonatype
> > > >>> >> >> > > > > > > > > > >> > > > >> repo?
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> 2015-12-02 16:16
> GMT+01:00
> > > >>> larry
> > > >>> >> mccay
> > > >>> >> >> <
> > > >>> >> >> > > > > > > > > > >> larry.mccay@gmail.com
> > > >>> >> >> > > > > > > > > > >> > >:
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > hmmm - I used:
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > mvn clean install
> > > >>> -DskipTests=true
> > > >>> >> >> > > > -Prelease
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > The repository entry is
> > in
> > > >>> there
> > > >>> >> >> > already.
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > No worky.
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > On Wed, Dec 2, 2015 at
> > > 10:12
> > > >>> AM,
> > > >>> >> >> Jérôme
> > > >>> >> >> > > > > LELEU <
> > > >>> >> >> > > > > > > > > > >> > > leleuj@gmail.com
> > > >>> >> >> > > > > > > > > > >> > > > >
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> wrote:
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Hi,
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > You need the
> j2e-pac4j
> > > >>> >> dependencies
> > > >>> >> >> > as
> > > >>> >> >> > > > well
> > > >>> >> >> > > > > > as
> > > >>> >> >> > > > > > > > the
> > > >>> >> >> > > > > > > > > > >> pac4j-*
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> dependencies,
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > but you don't need to
> > > >>> build them
> > > >>> >> >> > > locally
> > > >>> >> >> > > > > > > > > (hopefully).
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > But you need a
> > dependency
> > > >>> on the
> > > >>> >> >> > > Sonatype
> > > >>> >> >> > > > > > > > snapshots
> > > >>> >> >> > > > > > > > > > >> > > repository
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> (where the
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > snapshot versions are
> > > >>> hosted),
> > > >>> >> >> which
> > > >>> >> >> > is
> > > >>> >> >> > > > > added
> > > >>> >> >> > > > > > > for
> > > >>> >> >> > > > > > > > > > >> Maven in
> > > >>> >> >> > > > > > > > > > >> > > the
> > > >>> >> >> > > > > > > > > > >> > > > >> root
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > pom.xml:
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > >>> >> >> > > > > > > > > > >> > > > >>
> > > >>> >> >> > > > > > > > > > >> > > >
> > > >>> >> >> > > > > > > > > > >> > >
> > > >>> >> >> > > > > > > > > > >> >
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > >
> > > >>> >> >> > > > > > > > >
> > > >>> >> >> > > > > > > >
> > > >>> >> >> > > > > > >
> > > >>> >> >> > > > > >
> > > >>> >> >> > > > >
> > > >>> >> >> > > >
> > > >>> >> >> > >
> > > >>> >> >> >
> > > >>> >> >>
> > > >>> >>
> > > >>>
> > >
> >
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > If you use Ant for
> the
> > > >>> build,
> > > >>> >> there
> > > >>> >> >> > is
> > > >>> >> >> > > > > maybe
> > > >>> >> >> > > > > > a
> > > >>> >> >> > > > > > > > > glitch
> > > >>> >> >> > > > > > > > > > >> to
> > > >>> >> >> > > > > > > > > > >> > > find
> > > >>> >> >> > > > > > > > > > >> > > > >> the
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > Sonatype
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Maven repo.
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Thanks.
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Best regards,
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Jérôme
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > 2015-12-02 16:06
> > > GMT+01:00
> > > >>> larry
> > > >>> >> >> > mccay
> > > >>> >> >> > > <
> > > >>> >> >> > > > > > > > > > >> > > larry.mccay@gmail.com
> > > >>> >> >> > > > > > > > > > >> > > > >:
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > 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.mccay@gmail.com>
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > wrote:
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > >
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > >
> > > >>> >> gateway-provider-security-pac4j
> > > >>> >> >> > > > doesn't
> > > >>> >> >> > > > > > > > build -
> > > >>> >> >> > > > > > > > > > do
> > > >>> >> >> > > > > > > > > > >> you
> > > >>> >> >> > > > > > > > > > >> > > > have
> > > >>> >> >> > > > > > > > > > >> > > > >> a
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> pending
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > > change for your
> > > >>> pom.xml or
> > > >>> >> >> > > something?
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > >
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>
> > > >>> >> >> > > > > > > > > > >> > > > >> > >>
> > > >>> >> >> > > > > > > > > > >> > > > >> > >
> > > >>> >> >> > > > > > > > > > >> > > > >> >
> > > >>> >> >> > > > > > > > > > >> > > > >>
> > > >>> >> >> > > > > > > > > > >> > > > >
> > > >>> >> >> > > > > > > > > > >> > > > >
> > > >>> >> >> > > > > > > > > > >> > > >
> > > >>> >> >> > > > > > > > > > >> > >
> > > >>> >> >> > > > > > > > > > >> >
> > > >>> >> >> > > > > > > > > > >>
> > > >>> >> >> > > > > > > > > > >
> > > >>> >> >> > > > > > > > > > >
> > > >>> >> >> > > > > > > > > >
> > > >>> >> >> > > > > > > > >
> > > >>> >> >> > > > > > > >
> > > >>> >> >> > > > > > >
> > > >>> >> >> > > > > >
> > > >>> >> >> > > > >
> > > >>> >> >> > > >
> > > >>> >> >> > >
> > > >>> >> >> >
> > > >>> >> >>
> > > >>> >>
> > > >>>
> > > >>
> > > >>
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by larry mccay <lm...@apache.org>.
That sounds pretty reasonable.
I will likely document a few of the integrations that are possible in
blogs/tutorials anyway.
I don't want testing of Knox at release time to have to jump around to much
in order to be able to test.
I think we can make that all good though.
I will see what I can do with okta today.
On Thu, Jan 14, 2016 at 5:00 AM, Jérôme LELEU <le...@gmail.com> wrote:
> Hi,
>
> Yes, the documentation is a bit too light. But you guessed it right: we
> need to have a keystore for encryption.
>
> The saml.identityProviderMetadataPath can point to a local resource or to a
> remote one, using the right prefix: resource:, file: or an url (by default,
> it is a file path). This must be documented though.
>
> With Okta, I used the defined url (Single Sign On URL = Recipient URL =
> Destination URL) for the serviceProviderEntityId, but I think it may
> depends on IdP as well. Reading the spec, it must be an URI, but I'm not
> sure if the SP metadata should be really available on this url. For Okta,
> it doesn't matter.
>
> According to your SAML configuration, the SP metadata will be generated
> somewhere and this somewhere can be defined via the
> serviceProviderMetadataPath parameter. You generally need to update your
> metadata to the IdP (not required for Okta though). Both the SP and IdP
> must know each other.
>
> When writing the documentation, I went fast on these parameters with the
> feeling they were regular ones, but indeed, the description in the Knox
> manual is not enough. This is somehow a bit normal as the real
> documentation for SAML is on the SAML wiki:
> https://github.com/pac4j/pac4j/wiki/Clients#details-for-saml-support
>
> So I propose to keep the Knox documentation mostly "as is", but add links
> to the pac4j wiki (where I could more easily made updates). All pac4j
> integrations need this documentation so it's better to centralize it, from
> my point of view. What do you think?
>
> Thanks.
> Best regards,
> Jérôme
>
>
>
> 2016-01-13 19:37 GMT+01:00 larry mccay <lm...@apache.org>:
>
> > Hi Jérôme -
> >
> > I'm trying to configure the pac4j provider for an okta "application"
> that I
> > created.
> > The following (from KNOX-642 docs patch) isn't quite enough to make it
> > clear to me how to go about doing so:
> >
> > +saml.keystorePassword | Password of the keystore (storepass)
> > +saml.privateKeyPassword | Password for the private key
> (keypass)
> > +saml.keystorePath | Path of the keystore
> > +saml.identityProviderMetadataPath | Path of the identity
> > provider metadata
> > +saml.maximumAuthenticationLifetime | Maximum lifetime for
> > authentication
> > +saml.serviceProviderEntityId | Identifier of the service
> > provider
> > +saml.serviceProviderMetadataPath | Path of the service
> provider
> > metadata
> >
> > I assume that I can use the gateway.jks keystore and the gateway-identity
> > keypair to do the request signing and that that information is what is
> > needed for the first 3 params. Unfortunately, I don't see any use of
> > gateway services to get the master secret therefore it needs to be in
> clear
> > text here. This won't work - but may not be a show stopper for committing
> > to master as long as we follow up with a fix.
> >
> > Can saml.identityProviderMetadataPath point to a remote location or does
> it
> > have to be local to the SP application. This would likely require it to
> be
> > on the local filesystem, provisioned by the contributor into the
> generated
> > web app or in some central location via NFS or something like that.
> >
> > The okta application that I created is called KnoxSSO - is that the value
> > for saml.serviceProviderEntityId?
> >
> > The saml.serviceProviderMetadataPath has the same questions as the
> metadata
> > for the IDP. In addition, is there a sample metadata file that we can
> > provide for the use of pac4j with KnoxSSO?
> >
> > I think that getting this working and clean (no clear text passwords)
> will
> > make a great feature and blog for featuring pac4j provider and the 0.8.0
> > release. So, let's try and iron this out clearly.
> >
> > I would really like to get this working and committed in the next couple
> > days to free us up for follow up items. In particular we need time to
> > figure out whether the identity assertion providers that we currently
> have
> > will suffice for an apache release that is featuring this new
> > functionality.
> >
> > I will also add the above comments/questions to the JIRA for visibility.
> >
> > thanks,
> >
> > --larry
> >
> > On Fri, Jan 8, 2016 at 12:40 PM, larry mccay <lm...@apache.org> wrote:
> >
> > > Jérôme -
> > >
> > > My testing of OpenID Connect is blocked.
> > > Can you see the comments in KNOX-641?
> > >
> > > thanks,
> > >
> > > --larry
> > >
> > > On Wed, Jan 6, 2016 at 2:30 PM, larry mccay <la...@gmail.com>
> > wrote:
> > >
> > >> Jérôme -
> > >>
> > >> Please see the comments on KNOX-641.
> > >>
> > >> thanks,
> > >>
> > >> --larry
> > >>
> > >> On Wed, Jan 6, 2016 at 11:24 AM, Kevin Minder <
> > >> kevin.minder@hortonworks.com> wrote:
> > >>
> > >>> I can certainly appreciate the issue of including external resources
> in
> > >>> automated tests. Nothing has driven me more crazy over the years.
> The
> > >>> flip side of this of course is not finding out about a breakage until
> > >>> someone is willing to go through the manual testing which will
> > typically
> > >>> happen just before a release. Also the implication is that these
> > testing
> > >>> procedures must be very will documented so that they can be continue
> > to be
> > >>> run once any of us are no longer active in the project.
> > >>>
> > >>>
> > >>>
> > >>> On 1/6/16, 2:12 AM, "Jérôme LELEU" <le...@gmail.com> wrote:
> > >>>
> > >>> >Hi,
> > >>> >
> > >>> >Yes, you can hit the CAS server at Heroku. Notice it's a Heroku free
> > >>> server
> > >>> >so it needs to be re-activated first (it takes a couple of seconds).
> > So
> > >>> for
> > >>> >a UI test, you should first hit it, wait 30 seconds and then perform
> > the
> > >>> >test.
> > >>> >
> > >>> >Just my 2 cents:
> > >>> >Using automated UI tests was my first strategy for pac4j but I
> > finally
> > >>> >gave up because public providers change very often, at least enough
> to
> > >>> make
> > >>> >the maintenance tests a nightmare. Currently, I'm using manual tests
> > >>> (the
> > >>> >same for all demos), it takes me around 5 minutes to play them all
> by
> > >>> hand
> > >>> >(for a demo) and I launched manually the UI tests I have for every
> > major
> > >>> >pac4j release. Just to say UI tests are not that easy. For a CAS
> > server,
> > >>> >it's fairly feasible as the CAS server and protocol change rarely.
> > >>> >That's why for Knox, I did some compromise with a simulated web test
> > >>> (based
> > >>> >on the basic auth). See:
> > >>> >
> > >>>
> >
> https://github.com/apache/knox/pull/2/files#diff-d0c880ca71b310dbe57975c577535e97R47
> > >>> >
> > >>> >Thanks.
> > >>> >Best regards,
> > >>> >Jérôme
> > >>> >
> > >>> >
> > >>> >
> > >>> >2016-01-05 21:20 GMT+01:00 Kevin Minder <
> kevin.minder@hortonworks.com
> > >:
> > >>> >
> > >>> >> From my perspective it would be ideal if there were some
> automatable
> > >>> >> functional tests for this. I’m not advocating that these be
> > something
> > >>> >> included in “mvn clean install” as that is running too long as it
> > is.
> > >>> >> Given that I don’t have as much context as Larry, I have some
> > >>> questions
> > >>> >> about what this would take. Lets say we had permission to hit
> > >>> >> https://casserverpac4j.herokuapp.com/login as part of some low
> > >>> frequency
> > >>> >> automated tests (e.g. Once nighty). What static credentials and
> > >>> other test
> > >>> >> automation infrastructure would need to be implemented in support
> of
> > >>> this?
> > >>> >> I understand that the test suite would require at a minimum
> > >>> >> 1) a test driver
> > >>> >> 2) a protected mock UI and
> > >>> >> 3) an appropriately configured Knox
> > >>> >> 4) a profile enabled maven module
> > >>> >> 5) an Apache jenkins job
> > >>> >> but I’m sure I’m missing other things. I’m certainly willing to
> > help
> > >>> >> setup the skeleton infrastructure (e.g. test driver, mock UI,
> maven
> > >>> module,
> > >>> >> jenkins job)
> > >>> >>
> > >>> >>
> > >>> >>
> > >>> >> On 1/5/16, 2:54 PM, "larry mccay" <la...@gmail.com> wrote:
> > >>> >>
> > >>> >> >Okay, very good.
> > >>> >> >I've used TestShib for the picketlink provider - thanks for the
> > >>> pointers!
> > >>> >> >
> > >>> >> >On Tue, Jan 5, 2016 at 1:38 PM, Jérôme LELEU <le...@gmail.com>
> > >>> wrote:
> > >>> >> >
> > >>> >> >> The online CAS server (
> > https://casserverpac4j.herokuapp.com/login)
> > >>> uses
> > >>> >> >> the
> > >>> >> >> CAS protocol. SAML support can be tested using some online IdP
> > like
> > >>> >> Okta,
> > >>> >> >> TestShib, OpenFeide, Ssocircle...
> > >>> >> >>
> > >>> >> >>
> > >>> >> >> 2016-01-05 17:32 GMT+01:00 larry mccay <larry.mccay@gmail.com
> >:
> > >>> >> >>
> > >>> >> >> > Great - thanks for that pointer!
> > >>> >> >> >
> > >>> >> >> > I will take a look at that and help drive the release related
> > >>> testing.
> > >>> >> >> > Merge testing will be gated on CAS server (is this SAML or
> CAS
> > >>> >> protocol?)
> > >>> >> >> > and testBasicAuth.
> > >>> >> >> >
> > >>> >> >> > On Tue, Jan 5, 2016 at 10:52 AM, Jérôme LELEU <
> > leleuj@gmail.com>
> > >>> >> wrote:
> > >>> >> >> >
> > >>> >> >> > > Hi,
> > >>> >> >> > >
> > >>> >> >> > > Glad to hear back from you!
> > >>> >> >> > >
> > >>> >> >> > > The core pac4j project is fully tested by unit tests (and
> > some
> > >>> >> >> > integration
> > >>> >> >> > > tests I run for major version), then all pac4j
> > implementations
> > >>> are
> > >>> >> each
> > >>> >> >> > > tested by the appropriate demo: j2e-pac4j-demo tests
> > j2e-pac4j,
> > >>> >> >> > > spring-webmvc-pac4j-demo tests spring-webmvc-pac4j, etc.
> > >>> >> >> > >
> > >>> >> >> > > So if you take a look at:
> > >>> >> >> > >
> > >>> >> >> > >
> > >>> >> >> >
> > >>> >> >>
> > >>> >>
> > >>>
> >
> https://github.com/pac4j/j2e-pac4j-demo/blob/master/src/main/java/org/pac4j/demo/j2e/config/DemoConfigFactory.java#L27
> > >>> >> >> > > (for example), you have all the required information to
> test.
> > >>> >> >> > >
> > >>> >> >> > > I can do that on my own, but it can be good for the Knox
> > >>> community
> > >>> >> to
> > >>> >> >> > start
> > >>> >> >> > > working / testing the pac4j support. It's up to yoy.
> > >>> >> >> > >
> > >>> >> >> > > Thanks.
> > >>> >> >> > > Best regards,
> > >>> >> >> > > Jérôme
> > >>> >> >> > >
> > >>> >> >> > >
> > >>> >> >> > > 2016-01-05 16:11 GMT+01:00 larry mccay <
> > larry.mccay@gmail.com
> > >>> >:
> > >>> >> >> > >
> > >>> >> >> > > > Hello Jérôme -
> > >>> >> >> > > >
> > >>> >> >> > > > Happy New Year!
> > >>> >> >> > > >
> > >>> >> >> > > > I am going to start reviewing your updates today,
> > hopefully.
> > >>> >> >> > > > I was thinking that we need to start discussions on what
> > the
> > >>> key
> > >>> >> >> > usecases
> > >>> >> >> > > > are and how to go about testing them.
> > >>> >> >> > > > We can certainly test the testBasicAuth and against the
> > >>> hosted CAS
> > >>> >> >> > server
> > >>> >> >> > > > but what about FB, openid, OAuth, etc?
> > >>> >> >> > > >
> > >>> >> >> > > > I'm not sure that FB would be a key feature but OpenID
> > >>> Connect and
> > >>> >> >> > OAuth
> > >>> >> >> > > > would be - as is SAML.
> > >>> >> >> > > > I think CAS buys us SAML testing - assuming that the
> > >>> >> configuration of
> > >>> >> >> > the
> > >>> >> >> > > > hosted server is actually a SAML 2 instance.
> > >>> >> >> > > >
> > >>> >> >> > > > What about the others?
> > >>> >> >> > > >
> > >>> >> >> > > > I don't know that we need to be able to test them all
> > before
> > >>> merge
> > >>> >> >> but
> > >>> >> >> > > some
> > >>> >> >> > > > sort of manual verification would be great.
> > >>> >> >> > > > We would need to be able to test them before the next
> > release
> > >>> >> which
> > >>> >> >> > would
> > >>> >> >> > > > be featuring the pac4j functionality.
> > >>> >> >> > > >
> > >>> >> >> > > > Maybe you can describe how you go about testing such
> things
> > >>> for
> > >>> >> the
> > >>> >> >> > pac4j
> > >>> >> >> > > > project itself?
> > >>> >> >> > > >
> > >>> >> >> > > > thanks,
> > >>> >> >> > > >
> > >>> >> >> > > > --larry
> > >>> >> >> > > >
> > >>> >> >> > > >
> > >>> >> >> > > > On Tue, Jan 5, 2016 at 9:55 AM, Jérôme LELEU <
> > >>> leleuj@gmail.com>
> > >>> >> >> wrote:
> > >>> >> >> > > >
> > >>> >> >> > > > > Hi,
> > >>> >> >> > > > >
> > >>> >> >> > > > > Happy new year!
> > >>> >> >> > > > >
> > >>> >> >> > > > > A few days ago, I updated my patch of the pac4j gateway
> > >>> provider
> > >>> >> >> > > > according
> > >>> >> >> > > > > to all comments on
> > >>> >> https://issues.apache.org/jira/browse/KNOX-641
> > >>> >> >> as
> > >>> >> >> > > > well
> > >>> >> >> > > > > as the documentation on KNOX-642.
> > >>> >> >> > > > >
> > >>> >> >> > > > > Is everything ok for the merge?
> > >>> >> >> > > > >
> > >>> >> >> > > > > Thanks.
> > >>> >> >> > > > > Best regards,
> > >>> >> >> > > > > Jérôme
> > >>> >> >> > > > >
> > >>> >> >> > > > >
> > >>> >> >> > > > > 2015-12-14 15:28 GMT+01:00 larry mccay <
> > >>> larry.mccay@gmail.com>:
> > >>> >> >> > > > >
> > >>> >> >> > > > > > Hi Jérôme -
> > >>> >> >> > > > > >
> > >>> >> >> > > > > > Not sure if you saw but I added review comments to
> > >>> KNOX-641.
> > >>> >> >> > > > > >
> > >>> >> >> > > > > > I think that we need to determine whether we want the
> > >>> >> >> testBasicAuth
> > >>> >> >> > > in
> > >>> >> >> > > > > the
> > >>> >> >> > > > > > provider itself.
> > >>> >> >> > > > > >
> > >>> >> >> > > > > > Let's follow up on the JIRA.
> > >>> >> >> > > > > >
> > >>> >> >> > > > > > thanks,
> > >>> >> >> > > > > >
> > >>> >> >> > > > > > --larry
> > >>> >> >> > > > > >
> > >>> >> >> > > > > > On Fri, Dec 11, 2015 at 8:44 AM, Jérôme LELEU <
> > >>> >> leleuj@gmail.com>
> > >>> >> >> > > > wrote:
> > >>> >> >> > > > > >
> > >>> >> >> > > > > > > Hi,
> > >>> >> >> > > > > > >
> > >>> >> >> > > > > > > No problem. It can go into a version 0.8.0 if
> needed.
> > >>> The
> > >>> >> truth
> > >>> >> >> > is
> > >>> >> >> > > > that
> > >>> >> >> > > > > > > there is only one change outside the new pac4j
> > module,
> > >>> so I
> > >>> >> >> think
> > >>> >> >> > > > risks
> > >>> >> >> > > > > > are
> > >>> >> >> > > > > > > extremly limited.
> > >>> >> >> > > > > > >
> > >>> >> >> > > > > > > Just let met know.
> > >>> >> >> > > > > > >
> > >>> >> >> > > > > > > Thanks.
> > >>> >> >> > > > > > > Best regards,
> > >>> >> >> > > > > > > Jérôme
> > >>> >> >> > > > > > >
> > >>> >> >> > > > > > >
> > >>> >> >> > > > > > > 2015-12-11 14:23 GMT+01:00 larry mccay <
> > >>> >> larry.mccay@gmail.com
> > >>> >> >> >:
> > >>> >> >> > > > > > >
> > >>> >> >> > > > > > > > Hi Jérôme -
> > >>> >> >> > > > > > > >
> > >>> >> >> > > > > > > > I have unfortunately not had a chance to pull,
> > >>> review and
> > >>> >> >> test
> > >>> >> >> > it
> > >>> >> >> > > > yet
> > >>> >> >> > > > > > and
> > >>> >> >> > > > > > > > have intended to do that today.
> > >>> >> >> > > > > > > > I apologize for the delay.
> > >>> >> >> > > > > > > >
> > >>> >> >> > > > > > > > I was actually thinking that this would go into a
> > >>> follow
> > >>> >> up
> > >>> >> >> > > release
> > >>> >> >> > > > > > that
> > >>> >> >> > > > > > > we
> > >>> >> >> > > > > > > > would try and get done rapidly after the 0.7.0
> > >>> release
> > >>> >> but we
> > >>> >> >> > can
> > >>> >> >> > > > > > discuss
> > >>> >> >> > > > > > > > the target and its chances of destabilizing
> 0.7.0.
> > >>> >> >> > > > > > > >
> > >>> >> >> > > > > > > > I believe that it is rather self-contained with
> > only
> > >>> a few
> > >>> >> >> > > changes
> > >>> >> >> > > > to
> > >>> >> >> > > > > > > > external modules.
> > >>> >> >> > > > > > > >
> > >>> >> >> > > > > > > > Opening the JIRAs is perfect and I was going to
> do
> > >>> that
> > >>> >> once
> > >>> >> >> I
> > >>> >> >> > > > > started
> > >>> >> >> > > > > > > the
> > >>> >> >> > > > > > > > review.
> > >>> >> >> > > > > > > >
> > >>> >> >> > > > > > > > Let's continue review comments and collaboration
> on
> > >>> those
> > >>> >> >> > JIRAs.
> > >>> >> >> > > > > > > > I will add you to the contributors list so that
> we
> > >>> can
> > >>> >> assign
> > >>> >> >> > > them
> > >>> >> >> > > > to
> > >>> >> >> > > > > > > you.
> > >>> >> >> > > > > > > >
> > >>> >> >> > > > > > > > Thank you for your contributions and your
> patience,
> > >>> >> Jérôme!
> > >>> >> >> > > > > > > >
> > >>> >> >> > > > > > > > --larry
> > >>> >> >> > > > > > > >
> > >>> >> >> > > > > > > > On Fri, Dec 11, 2015 at 3:00 AM, Jérôme LELEU <
> > >>> >> >> > leleuj@gmail.com>
> > >>> >> >> > > > > > wrote:
> > >>> >> >> > > > > > > >
> > >>> >> >> > > > > > > > > Hi,
> > >>> >> >> > > > > > > > >
> > >>> >> >> > > > > > > > > I didn't get any new feedback on the pull
> request
> > >>> so I
> > >>> >> >> assume
> > >>> >> >> > > > > > > everything
> > >>> >> >> > > > > > > > is
> > >>> >> >> > > > > > > > > ok from your point of view.
> > >>> >> >> > > > > > > > >
> > >>> >> >> > > > > > > > > I released pac4j v1.8.1 and j2e-pac4j v1.2.1
> so I
> > >>> >> updated
> > >>> >> >> the
> > >>> >> >> > > > pull
> > >>> >> >> > > > > > > > request
> > >>> >> >> > > > > > > > > to use them and successfully re-tested
> > everything.
> > >>> >> >> > > > > > > > >
> > >>> >> >> > > > > > > > > I opened KNOX-641 and submitted the
> corresponding
> > >>> patch.
> > >>> >> >> > > > > > > > >
> > >>> >> >> > > > > > > > > I also wrote the documentation, opened KNOX-642
> > and
> > >>> >> >> submitted
> > >>> >> >> > > the
> > >>> >> >> > > > > > > > > corresponding patch (just to let you know that
> it
> > >>> >> doesn't
> > >>> >> >> > work
> > >>> >> >> > > > out
> > >>> >> >> > > > > of
> > >>> >> >> > > > > > > the
> > >>> >> >> > > > > > > > > box in Windows, I had to replace mvn.bat by
> > >>> mvn.cmd to
> > >>> >> make
> > >>> >> >> > ant
> > >>> >> >> > > > > > work).
> > >>> >> >> > > > > > > > >
> > >>> >> >> > > > > > > > > Even if the branch 0.7.0 has already been
> > created,
> > >>> I
> > >>> >> >> assumed
> > >>> >> >> > > this
> > >>> >> >> > > > > new
> > >>> >> >> > > > > > > > pac4j
> > >>> >> >> > > > > > > > > provider will go into this version 0.7.0
> > >>> (dependency on
> > >>> >> the
> > >>> >> >> > > > > > > > 0.7.0-SNAPSHOT
> > >>> >> >> > > > > > > > > parent version).
> > >>> >> >> > > > > > > > >
> > >>> >> >> > > > > > > > > Just let me know if everything is ok and when
> > it's
> > >>> >> goind to
> > >>> >> >> > be
> > >>> >> >> > > > > > merged.
> > >>> >> >> > > > > > > > >
> > >>> >> >> > > > > > > > > Thanks.
> > >>> >> >> > > > > > > > > Best regards,
> > >>> >> >> > > > > > > > > Jérôme
> > >>> >> >> > > > > > > > >
> > >>> >> >> > > > > > > > >
> > >>> >> >> > > > > > > > >
> > >>> >> >> > > > > > > > >
> > >>> >> >> > > > > > > > > 2015-12-04 14:20 GMT+01:00 larry mccay <
> > >>> >> >> > larry.mccay@gmail.com
> > >>> >> >> > > >:
> > >>> >> >> > > > > > > > >
> > >>> >> >> > > > > > > > > > That ability to configure multiple mechanisms
> > >>> based on
> > >>> >> >> > > > clientName
> > >>> >> >> > > > > > is
> > >>> >> >> > > > > > > > > really
> > >>> >> >> > > > > > > > > > interesting for Knox.
> > >>> >> >> > > > > > > > > > Currently, we require separate topologies per
> > >>> >> >> > authentication
> > >>> >> >> > > > > > > mechanism.
> > >>> >> >> > > > > > > > > > The ability to configure them all in one is
> > >>> really
> > >>> >> great.
> > >>> >> >> > > > > > > > > >
> > >>> >> >> > > > > > > > > > We would need to think through the best way
> to
> > >>> provide
> > >>> >> >> the
> > >>> >> >> > > > > > clientName
> > >>> >> >> > > > > > > > > > parameter.
> > >>> >> >> > > > > > > > > > Since this is targeting KnoxSSO it can
> actually
> > >>> be
> > >>> >> added
> > >>> >> >> to
> > >>> >> >> > > the
> > >>> >> >> > > > > > > > > providerURL
> > >>> >> >> > > > > > > > > > used to redirect from the participating
> > >>> application.
> > >>> >> >> > > > > > > > > > Regardless of the authentication mechanism
> used
> > >>> each
> > >>> >> >> > > > application
> > >>> >> >> > > > > > will
> > >>> >> >> > > > > > > > > still
> > >>> >> >> > > > > > > > > > get the same JWT based cookie.
> > >>> >> >> > > > > > > > > >
> > >>> >> >> > > > > > > > > > I think that should work really nicely.
> > >>> >> >> > > > > > > > > >
> > >>> >> >> > > > > > > > > >
> > >>> >> >> > > > > > > > > > On Fri, Dec 4, 2015 at 7:17 AM, larry mccay <
> > >>> >> >> > > > > larry.mccay@gmail.com
> > >>> >> >> > > > > > >
> > >>> >> >> > > > > > > > > wrote:
> > >>> >> >> > > > > > > > > >
> > >>> >> >> > > > > > > > > > > Excellent, Jérôme.
> > >>> >> >> > > > > > > > > > > Thanks!
> > >>> >> >> > > > > > > > > > >
> > >>> >> >> > > > > > > > > > > On Fri, Dec 4, 2015 at 2:40 AM, Jérôme
> LELEU
> > <
> > >>> >> >> > > > leleuj@gmail.com
> > >>> >> >> > > > > >
> > >>> >> >> > > > > > > > wrote:
> > >>> >> >> > > > > > > > > > >
> > >>> >> >> > > > > > > > > > >> Hi,
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > > >> I will write how to configure the pac4j
> > >>> provider in
> > >>> >> >> the
> > >>> >> >> > > > > > > > documentation,
> > >>> >> >> > > > > > > > > > but
> > >>> >> >> > > > > > > > > > >> I can already give you some insights.
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > > >> My main goal is always to respect the key
> > >>> design
> > >>> >> >> > > principles
> > >>> >> >> > > > of
> > >>> >> >> > > > > > > pac4j
> > >>> >> >> > > > > > > > > > >> whatever the environment / framework in
> > which
> > >>> it is
> > >>> >> >> > > > > implemented.
> > >>> >> >> > > > > > > For
> > >>> >> >> > > > > > > > > > Knox,
> > >>> >> >> > > > > > > > > > >> I'm pretty happy with the use of the
> > j2e-pac4j
> > >>> >> >> library,
> > >>> >> >> > > > which
> > >>> >> >> > > > > > > means
> > >>> >> >> > > > > > > > > that
> > >>> >> >> > > > > > > > > > >> almost all the pac4j features are
> available,
> > >>> >> >> especially
> > >>> >> >> > > both
> > >>> >> >> > > > > > > direct
> > >>> >> >> > > > > > > > > and
> > >>> >> >> > > > > > > > > > >> indirect clients. So it can do what Shiro
> > >>> already
> > >>> >> does
> > >>> >> >> > but
> > >>> >> >> > > > > also,
> > >>> >> >> > > > > > > as
> > >>> >> >> > > > > > > > we
> > >>> >> >> > > > > > > > > > >> agreed together, supports remote
> > >>> authentications.
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > > >> It is only limited by what you can
> currently
> > >>> >> >> configure.
> > >>> >> >> > > And
> > >>> >> >> > > > > even
> > >>> >> >> > > > > > > > > > >> configuration is a pac4j feature as the
> CAS
> > >>> server
> > >>> >> has
> > >>> >> >> > the
> > >>> >> >> > > > > same
> > >>> >> >> > > > > > > > need.
> > >>> >> >> > > > > > > > > > >> Everything happens in this class:
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > >
> > >>> >> >> > > > > > > > >
> > >>> >> >> > > > > > > >
> > >>> >> >> > > > > > >
> > >>> >> >> > > > > >
> > >>> >> >> > > > >
> > >>> >> >> > > >
> > >>> >> >> > >
> > >>> >> >> >
> > >>> >> >>
> > >>> >>
> > >>>
> >
> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java
> > >>> >> >> > > > > > > > > > >> ,
> > >>> >> >> > > > > > > > > > >> which allows you to configure Facebook,
> > >>> Twitter, a
> > >>> >> CAS
> > >>> >> >> > > > > server, a
> > >>> >> >> > > > > > > > SAML
> > >>> >> >> > > > > > > > > > IdP
> > >>> >> >> > > > > > > > > > >> or an OpenID Connect provider. All the
> > >>> provided
> > >>> >> >> > parameters
> > >>> >> >> > > > to
> > >>> >> >> > > > > > the
> > >>> >> >> > > > > > > > > pac4j
> > >>> >> >> > > > > > > > > > >> provider are put into a Map and the
> > >>> >> >> > > ConfigPropertiesFactory
> > >>> >> >> > > > is
> > >>> >> >> > > > > > > built
> > >>> >> >> > > > > > > > > > with
> > >>> >> >> > > > > > > > > > >> this Map to return the built client (=
> > >>> >> authentication
> > >>> >> >> > > > > > mechanism).
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > > >> You have one more specific option for Knox
> > as
> > >>> a
> > >>> >> basic
> > >>> >> >> > > > > > > authentication
> > >>> >> >> > > > > > > > > > popup
> > >>> >> >> > > > > > > > > > >> where the username must match the
> password,
> > >>> you can
> > >>> >> >> > define
> > >>> >> >> > > > > that
> > >>> >> >> > > > > > > by:
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > > >> <param>
> > >>> >> >> > > > > > > > > > >> <name>clientName</name>
> > >>> >> >> > > > > > > > > > >> <value>testBasicAuth</value>
> > >>> >> >> > > > > > > > > > >> </param>
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > > >> It's for testing only.
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > > >> For a CAS server:
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > > >> <param>
> > >>> >> >> > > > > > > > > > >> <name>cas.loginUrl</name>
> > >>> >> >> > > > > > > > > > >> <value>
> > >>> >> https://casserverpac4j.herokuapp.com/login
> > >>> >> >> > > </value>
> > >>> >> >> > > > > > > > > > >> </param>
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > > >> Here are all the properties available for
> > >>> building
> > >>> >> >> > clients
> > >>> >> >> > > > > > (their
> > >>> >> >> > > > > > > > > > meaning
> > >>> >> >> > > > > > > > > > >> is obvious):
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > > >> facebook.id
> > >>> >> >> > > > > > > > > > >> facebook.secret
> > >>> >> >> > > > > > > > > > >> facebook.scope
> > >>> >> >> > > > > > > > > > >> facebook.fields
> > >>> >> >> > > > > > > > > > >> twitter.id
> > >>> >> >> > > > > > > > > > >> twitter.secret
> > >>> >> >> > > > > > > > > > >> saml.keystorePassword
> > >>> >> >> > > > > > > > > > >> saml.privateKeyPassword
> > >>> >> >> > > > > > > > > > >> saml.keystorePath
> > >>> >> >> > > > > > > > > > >> saml.identityProviderMetadataPath
> > >>> >> >> > > > > > > > > > >> saml.maximumAuthenticationLifetime
> > >>> >> >> > > > > > > > > > >> saml.serviceProviderEntityId
> > >>> >> >> > > > > > > > > > >> saml.serviceProviderMetadataPath
> > >>> >> >> > > > > > > > > > >> cas.loginUrl
> > >>> >> >> > > > > > > > > > >> cas.protocol
> > >>> >> >> > > > > > > > > > >> oidc.id
> > >>> >> >> > > > > > > > > > >> oidc.secret
> > >>> >> >> > > > > > > > > > >> oidc.discoveryUri
> > >>> >> >> > > > > > > > > > >> oidc.customParamKey1
> > >>> >> >> > > > > > > > > > >> oidc.customParamValue1
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > > >> If you define multiple clients, the first
> > one
> > >>> will
> > >>> >> be
> > >>> >> >> > used
> > >>> >> >> > > > for
> > >>> >> >> > > > > > > > > > >> authentication, but you can explicitly
> > choose
> > >>> the
> > >>> >> >> client
> > >>> >> >> > > you
> > >>> >> >> > > > > > want
> > >>> >> >> > > > > > > to
> > >>> >> >> > > > > > > > > use
> > >>> >> >> > > > > > > > > > >> via the clientName parameter, assuming you
> > >>> want to
> > >>> >> >> > switch
> > >>> >> >> > > > from
> > >>> >> >> > > > > > > > client
> > >>> >> >> > > > > > > > > > >> depending on environment for example.
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > > >> So if you want to add some new
> > authentication
> > >>> >> >> mechanism,
> > >>> >> >> > > you
> > >>> >> >> > > > > > must
> > >>> >> >> > > > > > > > > first
> > >>> >> >> > > > > > > > > > >> check that it is available in pac4j (if
> it's
> > >>> not,
> > >>> >> it's
> > >>> >> >> > > > another
> > >>> >> >> > > > > > > > > > discussion,
> > >>> >> >> > > > > > > > > > >> but generally, it is). Then, you'll need
> to
> > >>> upgrade
> > >>> >> >> the
> > >>> >> >> > > > > > > > > > >> ConfigPropertiesFactory by submitting a
> new
> > >>> pull
> > >>> >> >> request
> > >>> >> >> > > to
> > >>> >> >> > > > > the
> > >>> >> >> > > > > > > > pac4j
> > >>> >> >> > > > > > > > > > >> project (I can do it myself, but I'm sure
> > you
> > >>> >> could do
> > >>> >> >> > > that
> > >>> >> >> > > > > > > easily),
> > >>> >> >> > > > > > > > > > >> finally wait for the new pac4j release and
> > >>> switch
> > >>> >> >> pac4j
> > >>> >> >> > > > > versions
> > >>> >> >> > > > > > > in
> > >>> >> >> > > > > > > > > Knox
> > >>> >> >> > > > > > > > > > >> to
> > >>> >> >> > > > > > > > > > >> benefit from the new feature.
> > >>> >> >> > > > > > > > > > >> The good thing is that if someone related
> to
> > >>> the
> > >>> >> CAS
> > >>> >> >> > > server
> > >>> >> >> > > > > does
> > >>> >> >> > > > > > > the
> > >>> >> >> > > > > > > > > > same
> > >>> >> >> > > > > > > > > > >> thing for CAS (in pac4j), you will
> > >>> automatically
> > >>> >> get
> > >>> >> >> it
> > >>> >> >> > > when
> > >>> >> >> > > > > > > you'll
> > >>> >> >> > > > > > > > > > >> upgrade
> > >>> >> >> > > > > > > > > > >> pac4j.
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > > >> To go even further, replacing LDAP Shiro
> > >>> >> >> authentication
> > >>> >> >> > is
> > >>> >> >> > > > > just
> > >>> >> >> > > > > > a
> > >>> >> >> > > > > > > > > matter
> > >>> >> >> > > > > > > > > > >> of
> > >>> >> >> > > > > > > > > > >> making pac4j LDAP authentication available
> > via
> > >>> >> >> > > configuration
> > >>> >> >> > > > > > > > > parameters.
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > > >> I hope it was clear enough.
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > > >> Thanks.
> > >>> >> >> > > > > > > > > > >> Best regards,
> > >>> >> >> > > > > > > > > > >> Jérôme
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > > >> 2015-12-03 20:45 GMT+01:00 larry mccay <
> > >>> >> >> > > > larry.mccay@gmail.com
> > >>> >> >> > > > > >:
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > > >> > Excellent!
> > >>> >> >> > > > > > > > > > >> >
> > >>> >> >> > > > > > > > > > >> > I will carve out some time to do code
> > >>> review.
> > >>> >> >> > > > > > > > > > >> > We will need to get some insights into
> how
> > >>> to go
> > >>> >> >> about
> > >>> >> >> > > > > > testing:
> > >>> >> >> > > > > > > > > > >> >
> > >>> >> >> > > > > > > > > > >> > * is the CAS server going to be
> available
> > >>> for
> > >>> >> >> testing?
> > >>> >> >> > > > > > > > > > >> > * what are the specific and
> > >>> generic/standard (if
> > >>> >> >> any)
> > >>> >> >> > > > > > > > authentication
> > >>> >> >> > > > > > > > > > >> > mechanisms available - for instance:
> > >>> >> >> > > > > > > > > > >> > - Facebook, Google, LinkedIn and CAS
> > are
> > >>> >> >> specifics
> > >>> >> >> > > > > > > > > > >> > - OAuth 2, OpenID Connect, SAML are
> > >>> >> >> > > generic/standards
> > >>> >> >> > > > -
> > >>> >> >> > > > > > that
> > >>> >> >> > > > > > > > may
> > >>> >> >> > > > > > > > > > be
> > >>> >> >> > > > > > > > > > >> > used for the above specifics...
> > >>> >> >> > > > > > > > > > >> > * how do we test things other than CAS -
> > in
> > >>> >> terms of
> > >>> >> >> > > > getting
> > >>> >> >> > > > > > > > > > >> credentials,
> > >>> >> >> > > > > > > > > > >> > configuration, etc
> > >>> >> >> > > > > > > > > > >> >
> > >>> >> >> > > > > > > > > > >> > We could certainly do this is phases as
> > >>> well.
> > >>> >> >> > > > > > > > > > >> >
> > >>> >> >> > > > > > > > > > >> > If you can enumerate the things that
> > should
> > >>> work
> > >>> >> and
> > >>> >> >> > > > provide
> > >>> >> >> > > > > > > some
> > >>> >> >> > > > > > > > > > >> testing
> > >>> >> >> > > > > > > > > > >> > details for CAS or as many as possible
> and
> > >>> OpenID
> > >>> >> >> > > Connect
> > >>> >> >> > > > > then
> > >>> >> >> > > > > > > we
> > >>> >> >> > > > > > > > > can
> > >>> >> >> > > > > > > > > > >> test
> > >>> >> >> > > > > > > > > > >> > the specific implementations that you
> > >>> provide and
> > >>> >> >> > enable
> > >>> >> >> > > > the
> > >>> >> >> > > > > > > > testing
> > >>> >> >> > > > > > > > > > of
> > >>> >> >> > > > > > > > > > >> > another OpenID Connect effort that is in
> > the
> > >>> >> works
> > >>> >> >> in
> > >>> >> >> > > the
> > >>> >> >> > > > > > > > community.
> > >>> >> >> > > > > > > > > > >> >
> > >>> >> >> > > > > > > > > > >> > I'm not sure whether we want to commit
> > >>> >> contributions
> > >>> >> >> > > that
> > >>> >> >> > > > > are
> > >>> >> >> > > > > > > > > > dependent
> > >>> >> >> > > > > > > > > > >> on
> > >>> >> >> > > > > > > > > > >> > snapshots - we certainly can't release
> > with
> > >>> any
> > >>> >> such
> > >>> >> >> > > > > > > dependencies.
> > >>> >> >> > > > > > > > > > >> > I would hate to add a cleanup task to a
> > >>> release
> > >>> >> to
> > >>> >> >> > make
> > >>> >> >> > > > sure
> > >>> >> >> > > > > > > there
> > >>> >> >> > > > > > > > > are
> > >>> >> >> > > > > > > > > > >> no
> > >>> >> >> > > > > > > > > > >> > snapshots in there.
> > >>> >> >> > > > > > > > > > >> > We will probably wait until after the
> > pac4j
> > >>> >> releases
> > >>> >> >> > to
> > >>> >> >> > > > > > commit.
> > >>> >> >> > > > > > > > > > >> >
> > >>> >> >> > > > > > > > > > >> > I am really happy that this integration
> is
> > >>> >> happening
> > >>> >> >> > and
> > >>> >> >> > > > > that
> > >>> >> >> > > > > > it
> > >>> >> >> > > > > > > > > went
> > >>> >> >> > > > > > > > > > >> > rather smoothly.
> > >>> >> >> > > > > > > > > > >> > These sorts of authentication protocols
> > are
> > >>> >> complex
> > >>> >> >> > and
> > >>> >> >> > > I
> > >>> >> >> > > > > > think
> > >>> >> >> > > > > > > we
> > >>> >> >> > > > > > > > > > >> lined up
> > >>> >> >> > > > > > > > > > >> > pretty well overall.
> > >>> >> >> > > > > > > > > > >> >
> > >>> >> >> > > > > > > > > > >> > Thanks for your work!
> > >>> >> >> > > > > > > > > > >> >
> > >>> >> >> > > > > > > > > > >> > On Thu, Dec 3, 2015 at 2:28 PM, Jérôme
> > >>> LELEU <
> > >>> >> >> > > > > > leleuj@gmail.com>
> > >>> >> >> > > > > > > > > > wrote:
> > >>> >> >> > > > > > > > > > >> >
> > >>> >> >> > > > > > > > > > >> > > Hi,
> > >>> >> >> > > > > > > > > > >> > >
> > >>> >> >> > > > > > > > > > >> > > I just sync'ed with master, cleaned
> > >>> >> dependencies
> > >>> >> >> and
> > >>> >> >> > > > added
> > >>> >> >> > > > > > > > missing
> > >>> >> >> > > > > > > > > > >> > > Javadocs. Everything works correctly
> > now.
> > >>> Many
> > >>> >> >> > thanks.
> > >>> >> >> > > > > > > > > > >> > >
> > >>> >> >> > > > > > > > > > >> > > The pull request is ready for a full
> > code
> > >>> >> review:
> > >>> >> >> > > > > > > > > > >> > > https://github.com/apache/knox/pull/2
> > >>> >> >> > > > > > > > > > >> > >
> > >>> >> >> > > > > > > > > > >> > > I'll write the documentation after the
> > >>> pac4j
> > >>> >> >> > releases
> > >>> >> >> > > (I
> > >>> >> >> > > > > > hope
> > >>> >> >> > > > > > > > next
> > >>> >> >> > > > > > > > > > >> week).
> > >>> >> >> > > > > > > > > > >> > >
> > >>> >> >> > > > > > > > > > >> > > Thanks.
> > >>> >> >> > > > > > > > > > >> > > Best regards,
> > >>> >> >> > > > > > > > > > >> > > Jérôme
> > >>> >> >> > > > > > > > > > >> > >
> > >>> >> >> > > > > > > > > > >> > >
> > >>> >> >> > > > > > > > > > >> > > 2015-12-02 19:18 GMT+01:00 larry
> mccay <
> > >>> >> >> > > > > > larry.mccay@gmail.com
> > >>> >> >> > > > > > > >:
> > >>> >> >> > > > > > > > > > >> > >
> > >>> >> >> > > > > > > > > > >> > > > Fixed in
> > >>> >> >> > > > https://issues.apache.org/jira/browse/KNOX-636
> > >>> >> >> > > > > .
> > >>> >> >> > > > > > > > > > >> > > >
> > >>> >> >> > > > > > > > > > >> > > > On Wed, Dec 2, 2015 at 12:42 PM,
> larry
> > >>> mccay
> > >>> >> <
> > >>> >> >> > > > > > > > > > larry.mccay@gmail.com
> > >>> >> >> > > > > > > > > > >> >
> > >>> >> >> > > > > > > > > > >> > > > wrote:
> > >>> >> >> > > > > > > > > > >> > > >
> > >>> >> >> > > > > > > > > > >> > > > > Sure - I can file a JIRA and
> commit
> > a
> > >>> fix.
> > >>> >> >> > > > > > > > > > >> > > > >
> > >>> >> >> > > > > > > > > > >> > > > > The secret generation should be
> done
> > >>> in one
> > >>> >> >> > > instance
> > >>> >> >> > > > > and
> > >>> >> >> > > > > > > > > > >> replicated
> > >>> >> >> > > > > > > > > > >> > > > across
> > >>> >> >> > > > > > > > > > >> > > > > others.
> > >>> >> >> > > > > > > > > > >> > > > > This replication/management of the
> > >>> >> credential
> > >>> >> >> > > stores
> > >>> >> >> > > > > is
> > >>> >> >> > > > > > > > > outside
> > >>> >> >> > > > > > > > > > of
> > >>> >> >> > > > > > > > > > >> > the
> > >>> >> >> > > > > > > > > > >> > > > > scope of Knox itself as of now.
> > >>> >> >> > > > > > > > > > >> > > > >
> > >>> >> >> > > > > > > > > > >> > > > > Documentation is done in markdown
> > and
> > >>> is
> > >>> >> >> > > > contributing
> > >>> >> >> > > > > > > > details
> > >>> >> >> > > > > > > > > > are
> > >>> >> >> > > > > > > > > > >> > > > > available at:
> > >>> >> >> > > > > > > > > > >> > > > >
> > >>> >> >> > > > > > > > > > >> > > >
> > >>> >> >> > > > > > > > > > >> > >
> > >>> >> >> > > > > > > > > > >> >
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > >
> > >>> >> >> > > > > > > > >
> > >>> >> >> > > > > > > >
> > >>> >> >> > > > > > >
> > >>> >> >> > > > > >
> > >>> >> >> > > > >
> > >>> >> >> > > >
> > >>> >> >> > >
> > >>> >> >> >
> > >>> >> >>
> > >>> >>
> > >>>
> >
> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
> > >>> >> >> > > > > > > > > > >> > > > >
> > >>> >> >> > > > > > > > > > >> > > > > Which should give you a general
> > idea.
> > >>> >> >> > > > > > > > > > >> > > > >
> > >>> >> >> > > > > > > > > > >> > > > > Find an example like:
> > >>> ./trunk/books/0.7.0/
> > >>> >> >> > > > > > > > > > >> > > config_preauth_sso_provider.md
> > >>> >> >> > > > > > > > > > >> > > > >
> > >>> >> >> > > > > > > > > > >> > > > > For an example of typical content
> > and
> > >>> >> format.
> > >>> >> >> > > > > > > > > > >> > > > >
> > >>> >> >> > > > > > > > > > >> > > > > Here is how that example renders:
> > >>> >> >> > > > > > > > > > >> > > > >
> > >>> >> >> > > > > > > > > > >> > > >
> > >>> >> >> > > > > > > > > > >> > >
> > >>> >> >> > > > > > > > > > >> >
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > >
> > >>> >> >> > > > > > > > >
> > >>> >> >> > > > > > > >
> > >>> >> >> > > > > > >
> > >>> >> >> > > > > >
> > >>> >> >> > > > >
> > >>> >> >> > > >
> > >>> >> >> > >
> > >>> >> >> >
> > >>> >> >>
> > >>> >>
> > >>>
> >
> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
> > >>> >> >> > > > > > > > > > >> > > > >
> > >>> >> >> > > > > > > > > > >> > > > > You'll need to tie it into the
> rest
> > >>> of the
> > >>> >> >> book
> > >>> >> >> > -
> > >>> >> >> > > > just
> > >>> >> >> > > > > > > grep
> > >>> >> >> > > > > > > > > for
> > >>> >> >> > > > > > > > > > >> where
> > >>> >> >> > > > > > > > > > >> > > > that
> > >>> >> >> > > > > > > > > > >> > > > > filename is referenced.
> > >>> >> >> > > > > > > > > > >> > > > > To test how it renders build the
> > site
> > >>> with:
> > >>> >> >> > "ant"
> > >>> >> >> > > > and
> > >>> >> >> > > > > > note
> > >>> >> >> > > > > > > > the
> > >>> >> >> > > > > > > > > > >> url to
> > >>> >> >> > > > > > > > > > >> > > the
> > >>> >> >> > > > > > > > > > >> > > > > 0.7.0 book.
> > >>> >> >> > > > > > > > > > >> > > > >
> > >>> >> >> > > > > > > > > > >> > > > >
> > >>> >> >> > > > > > > > > > >> > > > > On Wed, Dec 2, 2015 at 12:12 PM,
> > >>> Jérôme
> > >>> >> LELEU
> > >>> >> >> <
> > >>> >> >> > > > > > > > > leleuj@gmail.com
> > >>> >> >> > > > > > > > > > >
> > >>> >> >> > > > > > > > > > >> > > wrote:
> > >>> >> >> > > > > > > > > > >> > > > >
> > >>> >> >> > > > > > > > > > >> > > > >> Hi,
> > >>> >> >> > > > > > > > > > >> > > > >>
> > >>> >> >> > > > > > > > > > >> > > > >> Why it doesn't work for pac4j
> while
> > >>> it
> > >>> >> works
> > >>> >> >> > for
> > >>> >> >> > > > > others
> > >>> >> >> > > > > > > is
> > >>> >> >> > > > > > > > a
> > >>> >> >> > > > > > > > > > bit
> > >>> >> >> > > > > > > > > > >> > > strange
> > >>> >> >> > > > > > > > > > >> > > > >> to
> > >>> >> >> > > > > > > > > > >> > > > >> me, but if you have the patch in
> > >>> front of
> > >>> >> >> your
> > >>> >> >> > > > eyes,
> > >>> >> >> > > > > > I'd
> > >>> >> >> > > > > > > > > rather
> > >>> >> >> > > > > > > > > > >> > prefer
> > >>> >> >> > > > > > > > > > >> > > > you
> > >>> >> >> > > > > > > > > > >> > > > >> to commit it. In all cases, I'll
> > >>> sync with
> > >>> >> >> the
> > >>> >> >> > > > > master.
> > >>> >> >> > > > > > > > > > >> > > > >>
> > >>> >> >> > > > > > > > > > >> > > > >> There was one question you didn't
> > >>> answer
> > >>> >> >> > > > previously:
> > >>> >> >> > > > > is
> > >>> >> >> > > > > > > the
> > >>> >> >> > > > > > > > > > >> password
> > >>> >> >> > > > > > > > > > >> > > > >> generated for the pac4j provider
> > the
> > >>> same
> > >>> >> >> > across
> > >>> >> >> > > > all
> > >>> >> >> > > > > > > > gateway
> > >>> >> >> > > > > > > > > > >> > > instances?
> > >>> >> >> > > > > > > > > > >> > > > >> Because I expect to have the same
> > >>> value
> > >>> >> as I
> > >>> >> >> > use
> > >>> >> >> > > it
> > >>> >> >> > > > > to
> > >>> >> >> > > > > > > > > encrypt
> > >>> >> >> > > > > > > > > > /
> > >>> >> >> > > > > > > > > > >> > > decrypt
> > >>> >> >> > > > > > > > > > >> > > > >> data.
> > >>> >> >> > > > > > > > > > >> > > > >>
> > >>> >> >> > > > > > > > > > >> > > > >> I will add the Javadoc. After
> that,
> > >>> you
> > >>> >> can
> > >>> >> >> > > review
> > >>> >> >> > > > > the
> > >>> >> >> > > > > > > pull
> > >>> >> >> > > > > > > > > > >> request
> > >>> >> >> > > > > > > > > > >> > > more
> > >>> >> >> > > > > > > > > > >> > > > >> completely.
> > >>> >> >> > > > > > > > > > >> > > > >>
> > >>> >> >> > > > > > > > > > >> > > > >> What do you expect for the
> > >>> documentation?
> > >>> >> >> > > > > > > > > > >> > > > >>
> > >>> >> >> > > > > > > > > > >> > > > >> Notice that pac4j dependencies
> are
> > >>> still
> > >>> >> >> > > snapshots,
> > >>> >> >> > > > > but
> > >>> >> >> > > > > > > > they
> > >>> >> >> > > > > > > > > > >> will be
> > >>> >> >> > > > > > > > > > >> > > > >> released in a week or two.
> > >>> >> >> > > > > > > > > > >> > > > >>
> > >>> >> >> > > > > > > > > > >> > > > >> Thanks.
> > >>> >> >> > > > > > > > > > >> > > > >> Best regards,
> > >>> >> >> > > > > > > > > > >> > > > >> Jérôme
> > >>> >> >> > > > > > > > > > >> > > > >>
> > >>> >> >> > > > > > > > > > >> > > > >>
> > >>> >> >> > > > > > > > > > >> > > > >> 2015-12-02 17:51 GMT+01:00 larry
> > >>> mccay <
> > >>> >> >> > > > > > > > > larry.mccay@gmail.com
> > >>> >> >> > > > > > > > > > >:
> > >>> >> >> > > > > > > > > > >> > > > >>
> > >>> >> >> > > > > > > > > > >> > > > >> > Jérôme -
> > >>> >> >> > > > > > > > > > >> > > > >> >
> > >>> >> >> > > > > > > > > > >> > > > >> > If you would like to add that
> > >>> change as
> > >>> >> >> part
> > >>> >> >> > of
> > >>> >> >> > > > > your
> > >>> >> >> > > > > > > > patch
> > >>> >> >> > > > > > > > > or
> > >>> >> >> > > > > > > > > > >> as a
> > >>> >> >> > > > > > > > > > >> > > > >> > separately filed JIRA to fix a
> > bug
> > >>> that
> > >>> >> >> would
> > >>> >> >> > > > > > certainly
> > >>> >> >> > > > > > > > be
> > >>> >> >> > > > > > > > > > >> > welcomed.
> > >>> >> >> > > > > > > > > > >> > > > >> > Otherwise, I can do it.
> > >>> >> >> > > > > > > > > > >> > > > >> >
> > >>> >> >> > > > > > > > > > >> > > > >> > Let me know.
> > >>> >> >> > > > > > > > > > >> > > > >> >
> > >>> >> >> > > > > > > > > > >> > > > >> > thanks,
> > >>> >> >> > > > > > > > > > >> > > > >> >
> > >>> >> >> > > > > > > > > > >> > > > >> > --larry
> > >>> >> >> > > > > > > > > > >> > > > >> >
> > >>> >> >> > > > > > > > > > >> > > > >> > On Wed, Dec 2, 2015 at 11:44
> AM,
> > >>> larry
> > >>> >> >> mccay
> > >>> >> >> > <
> > >>> >> >> > > > > > > > > > >> > larry.mccay@gmail.com
> > >>> >> >> > > > > > > > > > >> > > >
> > >>> >> >> > > > > > > > > > >> > > > >> > wrote:
> > >>> >> >> > > > > > > > > > >> > > > >> >
> > >>> >> >> > > > > > > > > > >> > > > >> > > Okay - I had to add an
> override
> > >>> of
> > >>> >> >> > > > > > getUserPrincipal()
> > >>> >> >> > > > > > > > to
> > >>> >> >> > > > > > > > > > the
> > >>> >> >> > > > > > > > > > >> > > > >> > >
> > >>> >> IdentityAsserterHttpServletRequestWrapper
> > >>> >> >> > and
> > >>> >> >> > > > > > return
> > >>> >> >> > > > > > > > the
> > >>> >> >> > > > > > > > > > >> member
> > >>> >> >> > > > > > > > > > >> > > > >> variable
> > >>> >> >> > > > > > > > > > >> > > > >> > > username and it works like a
> > >>> charm.
> > >>> >> >> > > > > > > > > > >> > > > >> > >
> > >>> >> >> > > > > > > > > > >> > > > >> > > Why I haven't seen this same
> > >>> behavior
> > >>> >> >> with
> > >>> >> >> > > > other
> > >>> >> >> > > > > > > > > providers
> > >>> >> >> > > > > > > > > > >> is a
> > >>> >> >> > > > > > > > > > >> > > bit
> > >>> >> >> > > > > > > > > > >> > > > >> of a
> > >>> >> >> > > > > > > > > > >> > > > >> > > mystery but they must be
> adding
> > >>> other
> > >>> >> >> > > wrappers
> > >>> >> >> > > > > that
> > >>> >> >> > > > > > > > > handle
> > >>> >> >> > > > > > > > > > >> it.
> > >>> >> >> > > > > > > > > > >> > > > >> > > This is quite cool, Jérôme!
> > >>> >> >> > > > > > > > > > >> > > > >> > >
> > >>> >> >> > > > > > > > > > >> > > > >> > > On Wed, Dec 2, 2015 at 10:41
> > AM,
> > >>> larry
> > >>> >> >> > mccay
> > >>> >> >> > > <
> > >>> >> >> > > > > > > > > > >> > > larry.mccay@gmail.com
> > >>> >> >> > > > > > > > > > >> > > > >
> > >>> >> >> > > > > > > > > > >> > > > >> > > wrote:
> > >>> >> >> > > > > > > > > > >> > > > >> > >
> > >>> >> >> > > > > > > > > > >> > > > >> > >> That was it - thanks!
> > >>> >> >> > > > > > > > > > >> > > > >> > >>
> > >>> >> >> > > > > > > > > > >> > > > >> > >> On Wed, Dec 2, 2015 at 10:20
> > AM,
> > >>> >> Jérôme
> > >>> >> >> > > LELEU
> > >>> >> >> > > > <
> > >>> >> >> > > > > > > > > > >> > leleuj@gmail.com>
> > >>> >> >> > > > > > > > > > >> > > > >> wrote:
> > >>> >> >> > > > > > > > > > >> > > > >> > >>
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> This is my exact command
> > line:
> > >>> mvn
> > >>> >> >> > > -Prelease
> > >>> >> >> > > > > > clean
> > >>> >> >> > > > > > > > > > install
> > >>> >> >> > > > > > > > > > >> > > > >> -DskipTests
> > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> You use an internal Maven
> > >>> >> repository to
> > >>> >> >> > > fetch
> > >>> >> >> > > > > > > > > > dependencies
> > >>> >> >> > > > > > > > > > >> > from
> > >>> >> >> > > > > > > > > > >> > > > >> > internet:
> > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > >>> >> >> > > > > > > > > > >> > >
> > >>> >> >> > > > > > > >
> > >>> >> >> > >
> > >>> http://nexus-private.hortonworks.com/nexus/content/groups/public/
> > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> Does this repository have
> > >>> access to
> > >>> >> the
> > >>> >> >> > > > remote
> > >>> >> >> > > > > > > > > Snapshots
> > >>> >> >> > > > > > > > > > >> > > Sonatype
> > >>> >> >> > > > > > > > > > >> > > > >> repo?
> > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> 2015-12-02 16:16 GMT+01:00
> > >>> larry
> > >>> >> mccay
> > >>> >> >> <
> > >>> >> >> > > > > > > > > > >> larry.mccay@gmail.com
> > >>> >> >> > > > > > > > > > >> > >:
> > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > hmmm - I used:
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > mvn clean install
> > >>> -DskipTests=true
> > >>> >> >> > > > -Prelease
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > The repository entry is
> in
> > >>> there
> > >>> >> >> > already.
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > No worky.
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > On Wed, Dec 2, 2015 at
> > 10:12
> > >>> AM,
> > >>> >> >> Jérôme
> > >>> >> >> > > > > LELEU <
> > >>> >> >> > > > > > > > > > >> > > leleuj@gmail.com
> > >>> >> >> > > > > > > > > > >> > > > >
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> wrote:
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Hi,
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > You need the j2e-pac4j
> > >>> >> dependencies
> > >>> >> >> > as
> > >>> >> >> > > > well
> > >>> >> >> > > > > > as
> > >>> >> >> > > > > > > > the
> > >>> >> >> > > > > > > > > > >> pac4j-*
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> dependencies,
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > but you don't need to
> > >>> build them
> > >>> >> >> > > locally
> > >>> >> >> > > > > > > > > (hopefully).
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > But you need a
> dependency
> > >>> on the
> > >>> >> >> > > Sonatype
> > >>> >> >> > > > > > > > snapshots
> > >>> >> >> > > > > > > > > > >> > > repository
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> (where the
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > snapshot versions are
> > >>> hosted),
> > >>> >> >> which
> > >>> >> >> > is
> > >>> >> >> > > > > added
> > >>> >> >> > > > > > > for
> > >>> >> >> > > > > > > > > > >> Maven in
> > >>> >> >> > > > > > > > > > >> > > the
> > >>> >> >> > > > > > > > > > >> > > > >> root
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > pom.xml:
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > >>> >> >> > > > > > > > > > >> > > > >> >
> > >>> >> >> > > > > > > > > > >> > > > >>
> > >>> >> >> > > > > > > > > > >> > > >
> > >>> >> >> > > > > > > > > > >> > >
> > >>> >> >> > > > > > > > > > >> >
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > >
> > >>> >> >> > > > > > > > >
> > >>> >> >> > > > > > > >
> > >>> >> >> > > > > > >
> > >>> >> >> > > > > >
> > >>> >> >> > > > >
> > >>> >> >> > > >
> > >>> >> >> > >
> > >>> >> >> >
> > >>> >> >>
> > >>> >>
> > >>>
> >
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > If you use Ant for the
> > >>> build,
> > >>> >> there
> > >>> >> >> > is
> > >>> >> >> > > > > maybe
> > >>> >> >> > > > > > a
> > >>> >> >> > > > > > > > > glitch
> > >>> >> >> > > > > > > > > > >> to
> > >>> >> >> > > > > > > > > > >> > > find
> > >>> >> >> > > > > > > > > > >> > > > >> the
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > Sonatype
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Maven repo.
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Thanks.
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Best regards,
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Jérôme
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > 2015-12-02 16:06
> > GMT+01:00
> > >>> larry
> > >>> >> >> > mccay
> > >>> >> >> > > <
> > >>> >> >> > > > > > > > > > >> > > larry.mccay@gmail.com
> > >>> >> >> > > > > > > > > > >> > > > >:
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > 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.mccay@gmail.com>
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > wrote:
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > >
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > >
> > >>> >> gateway-provider-security-pac4j
> > >>> >> >> > > > doesn't
> > >>> >> >> > > > > > > > build -
> > >>> >> >> > > > > > > > > > do
> > >>> >> >> > > > > > > > > > >> you
> > >>> >> >> > > > > > > > > > >> > > > have
> > >>> >> >> > > > > > > > > > >> > > > >> a
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> pending
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > > change for your
> > >>> pom.xml or
> > >>> >> >> > > something?
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > >
> > >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> > >>> >> >> > > > > > > > > > >> > > > >> > >>>
> > >>> >> >> > > > > > > > > > >> > > > >> > >>
> > >>> >> >> > > > > > > > > > >> > > > >> > >>
> > >>> >> >> > > > > > > > > > >> > > > >> > >
> > >>> >> >> > > > > > > > > > >> > > > >> >
> > >>> >> >> > > > > > > > > > >> > > > >>
> > >>> >> >> > > > > > > > > > >> > > > >
> > >>> >> >> > > > > > > > > > >> > > > >
> > >>> >> >> > > > > > > > > > >> > > >
> > >>> >> >> > > > > > > > > > >> > >
> > >>> >> >> > > > > > > > > > >> >
> > >>> >> >> > > > > > > > > > >>
> > >>> >> >> > > > > > > > > > >
> > >>> >> >> > > > > > > > > > >
> > >>> >> >> > > > > > > > > >
> > >>> >> >> > > > > > > > >
> > >>> >> >> > > > > > > >
> > >>> >> >> > > > > > >
> > >>> >> >> > > > > >
> > >>> >> >> > > > >
> > >>> >> >> > > >
> > >>> >> >> > >
> > >>> >> >> >
> > >>> >> >>
> > >>> >>
> > >>>
> > >>
> > >>
> > >
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Hi,
Yes, the documentation is a bit too light. But you guessed it right: we
need to have a keystore for encryption.
The saml.identityProviderMetadataPath can point to a local resource or to a
remote one, using the right prefix: resource:, file: or an url (by default,
it is a file path). This must be documented though.
With Okta, I used the defined url (Single Sign On URL = Recipient URL =
Destination URL) for the serviceProviderEntityId, but I think it may
depends on IdP as well. Reading the spec, it must be an URI, but I'm not
sure if the SP metadata should be really available on this url. For Okta,
it doesn't matter.
According to your SAML configuration, the SP metadata will be generated
somewhere and this somewhere can be defined via the
serviceProviderMetadataPath parameter. You generally need to update your
metadata to the IdP (not required for Okta though). Both the SP and IdP
must know each other.
When writing the documentation, I went fast on these parameters with the
feeling they were regular ones, but indeed, the description in the Knox
manual is not enough. This is somehow a bit normal as the real
documentation for SAML is on the SAML wiki:
https://github.com/pac4j/pac4j/wiki/Clients#details-for-saml-support
So I propose to keep the Knox documentation mostly "as is", but add links
to the pac4j wiki (where I could more easily made updates). All pac4j
integrations need this documentation so it's better to centralize it, from
my point of view. What do you think?
Thanks.
Best regards,
Jérôme
2016-01-13 19:37 GMT+01:00 larry mccay <lm...@apache.org>:
> Hi Jérôme -
>
> I'm trying to configure the pac4j provider for an okta "application" that I
> created.
> The following (from KNOX-642 docs patch) isn't quite enough to make it
> clear to me how to go about doing so:
>
> +saml.keystorePassword | Password of the keystore (storepass)
> +saml.privateKeyPassword | Password for the private key (keypass)
> +saml.keystorePath | Path of the keystore
> +saml.identityProviderMetadataPath | Path of the identity
> provider metadata
> +saml.maximumAuthenticationLifetime | Maximum lifetime for
> authentication
> +saml.serviceProviderEntityId | Identifier of the service
> provider
> +saml.serviceProviderMetadataPath | Path of the service provider
> metadata
>
> I assume that I can use the gateway.jks keystore and the gateway-identity
> keypair to do the request signing and that that information is what is
> needed for the first 3 params. Unfortunately, I don't see any use of
> gateway services to get the master secret therefore it needs to be in clear
> text here. This won't work - but may not be a show stopper for committing
> to master as long as we follow up with a fix.
>
> Can saml.identityProviderMetadataPath point to a remote location or does it
> have to be local to the SP application. This would likely require it to be
> on the local filesystem, provisioned by the contributor into the generated
> web app or in some central location via NFS or something like that.
>
> The okta application that I created is called KnoxSSO - is that the value
> for saml.serviceProviderEntityId?
>
> The saml.serviceProviderMetadataPath has the same questions as the metadata
> for the IDP. In addition, is there a sample metadata file that we can
> provide for the use of pac4j with KnoxSSO?
>
> I think that getting this working and clean (no clear text passwords) will
> make a great feature and blog for featuring pac4j provider and the 0.8.0
> release. So, let's try and iron this out clearly.
>
> I would really like to get this working and committed in the next couple
> days to free us up for follow up items. In particular we need time to
> figure out whether the identity assertion providers that we currently have
> will suffice for an apache release that is featuring this new
> functionality.
>
> I will also add the above comments/questions to the JIRA for visibility.
>
> thanks,
>
> --larry
>
> On Fri, Jan 8, 2016 at 12:40 PM, larry mccay <lm...@apache.org> wrote:
>
> > Jérôme -
> >
> > My testing of OpenID Connect is blocked.
> > Can you see the comments in KNOX-641?
> >
> > thanks,
> >
> > --larry
> >
> > On Wed, Jan 6, 2016 at 2:30 PM, larry mccay <la...@gmail.com>
> wrote:
> >
> >> Jérôme -
> >>
> >> Please see the comments on KNOX-641.
> >>
> >> thanks,
> >>
> >> --larry
> >>
> >> On Wed, Jan 6, 2016 at 11:24 AM, Kevin Minder <
> >> kevin.minder@hortonworks.com> wrote:
> >>
> >>> I can certainly appreciate the issue of including external resources in
> >>> automated tests. Nothing has driven me more crazy over the years. The
> >>> flip side of this of course is not finding out about a breakage until
> >>> someone is willing to go through the manual testing which will
> typically
> >>> happen just before a release. Also the implication is that these
> testing
> >>> procedures must be very will documented so that they can be continue
> to be
> >>> run once any of us are no longer active in the project.
> >>>
> >>>
> >>>
> >>> On 1/6/16, 2:12 AM, "Jérôme LELEU" <le...@gmail.com> wrote:
> >>>
> >>> >Hi,
> >>> >
> >>> >Yes, you can hit the CAS server at Heroku. Notice it's a Heroku free
> >>> server
> >>> >so it needs to be re-activated first (it takes a couple of seconds).
> So
> >>> for
> >>> >a UI test, you should first hit it, wait 30 seconds and then perform
> the
> >>> >test.
> >>> >
> >>> >Just my 2 cents:
> >>> >Using automated UI tests was my first strategy for pac4j but I
> finally
> >>> >gave up because public providers change very often, at least enough to
> >>> make
> >>> >the maintenance tests a nightmare. Currently, I'm using manual tests
> >>> (the
> >>> >same for all demos), it takes me around 5 minutes to play them all by
> >>> hand
> >>> >(for a demo) and I launched manually the UI tests I have for every
> major
> >>> >pac4j release. Just to say UI tests are not that easy. For a CAS
> server,
> >>> >it's fairly feasible as the CAS server and protocol change rarely.
> >>> >That's why for Knox, I did some compromise with a simulated web test
> >>> (based
> >>> >on the basic auth). See:
> >>> >
> >>>
> https://github.com/apache/knox/pull/2/files#diff-d0c880ca71b310dbe57975c577535e97R47
> >>> >
> >>> >Thanks.
> >>> >Best regards,
> >>> >Jérôme
> >>> >
> >>> >
> >>> >
> >>> >2016-01-05 21:20 GMT+01:00 Kevin Minder <kevin.minder@hortonworks.com
> >:
> >>> >
> >>> >> From my perspective it would be ideal if there were some automatable
> >>> >> functional tests for this. I’m not advocating that these be
> something
> >>> >> included in “mvn clean install” as that is running too long as it
> is.
> >>> >> Given that I don’t have as much context as Larry, I have some
> >>> questions
> >>> >> about what this would take. Lets say we had permission to hit
> >>> >> https://casserverpac4j.herokuapp.com/login as part of some low
> >>> frequency
> >>> >> automated tests (e.g. Once nighty). What static credentials and
> >>> other test
> >>> >> automation infrastructure would need to be implemented in support of
> >>> this?
> >>> >> I understand that the test suite would require at a minimum
> >>> >> 1) a test driver
> >>> >> 2) a protected mock UI and
> >>> >> 3) an appropriately configured Knox
> >>> >> 4) a profile enabled maven module
> >>> >> 5) an Apache jenkins job
> >>> >> but I’m sure I’m missing other things. I’m certainly willing to
> help
> >>> >> setup the skeleton infrastructure (e.g. test driver, mock UI, maven
> >>> module,
> >>> >> jenkins job)
> >>> >>
> >>> >>
> >>> >>
> >>> >> On 1/5/16, 2:54 PM, "larry mccay" <la...@gmail.com> wrote:
> >>> >>
> >>> >> >Okay, very good.
> >>> >> >I've used TestShib for the picketlink provider - thanks for the
> >>> pointers!
> >>> >> >
> >>> >> >On Tue, Jan 5, 2016 at 1:38 PM, Jérôme LELEU <le...@gmail.com>
> >>> wrote:
> >>> >> >
> >>> >> >> The online CAS server (
> https://casserverpac4j.herokuapp.com/login)
> >>> uses
> >>> >> >> the
> >>> >> >> CAS protocol. SAML support can be tested using some online IdP
> like
> >>> >> Okta,
> >>> >> >> TestShib, OpenFeide, Ssocircle...
> >>> >> >>
> >>> >> >>
> >>> >> >> 2016-01-05 17:32 GMT+01:00 larry mccay <la...@gmail.com>:
> >>> >> >>
> >>> >> >> > Great - thanks for that pointer!
> >>> >> >> >
> >>> >> >> > I will take a look at that and help drive the release related
> >>> testing.
> >>> >> >> > Merge testing will be gated on CAS server (is this SAML or CAS
> >>> >> protocol?)
> >>> >> >> > and testBasicAuth.
> >>> >> >> >
> >>> >> >> > On Tue, Jan 5, 2016 at 10:52 AM, Jérôme LELEU <
> leleuj@gmail.com>
> >>> >> wrote:
> >>> >> >> >
> >>> >> >> > > Hi,
> >>> >> >> > >
> >>> >> >> > > Glad to hear back from you!
> >>> >> >> > >
> >>> >> >> > > The core pac4j project is fully tested by unit tests (and
> some
> >>> >> >> > integration
> >>> >> >> > > tests I run for major version), then all pac4j
> implementations
> >>> are
> >>> >> each
> >>> >> >> > > tested by the appropriate demo: j2e-pac4j-demo tests
> j2e-pac4j,
> >>> >> >> > > spring-webmvc-pac4j-demo tests spring-webmvc-pac4j, etc.
> >>> >> >> > >
> >>> >> >> > > So if you take a look at:
> >>> >> >> > >
> >>> >> >> > >
> >>> >> >> >
> >>> >> >>
> >>> >>
> >>>
> https://github.com/pac4j/j2e-pac4j-demo/blob/master/src/main/java/org/pac4j/demo/j2e/config/DemoConfigFactory.java#L27
> >>> >> >> > > (for example), you have all the required information to test.
> >>> >> >> > >
> >>> >> >> > > I can do that on my own, but it can be good for the Knox
> >>> community
> >>> >> to
> >>> >> >> > start
> >>> >> >> > > working / testing the pac4j support. It's up to yoy.
> >>> >> >> > >
> >>> >> >> > > Thanks.
> >>> >> >> > > Best regards,
> >>> >> >> > > Jérôme
> >>> >> >> > >
> >>> >> >> > >
> >>> >> >> > > 2016-01-05 16:11 GMT+01:00 larry mccay <
> larry.mccay@gmail.com
> >>> >:
> >>> >> >> > >
> >>> >> >> > > > Hello Jérôme -
> >>> >> >> > > >
> >>> >> >> > > > Happy New Year!
> >>> >> >> > > >
> >>> >> >> > > > I am going to start reviewing your updates today,
> hopefully.
> >>> >> >> > > > I was thinking that we need to start discussions on what
> the
> >>> key
> >>> >> >> > usecases
> >>> >> >> > > > are and how to go about testing them.
> >>> >> >> > > > We can certainly test the testBasicAuth and against the
> >>> hosted CAS
> >>> >> >> > server
> >>> >> >> > > > but what about FB, openid, OAuth, etc?
> >>> >> >> > > >
> >>> >> >> > > > I'm not sure that FB would be a key feature but OpenID
> >>> Connect and
> >>> >> >> > OAuth
> >>> >> >> > > > would be - as is SAML.
> >>> >> >> > > > I think CAS buys us SAML testing - assuming that the
> >>> >> configuration of
> >>> >> >> > the
> >>> >> >> > > > hosted server is actually a SAML 2 instance.
> >>> >> >> > > >
> >>> >> >> > > > What about the others?
> >>> >> >> > > >
> >>> >> >> > > > I don't know that we need to be able to test them all
> before
> >>> merge
> >>> >> >> but
> >>> >> >> > > some
> >>> >> >> > > > sort of manual verification would be great.
> >>> >> >> > > > We would need to be able to test them before the next
> release
> >>> >> which
> >>> >> >> > would
> >>> >> >> > > > be featuring the pac4j functionality.
> >>> >> >> > > >
> >>> >> >> > > > Maybe you can describe how you go about testing such things
> >>> for
> >>> >> the
> >>> >> >> > pac4j
> >>> >> >> > > > project itself?
> >>> >> >> > > >
> >>> >> >> > > > thanks,
> >>> >> >> > > >
> >>> >> >> > > > --larry
> >>> >> >> > > >
> >>> >> >> > > >
> >>> >> >> > > > On Tue, Jan 5, 2016 at 9:55 AM, Jérôme LELEU <
> >>> leleuj@gmail.com>
> >>> >> >> wrote:
> >>> >> >> > > >
> >>> >> >> > > > > Hi,
> >>> >> >> > > > >
> >>> >> >> > > > > Happy new year!
> >>> >> >> > > > >
> >>> >> >> > > > > A few days ago, I updated my patch of the pac4j gateway
> >>> provider
> >>> >> >> > > > according
> >>> >> >> > > > > to all comments on
> >>> >> https://issues.apache.org/jira/browse/KNOX-641
> >>> >> >> as
> >>> >> >> > > > well
> >>> >> >> > > > > as the documentation on KNOX-642.
> >>> >> >> > > > >
> >>> >> >> > > > > Is everything ok for the merge?
> >>> >> >> > > > >
> >>> >> >> > > > > Thanks.
> >>> >> >> > > > > Best regards,
> >>> >> >> > > > > Jérôme
> >>> >> >> > > > >
> >>> >> >> > > > >
> >>> >> >> > > > > 2015-12-14 15:28 GMT+01:00 larry mccay <
> >>> larry.mccay@gmail.com>:
> >>> >> >> > > > >
> >>> >> >> > > > > > Hi Jérôme -
> >>> >> >> > > > > >
> >>> >> >> > > > > > Not sure if you saw but I added review comments to
> >>> KNOX-641.
> >>> >> >> > > > > >
> >>> >> >> > > > > > I think that we need to determine whether we want the
> >>> >> >> testBasicAuth
> >>> >> >> > > in
> >>> >> >> > > > > the
> >>> >> >> > > > > > provider itself.
> >>> >> >> > > > > >
> >>> >> >> > > > > > Let's follow up on the JIRA.
> >>> >> >> > > > > >
> >>> >> >> > > > > > thanks,
> >>> >> >> > > > > >
> >>> >> >> > > > > > --larry
> >>> >> >> > > > > >
> >>> >> >> > > > > > On Fri, Dec 11, 2015 at 8:44 AM, Jérôme LELEU <
> >>> >> leleuj@gmail.com>
> >>> >> >> > > > wrote:
> >>> >> >> > > > > >
> >>> >> >> > > > > > > Hi,
> >>> >> >> > > > > > >
> >>> >> >> > > > > > > No problem. It can go into a version 0.8.0 if needed.
> >>> The
> >>> >> truth
> >>> >> >> > is
> >>> >> >> > > > that
> >>> >> >> > > > > > > there is only one change outside the new pac4j
> module,
> >>> so I
> >>> >> >> think
> >>> >> >> > > > risks
> >>> >> >> > > > > > are
> >>> >> >> > > > > > > extremly limited.
> >>> >> >> > > > > > >
> >>> >> >> > > > > > > Just let met know.
> >>> >> >> > > > > > >
> >>> >> >> > > > > > > Thanks.
> >>> >> >> > > > > > > Best regards,
> >>> >> >> > > > > > > Jérôme
> >>> >> >> > > > > > >
> >>> >> >> > > > > > >
> >>> >> >> > > > > > > 2015-12-11 14:23 GMT+01:00 larry mccay <
> >>> >> larry.mccay@gmail.com
> >>> >> >> >:
> >>> >> >> > > > > > >
> >>> >> >> > > > > > > > Hi Jérôme -
> >>> >> >> > > > > > > >
> >>> >> >> > > > > > > > I have unfortunately not had a chance to pull,
> >>> review and
> >>> >> >> test
> >>> >> >> > it
> >>> >> >> > > > yet
> >>> >> >> > > > > > and
> >>> >> >> > > > > > > > have intended to do that today.
> >>> >> >> > > > > > > > I apologize for the delay.
> >>> >> >> > > > > > > >
> >>> >> >> > > > > > > > I was actually thinking that this would go into a
> >>> follow
> >>> >> up
> >>> >> >> > > release
> >>> >> >> > > > > > that
> >>> >> >> > > > > > > we
> >>> >> >> > > > > > > > would try and get done rapidly after the 0.7.0
> >>> release
> >>> >> but we
> >>> >> >> > can
> >>> >> >> > > > > > discuss
> >>> >> >> > > > > > > > the target and its chances of destabilizing 0.7.0.
> >>> >> >> > > > > > > >
> >>> >> >> > > > > > > > I believe that it is rather self-contained with
> only
> >>> a few
> >>> >> >> > > changes
> >>> >> >> > > > to
> >>> >> >> > > > > > > > external modules.
> >>> >> >> > > > > > > >
> >>> >> >> > > > > > > > Opening the JIRAs is perfect and I was going to do
> >>> that
> >>> >> once
> >>> >> >> I
> >>> >> >> > > > > started
> >>> >> >> > > > > > > the
> >>> >> >> > > > > > > > review.
> >>> >> >> > > > > > > >
> >>> >> >> > > > > > > > Let's continue review comments and collaboration on
> >>> those
> >>> >> >> > JIRAs.
> >>> >> >> > > > > > > > I will add you to the contributors list so that we
> >>> can
> >>> >> assign
> >>> >> >> > > them
> >>> >> >> > > > to
> >>> >> >> > > > > > > you.
> >>> >> >> > > > > > > >
> >>> >> >> > > > > > > > Thank you for your contributions and your patience,
> >>> >> Jérôme!
> >>> >> >> > > > > > > >
> >>> >> >> > > > > > > > --larry
> >>> >> >> > > > > > > >
> >>> >> >> > > > > > > > On Fri, Dec 11, 2015 at 3:00 AM, Jérôme LELEU <
> >>> >> >> > leleuj@gmail.com>
> >>> >> >> > > > > > wrote:
> >>> >> >> > > > > > > >
> >>> >> >> > > > > > > > > Hi,
> >>> >> >> > > > > > > > >
> >>> >> >> > > > > > > > > I didn't get any new feedback on the pull request
> >>> so I
> >>> >> >> assume
> >>> >> >> > > > > > > everything
> >>> >> >> > > > > > > > is
> >>> >> >> > > > > > > > > ok from your point of view.
> >>> >> >> > > > > > > > >
> >>> >> >> > > > > > > > > I released pac4j v1.8.1 and j2e-pac4j v1.2.1 so I
> >>> >> updated
> >>> >> >> the
> >>> >> >> > > > pull
> >>> >> >> > > > > > > > request
> >>> >> >> > > > > > > > > to use them and successfully re-tested
> everything.
> >>> >> >> > > > > > > > >
> >>> >> >> > > > > > > > > I opened KNOX-641 and submitted the corresponding
> >>> patch.
> >>> >> >> > > > > > > > >
> >>> >> >> > > > > > > > > I also wrote the documentation, opened KNOX-642
> and
> >>> >> >> submitted
> >>> >> >> > > the
> >>> >> >> > > > > > > > > corresponding patch (just to let you know that it
> >>> >> doesn't
> >>> >> >> > work
> >>> >> >> > > > out
> >>> >> >> > > > > of
> >>> >> >> > > > > > > the
> >>> >> >> > > > > > > > > box in Windows, I had to replace mvn.bat by
> >>> mvn.cmd to
> >>> >> make
> >>> >> >> > ant
> >>> >> >> > > > > > work).
> >>> >> >> > > > > > > > >
> >>> >> >> > > > > > > > > Even if the branch 0.7.0 has already been
> created,
> >>> I
> >>> >> >> assumed
> >>> >> >> > > this
> >>> >> >> > > > > new
> >>> >> >> > > > > > > > pac4j
> >>> >> >> > > > > > > > > provider will go into this version 0.7.0
> >>> (dependency on
> >>> >> the
> >>> >> >> > > > > > > > 0.7.0-SNAPSHOT
> >>> >> >> > > > > > > > > parent version).
> >>> >> >> > > > > > > > >
> >>> >> >> > > > > > > > > Just let me know if everything is ok and when
> it's
> >>> >> goind to
> >>> >> >> > be
> >>> >> >> > > > > > merged.
> >>> >> >> > > > > > > > >
> >>> >> >> > > > > > > > > Thanks.
> >>> >> >> > > > > > > > > Best regards,
> >>> >> >> > > > > > > > > Jérôme
> >>> >> >> > > > > > > > >
> >>> >> >> > > > > > > > >
> >>> >> >> > > > > > > > >
> >>> >> >> > > > > > > > >
> >>> >> >> > > > > > > > > 2015-12-04 14:20 GMT+01:00 larry mccay <
> >>> >> >> > larry.mccay@gmail.com
> >>> >> >> > > >:
> >>> >> >> > > > > > > > >
> >>> >> >> > > > > > > > > > That ability to configure multiple mechanisms
> >>> based on
> >>> >> >> > > > clientName
> >>> >> >> > > > > > is
> >>> >> >> > > > > > > > > really
> >>> >> >> > > > > > > > > > interesting for Knox.
> >>> >> >> > > > > > > > > > Currently, we require separate topologies per
> >>> >> >> > authentication
> >>> >> >> > > > > > > mechanism.
> >>> >> >> > > > > > > > > > The ability to configure them all in one is
> >>> really
> >>> >> great.
> >>> >> >> > > > > > > > > >
> >>> >> >> > > > > > > > > > We would need to think through the best way to
> >>> provide
> >>> >> >> the
> >>> >> >> > > > > > clientName
> >>> >> >> > > > > > > > > > parameter.
> >>> >> >> > > > > > > > > > Since this is targeting KnoxSSO it can actually
> >>> be
> >>> >> added
> >>> >> >> to
> >>> >> >> > > the
> >>> >> >> > > > > > > > > providerURL
> >>> >> >> > > > > > > > > > used to redirect from the participating
> >>> application.
> >>> >> >> > > > > > > > > > Regardless of the authentication mechanism used
> >>> each
> >>> >> >> > > > application
> >>> >> >> > > > > > will
> >>> >> >> > > > > > > > > still
> >>> >> >> > > > > > > > > > get the same JWT based cookie.
> >>> >> >> > > > > > > > > >
> >>> >> >> > > > > > > > > > I think that should work really nicely.
> >>> >> >> > > > > > > > > >
> >>> >> >> > > > > > > > > >
> >>> >> >> > > > > > > > > > On Fri, Dec 4, 2015 at 7:17 AM, larry mccay <
> >>> >> >> > > > > larry.mccay@gmail.com
> >>> >> >> > > > > > >
> >>> >> >> > > > > > > > > wrote:
> >>> >> >> > > > > > > > > >
> >>> >> >> > > > > > > > > > > Excellent, Jérôme.
> >>> >> >> > > > > > > > > > > Thanks!
> >>> >> >> > > > > > > > > > >
> >>> >> >> > > > > > > > > > > On Fri, Dec 4, 2015 at 2:40 AM, Jérôme LELEU
> <
> >>> >> >> > > > leleuj@gmail.com
> >>> >> >> > > > > >
> >>> >> >> > > > > > > > wrote:
> >>> >> >> > > > > > > > > > >
> >>> >> >> > > > > > > > > > >> Hi,
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > > >> I will write how to configure the pac4j
> >>> provider in
> >>> >> >> the
> >>> >> >> > > > > > > > documentation,
> >>> >> >> > > > > > > > > > but
> >>> >> >> > > > > > > > > > >> I can already give you some insights.
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > > >> My main goal is always to respect the key
> >>> design
> >>> >> >> > > principles
> >>> >> >> > > > of
> >>> >> >> > > > > > > pac4j
> >>> >> >> > > > > > > > > > >> whatever the environment / framework in
> which
> >>> it is
> >>> >> >> > > > > implemented.
> >>> >> >> > > > > > > For
> >>> >> >> > > > > > > > > > Knox,
> >>> >> >> > > > > > > > > > >> I'm pretty happy with the use of the
> j2e-pac4j
> >>> >> >> library,
> >>> >> >> > > > which
> >>> >> >> > > > > > > means
> >>> >> >> > > > > > > > > that
> >>> >> >> > > > > > > > > > >> almost all the pac4j features are available,
> >>> >> >> especially
> >>> >> >> > > both
> >>> >> >> > > > > > > direct
> >>> >> >> > > > > > > > > and
> >>> >> >> > > > > > > > > > >> indirect clients. So it can do what Shiro
> >>> already
> >>> >> does
> >>> >> >> > but
> >>> >> >> > > > > also,
> >>> >> >> > > > > > > as
> >>> >> >> > > > > > > > we
> >>> >> >> > > > > > > > > > >> agreed together, supports remote
> >>> authentications.
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > > >> It is only limited by what you can currently
> >>> >> >> configure.
> >>> >> >> > > And
> >>> >> >> > > > > even
> >>> >> >> > > > > > > > > > >> configuration is a pac4j feature as the CAS
> >>> server
> >>> >> has
> >>> >> >> > the
> >>> >> >> > > > > same
> >>> >> >> > > > > > > > need.
> >>> >> >> > > > > > > > > > >> Everything happens in this class:
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > >
> >>> >> >> > > > > > > > >
> >>> >> >> > > > > > > >
> >>> >> >> > > > > > >
> >>> >> >> > > > > >
> >>> >> >> > > > >
> >>> >> >> > > >
> >>> >> >> > >
> >>> >> >> >
> >>> >> >>
> >>> >>
> >>>
> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java
> >>> >> >> > > > > > > > > > >> ,
> >>> >> >> > > > > > > > > > >> which allows you to configure Facebook,
> >>> Twitter, a
> >>> >> CAS
> >>> >> >> > > > > server, a
> >>> >> >> > > > > > > > SAML
> >>> >> >> > > > > > > > > > IdP
> >>> >> >> > > > > > > > > > >> or an OpenID Connect provider. All the
> >>> provided
> >>> >> >> > parameters
> >>> >> >> > > > to
> >>> >> >> > > > > > the
> >>> >> >> > > > > > > > > pac4j
> >>> >> >> > > > > > > > > > >> provider are put into a Map and the
> >>> >> >> > > ConfigPropertiesFactory
> >>> >> >> > > > is
> >>> >> >> > > > > > > built
> >>> >> >> > > > > > > > > > with
> >>> >> >> > > > > > > > > > >> this Map to return the built client (=
> >>> >> authentication
> >>> >> >> > > > > > mechanism).
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > > >> You have one more specific option for Knox
> as
> >>> a
> >>> >> basic
> >>> >> >> > > > > > > authentication
> >>> >> >> > > > > > > > > > popup
> >>> >> >> > > > > > > > > > >> where the username must match the password,
> >>> you can
> >>> >> >> > define
> >>> >> >> > > > > that
> >>> >> >> > > > > > > by:
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > > >> <param>
> >>> >> >> > > > > > > > > > >> <name>clientName</name>
> >>> >> >> > > > > > > > > > >> <value>testBasicAuth</value>
> >>> >> >> > > > > > > > > > >> </param>
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > > >> It's for testing only.
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > > >> For a CAS server:
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > > >> <param>
> >>> >> >> > > > > > > > > > >> <name>cas.loginUrl</name>
> >>> >> >> > > > > > > > > > >> <value>
> >>> >> https://casserverpac4j.herokuapp.com/login
> >>> >> >> > > </value>
> >>> >> >> > > > > > > > > > >> </param>
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > > >> Here are all the properties available for
> >>> building
> >>> >> >> > clients
> >>> >> >> > > > > > (their
> >>> >> >> > > > > > > > > > meaning
> >>> >> >> > > > > > > > > > >> is obvious):
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > > >> facebook.id
> >>> >> >> > > > > > > > > > >> facebook.secret
> >>> >> >> > > > > > > > > > >> facebook.scope
> >>> >> >> > > > > > > > > > >> facebook.fields
> >>> >> >> > > > > > > > > > >> twitter.id
> >>> >> >> > > > > > > > > > >> twitter.secret
> >>> >> >> > > > > > > > > > >> saml.keystorePassword
> >>> >> >> > > > > > > > > > >> saml.privateKeyPassword
> >>> >> >> > > > > > > > > > >> saml.keystorePath
> >>> >> >> > > > > > > > > > >> saml.identityProviderMetadataPath
> >>> >> >> > > > > > > > > > >> saml.maximumAuthenticationLifetime
> >>> >> >> > > > > > > > > > >> saml.serviceProviderEntityId
> >>> >> >> > > > > > > > > > >> saml.serviceProviderMetadataPath
> >>> >> >> > > > > > > > > > >> cas.loginUrl
> >>> >> >> > > > > > > > > > >> cas.protocol
> >>> >> >> > > > > > > > > > >> oidc.id
> >>> >> >> > > > > > > > > > >> oidc.secret
> >>> >> >> > > > > > > > > > >> oidc.discoveryUri
> >>> >> >> > > > > > > > > > >> oidc.customParamKey1
> >>> >> >> > > > > > > > > > >> oidc.customParamValue1
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > > >> If you define multiple clients, the first
> one
> >>> will
> >>> >> be
> >>> >> >> > used
> >>> >> >> > > > for
> >>> >> >> > > > > > > > > > >> authentication, but you can explicitly
> choose
> >>> the
> >>> >> >> client
> >>> >> >> > > you
> >>> >> >> > > > > > want
> >>> >> >> > > > > > > to
> >>> >> >> > > > > > > > > use
> >>> >> >> > > > > > > > > > >> via the clientName parameter, assuming you
> >>> want to
> >>> >> >> > switch
> >>> >> >> > > > from
> >>> >> >> > > > > > > > client
> >>> >> >> > > > > > > > > > >> depending on environment for example.
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > > >> So if you want to add some new
> authentication
> >>> >> >> mechanism,
> >>> >> >> > > you
> >>> >> >> > > > > > must
> >>> >> >> > > > > > > > > first
> >>> >> >> > > > > > > > > > >> check that it is available in pac4j (if it's
> >>> not,
> >>> >> it's
> >>> >> >> > > > another
> >>> >> >> > > > > > > > > > discussion,
> >>> >> >> > > > > > > > > > >> but generally, it is). Then, you'll need to
> >>> upgrade
> >>> >> >> the
> >>> >> >> > > > > > > > > > >> ConfigPropertiesFactory by submitting a new
> >>> pull
> >>> >> >> request
> >>> >> >> > > to
> >>> >> >> > > > > the
> >>> >> >> > > > > > > > pac4j
> >>> >> >> > > > > > > > > > >> project (I can do it myself, but I'm sure
> you
> >>> >> could do
> >>> >> >> > > that
> >>> >> >> > > > > > > easily),
> >>> >> >> > > > > > > > > > >> finally wait for the new pac4j release and
> >>> switch
> >>> >> >> pac4j
> >>> >> >> > > > > versions
> >>> >> >> > > > > > > in
> >>> >> >> > > > > > > > > Knox
> >>> >> >> > > > > > > > > > >> to
> >>> >> >> > > > > > > > > > >> benefit from the new feature.
> >>> >> >> > > > > > > > > > >> The good thing is that if someone related to
> >>> the
> >>> >> CAS
> >>> >> >> > > server
> >>> >> >> > > > > does
> >>> >> >> > > > > > > the
> >>> >> >> > > > > > > > > > same
> >>> >> >> > > > > > > > > > >> thing for CAS (in pac4j), you will
> >>> automatically
> >>> >> get
> >>> >> >> it
> >>> >> >> > > when
> >>> >> >> > > > > > > you'll
> >>> >> >> > > > > > > > > > >> upgrade
> >>> >> >> > > > > > > > > > >> pac4j.
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > > >> To go even further, replacing LDAP Shiro
> >>> >> >> authentication
> >>> >> >> > is
> >>> >> >> > > > > just
> >>> >> >> > > > > > a
> >>> >> >> > > > > > > > > matter
> >>> >> >> > > > > > > > > > >> of
> >>> >> >> > > > > > > > > > >> making pac4j LDAP authentication available
> via
> >>> >> >> > > configuration
> >>> >> >> > > > > > > > > parameters.
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > > >> I hope it was clear enough.
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > > >> Thanks.
> >>> >> >> > > > > > > > > > >> Best regards,
> >>> >> >> > > > > > > > > > >> Jérôme
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > > >> 2015-12-03 20:45 GMT+01:00 larry mccay <
> >>> >> >> > > > larry.mccay@gmail.com
> >>> >> >> > > > > >:
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > > >> > Excellent!
> >>> >> >> > > > > > > > > > >> >
> >>> >> >> > > > > > > > > > >> > I will carve out some time to do code
> >>> review.
> >>> >> >> > > > > > > > > > >> > We will need to get some insights into how
> >>> to go
> >>> >> >> about
> >>> >> >> > > > > > testing:
> >>> >> >> > > > > > > > > > >> >
> >>> >> >> > > > > > > > > > >> > * is the CAS server going to be available
> >>> for
> >>> >> >> testing?
> >>> >> >> > > > > > > > > > >> > * what are the specific and
> >>> generic/standard (if
> >>> >> >> any)
> >>> >> >> > > > > > > > authentication
> >>> >> >> > > > > > > > > > >> > mechanisms available - for instance:
> >>> >> >> > > > > > > > > > >> > - Facebook, Google, LinkedIn and CAS
> are
> >>> >> >> specifics
> >>> >> >> > > > > > > > > > >> > - OAuth 2, OpenID Connect, SAML are
> >>> >> >> > > generic/standards
> >>> >> >> > > > -
> >>> >> >> > > > > > that
> >>> >> >> > > > > > > > may
> >>> >> >> > > > > > > > > > be
> >>> >> >> > > > > > > > > > >> > used for the above specifics...
> >>> >> >> > > > > > > > > > >> > * how do we test things other than CAS -
> in
> >>> >> terms of
> >>> >> >> > > > getting
> >>> >> >> > > > > > > > > > >> credentials,
> >>> >> >> > > > > > > > > > >> > configuration, etc
> >>> >> >> > > > > > > > > > >> >
> >>> >> >> > > > > > > > > > >> > We could certainly do this is phases as
> >>> well.
> >>> >> >> > > > > > > > > > >> >
> >>> >> >> > > > > > > > > > >> > If you can enumerate the things that
> should
> >>> work
> >>> >> and
> >>> >> >> > > > provide
> >>> >> >> > > > > > > some
> >>> >> >> > > > > > > > > > >> testing
> >>> >> >> > > > > > > > > > >> > details for CAS or as many as possible and
> >>> OpenID
> >>> >> >> > > Connect
> >>> >> >> > > > > then
> >>> >> >> > > > > > > we
> >>> >> >> > > > > > > > > can
> >>> >> >> > > > > > > > > > >> test
> >>> >> >> > > > > > > > > > >> > the specific implementations that you
> >>> provide and
> >>> >> >> > enable
> >>> >> >> > > > the
> >>> >> >> > > > > > > > testing
> >>> >> >> > > > > > > > > > of
> >>> >> >> > > > > > > > > > >> > another OpenID Connect effort that is in
> the
> >>> >> works
> >>> >> >> in
> >>> >> >> > > the
> >>> >> >> > > > > > > > community.
> >>> >> >> > > > > > > > > > >> >
> >>> >> >> > > > > > > > > > >> > I'm not sure whether we want to commit
> >>> >> contributions
> >>> >> >> > > that
> >>> >> >> > > > > are
> >>> >> >> > > > > > > > > > dependent
> >>> >> >> > > > > > > > > > >> on
> >>> >> >> > > > > > > > > > >> > snapshots - we certainly can't release
> with
> >>> any
> >>> >> such
> >>> >> >> > > > > > > dependencies.
> >>> >> >> > > > > > > > > > >> > I would hate to add a cleanup task to a
> >>> release
> >>> >> to
> >>> >> >> > make
> >>> >> >> > > > sure
> >>> >> >> > > > > > > there
> >>> >> >> > > > > > > > > are
> >>> >> >> > > > > > > > > > >> no
> >>> >> >> > > > > > > > > > >> > snapshots in there.
> >>> >> >> > > > > > > > > > >> > We will probably wait until after the
> pac4j
> >>> >> releases
> >>> >> >> > to
> >>> >> >> > > > > > commit.
> >>> >> >> > > > > > > > > > >> >
> >>> >> >> > > > > > > > > > >> > I am really happy that this integration is
> >>> >> happening
> >>> >> >> > and
> >>> >> >> > > > > that
> >>> >> >> > > > > > it
> >>> >> >> > > > > > > > > went
> >>> >> >> > > > > > > > > > >> > rather smoothly.
> >>> >> >> > > > > > > > > > >> > These sorts of authentication protocols
> are
> >>> >> complex
> >>> >> >> > and
> >>> >> >> > > I
> >>> >> >> > > > > > think
> >>> >> >> > > > > > > we
> >>> >> >> > > > > > > > > > >> lined up
> >>> >> >> > > > > > > > > > >> > pretty well overall.
> >>> >> >> > > > > > > > > > >> >
> >>> >> >> > > > > > > > > > >> > Thanks for your work!
> >>> >> >> > > > > > > > > > >> >
> >>> >> >> > > > > > > > > > >> > On Thu, Dec 3, 2015 at 2:28 PM, Jérôme
> >>> LELEU <
> >>> >> >> > > > > > leleuj@gmail.com>
> >>> >> >> > > > > > > > > > wrote:
> >>> >> >> > > > > > > > > > >> >
> >>> >> >> > > > > > > > > > >> > > Hi,
> >>> >> >> > > > > > > > > > >> > >
> >>> >> >> > > > > > > > > > >> > > I just sync'ed with master, cleaned
> >>> >> dependencies
> >>> >> >> and
> >>> >> >> > > > added
> >>> >> >> > > > > > > > missing
> >>> >> >> > > > > > > > > > >> > > Javadocs. Everything works correctly
> now.
> >>> Many
> >>> >> >> > thanks.
> >>> >> >> > > > > > > > > > >> > >
> >>> >> >> > > > > > > > > > >> > > The pull request is ready for a full
> code
> >>> >> review:
> >>> >> >> > > > > > > > > > >> > > https://github.com/apache/knox/pull/2
> >>> >> >> > > > > > > > > > >> > >
> >>> >> >> > > > > > > > > > >> > > I'll write the documentation after the
> >>> pac4j
> >>> >> >> > releases
> >>> >> >> > > (I
> >>> >> >> > > > > > hope
> >>> >> >> > > > > > > > next
> >>> >> >> > > > > > > > > > >> week).
> >>> >> >> > > > > > > > > > >> > >
> >>> >> >> > > > > > > > > > >> > > Thanks.
> >>> >> >> > > > > > > > > > >> > > Best regards,
> >>> >> >> > > > > > > > > > >> > > Jérôme
> >>> >> >> > > > > > > > > > >> > >
> >>> >> >> > > > > > > > > > >> > >
> >>> >> >> > > > > > > > > > >> > > 2015-12-02 19:18 GMT+01:00 larry mccay <
> >>> >> >> > > > > > larry.mccay@gmail.com
> >>> >> >> > > > > > > >:
> >>> >> >> > > > > > > > > > >> > >
> >>> >> >> > > > > > > > > > >> > > > Fixed in
> >>> >> >> > > > https://issues.apache.org/jira/browse/KNOX-636
> >>> >> >> > > > > .
> >>> >> >> > > > > > > > > > >> > > >
> >>> >> >> > > > > > > > > > >> > > > On Wed, Dec 2, 2015 at 12:42 PM, larry
> >>> mccay
> >>> >> <
> >>> >> >> > > > > > > > > > larry.mccay@gmail.com
> >>> >> >> > > > > > > > > > >> >
> >>> >> >> > > > > > > > > > >> > > > wrote:
> >>> >> >> > > > > > > > > > >> > > >
> >>> >> >> > > > > > > > > > >> > > > > Sure - I can file a JIRA and commit
> a
> >>> fix.
> >>> >> >> > > > > > > > > > >> > > > >
> >>> >> >> > > > > > > > > > >> > > > > The secret generation should be done
> >>> in one
> >>> >> >> > > instance
> >>> >> >> > > > > and
> >>> >> >> > > > > > > > > > >> replicated
> >>> >> >> > > > > > > > > > >> > > > across
> >>> >> >> > > > > > > > > > >> > > > > others.
> >>> >> >> > > > > > > > > > >> > > > > This replication/management of the
> >>> >> credential
> >>> >> >> > > stores
> >>> >> >> > > > > is
> >>> >> >> > > > > > > > > outside
> >>> >> >> > > > > > > > > > of
> >>> >> >> > > > > > > > > > >> > the
> >>> >> >> > > > > > > > > > >> > > > > scope of Knox itself as of now.
> >>> >> >> > > > > > > > > > >> > > > >
> >>> >> >> > > > > > > > > > >> > > > > Documentation is done in markdown
> and
> >>> is
> >>> >> >> > > > contributing
> >>> >> >> > > > > > > > details
> >>> >> >> > > > > > > > > > are
> >>> >> >> > > > > > > > > > >> > > > > available at:
> >>> >> >> > > > > > > > > > >> > > > >
> >>> >> >> > > > > > > > > > >> > > >
> >>> >> >> > > > > > > > > > >> > >
> >>> >> >> > > > > > > > > > >> >
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > >
> >>> >> >> > > > > > > > >
> >>> >> >> > > > > > > >
> >>> >> >> > > > > > >
> >>> >> >> > > > > >
> >>> >> >> > > > >
> >>> >> >> > > >
> >>> >> >> > >
> >>> >> >> >
> >>> >> >>
> >>> >>
> >>>
> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
> >>> >> >> > > > > > > > > > >> > > > >
> >>> >> >> > > > > > > > > > >> > > > > Which should give you a general
> idea.
> >>> >> >> > > > > > > > > > >> > > > >
> >>> >> >> > > > > > > > > > >> > > > > Find an example like:
> >>> ./trunk/books/0.7.0/
> >>> >> >> > > > > > > > > > >> > > config_preauth_sso_provider.md
> >>> >> >> > > > > > > > > > >> > > > >
> >>> >> >> > > > > > > > > > >> > > > > For an example of typical content
> and
> >>> >> format.
> >>> >> >> > > > > > > > > > >> > > > >
> >>> >> >> > > > > > > > > > >> > > > > Here is how that example renders:
> >>> >> >> > > > > > > > > > >> > > > >
> >>> >> >> > > > > > > > > > >> > > >
> >>> >> >> > > > > > > > > > >> > >
> >>> >> >> > > > > > > > > > >> >
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > >
> >>> >> >> > > > > > > > >
> >>> >> >> > > > > > > >
> >>> >> >> > > > > > >
> >>> >> >> > > > > >
> >>> >> >> > > > >
> >>> >> >> > > >
> >>> >> >> > >
> >>> >> >> >
> >>> >> >>
> >>> >>
> >>>
> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
> >>> >> >> > > > > > > > > > >> > > > >
> >>> >> >> > > > > > > > > > >> > > > > You'll need to tie it into the rest
> >>> of the
> >>> >> >> book
> >>> >> >> > -
> >>> >> >> > > > just
> >>> >> >> > > > > > > grep
> >>> >> >> > > > > > > > > for
> >>> >> >> > > > > > > > > > >> where
> >>> >> >> > > > > > > > > > >> > > > that
> >>> >> >> > > > > > > > > > >> > > > > filename is referenced.
> >>> >> >> > > > > > > > > > >> > > > > To test how it renders build the
> site
> >>> with:
> >>> >> >> > "ant"
> >>> >> >> > > > and
> >>> >> >> > > > > > note
> >>> >> >> > > > > > > > the
> >>> >> >> > > > > > > > > > >> url to
> >>> >> >> > > > > > > > > > >> > > the
> >>> >> >> > > > > > > > > > >> > > > > 0.7.0 book.
> >>> >> >> > > > > > > > > > >> > > > >
> >>> >> >> > > > > > > > > > >> > > > >
> >>> >> >> > > > > > > > > > >> > > > > On Wed, Dec 2, 2015 at 12:12 PM,
> >>> Jérôme
> >>> >> LELEU
> >>> >> >> <
> >>> >> >> > > > > > > > > leleuj@gmail.com
> >>> >> >> > > > > > > > > > >
> >>> >> >> > > > > > > > > > >> > > wrote:
> >>> >> >> > > > > > > > > > >> > > > >
> >>> >> >> > > > > > > > > > >> > > > >> Hi,
> >>> >> >> > > > > > > > > > >> > > > >>
> >>> >> >> > > > > > > > > > >> > > > >> Why it doesn't work for pac4j while
> >>> it
> >>> >> works
> >>> >> >> > for
> >>> >> >> > > > > others
> >>> >> >> > > > > > > is
> >>> >> >> > > > > > > > a
> >>> >> >> > > > > > > > > > bit
> >>> >> >> > > > > > > > > > >> > > strange
> >>> >> >> > > > > > > > > > >> > > > >> to
> >>> >> >> > > > > > > > > > >> > > > >> me, but if you have the patch in
> >>> front of
> >>> >> >> your
> >>> >> >> > > > eyes,
> >>> >> >> > > > > > I'd
> >>> >> >> > > > > > > > > rather
> >>> >> >> > > > > > > > > > >> > prefer
> >>> >> >> > > > > > > > > > >> > > > you
> >>> >> >> > > > > > > > > > >> > > > >> to commit it. In all cases, I'll
> >>> sync with
> >>> >> >> the
> >>> >> >> > > > > master.
> >>> >> >> > > > > > > > > > >> > > > >>
> >>> >> >> > > > > > > > > > >> > > > >> There was one question you didn't
> >>> answer
> >>> >> >> > > > previously:
> >>> >> >> > > > > is
> >>> >> >> > > > > > > the
> >>> >> >> > > > > > > > > > >> password
> >>> >> >> > > > > > > > > > >> > > > >> generated for the pac4j provider
> the
> >>> same
> >>> >> >> > across
> >>> >> >> > > > all
> >>> >> >> > > > > > > > gateway
> >>> >> >> > > > > > > > > > >> > > instances?
> >>> >> >> > > > > > > > > > >> > > > >> Because I expect to have the same
> >>> value
> >>> >> as I
> >>> >> >> > use
> >>> >> >> > > it
> >>> >> >> > > > > to
> >>> >> >> > > > > > > > > encrypt
> >>> >> >> > > > > > > > > > /
> >>> >> >> > > > > > > > > > >> > > decrypt
> >>> >> >> > > > > > > > > > >> > > > >> data.
> >>> >> >> > > > > > > > > > >> > > > >>
> >>> >> >> > > > > > > > > > >> > > > >> I will add the Javadoc. After that,
> >>> you
> >>> >> can
> >>> >> >> > > review
> >>> >> >> > > > > the
> >>> >> >> > > > > > > pull
> >>> >> >> > > > > > > > > > >> request
> >>> >> >> > > > > > > > > > >> > > more
> >>> >> >> > > > > > > > > > >> > > > >> completely.
> >>> >> >> > > > > > > > > > >> > > > >>
> >>> >> >> > > > > > > > > > >> > > > >> What do you expect for the
> >>> documentation?
> >>> >> >> > > > > > > > > > >> > > > >>
> >>> >> >> > > > > > > > > > >> > > > >> Notice that pac4j dependencies are
> >>> still
> >>> >> >> > > snapshots,
> >>> >> >> > > > > but
> >>> >> >> > > > > > > > they
> >>> >> >> > > > > > > > > > >> will be
> >>> >> >> > > > > > > > > > >> > > > >> released in a week or two.
> >>> >> >> > > > > > > > > > >> > > > >>
> >>> >> >> > > > > > > > > > >> > > > >> Thanks.
> >>> >> >> > > > > > > > > > >> > > > >> Best regards,
> >>> >> >> > > > > > > > > > >> > > > >> Jérôme
> >>> >> >> > > > > > > > > > >> > > > >>
> >>> >> >> > > > > > > > > > >> > > > >>
> >>> >> >> > > > > > > > > > >> > > > >> 2015-12-02 17:51 GMT+01:00 larry
> >>> mccay <
> >>> >> >> > > > > > > > > larry.mccay@gmail.com
> >>> >> >> > > > > > > > > > >:
> >>> >> >> > > > > > > > > > >> > > > >>
> >>> >> >> > > > > > > > > > >> > > > >> > Jérôme -
> >>> >> >> > > > > > > > > > >> > > > >> >
> >>> >> >> > > > > > > > > > >> > > > >> > If you would like to add that
> >>> change as
> >>> >> >> part
> >>> >> >> > of
> >>> >> >> > > > > your
> >>> >> >> > > > > > > > patch
> >>> >> >> > > > > > > > > or
> >>> >> >> > > > > > > > > > >> as a
> >>> >> >> > > > > > > > > > >> > > > >> > separately filed JIRA to fix a
> bug
> >>> that
> >>> >> >> would
> >>> >> >> > > > > > certainly
> >>> >> >> > > > > > > > be
> >>> >> >> > > > > > > > > > >> > welcomed.
> >>> >> >> > > > > > > > > > >> > > > >> > Otherwise, I can do it.
> >>> >> >> > > > > > > > > > >> > > > >> >
> >>> >> >> > > > > > > > > > >> > > > >> > Let me know.
> >>> >> >> > > > > > > > > > >> > > > >> >
> >>> >> >> > > > > > > > > > >> > > > >> > thanks,
> >>> >> >> > > > > > > > > > >> > > > >> >
> >>> >> >> > > > > > > > > > >> > > > >> > --larry
> >>> >> >> > > > > > > > > > >> > > > >> >
> >>> >> >> > > > > > > > > > >> > > > >> > On Wed, Dec 2, 2015 at 11:44 AM,
> >>> larry
> >>> >> >> mccay
> >>> >> >> > <
> >>> >> >> > > > > > > > > > >> > larry.mccay@gmail.com
> >>> >> >> > > > > > > > > > >> > > >
> >>> >> >> > > > > > > > > > >> > > > >> > wrote:
> >>> >> >> > > > > > > > > > >> > > > >> >
> >>> >> >> > > > > > > > > > >> > > > >> > > Okay - I had to add an override
> >>> of
> >>> >> >> > > > > > getUserPrincipal()
> >>> >> >> > > > > > > > to
> >>> >> >> > > > > > > > > > the
> >>> >> >> > > > > > > > > > >> > > > >> > >
> >>> >> IdentityAsserterHttpServletRequestWrapper
> >>> >> >> > and
> >>> >> >> > > > > > return
> >>> >> >> > > > > > > > the
> >>> >> >> > > > > > > > > > >> member
> >>> >> >> > > > > > > > > > >> > > > >> variable
> >>> >> >> > > > > > > > > > >> > > > >> > > username and it works like a
> >>> charm.
> >>> >> >> > > > > > > > > > >> > > > >> > >
> >>> >> >> > > > > > > > > > >> > > > >> > > Why I haven't seen this same
> >>> behavior
> >>> >> >> with
> >>> >> >> > > > other
> >>> >> >> > > > > > > > > providers
> >>> >> >> > > > > > > > > > >> is a
> >>> >> >> > > > > > > > > > >> > > bit
> >>> >> >> > > > > > > > > > >> > > > >> of a
> >>> >> >> > > > > > > > > > >> > > > >> > > mystery but they must be adding
> >>> other
> >>> >> >> > > wrappers
> >>> >> >> > > > > that
> >>> >> >> > > > > > > > > handle
> >>> >> >> > > > > > > > > > >> it.
> >>> >> >> > > > > > > > > > >> > > > >> > > This is quite cool, Jérôme!
> >>> >> >> > > > > > > > > > >> > > > >> > >
> >>> >> >> > > > > > > > > > >> > > > >> > > On Wed, Dec 2, 2015 at 10:41
> AM,
> >>> larry
> >>> >> >> > mccay
> >>> >> >> > > <
> >>> >> >> > > > > > > > > > >> > > larry.mccay@gmail.com
> >>> >> >> > > > > > > > > > >> > > > >
> >>> >> >> > > > > > > > > > >> > > > >> > > wrote:
> >>> >> >> > > > > > > > > > >> > > > >> > >
> >>> >> >> > > > > > > > > > >> > > > >> > >> That was it - thanks!
> >>> >> >> > > > > > > > > > >> > > > >> > >>
> >>> >> >> > > > > > > > > > >> > > > >> > >> On Wed, Dec 2, 2015 at 10:20
> AM,
> >>> >> Jérôme
> >>> >> >> > > LELEU
> >>> >> >> > > > <
> >>> >> >> > > > > > > > > > >> > leleuj@gmail.com>
> >>> >> >> > > > > > > > > > >> > > > >> wrote:
> >>> >> >> > > > > > > > > > >> > > > >> > >>
> >>> >> >> > > > > > > > > > >> > > > >> > >>> This is my exact command
> line:
> >>> mvn
> >>> >> >> > > -Prelease
> >>> >> >> > > > > > clean
> >>> >> >> > > > > > > > > > install
> >>> >> >> > > > > > > > > > >> > > > >> -DskipTests
> >>> >> >> > > > > > > > > > >> > > > >> > >>>
> >>> >> >> > > > > > > > > > >> > > > >> > >>> You use an internal Maven
> >>> >> repository to
> >>> >> >> > > fetch
> >>> >> >> > > > > > > > > > dependencies
> >>> >> >> > > > > > > > > > >> > from
> >>> >> >> > > > > > > > > > >> > > > >> > internet:
> >>> >> >> > > > > > > > > > >> > > > >> > >>>
> >>> >> >> > > > > > > > > > >> > >
> >>> >> >> > > > > > > >
> >>> >> >> > >
> >>> http://nexus-private.hortonworks.com/nexus/content/groups/public/
> >>> >> >> > > > > > > > > > >> > > > >> > >>>
> >>> >> >> > > > > > > > > > >> > > > >> > >>> Does this repository have
> >>> access to
> >>> >> the
> >>> >> >> > > > remote
> >>> >> >> > > > > > > > > Snapshots
> >>> >> >> > > > > > > > > > >> > > Sonatype
> >>> >> >> > > > > > > > > > >> > > > >> repo?
> >>> >> >> > > > > > > > > > >> > > > >> > >>>
> >>> >> >> > > > > > > > > > >> > > > >> > >>>
> >>> >> >> > > > > > > > > > >> > > > >> > >>>
> >>> >> >> > > > > > > > > > >> > > > >> > >>> 2015-12-02 16:16 GMT+01:00
> >>> larry
> >>> >> mccay
> >>> >> >> <
> >>> >> >> > > > > > > > > > >> larry.mccay@gmail.com
> >>> >> >> > > > > > > > > > >> > >:
> >>> >> >> > > > > > > > > > >> > > > >> > >>>
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > hmmm - I used:
> >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > mvn clean install
> >>> -DskipTests=true
> >>> >> >> > > > -Prelease
> >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > The repository entry is in
> >>> there
> >>> >> >> > already.
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > No worky.
> >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > On Wed, Dec 2, 2015 at
> 10:12
> >>> AM,
> >>> >> >> Jérôme
> >>> >> >> > > > > LELEU <
> >>> >> >> > > > > > > > > > >> > > leleuj@gmail.com
> >>> >> >> > > > > > > > > > >> > > > >
> >>> >> >> > > > > > > > > > >> > > > >> > >>> wrote:
> >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Hi,
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > > You need the j2e-pac4j
> >>> >> dependencies
> >>> >> >> > as
> >>> >> >> > > > well
> >>> >> >> > > > > > as
> >>> >> >> > > > > > > > the
> >>> >> >> > > > > > > > > > >> pac4j-*
> >>> >> >> > > > > > > > > > >> > > > >> > >>> dependencies,
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > > but you don't need to
> >>> build them
> >>> >> >> > > locally
> >>> >> >> > > > > > > > > (hopefully).
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > > But you need a dependency
> >>> on the
> >>> >> >> > > Sonatype
> >>> >> >> > > > > > > > snapshots
> >>> >> >> > > > > > > > > > >> > > repository
> >>> >> >> > > > > > > > > > >> > > > >> > >>> (where the
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > > snapshot versions are
> >>> hosted),
> >>> >> >> which
> >>> >> >> > is
> >>> >> >> > > > > added
> >>> >> >> > > > > > > for
> >>> >> >> > > > > > > > > > >> Maven in
> >>> >> >> > > > > > > > > > >> > > the
> >>> >> >> > > > > > > > > > >> > > > >> root
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > > pom.xml:
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> >>> >> >> > > > > > > > > > >> > > > >> > >>>
> >>> >> >> > > > > > > > > > >> > > > >> >
> >>> >> >> > > > > > > > > > >> > > > >>
> >>> >> >> > > > > > > > > > >> > > >
> >>> >> >> > > > > > > > > > >> > >
> >>> >> >> > > > > > > > > > >> >
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > >
> >>> >> >> > > > > > > > >
> >>> >> >> > > > > > > >
> >>> >> >> > > > > > >
> >>> >> >> > > > > >
> >>> >> >> > > > >
> >>> >> >> > > >
> >>> >> >> > >
> >>> >> >> >
> >>> >> >>
> >>> >>
> >>>
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > > If you use Ant for the
> >>> build,
> >>> >> there
> >>> >> >> > is
> >>> >> >> > > > > maybe
> >>> >> >> > > > > > a
> >>> >> >> > > > > > > > > glitch
> >>> >> >> > > > > > > > > > >> to
> >>> >> >> > > > > > > > > > >> > > find
> >>> >> >> > > > > > > > > > >> > > > >> the
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > Sonatype
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Maven repo.
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Thanks.
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Best regards,
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > > Jérôme
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > > 2015-12-02 16:06
> GMT+01:00
> >>> larry
> >>> >> >> > mccay
> >>> >> >> > > <
> >>> >> >> > > > > > > > > > >> > > larry.mccay@gmail.com
> >>> >> >> > > > > > > > > > >> > > > >:
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > >
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > 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.mccay@gmail.com>
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > wrote:
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > > >
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > >
> >>> >> gateway-provider-security-pac4j
> >>> >> >> > > > doesn't
> >>> >> >> > > > > > > > build -
> >>> >> >> > > > > > > > > > do
> >>> >> >> > > > > > > > > > >> you
> >>> >> >> > > > > > > > > > >> > > > have
> >>> >> >> > > > > > > > > > >> > > > >> a
> >>> >> >> > > > > > > > > > >> > > > >> > >>> pending
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > > change for your
> >>> pom.xml or
> >>> >> >> > > something?
> >>> >> >> > > > > > > > > > >> > > > >> > >>> > > > >
> >>> >> >> > > > > > > > > > >> > > > >> > >>> >
> >>> >> >> > > > > > > > > > >> > > > >> > >>>
> >>> >> >> > > > > > > > > > >> > > > >> > >>
> >>> >> >> > > > > > > > > > >> > > > >> > >>
> >>> >> >> > > > > > > > > > >> > > > >> > >
> >>> >> >> > > > > > > > > > >> > > > >> >
> >>> >> >> > > > > > > > > > >> > > > >>
> >>> >> >> > > > > > > > > > >> > > > >
> >>> >> >> > > > > > > > > > >> > > > >
> >>> >> >> > > > > > > > > > >> > > >
> >>> >> >> > > > > > > > > > >> > >
> >>> >> >> > > > > > > > > > >> >
> >>> >> >> > > > > > > > > > >>
> >>> >> >> > > > > > > > > > >
> >>> >> >> > > > > > > > > > >
> >>> >> >> > > > > > > > > >
> >>> >> >> > > > > > > > >
> >>> >> >> > > > > > > >
> >>> >> >> > > > > > >
> >>> >> >> > > > > >
> >>> >> >> > > > >
> >>> >> >> > > >
> >>> >> >> > >
> >>> >> >> >
> >>> >> >>
> >>> >>
> >>>
> >>
> >>
> >
>
Re: pac4j and Apache Knox
Posted by larry mccay <lm...@apache.org>.
Hi Jérôme -
I'm trying to configure the pac4j provider for an okta "application" that I
created.
The following (from KNOX-642 docs patch) isn't quite enough to make it
clear to me how to go about doing so:
+saml.keystorePassword | Password of the keystore (storepass)
+saml.privateKeyPassword | Password for the private key (keypass)
+saml.keystorePath | Path of the keystore
+saml.identityProviderMetadataPath | Path of the identity
provider metadata
+saml.maximumAuthenticationLifetime | Maximum lifetime for
authentication
+saml.serviceProviderEntityId | Identifier of the service provider
+saml.serviceProviderMetadataPath | Path of the service provider
metadata
I assume that I can use the gateway.jks keystore and the gateway-identity
keypair to do the request signing and that that information is what is
needed for the first 3 params. Unfortunately, I don't see any use of
gateway services to get the master secret therefore it needs to be in clear
text here. This won't work - but may not be a show stopper for committing
to master as long as we follow up with a fix.
Can saml.identityProviderMetadataPath point to a remote location or does it
have to be local to the SP application. This would likely require it to be
on the local filesystem, provisioned by the contributor into the generated
web app or in some central location via NFS or something like that.
The okta application that I created is called KnoxSSO - is that the value
for saml.serviceProviderEntityId?
The saml.serviceProviderMetadataPath has the same questions as the metadata
for the IDP. In addition, is there a sample metadata file that we can
provide for the use of pac4j with KnoxSSO?
I think that getting this working and clean (no clear text passwords) will
make a great feature and blog for featuring pac4j provider and the 0.8.0
release. So, let's try and iron this out clearly.
I would really like to get this working and committed in the next couple
days to free us up for follow up items. In particular we need time to
figure out whether the identity assertion providers that we currently have
will suffice for an apache release that is featuring this new functionality.
I will also add the above comments/questions to the JIRA for visibility.
thanks,
--larry
On Fri, Jan 8, 2016 at 12:40 PM, larry mccay <lm...@apache.org> wrote:
> Jérôme -
>
> My testing of OpenID Connect is blocked.
> Can you see the comments in KNOX-641?
>
> thanks,
>
> --larry
>
> On Wed, Jan 6, 2016 at 2:30 PM, larry mccay <la...@gmail.com> wrote:
>
>> Jérôme -
>>
>> Please see the comments on KNOX-641.
>>
>> thanks,
>>
>> --larry
>>
>> On Wed, Jan 6, 2016 at 11:24 AM, Kevin Minder <
>> kevin.minder@hortonworks.com> wrote:
>>
>>> I can certainly appreciate the issue of including external resources in
>>> automated tests. Nothing has driven me more crazy over the years. The
>>> flip side of this of course is not finding out about a breakage until
>>> someone is willing to go through the manual testing which will typically
>>> happen just before a release. Also the implication is that these testing
>>> procedures must be very will documented so that they can be continue to be
>>> run once any of us are no longer active in the project.
>>>
>>>
>>>
>>> On 1/6/16, 2:12 AM, "Jérôme LELEU" <le...@gmail.com> wrote:
>>>
>>> >Hi,
>>> >
>>> >Yes, you can hit the CAS server at Heroku. Notice it's a Heroku free
>>> server
>>> >so it needs to be re-activated first (it takes a couple of seconds). So
>>> for
>>> >a UI test, you should first hit it, wait 30 seconds and then perform the
>>> >test.
>>> >
>>> >Just my 2 cents:
>>> >Using automated UI tests was my first strategy for pac4j but I finally
>>> >gave up because public providers change very often, at least enough to
>>> make
>>> >the maintenance tests a nightmare. Currently, I'm using manual tests
>>> (the
>>> >same for all demos), it takes me around 5 minutes to play them all by
>>> hand
>>> >(for a demo) and I launched manually the UI tests I have for every major
>>> >pac4j release. Just to say UI tests are not that easy. For a CAS server,
>>> >it's fairly feasible as the CAS server and protocol change rarely.
>>> >That's why for Knox, I did some compromise with a simulated web test
>>> (based
>>> >on the basic auth). See:
>>> >
>>> https://github.com/apache/knox/pull/2/files#diff-d0c880ca71b310dbe57975c577535e97R47
>>> >
>>> >Thanks.
>>> >Best regards,
>>> >Jérôme
>>> >
>>> >
>>> >
>>> >2016-01-05 21:20 GMT+01:00 Kevin Minder <ke...@hortonworks.com>:
>>> >
>>> >> From my perspective it would be ideal if there were some automatable
>>> >> functional tests for this. I’m not advocating that these be something
>>> >> included in “mvn clean install” as that is running too long as it is.
>>> >> Given that I don’t have as much context as Larry, I have some
>>> questions
>>> >> about what this would take. Lets say we had permission to hit
>>> >> https://casserverpac4j.herokuapp.com/login as part of some low
>>> frequency
>>> >> automated tests (e.g. Once nighty). What static credentials and
>>> other test
>>> >> automation infrastructure would need to be implemented in support of
>>> this?
>>> >> I understand that the test suite would require at a minimum
>>> >> 1) a test driver
>>> >> 2) a protected mock UI and
>>> >> 3) an appropriately configured Knox
>>> >> 4) a profile enabled maven module
>>> >> 5) an Apache jenkins job
>>> >> but I’m sure I’m missing other things. I’m certainly willing to help
>>> >> setup the skeleton infrastructure (e.g. test driver, mock UI, maven
>>> module,
>>> >> jenkins job)
>>> >>
>>> >>
>>> >>
>>> >> On 1/5/16, 2:54 PM, "larry mccay" <la...@gmail.com> wrote:
>>> >>
>>> >> >Okay, very good.
>>> >> >I've used TestShib for the picketlink provider - thanks for the
>>> pointers!
>>> >> >
>>> >> >On Tue, Jan 5, 2016 at 1:38 PM, Jérôme LELEU <le...@gmail.com>
>>> wrote:
>>> >> >
>>> >> >> The online CAS server (https://casserverpac4j.herokuapp.com/login)
>>> uses
>>> >> >> the
>>> >> >> CAS protocol. SAML support can be tested using some online IdP like
>>> >> Okta,
>>> >> >> TestShib, OpenFeide, Ssocircle...
>>> >> >>
>>> >> >>
>>> >> >> 2016-01-05 17:32 GMT+01:00 larry mccay <la...@gmail.com>:
>>> >> >>
>>> >> >> > Great - thanks for that pointer!
>>> >> >> >
>>> >> >> > I will take a look at that and help drive the release related
>>> testing.
>>> >> >> > Merge testing will be gated on CAS server (is this SAML or CAS
>>> >> protocol?)
>>> >> >> > and testBasicAuth.
>>> >> >> >
>>> >> >> > On Tue, Jan 5, 2016 at 10:52 AM, Jérôme LELEU <le...@gmail.com>
>>> >> wrote:
>>> >> >> >
>>> >> >> > > Hi,
>>> >> >> > >
>>> >> >> > > Glad to hear back from you!
>>> >> >> > >
>>> >> >> > > The core pac4j project is fully tested by unit tests (and some
>>> >> >> > integration
>>> >> >> > > tests I run for major version), then all pac4j implementations
>>> are
>>> >> each
>>> >> >> > > tested by the appropriate demo: j2e-pac4j-demo tests j2e-pac4j,
>>> >> >> > > spring-webmvc-pac4j-demo tests spring-webmvc-pac4j, etc.
>>> >> >> > >
>>> >> >> > > So if you take a look at:
>>> >> >> > >
>>> >> >> > >
>>> >> >> >
>>> >> >>
>>> >>
>>> https://github.com/pac4j/j2e-pac4j-demo/blob/master/src/main/java/org/pac4j/demo/j2e/config/DemoConfigFactory.java#L27
>>> >> >> > > (for example), you have all the required information to test.
>>> >> >> > >
>>> >> >> > > I can do that on my own, but it can be good for the Knox
>>> community
>>> >> to
>>> >> >> > start
>>> >> >> > > working / testing the pac4j support. It's up to yoy.
>>> >> >> > >
>>> >> >> > > Thanks.
>>> >> >> > > Best regards,
>>> >> >> > > Jérôme
>>> >> >> > >
>>> >> >> > >
>>> >> >> > > 2016-01-05 16:11 GMT+01:00 larry mccay <larry.mccay@gmail.com
>>> >:
>>> >> >> > >
>>> >> >> > > > Hello Jérôme -
>>> >> >> > > >
>>> >> >> > > > Happy New Year!
>>> >> >> > > >
>>> >> >> > > > I am going to start reviewing your updates today, hopefully.
>>> >> >> > > > I was thinking that we need to start discussions on what the
>>> key
>>> >> >> > usecases
>>> >> >> > > > are and how to go about testing them.
>>> >> >> > > > We can certainly test the testBasicAuth and against the
>>> hosted CAS
>>> >> >> > server
>>> >> >> > > > but what about FB, openid, OAuth, etc?
>>> >> >> > > >
>>> >> >> > > > I'm not sure that FB would be a key feature but OpenID
>>> Connect and
>>> >> >> > OAuth
>>> >> >> > > > would be - as is SAML.
>>> >> >> > > > I think CAS buys us SAML testing - assuming that the
>>> >> configuration of
>>> >> >> > the
>>> >> >> > > > hosted server is actually a SAML 2 instance.
>>> >> >> > > >
>>> >> >> > > > What about the others?
>>> >> >> > > >
>>> >> >> > > > I don't know that we need to be able to test them all before
>>> merge
>>> >> >> but
>>> >> >> > > some
>>> >> >> > > > sort of manual verification would be great.
>>> >> >> > > > We would need to be able to test them before the next release
>>> >> which
>>> >> >> > would
>>> >> >> > > > be featuring the pac4j functionality.
>>> >> >> > > >
>>> >> >> > > > Maybe you can describe how you go about testing such things
>>> for
>>> >> the
>>> >> >> > pac4j
>>> >> >> > > > project itself?
>>> >> >> > > >
>>> >> >> > > > thanks,
>>> >> >> > > >
>>> >> >> > > > --larry
>>> >> >> > > >
>>> >> >> > > >
>>> >> >> > > > On Tue, Jan 5, 2016 at 9:55 AM, Jérôme LELEU <
>>> leleuj@gmail.com>
>>> >> >> wrote:
>>> >> >> > > >
>>> >> >> > > > > Hi,
>>> >> >> > > > >
>>> >> >> > > > > Happy new year!
>>> >> >> > > > >
>>> >> >> > > > > A few days ago, I updated my patch of the pac4j gateway
>>> provider
>>> >> >> > > > according
>>> >> >> > > > > to all comments on
>>> >> https://issues.apache.org/jira/browse/KNOX-641
>>> >> >> as
>>> >> >> > > > well
>>> >> >> > > > > as the documentation on KNOX-642.
>>> >> >> > > > >
>>> >> >> > > > > Is everything ok for the merge?
>>> >> >> > > > >
>>> >> >> > > > > Thanks.
>>> >> >> > > > > Best regards,
>>> >> >> > > > > Jérôme
>>> >> >> > > > >
>>> >> >> > > > >
>>> >> >> > > > > 2015-12-14 15:28 GMT+01:00 larry mccay <
>>> larry.mccay@gmail.com>:
>>> >> >> > > > >
>>> >> >> > > > > > Hi Jérôme -
>>> >> >> > > > > >
>>> >> >> > > > > > Not sure if you saw but I added review comments to
>>> KNOX-641.
>>> >> >> > > > > >
>>> >> >> > > > > > I think that we need to determine whether we want the
>>> >> >> testBasicAuth
>>> >> >> > > in
>>> >> >> > > > > the
>>> >> >> > > > > > provider itself.
>>> >> >> > > > > >
>>> >> >> > > > > > Let's follow up on the JIRA.
>>> >> >> > > > > >
>>> >> >> > > > > > thanks,
>>> >> >> > > > > >
>>> >> >> > > > > > --larry
>>> >> >> > > > > >
>>> >> >> > > > > > On Fri, Dec 11, 2015 at 8:44 AM, Jérôme LELEU <
>>> >> leleuj@gmail.com>
>>> >> >> > > > wrote:
>>> >> >> > > > > >
>>> >> >> > > > > > > Hi,
>>> >> >> > > > > > >
>>> >> >> > > > > > > No problem. It can go into a version 0.8.0 if needed.
>>> The
>>> >> truth
>>> >> >> > is
>>> >> >> > > > that
>>> >> >> > > > > > > there is only one change outside the new pac4j module,
>>> so I
>>> >> >> think
>>> >> >> > > > risks
>>> >> >> > > > > > are
>>> >> >> > > > > > > extremly limited.
>>> >> >> > > > > > >
>>> >> >> > > > > > > Just let met know.
>>> >> >> > > > > > >
>>> >> >> > > > > > > Thanks.
>>> >> >> > > > > > > Best regards,
>>> >> >> > > > > > > Jérôme
>>> >> >> > > > > > >
>>> >> >> > > > > > >
>>> >> >> > > > > > > 2015-12-11 14:23 GMT+01:00 larry mccay <
>>> >> larry.mccay@gmail.com
>>> >> >> >:
>>> >> >> > > > > > >
>>> >> >> > > > > > > > Hi Jérôme -
>>> >> >> > > > > > > >
>>> >> >> > > > > > > > I have unfortunately not had a chance to pull,
>>> review and
>>> >> >> test
>>> >> >> > it
>>> >> >> > > > yet
>>> >> >> > > > > > and
>>> >> >> > > > > > > > have intended to do that today.
>>> >> >> > > > > > > > I apologize for the delay.
>>> >> >> > > > > > > >
>>> >> >> > > > > > > > I was actually thinking that this would go into a
>>> follow
>>> >> up
>>> >> >> > > release
>>> >> >> > > > > > that
>>> >> >> > > > > > > we
>>> >> >> > > > > > > > would try and get done rapidly after the 0.7.0
>>> release
>>> >> but we
>>> >> >> > can
>>> >> >> > > > > > discuss
>>> >> >> > > > > > > > the target and its chances of destabilizing 0.7.0.
>>> >> >> > > > > > > >
>>> >> >> > > > > > > > I believe that it is rather self-contained with only
>>> a few
>>> >> >> > > changes
>>> >> >> > > > to
>>> >> >> > > > > > > > external modules.
>>> >> >> > > > > > > >
>>> >> >> > > > > > > > Opening the JIRAs is perfect and I was going to do
>>> that
>>> >> once
>>> >> >> I
>>> >> >> > > > > started
>>> >> >> > > > > > > the
>>> >> >> > > > > > > > review.
>>> >> >> > > > > > > >
>>> >> >> > > > > > > > Let's continue review comments and collaboration on
>>> those
>>> >> >> > JIRAs.
>>> >> >> > > > > > > > I will add you to the contributors list so that we
>>> can
>>> >> assign
>>> >> >> > > them
>>> >> >> > > > to
>>> >> >> > > > > > > you.
>>> >> >> > > > > > > >
>>> >> >> > > > > > > > Thank you for your contributions and your patience,
>>> >> Jérôme!
>>> >> >> > > > > > > >
>>> >> >> > > > > > > > --larry
>>> >> >> > > > > > > >
>>> >> >> > > > > > > > On Fri, Dec 11, 2015 at 3:00 AM, Jérôme LELEU <
>>> >> >> > leleuj@gmail.com>
>>> >> >> > > > > > wrote:
>>> >> >> > > > > > > >
>>> >> >> > > > > > > > > Hi,
>>> >> >> > > > > > > > >
>>> >> >> > > > > > > > > I didn't get any new feedback on the pull request
>>> so I
>>> >> >> assume
>>> >> >> > > > > > > everything
>>> >> >> > > > > > > > is
>>> >> >> > > > > > > > > ok from your point of view.
>>> >> >> > > > > > > > >
>>> >> >> > > > > > > > > I released pac4j v1.8.1 and j2e-pac4j v1.2.1 so I
>>> >> updated
>>> >> >> the
>>> >> >> > > > pull
>>> >> >> > > > > > > > request
>>> >> >> > > > > > > > > to use them and successfully re-tested everything.
>>> >> >> > > > > > > > >
>>> >> >> > > > > > > > > I opened KNOX-641 and submitted the corresponding
>>> patch.
>>> >> >> > > > > > > > >
>>> >> >> > > > > > > > > I also wrote the documentation, opened KNOX-642 and
>>> >> >> submitted
>>> >> >> > > the
>>> >> >> > > > > > > > > corresponding patch (just to let you know that it
>>> >> doesn't
>>> >> >> > work
>>> >> >> > > > out
>>> >> >> > > > > of
>>> >> >> > > > > > > the
>>> >> >> > > > > > > > > box in Windows, I had to replace mvn.bat by
>>> mvn.cmd to
>>> >> make
>>> >> >> > ant
>>> >> >> > > > > > work).
>>> >> >> > > > > > > > >
>>> >> >> > > > > > > > > Even if the branch 0.7.0 has already been created,
>>> I
>>> >> >> assumed
>>> >> >> > > this
>>> >> >> > > > > new
>>> >> >> > > > > > > > pac4j
>>> >> >> > > > > > > > > provider will go into this version 0.7.0
>>> (dependency on
>>> >> the
>>> >> >> > > > > > > > 0.7.0-SNAPSHOT
>>> >> >> > > > > > > > > parent version).
>>> >> >> > > > > > > > >
>>> >> >> > > > > > > > > Just let me know if everything is ok and when it's
>>> >> goind to
>>> >> >> > be
>>> >> >> > > > > > merged.
>>> >> >> > > > > > > > >
>>> >> >> > > > > > > > > Thanks.
>>> >> >> > > > > > > > > Best regards,
>>> >> >> > > > > > > > > Jérôme
>>> >> >> > > > > > > > >
>>> >> >> > > > > > > > >
>>> >> >> > > > > > > > >
>>> >> >> > > > > > > > >
>>> >> >> > > > > > > > > 2015-12-04 14:20 GMT+01:00 larry mccay <
>>> >> >> > larry.mccay@gmail.com
>>> >> >> > > >:
>>> >> >> > > > > > > > >
>>> >> >> > > > > > > > > > That ability to configure multiple mechanisms
>>> based on
>>> >> >> > > > clientName
>>> >> >> > > > > > is
>>> >> >> > > > > > > > > really
>>> >> >> > > > > > > > > > interesting for Knox.
>>> >> >> > > > > > > > > > Currently, we require separate topologies per
>>> >> >> > authentication
>>> >> >> > > > > > > mechanism.
>>> >> >> > > > > > > > > > The ability to configure them all in one is
>>> really
>>> >> great.
>>> >> >> > > > > > > > > >
>>> >> >> > > > > > > > > > We would need to think through the best way to
>>> provide
>>> >> >> the
>>> >> >> > > > > > clientName
>>> >> >> > > > > > > > > > parameter.
>>> >> >> > > > > > > > > > Since this is targeting KnoxSSO it can actually
>>> be
>>> >> added
>>> >> >> to
>>> >> >> > > the
>>> >> >> > > > > > > > > providerURL
>>> >> >> > > > > > > > > > used to redirect from the participating
>>> application.
>>> >> >> > > > > > > > > > Regardless of the authentication mechanism used
>>> each
>>> >> >> > > > application
>>> >> >> > > > > > will
>>> >> >> > > > > > > > > still
>>> >> >> > > > > > > > > > get the same JWT based cookie.
>>> >> >> > > > > > > > > >
>>> >> >> > > > > > > > > > I think that should work really nicely.
>>> >> >> > > > > > > > > >
>>> >> >> > > > > > > > > >
>>> >> >> > > > > > > > > > On Fri, Dec 4, 2015 at 7:17 AM, larry mccay <
>>> >> >> > > > > larry.mccay@gmail.com
>>> >> >> > > > > > >
>>> >> >> > > > > > > > > wrote:
>>> >> >> > > > > > > > > >
>>> >> >> > > > > > > > > > > Excellent, Jérôme.
>>> >> >> > > > > > > > > > > Thanks!
>>> >> >> > > > > > > > > > >
>>> >> >> > > > > > > > > > > On Fri, Dec 4, 2015 at 2:40 AM, Jérôme LELEU <
>>> >> >> > > > leleuj@gmail.com
>>> >> >> > > > > >
>>> >> >> > > > > > > > wrote:
>>> >> >> > > > > > > > > > >
>>> >> >> > > > > > > > > > >> Hi,
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > > >> I will write how to configure the pac4j
>>> provider in
>>> >> >> the
>>> >> >> > > > > > > > documentation,
>>> >> >> > > > > > > > > > but
>>> >> >> > > > > > > > > > >> I can already give you some insights.
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > > >> My main goal is always to respect the key
>>> design
>>> >> >> > > principles
>>> >> >> > > > of
>>> >> >> > > > > > > pac4j
>>> >> >> > > > > > > > > > >> whatever the environment / framework in which
>>> it is
>>> >> >> > > > > implemented.
>>> >> >> > > > > > > For
>>> >> >> > > > > > > > > > Knox,
>>> >> >> > > > > > > > > > >> I'm pretty happy with the use of the j2e-pac4j
>>> >> >> library,
>>> >> >> > > > which
>>> >> >> > > > > > > means
>>> >> >> > > > > > > > > that
>>> >> >> > > > > > > > > > >> almost all the pac4j features are available,
>>> >> >> especially
>>> >> >> > > both
>>> >> >> > > > > > > direct
>>> >> >> > > > > > > > > and
>>> >> >> > > > > > > > > > >> indirect clients. So it can do what Shiro
>>> already
>>> >> does
>>> >> >> > but
>>> >> >> > > > > also,
>>> >> >> > > > > > > as
>>> >> >> > > > > > > > we
>>> >> >> > > > > > > > > > >> agreed together, supports remote
>>> authentications.
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > > >> It is only limited by what you can currently
>>> >> >> configure.
>>> >> >> > > And
>>> >> >> > > > > even
>>> >> >> > > > > > > > > > >> configuration is a pac4j feature as the CAS
>>> server
>>> >> has
>>> >> >> > the
>>> >> >> > > > > same
>>> >> >> > > > > > > > need.
>>> >> >> > > > > > > > > > >> Everything happens in this class:
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > >
>>> >> >> > > > > > > > >
>>> >> >> > > > > > > >
>>> >> >> > > > > > >
>>> >> >> > > > > >
>>> >> >> > > > >
>>> >> >> > > >
>>> >> >> > >
>>> >> >> >
>>> >> >>
>>> >>
>>> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java
>>> >> >> > > > > > > > > > >> ,
>>> >> >> > > > > > > > > > >> which allows you to configure Facebook,
>>> Twitter, a
>>> >> CAS
>>> >> >> > > > > server, a
>>> >> >> > > > > > > > SAML
>>> >> >> > > > > > > > > > IdP
>>> >> >> > > > > > > > > > >> or an OpenID Connect provider. All the
>>> provided
>>> >> >> > parameters
>>> >> >> > > > to
>>> >> >> > > > > > the
>>> >> >> > > > > > > > > pac4j
>>> >> >> > > > > > > > > > >> provider are put into a Map and the
>>> >> >> > > ConfigPropertiesFactory
>>> >> >> > > > is
>>> >> >> > > > > > > built
>>> >> >> > > > > > > > > > with
>>> >> >> > > > > > > > > > >> this Map to return the built client (=
>>> >> authentication
>>> >> >> > > > > > mechanism).
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > > >> You have one more specific option for Knox as
>>> a
>>> >> basic
>>> >> >> > > > > > > authentication
>>> >> >> > > > > > > > > > popup
>>> >> >> > > > > > > > > > >> where the username must match the password,
>>> you can
>>> >> >> > define
>>> >> >> > > > > that
>>> >> >> > > > > > > by:
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > > >> <param>
>>> >> >> > > > > > > > > > >> <name>clientName</name>
>>> >> >> > > > > > > > > > >> <value>testBasicAuth</value>
>>> >> >> > > > > > > > > > >> </param>
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > > >> It's for testing only.
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > > >> For a CAS server:
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > > >> <param>
>>> >> >> > > > > > > > > > >> <name>cas.loginUrl</name>
>>> >> >> > > > > > > > > > >> <value>
>>> >> https://casserverpac4j.herokuapp.com/login
>>> >> >> > > </value>
>>> >> >> > > > > > > > > > >> </param>
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > > >> Here are all the properties available for
>>> building
>>> >> >> > clients
>>> >> >> > > > > > (their
>>> >> >> > > > > > > > > > meaning
>>> >> >> > > > > > > > > > >> is obvious):
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > > >> facebook.id
>>> >> >> > > > > > > > > > >> facebook.secret
>>> >> >> > > > > > > > > > >> facebook.scope
>>> >> >> > > > > > > > > > >> facebook.fields
>>> >> >> > > > > > > > > > >> twitter.id
>>> >> >> > > > > > > > > > >> twitter.secret
>>> >> >> > > > > > > > > > >> saml.keystorePassword
>>> >> >> > > > > > > > > > >> saml.privateKeyPassword
>>> >> >> > > > > > > > > > >> saml.keystorePath
>>> >> >> > > > > > > > > > >> saml.identityProviderMetadataPath
>>> >> >> > > > > > > > > > >> saml.maximumAuthenticationLifetime
>>> >> >> > > > > > > > > > >> saml.serviceProviderEntityId
>>> >> >> > > > > > > > > > >> saml.serviceProviderMetadataPath
>>> >> >> > > > > > > > > > >> cas.loginUrl
>>> >> >> > > > > > > > > > >> cas.protocol
>>> >> >> > > > > > > > > > >> oidc.id
>>> >> >> > > > > > > > > > >> oidc.secret
>>> >> >> > > > > > > > > > >> oidc.discoveryUri
>>> >> >> > > > > > > > > > >> oidc.customParamKey1
>>> >> >> > > > > > > > > > >> oidc.customParamValue1
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > > >> If you define multiple clients, the first one
>>> will
>>> >> be
>>> >> >> > used
>>> >> >> > > > for
>>> >> >> > > > > > > > > > >> authentication, but you can explicitly choose
>>> the
>>> >> >> client
>>> >> >> > > you
>>> >> >> > > > > > want
>>> >> >> > > > > > > to
>>> >> >> > > > > > > > > use
>>> >> >> > > > > > > > > > >> via the clientName parameter, assuming you
>>> want to
>>> >> >> > switch
>>> >> >> > > > from
>>> >> >> > > > > > > > client
>>> >> >> > > > > > > > > > >> depending on environment for example.
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > > >> So if you want to add some new authentication
>>> >> >> mechanism,
>>> >> >> > > you
>>> >> >> > > > > > must
>>> >> >> > > > > > > > > first
>>> >> >> > > > > > > > > > >> check that it is available in pac4j (if it's
>>> not,
>>> >> it's
>>> >> >> > > > another
>>> >> >> > > > > > > > > > discussion,
>>> >> >> > > > > > > > > > >> but generally, it is). Then, you'll need to
>>> upgrade
>>> >> >> the
>>> >> >> > > > > > > > > > >> ConfigPropertiesFactory by submitting a new
>>> pull
>>> >> >> request
>>> >> >> > > to
>>> >> >> > > > > the
>>> >> >> > > > > > > > pac4j
>>> >> >> > > > > > > > > > >> project (I can do it myself, but I'm sure you
>>> >> could do
>>> >> >> > > that
>>> >> >> > > > > > > easily),
>>> >> >> > > > > > > > > > >> finally wait for the new pac4j release and
>>> switch
>>> >> >> pac4j
>>> >> >> > > > > versions
>>> >> >> > > > > > > in
>>> >> >> > > > > > > > > Knox
>>> >> >> > > > > > > > > > >> to
>>> >> >> > > > > > > > > > >> benefit from the new feature.
>>> >> >> > > > > > > > > > >> The good thing is that if someone related to
>>> the
>>> >> CAS
>>> >> >> > > server
>>> >> >> > > > > does
>>> >> >> > > > > > > the
>>> >> >> > > > > > > > > > same
>>> >> >> > > > > > > > > > >> thing for CAS (in pac4j), you will
>>> automatically
>>> >> get
>>> >> >> it
>>> >> >> > > when
>>> >> >> > > > > > > you'll
>>> >> >> > > > > > > > > > >> upgrade
>>> >> >> > > > > > > > > > >> pac4j.
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > > >> To go even further, replacing LDAP Shiro
>>> >> >> authentication
>>> >> >> > is
>>> >> >> > > > > just
>>> >> >> > > > > > a
>>> >> >> > > > > > > > > matter
>>> >> >> > > > > > > > > > >> of
>>> >> >> > > > > > > > > > >> making pac4j LDAP authentication available via
>>> >> >> > > configuration
>>> >> >> > > > > > > > > parameters.
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > > >> I hope it was clear enough.
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > > >> Thanks.
>>> >> >> > > > > > > > > > >> Best regards,
>>> >> >> > > > > > > > > > >> Jérôme
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > > >> 2015-12-03 20:45 GMT+01:00 larry mccay <
>>> >> >> > > > larry.mccay@gmail.com
>>> >> >> > > > > >:
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > > >> > Excellent!
>>> >> >> > > > > > > > > > >> >
>>> >> >> > > > > > > > > > >> > I will carve out some time to do code
>>> review.
>>> >> >> > > > > > > > > > >> > We will need to get some insights into how
>>> to go
>>> >> >> about
>>> >> >> > > > > > testing:
>>> >> >> > > > > > > > > > >> >
>>> >> >> > > > > > > > > > >> > * is the CAS server going to be available
>>> for
>>> >> >> testing?
>>> >> >> > > > > > > > > > >> > * what are the specific and
>>> generic/standard (if
>>> >> >> any)
>>> >> >> > > > > > > > authentication
>>> >> >> > > > > > > > > > >> > mechanisms available - for instance:
>>> >> >> > > > > > > > > > >> > - Facebook, Google, LinkedIn and CAS are
>>> >> >> specifics
>>> >> >> > > > > > > > > > >> > - OAuth 2, OpenID Connect, SAML are
>>> >> >> > > generic/standards
>>> >> >> > > > -
>>> >> >> > > > > > that
>>> >> >> > > > > > > > may
>>> >> >> > > > > > > > > > be
>>> >> >> > > > > > > > > > >> > used for the above specifics...
>>> >> >> > > > > > > > > > >> > * how do we test things other than CAS - in
>>> >> terms of
>>> >> >> > > > getting
>>> >> >> > > > > > > > > > >> credentials,
>>> >> >> > > > > > > > > > >> > configuration, etc
>>> >> >> > > > > > > > > > >> >
>>> >> >> > > > > > > > > > >> > We could certainly do this is phases as
>>> well.
>>> >> >> > > > > > > > > > >> >
>>> >> >> > > > > > > > > > >> > If you can enumerate the things that should
>>> work
>>> >> and
>>> >> >> > > > provide
>>> >> >> > > > > > > some
>>> >> >> > > > > > > > > > >> testing
>>> >> >> > > > > > > > > > >> > details for CAS or as many as possible and
>>> OpenID
>>> >> >> > > Connect
>>> >> >> > > > > then
>>> >> >> > > > > > > we
>>> >> >> > > > > > > > > can
>>> >> >> > > > > > > > > > >> test
>>> >> >> > > > > > > > > > >> > the specific implementations that you
>>> provide and
>>> >> >> > enable
>>> >> >> > > > the
>>> >> >> > > > > > > > testing
>>> >> >> > > > > > > > > > of
>>> >> >> > > > > > > > > > >> > another OpenID Connect effort that is in the
>>> >> works
>>> >> >> in
>>> >> >> > > the
>>> >> >> > > > > > > > community.
>>> >> >> > > > > > > > > > >> >
>>> >> >> > > > > > > > > > >> > I'm not sure whether we want to commit
>>> >> contributions
>>> >> >> > > that
>>> >> >> > > > > are
>>> >> >> > > > > > > > > > dependent
>>> >> >> > > > > > > > > > >> on
>>> >> >> > > > > > > > > > >> > snapshots - we certainly can't release with
>>> any
>>> >> such
>>> >> >> > > > > > > dependencies.
>>> >> >> > > > > > > > > > >> > I would hate to add a cleanup task to a
>>> release
>>> >> to
>>> >> >> > make
>>> >> >> > > > sure
>>> >> >> > > > > > > there
>>> >> >> > > > > > > > > are
>>> >> >> > > > > > > > > > >> no
>>> >> >> > > > > > > > > > >> > snapshots in there.
>>> >> >> > > > > > > > > > >> > We will probably wait until after the pac4j
>>> >> releases
>>> >> >> > to
>>> >> >> > > > > > commit.
>>> >> >> > > > > > > > > > >> >
>>> >> >> > > > > > > > > > >> > I am really happy that this integration is
>>> >> happening
>>> >> >> > and
>>> >> >> > > > > that
>>> >> >> > > > > > it
>>> >> >> > > > > > > > > went
>>> >> >> > > > > > > > > > >> > rather smoothly.
>>> >> >> > > > > > > > > > >> > These sorts of authentication protocols are
>>> >> complex
>>> >> >> > and
>>> >> >> > > I
>>> >> >> > > > > > think
>>> >> >> > > > > > > we
>>> >> >> > > > > > > > > > >> lined up
>>> >> >> > > > > > > > > > >> > pretty well overall.
>>> >> >> > > > > > > > > > >> >
>>> >> >> > > > > > > > > > >> > Thanks for your work!
>>> >> >> > > > > > > > > > >> >
>>> >> >> > > > > > > > > > >> > On Thu, Dec 3, 2015 at 2:28 PM, Jérôme
>>> LELEU <
>>> >> >> > > > > > leleuj@gmail.com>
>>> >> >> > > > > > > > > > wrote:
>>> >> >> > > > > > > > > > >> >
>>> >> >> > > > > > > > > > >> > > Hi,
>>> >> >> > > > > > > > > > >> > >
>>> >> >> > > > > > > > > > >> > > I just sync'ed with master, cleaned
>>> >> dependencies
>>> >> >> and
>>> >> >> > > > added
>>> >> >> > > > > > > > missing
>>> >> >> > > > > > > > > > >> > > Javadocs. Everything works correctly now.
>>> Many
>>> >> >> > thanks.
>>> >> >> > > > > > > > > > >> > >
>>> >> >> > > > > > > > > > >> > > The pull request is ready for a full code
>>> >> review:
>>> >> >> > > > > > > > > > >> > > https://github.com/apache/knox/pull/2
>>> >> >> > > > > > > > > > >> > >
>>> >> >> > > > > > > > > > >> > > I'll write the documentation after the
>>> pac4j
>>> >> >> > releases
>>> >> >> > > (I
>>> >> >> > > > > > hope
>>> >> >> > > > > > > > next
>>> >> >> > > > > > > > > > >> week).
>>> >> >> > > > > > > > > > >> > >
>>> >> >> > > > > > > > > > >> > > Thanks.
>>> >> >> > > > > > > > > > >> > > Best regards,
>>> >> >> > > > > > > > > > >> > > Jérôme
>>> >> >> > > > > > > > > > >> > >
>>> >> >> > > > > > > > > > >> > >
>>> >> >> > > > > > > > > > >> > > 2015-12-02 19:18 GMT+01:00 larry mccay <
>>> >> >> > > > > > larry.mccay@gmail.com
>>> >> >> > > > > > > >:
>>> >> >> > > > > > > > > > >> > >
>>> >> >> > > > > > > > > > >> > > > Fixed in
>>> >> >> > > > https://issues.apache.org/jira/browse/KNOX-636
>>> >> >> > > > > .
>>> >> >> > > > > > > > > > >> > > >
>>> >> >> > > > > > > > > > >> > > > On Wed, Dec 2, 2015 at 12:42 PM, larry
>>> mccay
>>> >> <
>>> >> >> > > > > > > > > > larry.mccay@gmail.com
>>> >> >> > > > > > > > > > >> >
>>> >> >> > > > > > > > > > >> > > > wrote:
>>> >> >> > > > > > > > > > >> > > >
>>> >> >> > > > > > > > > > >> > > > > Sure - I can file a JIRA and commit a
>>> fix.
>>> >> >> > > > > > > > > > >> > > > >
>>> >> >> > > > > > > > > > >> > > > > The secret generation should be done
>>> in one
>>> >> >> > > instance
>>> >> >> > > > > and
>>> >> >> > > > > > > > > > >> replicated
>>> >> >> > > > > > > > > > >> > > > across
>>> >> >> > > > > > > > > > >> > > > > others.
>>> >> >> > > > > > > > > > >> > > > > This replication/management of the
>>> >> credential
>>> >> >> > > stores
>>> >> >> > > > > is
>>> >> >> > > > > > > > > outside
>>> >> >> > > > > > > > > > of
>>> >> >> > > > > > > > > > >> > the
>>> >> >> > > > > > > > > > >> > > > > scope of Knox itself as of now.
>>> >> >> > > > > > > > > > >> > > > >
>>> >> >> > > > > > > > > > >> > > > > Documentation is done in markdown and
>>> is
>>> >> >> > > > contributing
>>> >> >> > > > > > > > details
>>> >> >> > > > > > > > > > are
>>> >> >> > > > > > > > > > >> > > > > available at:
>>> >> >> > > > > > > > > > >> > > > >
>>> >> >> > > > > > > > > > >> > > >
>>> >> >> > > > > > > > > > >> > >
>>> >> >> > > > > > > > > > >> >
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > >
>>> >> >> > > > > > > > >
>>> >> >> > > > > > > >
>>> >> >> > > > > > >
>>> >> >> > > > > >
>>> >> >> > > > >
>>> >> >> > > >
>>> >> >> > >
>>> >> >> >
>>> >> >>
>>> >>
>>> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
>>> >> >> > > > > > > > > > >> > > > >
>>> >> >> > > > > > > > > > >> > > > > Which should give you a general idea.
>>> >> >> > > > > > > > > > >> > > > >
>>> >> >> > > > > > > > > > >> > > > > Find an example like:
>>> ./trunk/books/0.7.0/
>>> >> >> > > > > > > > > > >> > > config_preauth_sso_provider.md
>>> >> >> > > > > > > > > > >> > > > >
>>> >> >> > > > > > > > > > >> > > > > For an example of typical content and
>>> >> format.
>>> >> >> > > > > > > > > > >> > > > >
>>> >> >> > > > > > > > > > >> > > > > Here is how that example renders:
>>> >> >> > > > > > > > > > >> > > > >
>>> >> >> > > > > > > > > > >> > > >
>>> >> >> > > > > > > > > > >> > >
>>> >> >> > > > > > > > > > >> >
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > >
>>> >> >> > > > > > > > >
>>> >> >> > > > > > > >
>>> >> >> > > > > > >
>>> >> >> > > > > >
>>> >> >> > > > >
>>> >> >> > > >
>>> >> >> > >
>>> >> >> >
>>> >> >>
>>> >>
>>> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
>>> >> >> > > > > > > > > > >> > > > >
>>> >> >> > > > > > > > > > >> > > > > You'll need to tie it into the rest
>>> of the
>>> >> >> book
>>> >> >> > -
>>> >> >> > > > just
>>> >> >> > > > > > > grep
>>> >> >> > > > > > > > > for
>>> >> >> > > > > > > > > > >> where
>>> >> >> > > > > > > > > > >> > > > that
>>> >> >> > > > > > > > > > >> > > > > filename is referenced.
>>> >> >> > > > > > > > > > >> > > > > To test how it renders build the site
>>> with:
>>> >> >> > "ant"
>>> >> >> > > > and
>>> >> >> > > > > > note
>>> >> >> > > > > > > > the
>>> >> >> > > > > > > > > > >> url to
>>> >> >> > > > > > > > > > >> > > the
>>> >> >> > > > > > > > > > >> > > > > 0.7.0 book.
>>> >> >> > > > > > > > > > >> > > > >
>>> >> >> > > > > > > > > > >> > > > >
>>> >> >> > > > > > > > > > >> > > > > On Wed, Dec 2, 2015 at 12:12 PM,
>>> Jérôme
>>> >> LELEU
>>> >> >> <
>>> >> >> > > > > > > > > leleuj@gmail.com
>>> >> >> > > > > > > > > > >
>>> >> >> > > > > > > > > > >> > > wrote:
>>> >> >> > > > > > > > > > >> > > > >
>>> >> >> > > > > > > > > > >> > > > >> Hi,
>>> >> >> > > > > > > > > > >> > > > >>
>>> >> >> > > > > > > > > > >> > > > >> Why it doesn't work for pac4j while
>>> it
>>> >> works
>>> >> >> > for
>>> >> >> > > > > others
>>> >> >> > > > > > > is
>>> >> >> > > > > > > > a
>>> >> >> > > > > > > > > > bit
>>> >> >> > > > > > > > > > >> > > strange
>>> >> >> > > > > > > > > > >> > > > >> to
>>> >> >> > > > > > > > > > >> > > > >> me, but if you have the patch in
>>> front of
>>> >> >> your
>>> >> >> > > > eyes,
>>> >> >> > > > > > I'd
>>> >> >> > > > > > > > > rather
>>> >> >> > > > > > > > > > >> > prefer
>>> >> >> > > > > > > > > > >> > > > you
>>> >> >> > > > > > > > > > >> > > > >> to commit it. In all cases, I'll
>>> sync with
>>> >> >> the
>>> >> >> > > > > master.
>>> >> >> > > > > > > > > > >> > > > >>
>>> >> >> > > > > > > > > > >> > > > >> There was one question you didn't
>>> answer
>>> >> >> > > > previously:
>>> >> >> > > > > is
>>> >> >> > > > > > > the
>>> >> >> > > > > > > > > > >> password
>>> >> >> > > > > > > > > > >> > > > >> generated for the pac4j provider the
>>> same
>>> >> >> > across
>>> >> >> > > > all
>>> >> >> > > > > > > > gateway
>>> >> >> > > > > > > > > > >> > > instances?
>>> >> >> > > > > > > > > > >> > > > >> Because I expect to have the same
>>> value
>>> >> as I
>>> >> >> > use
>>> >> >> > > it
>>> >> >> > > > > to
>>> >> >> > > > > > > > > encrypt
>>> >> >> > > > > > > > > > /
>>> >> >> > > > > > > > > > >> > > decrypt
>>> >> >> > > > > > > > > > >> > > > >> data.
>>> >> >> > > > > > > > > > >> > > > >>
>>> >> >> > > > > > > > > > >> > > > >> I will add the Javadoc. After that,
>>> you
>>> >> can
>>> >> >> > > review
>>> >> >> > > > > the
>>> >> >> > > > > > > pull
>>> >> >> > > > > > > > > > >> request
>>> >> >> > > > > > > > > > >> > > more
>>> >> >> > > > > > > > > > >> > > > >> completely.
>>> >> >> > > > > > > > > > >> > > > >>
>>> >> >> > > > > > > > > > >> > > > >> What do you expect for the
>>> documentation?
>>> >> >> > > > > > > > > > >> > > > >>
>>> >> >> > > > > > > > > > >> > > > >> Notice that pac4j dependencies are
>>> still
>>> >> >> > > snapshots,
>>> >> >> > > > > but
>>> >> >> > > > > > > > they
>>> >> >> > > > > > > > > > >> will be
>>> >> >> > > > > > > > > > >> > > > >> released in a week or two.
>>> >> >> > > > > > > > > > >> > > > >>
>>> >> >> > > > > > > > > > >> > > > >> Thanks.
>>> >> >> > > > > > > > > > >> > > > >> Best regards,
>>> >> >> > > > > > > > > > >> > > > >> Jérôme
>>> >> >> > > > > > > > > > >> > > > >>
>>> >> >> > > > > > > > > > >> > > > >>
>>> >> >> > > > > > > > > > >> > > > >> 2015-12-02 17:51 GMT+01:00 larry
>>> mccay <
>>> >> >> > > > > > > > > larry.mccay@gmail.com
>>> >> >> > > > > > > > > > >:
>>> >> >> > > > > > > > > > >> > > > >>
>>> >> >> > > > > > > > > > >> > > > >> > Jérôme -
>>> >> >> > > > > > > > > > >> > > > >> >
>>> >> >> > > > > > > > > > >> > > > >> > If you would like to add that
>>> change as
>>> >> >> part
>>> >> >> > of
>>> >> >> > > > > your
>>> >> >> > > > > > > > patch
>>> >> >> > > > > > > > > or
>>> >> >> > > > > > > > > > >> as a
>>> >> >> > > > > > > > > > >> > > > >> > separately filed JIRA to fix a bug
>>> that
>>> >> >> would
>>> >> >> > > > > > certainly
>>> >> >> > > > > > > > be
>>> >> >> > > > > > > > > > >> > welcomed.
>>> >> >> > > > > > > > > > >> > > > >> > Otherwise, I can do it.
>>> >> >> > > > > > > > > > >> > > > >> >
>>> >> >> > > > > > > > > > >> > > > >> > Let me know.
>>> >> >> > > > > > > > > > >> > > > >> >
>>> >> >> > > > > > > > > > >> > > > >> > thanks,
>>> >> >> > > > > > > > > > >> > > > >> >
>>> >> >> > > > > > > > > > >> > > > >> > --larry
>>> >> >> > > > > > > > > > >> > > > >> >
>>> >> >> > > > > > > > > > >> > > > >> > On Wed, Dec 2, 2015 at 11:44 AM,
>>> larry
>>> >> >> mccay
>>> >> >> > <
>>> >> >> > > > > > > > > > >> > larry.mccay@gmail.com
>>> >> >> > > > > > > > > > >> > > >
>>> >> >> > > > > > > > > > >> > > > >> > wrote:
>>> >> >> > > > > > > > > > >> > > > >> >
>>> >> >> > > > > > > > > > >> > > > >> > > Okay - I had to add an override
>>> of
>>> >> >> > > > > > getUserPrincipal()
>>> >> >> > > > > > > > to
>>> >> >> > > > > > > > > > the
>>> >> >> > > > > > > > > > >> > > > >> > >
>>> >> IdentityAsserterHttpServletRequestWrapper
>>> >> >> > and
>>> >> >> > > > > > return
>>> >> >> > > > > > > > the
>>> >> >> > > > > > > > > > >> member
>>> >> >> > > > > > > > > > >> > > > >> variable
>>> >> >> > > > > > > > > > >> > > > >> > > username and it works like a
>>> charm.
>>> >> >> > > > > > > > > > >> > > > >> > >
>>> >> >> > > > > > > > > > >> > > > >> > > Why I haven't seen this same
>>> behavior
>>> >> >> with
>>> >> >> > > > other
>>> >> >> > > > > > > > > providers
>>> >> >> > > > > > > > > > >> is a
>>> >> >> > > > > > > > > > >> > > bit
>>> >> >> > > > > > > > > > >> > > > >> of a
>>> >> >> > > > > > > > > > >> > > > >> > > mystery but they must be adding
>>> other
>>> >> >> > > wrappers
>>> >> >> > > > > that
>>> >> >> > > > > > > > > handle
>>> >> >> > > > > > > > > > >> it.
>>> >> >> > > > > > > > > > >> > > > >> > > This is quite cool, Jérôme!
>>> >> >> > > > > > > > > > >> > > > >> > >
>>> >> >> > > > > > > > > > >> > > > >> > > On Wed, Dec 2, 2015 at 10:41 AM,
>>> larry
>>> >> >> > mccay
>>> >> >> > > <
>>> >> >> > > > > > > > > > >> > > larry.mccay@gmail.com
>>> >> >> > > > > > > > > > >> > > > >
>>> >> >> > > > > > > > > > >> > > > >> > > wrote:
>>> >> >> > > > > > > > > > >> > > > >> > >
>>> >> >> > > > > > > > > > >> > > > >> > >> That was it - thanks!
>>> >> >> > > > > > > > > > >> > > > >> > >>
>>> >> >> > > > > > > > > > >> > > > >> > >> On Wed, Dec 2, 2015 at 10:20 AM,
>>> >> Jérôme
>>> >> >> > > LELEU
>>> >> >> > > > <
>>> >> >> > > > > > > > > > >> > leleuj@gmail.com>
>>> >> >> > > > > > > > > > >> > > > >> wrote:
>>> >> >> > > > > > > > > > >> > > > >> > >>
>>> >> >> > > > > > > > > > >> > > > >> > >>> This is my exact command line:
>>> mvn
>>> >> >> > > -Prelease
>>> >> >> > > > > > clean
>>> >> >> > > > > > > > > > install
>>> >> >> > > > > > > > > > >> > > > >> -DskipTests
>>> >> >> > > > > > > > > > >> > > > >> > >>>
>>> >> >> > > > > > > > > > >> > > > >> > >>> You use an internal Maven
>>> >> repository to
>>> >> >> > > fetch
>>> >> >> > > > > > > > > > dependencies
>>> >> >> > > > > > > > > > >> > from
>>> >> >> > > > > > > > > > >> > > > >> > internet:
>>> >> >> > > > > > > > > > >> > > > >> > >>>
>>> >> >> > > > > > > > > > >> > >
>>> >> >> > > > > > > >
>>> >> >> > >
>>> http://nexus-private.hortonworks.com/nexus/content/groups/public/
>>> >> >> > > > > > > > > > >> > > > >> > >>>
>>> >> >> > > > > > > > > > >> > > > >> > >>> Does this repository have
>>> access to
>>> >> the
>>> >> >> > > > remote
>>> >> >> > > > > > > > > Snapshots
>>> >> >> > > > > > > > > > >> > > Sonatype
>>> >> >> > > > > > > > > > >> > > > >> repo?
>>> >> >> > > > > > > > > > >> > > > >> > >>>
>>> >> >> > > > > > > > > > >> > > > >> > >>>
>>> >> >> > > > > > > > > > >> > > > >> > >>>
>>> >> >> > > > > > > > > > >> > > > >> > >>> 2015-12-02 16:16 GMT+01:00
>>> larry
>>> >> mccay
>>> >> >> <
>>> >> >> > > > > > > > > > >> larry.mccay@gmail.com
>>> >> >> > > > > > > > > > >> > >:
>>> >> >> > > > > > > > > > >> > > > >> > >>>
>>> >> >> > > > > > > > > > >> > > > >> > >>> > hmmm - I used:
>>> >> >> > > > > > > > > > >> > > > >> > >>> >
>>> >> >> > > > > > > > > > >> > > > >> > >>> > mvn clean install
>>> -DskipTests=true
>>> >> >> > > > -Prelease
>>> >> >> > > > > > > > > > >> > > > >> > >>> >
>>> >> >> > > > > > > > > > >> > > > >> > >>> > The repository entry is in
>>> there
>>> >> >> > already.
>>> >> >> > > > > > > > > > >> > > > >> > >>> > No worky.
>>> >> >> > > > > > > > > > >> > > > >> > >>> >
>>> >> >> > > > > > > > > > >> > > > >> > >>> > On Wed, Dec 2, 2015 at 10:12
>>> AM,
>>> >> >> Jérôme
>>> >> >> > > > > LELEU <
>>> >> >> > > > > > > > > > >> > > leleuj@gmail.com
>>> >> >> > > > > > > > > > >> > > > >
>>> >> >> > > > > > > > > > >> > > > >> > >>> wrote:
>>> >> >> > > > > > > > > > >> > > > >> > >>> >
>>> >> >> > > > > > > > > > >> > > > >> > >>> > > Hi,
>>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>>> >> >> > > > > > > > > > >> > > > >> > >>> > > You need the j2e-pac4j
>>> >> dependencies
>>> >> >> > as
>>> >> >> > > > well
>>> >> >> > > > > > as
>>> >> >> > > > > > > > the
>>> >> >> > > > > > > > > > >> pac4j-*
>>> >> >> > > > > > > > > > >> > > > >> > >>> dependencies,
>>> >> >> > > > > > > > > > >> > > > >> > >>> > > but you don't need to
>>> build them
>>> >> >> > > locally
>>> >> >> > > > > > > > > (hopefully).
>>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>>> >> >> > > > > > > > > > >> > > > >> > >>> > > But you need a dependency
>>> on the
>>> >> >> > > Sonatype
>>> >> >> > > > > > > > snapshots
>>> >> >> > > > > > > > > > >> > > repository
>>> >> >> > > > > > > > > > >> > > > >> > >>> (where the
>>> >> >> > > > > > > > > > >> > > > >> > >>> > > snapshot versions are
>>> hosted),
>>> >> >> which
>>> >> >> > is
>>> >> >> > > > > added
>>> >> >> > > > > > > for
>>> >> >> > > > > > > > > > >> Maven in
>>> >> >> > > > > > > > > > >> > > the
>>> >> >> > > > > > > > > > >> > > > >> root
>>> >> >> > > > > > > > > > >> > > > >> > >>> > > pom.xml:
>>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>>> >> >> > > > > > > > > > >> > > > >> > >>> >
>>> >> >> > > > > > > > > > >> > > > >> > >>>
>>> >> >> > > > > > > > > > >> > > > >> >
>>> >> >> > > > > > > > > > >> > > > >>
>>> >> >> > > > > > > > > > >> > > >
>>> >> >> > > > > > > > > > >> > >
>>> >> >> > > > > > > > > > >> >
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > >
>>> >> >> > > > > > > > >
>>> >> >> > > > > > > >
>>> >> >> > > > > > >
>>> >> >> > > > > >
>>> >> >> > > > >
>>> >> >> > > >
>>> >> >> > >
>>> >> >> >
>>> >> >>
>>> >>
>>> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
>>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>>> >> >> > > > > > > > > > >> > > > >> > >>> > > If you use Ant for the
>>> build,
>>> >> there
>>> >> >> > is
>>> >> >> > > > > maybe
>>> >> >> > > > > > a
>>> >> >> > > > > > > > > glitch
>>> >> >> > > > > > > > > > >> to
>>> >> >> > > > > > > > > > >> > > find
>>> >> >> > > > > > > > > > >> > > > >> the
>>> >> >> > > > > > > > > > >> > > > >> > >>> > Sonatype
>>> >> >> > > > > > > > > > >> > > > >> > >>> > > Maven repo.
>>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>>> >> >> > > > > > > > > > >> > > > >> > >>> > > Thanks.
>>> >> >> > > > > > > > > > >> > > > >> > >>> > > Best regards,
>>> >> >> > > > > > > > > > >> > > > >> > >>> > > Jérôme
>>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>>> >> >> > > > > > > > > > >> > > > >> > >>> > > 2015-12-02 16:06 GMT+01:00
>>> larry
>>> >> >> > mccay
>>> >> >> > > <
>>> >> >> > > > > > > > > > >> > > larry.mccay@gmail.com
>>> >> >> > > > > > > > > > >> > > > >:
>>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>>> >> >> > > > > > > > > > >> > > > >> > >>> > > > 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.mccay@gmail.com>
>>> >> >> > > > > > > > > > >> > > > >> > >>> > > > wrote:
>>> >> >> > > > > > > > > > >> > > > >> > >>> > > >
>>> >> >> > > > > > > > > > >> > > > >> > >>> > > > >
>>> >> gateway-provider-security-pac4j
>>> >> >> > > > doesn't
>>> >> >> > > > > > > > build -
>>> >> >> > > > > > > > > > do
>>> >> >> > > > > > > > > > >> you
>>> >> >> > > > > > > > > > >> > > > have
>>> >> >> > > > > > > > > > >> > > > >> a
>>> >> >> > > > > > > > > > >> > > > >> > >>> pending
>>> >> >> > > > > > > > > > >> > > > >> > >>> > > > > change for your
>>> pom.xml or
>>> >> >> > > something?
>>> >> >> > > > > > > > > > >> > > > >> > >>> > > > >
>>> >> >> > > > > > > > > > >> > > > >> > >>> >
>>> >> >> > > > > > > > > > >> > > > >> > >>>
>>> >> >> > > > > > > > > > >> > > > >> > >>
>>> >> >> > > > > > > > > > >> > > > >> > >>
>>> >> >> > > > > > > > > > >> > > > >> > >
>>> >> >> > > > > > > > > > >> > > > >> >
>>> >> >> > > > > > > > > > >> > > > >>
>>> >> >> > > > > > > > > > >> > > > >
>>> >> >> > > > > > > > > > >> > > > >
>>> >> >> > > > > > > > > > >> > > >
>>> >> >> > > > > > > > > > >> > >
>>> >> >> > > > > > > > > > >> >
>>> >> >> > > > > > > > > > >>
>>> >> >> > > > > > > > > > >
>>> >> >> > > > > > > > > > >
>>> >> >> > > > > > > > > >
>>> >> >> > > > > > > > >
>>> >> >> > > > > > > >
>>> >> >> > > > > > >
>>> >> >> > > > > >
>>> >> >> > > > >
>>> >> >> > > >
>>> >> >> > >
>>> >> >> >
>>> >> >>
>>> >>
>>>
>>
>>
>
Re: pac4j and Apache Knox
Posted by larry mccay <lm...@apache.org>.
Jérôme -
My testing of OpenID Connect is blocked.
Can you see the comments in KNOX-641?
thanks,
--larry
On Wed, Jan 6, 2016 at 2:30 PM, larry mccay <la...@gmail.com> wrote:
> Jérôme -
>
> Please see the comments on KNOX-641.
>
> thanks,
>
> --larry
>
> On Wed, Jan 6, 2016 at 11:24 AM, Kevin Minder <
> kevin.minder@hortonworks.com> wrote:
>
>> I can certainly appreciate the issue of including external resources in
>> automated tests. Nothing has driven me more crazy over the years. The
>> flip side of this of course is not finding out about a breakage until
>> someone is willing to go through the manual testing which will typically
>> happen just before a release. Also the implication is that these testing
>> procedures must be very will documented so that they can be continue to be
>> run once any of us are no longer active in the project.
>>
>>
>>
>> On 1/6/16, 2:12 AM, "Jérôme LELEU" <le...@gmail.com> wrote:
>>
>> >Hi,
>> >
>> >Yes, you can hit the CAS server at Heroku. Notice it's a Heroku free
>> server
>> >so it needs to be re-activated first (it takes a couple of seconds). So
>> for
>> >a UI test, you should first hit it, wait 30 seconds and then perform the
>> >test.
>> >
>> >Just my 2 cents:
>> >Using automated UI tests was my first strategy for pac4j but I finally
>> >gave up because public providers change very often, at least enough to
>> make
>> >the maintenance tests a nightmare. Currently, I'm using manual tests (the
>> >same for all demos), it takes me around 5 minutes to play them all by
>> hand
>> >(for a demo) and I launched manually the UI tests I have for every major
>> >pac4j release. Just to say UI tests are not that easy. For a CAS server,
>> >it's fairly feasible as the CAS server and protocol change rarely.
>> >That's why for Knox, I did some compromise with a simulated web test
>> (based
>> >on the basic auth). See:
>> >
>> https://github.com/apache/knox/pull/2/files#diff-d0c880ca71b310dbe57975c577535e97R47
>> >
>> >Thanks.
>> >Best regards,
>> >Jérôme
>> >
>> >
>> >
>> >2016-01-05 21:20 GMT+01:00 Kevin Minder <ke...@hortonworks.com>:
>> >
>> >> From my perspective it would be ideal if there were some automatable
>> >> functional tests for this. I’m not advocating that these be something
>> >> included in “mvn clean install” as that is running too long as it is.
>> >> Given that I don’t have as much context as Larry, I have some questions
>> >> about what this would take. Lets say we had permission to hit
>> >> https://casserverpac4j.herokuapp.com/login as part of some low
>> frequency
>> >> automated tests (e.g. Once nighty). What static credentials and other
>> test
>> >> automation infrastructure would need to be implemented in support of
>> this?
>> >> I understand that the test suite would require at a minimum
>> >> 1) a test driver
>> >> 2) a protected mock UI and
>> >> 3) an appropriately configured Knox
>> >> 4) a profile enabled maven module
>> >> 5) an Apache jenkins job
>> >> but I’m sure I’m missing other things. I’m certainly willing to help
>> >> setup the skeleton infrastructure (e.g. test driver, mock UI, maven
>> module,
>> >> jenkins job)
>> >>
>> >>
>> >>
>> >> On 1/5/16, 2:54 PM, "larry mccay" <la...@gmail.com> wrote:
>> >>
>> >> >Okay, very good.
>> >> >I've used TestShib for the picketlink provider - thanks for the
>> pointers!
>> >> >
>> >> >On Tue, Jan 5, 2016 at 1:38 PM, Jérôme LELEU <le...@gmail.com>
>> wrote:
>> >> >
>> >> >> The online CAS server (https://casserverpac4j.herokuapp.com/login)
>> uses
>> >> >> the
>> >> >> CAS protocol. SAML support can be tested using some online IdP like
>> >> Okta,
>> >> >> TestShib, OpenFeide, Ssocircle...
>> >> >>
>> >> >>
>> >> >> 2016-01-05 17:32 GMT+01:00 larry mccay <la...@gmail.com>:
>> >> >>
>> >> >> > Great - thanks for that pointer!
>> >> >> >
>> >> >> > I will take a look at that and help drive the release related
>> testing.
>> >> >> > Merge testing will be gated on CAS server (is this SAML or CAS
>> >> protocol?)
>> >> >> > and testBasicAuth.
>> >> >> >
>> >> >> > On Tue, Jan 5, 2016 at 10:52 AM, Jérôme LELEU <le...@gmail.com>
>> >> wrote:
>> >> >> >
>> >> >> > > Hi,
>> >> >> > >
>> >> >> > > Glad to hear back from you!
>> >> >> > >
>> >> >> > > The core pac4j project is fully tested by unit tests (and some
>> >> >> > integration
>> >> >> > > tests I run for major version), then all pac4j implementations
>> are
>> >> each
>> >> >> > > tested by the appropriate demo: j2e-pac4j-demo tests j2e-pac4j,
>> >> >> > > spring-webmvc-pac4j-demo tests spring-webmvc-pac4j, etc.
>> >> >> > >
>> >> >> > > So if you take a look at:
>> >> >> > >
>> >> >> > >
>> >> >> >
>> >> >>
>> >>
>> https://github.com/pac4j/j2e-pac4j-demo/blob/master/src/main/java/org/pac4j/demo/j2e/config/DemoConfigFactory.java#L27
>> >> >> > > (for example), you have all the required information to test.
>> >> >> > >
>> >> >> > > I can do that on my own, but it can be good for the Knox
>> community
>> >> to
>> >> >> > start
>> >> >> > > working / testing the pac4j support. It's up to yoy.
>> >> >> > >
>> >> >> > > Thanks.
>> >> >> > > Best regards,
>> >> >> > > Jérôme
>> >> >> > >
>> >> >> > >
>> >> >> > > 2016-01-05 16:11 GMT+01:00 larry mccay <la...@gmail.com>:
>> >> >> > >
>> >> >> > > > Hello Jérôme -
>> >> >> > > >
>> >> >> > > > Happy New Year!
>> >> >> > > >
>> >> >> > > > I am going to start reviewing your updates today, hopefully.
>> >> >> > > > I was thinking that we need to start discussions on what the
>> key
>> >> >> > usecases
>> >> >> > > > are and how to go about testing them.
>> >> >> > > > We can certainly test the testBasicAuth and against the
>> hosted CAS
>> >> >> > server
>> >> >> > > > but what about FB, openid, OAuth, etc?
>> >> >> > > >
>> >> >> > > > I'm not sure that FB would be a key feature but OpenID
>> Connect and
>> >> >> > OAuth
>> >> >> > > > would be - as is SAML.
>> >> >> > > > I think CAS buys us SAML testing - assuming that the
>> >> configuration of
>> >> >> > the
>> >> >> > > > hosted server is actually a SAML 2 instance.
>> >> >> > > >
>> >> >> > > > What about the others?
>> >> >> > > >
>> >> >> > > > I don't know that we need to be able to test them all before
>> merge
>> >> >> but
>> >> >> > > some
>> >> >> > > > sort of manual verification would be great.
>> >> >> > > > We would need to be able to test them before the next release
>> >> which
>> >> >> > would
>> >> >> > > > be featuring the pac4j functionality.
>> >> >> > > >
>> >> >> > > > Maybe you can describe how you go about testing such things
>> for
>> >> the
>> >> >> > pac4j
>> >> >> > > > project itself?
>> >> >> > > >
>> >> >> > > > thanks,
>> >> >> > > >
>> >> >> > > > --larry
>> >> >> > > >
>> >> >> > > >
>> >> >> > > > On Tue, Jan 5, 2016 at 9:55 AM, Jérôme LELEU <
>> leleuj@gmail.com>
>> >> >> wrote:
>> >> >> > > >
>> >> >> > > > > Hi,
>> >> >> > > > >
>> >> >> > > > > Happy new year!
>> >> >> > > > >
>> >> >> > > > > A few days ago, I updated my patch of the pac4j gateway
>> provider
>> >> >> > > > according
>> >> >> > > > > to all comments on
>> >> https://issues.apache.org/jira/browse/KNOX-641
>> >> >> as
>> >> >> > > > well
>> >> >> > > > > as the documentation on KNOX-642.
>> >> >> > > > >
>> >> >> > > > > Is everything ok for the merge?
>> >> >> > > > >
>> >> >> > > > > Thanks.
>> >> >> > > > > Best regards,
>> >> >> > > > > Jérôme
>> >> >> > > > >
>> >> >> > > > >
>> >> >> > > > > 2015-12-14 15:28 GMT+01:00 larry mccay <
>> larry.mccay@gmail.com>:
>> >> >> > > > >
>> >> >> > > > > > Hi Jérôme -
>> >> >> > > > > >
>> >> >> > > > > > Not sure if you saw but I added review comments to
>> KNOX-641.
>> >> >> > > > > >
>> >> >> > > > > > I think that we need to determine whether we want the
>> >> >> testBasicAuth
>> >> >> > > in
>> >> >> > > > > the
>> >> >> > > > > > provider itself.
>> >> >> > > > > >
>> >> >> > > > > > Let's follow up on the JIRA.
>> >> >> > > > > >
>> >> >> > > > > > thanks,
>> >> >> > > > > >
>> >> >> > > > > > --larry
>> >> >> > > > > >
>> >> >> > > > > > On Fri, Dec 11, 2015 at 8:44 AM, Jérôme LELEU <
>> >> leleuj@gmail.com>
>> >> >> > > > wrote:
>> >> >> > > > > >
>> >> >> > > > > > > Hi,
>> >> >> > > > > > >
>> >> >> > > > > > > No problem. It can go into a version 0.8.0 if needed.
>> The
>> >> truth
>> >> >> > is
>> >> >> > > > that
>> >> >> > > > > > > there is only one change outside the new pac4j module,
>> so I
>> >> >> think
>> >> >> > > > risks
>> >> >> > > > > > are
>> >> >> > > > > > > extremly limited.
>> >> >> > > > > > >
>> >> >> > > > > > > Just let met know.
>> >> >> > > > > > >
>> >> >> > > > > > > Thanks.
>> >> >> > > > > > > Best regards,
>> >> >> > > > > > > Jérôme
>> >> >> > > > > > >
>> >> >> > > > > > >
>> >> >> > > > > > > 2015-12-11 14:23 GMT+01:00 larry mccay <
>> >> larry.mccay@gmail.com
>> >> >> >:
>> >> >> > > > > > >
>> >> >> > > > > > > > Hi Jérôme -
>> >> >> > > > > > > >
>> >> >> > > > > > > > I have unfortunately not had a chance to pull, review
>> and
>> >> >> test
>> >> >> > it
>> >> >> > > > yet
>> >> >> > > > > > and
>> >> >> > > > > > > > have intended to do that today.
>> >> >> > > > > > > > I apologize for the delay.
>> >> >> > > > > > > >
>> >> >> > > > > > > > I was actually thinking that this would go into a
>> follow
>> >> up
>> >> >> > > release
>> >> >> > > > > > that
>> >> >> > > > > > > we
>> >> >> > > > > > > > would try and get done rapidly after the 0.7.0 release
>> >> but we
>> >> >> > can
>> >> >> > > > > > discuss
>> >> >> > > > > > > > the target and its chances of destabilizing 0.7.0.
>> >> >> > > > > > > >
>> >> >> > > > > > > > I believe that it is rather self-contained with only
>> a few
>> >> >> > > changes
>> >> >> > > > to
>> >> >> > > > > > > > external modules.
>> >> >> > > > > > > >
>> >> >> > > > > > > > Opening the JIRAs is perfect and I was going to do
>> that
>> >> once
>> >> >> I
>> >> >> > > > > started
>> >> >> > > > > > > the
>> >> >> > > > > > > > review.
>> >> >> > > > > > > >
>> >> >> > > > > > > > Let's continue review comments and collaboration on
>> those
>> >> >> > JIRAs.
>> >> >> > > > > > > > I will add you to the contributors list so that we can
>> >> assign
>> >> >> > > them
>> >> >> > > > to
>> >> >> > > > > > > you.
>> >> >> > > > > > > >
>> >> >> > > > > > > > Thank you for your contributions and your patience,
>> >> Jérôme!
>> >> >> > > > > > > >
>> >> >> > > > > > > > --larry
>> >> >> > > > > > > >
>> >> >> > > > > > > > On Fri, Dec 11, 2015 at 3:00 AM, Jérôme LELEU <
>> >> >> > leleuj@gmail.com>
>> >> >> > > > > > wrote:
>> >> >> > > > > > > >
>> >> >> > > > > > > > > Hi,
>> >> >> > > > > > > > >
>> >> >> > > > > > > > > I didn't get any new feedback on the pull request
>> so I
>> >> >> assume
>> >> >> > > > > > > everything
>> >> >> > > > > > > > is
>> >> >> > > > > > > > > ok from your point of view.
>> >> >> > > > > > > > >
>> >> >> > > > > > > > > I released pac4j v1.8.1 and j2e-pac4j v1.2.1 so I
>> >> updated
>> >> >> the
>> >> >> > > > pull
>> >> >> > > > > > > > request
>> >> >> > > > > > > > > to use them and successfully re-tested everything.
>> >> >> > > > > > > > >
>> >> >> > > > > > > > > I opened KNOX-641 and submitted the corresponding
>> patch.
>> >> >> > > > > > > > >
>> >> >> > > > > > > > > I also wrote the documentation, opened KNOX-642 and
>> >> >> submitted
>> >> >> > > the
>> >> >> > > > > > > > > corresponding patch (just to let you know that it
>> >> doesn't
>> >> >> > work
>> >> >> > > > out
>> >> >> > > > > of
>> >> >> > > > > > > the
>> >> >> > > > > > > > > box in Windows, I had to replace mvn.bat by mvn.cmd
>> to
>> >> make
>> >> >> > ant
>> >> >> > > > > > work).
>> >> >> > > > > > > > >
>> >> >> > > > > > > > > Even if the branch 0.7.0 has already been created, I
>> >> >> assumed
>> >> >> > > this
>> >> >> > > > > new
>> >> >> > > > > > > > pac4j
>> >> >> > > > > > > > > provider will go into this version 0.7.0
>> (dependency on
>> >> the
>> >> >> > > > > > > > 0.7.0-SNAPSHOT
>> >> >> > > > > > > > > parent version).
>> >> >> > > > > > > > >
>> >> >> > > > > > > > > Just let me know if everything is ok and when it's
>> >> goind to
>> >> >> > be
>> >> >> > > > > > merged.
>> >> >> > > > > > > > >
>> >> >> > > > > > > > > Thanks.
>> >> >> > > > > > > > > Best regards,
>> >> >> > > > > > > > > Jérôme
>> >> >> > > > > > > > >
>> >> >> > > > > > > > >
>> >> >> > > > > > > > >
>> >> >> > > > > > > > >
>> >> >> > > > > > > > > 2015-12-04 14:20 GMT+01:00 larry mccay <
>> >> >> > larry.mccay@gmail.com
>> >> >> > > >:
>> >> >> > > > > > > > >
>> >> >> > > > > > > > > > That ability to configure multiple mechanisms
>> based on
>> >> >> > > > clientName
>> >> >> > > > > > is
>> >> >> > > > > > > > > really
>> >> >> > > > > > > > > > interesting for Knox.
>> >> >> > > > > > > > > > Currently, we require separate topologies per
>> >> >> > authentication
>> >> >> > > > > > > mechanism.
>> >> >> > > > > > > > > > The ability to configure them all in one is really
>> >> great.
>> >> >> > > > > > > > > >
>> >> >> > > > > > > > > > We would need to think through the best way to
>> provide
>> >> >> the
>> >> >> > > > > > clientName
>> >> >> > > > > > > > > > parameter.
>> >> >> > > > > > > > > > Since this is targeting KnoxSSO it can actually be
>> >> added
>> >> >> to
>> >> >> > > the
>> >> >> > > > > > > > > providerURL
>> >> >> > > > > > > > > > used to redirect from the participating
>> application.
>> >> >> > > > > > > > > > Regardless of the authentication mechanism used
>> each
>> >> >> > > > application
>> >> >> > > > > > will
>> >> >> > > > > > > > > still
>> >> >> > > > > > > > > > get the same JWT based cookie.
>> >> >> > > > > > > > > >
>> >> >> > > > > > > > > > I think that should work really nicely.
>> >> >> > > > > > > > > >
>> >> >> > > > > > > > > >
>> >> >> > > > > > > > > > On Fri, Dec 4, 2015 at 7:17 AM, larry mccay <
>> >> >> > > > > larry.mccay@gmail.com
>> >> >> > > > > > >
>> >> >> > > > > > > > > wrote:
>> >> >> > > > > > > > > >
>> >> >> > > > > > > > > > > Excellent, Jérôme.
>> >> >> > > > > > > > > > > Thanks!
>> >> >> > > > > > > > > > >
>> >> >> > > > > > > > > > > On Fri, Dec 4, 2015 at 2:40 AM, Jérôme LELEU <
>> >> >> > > > leleuj@gmail.com
>> >> >> > > > > >
>> >> >> > > > > > > > wrote:
>> >> >> > > > > > > > > > >
>> >> >> > > > > > > > > > >> Hi,
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > > >> I will write how to configure the pac4j
>> provider in
>> >> >> the
>> >> >> > > > > > > > documentation,
>> >> >> > > > > > > > > > but
>> >> >> > > > > > > > > > >> I can already give you some insights.
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > > >> My main goal is always to respect the key
>> design
>> >> >> > > principles
>> >> >> > > > of
>> >> >> > > > > > > pac4j
>> >> >> > > > > > > > > > >> whatever the environment / framework in which
>> it is
>> >> >> > > > > implemented.
>> >> >> > > > > > > For
>> >> >> > > > > > > > > > Knox,
>> >> >> > > > > > > > > > >> I'm pretty happy with the use of the j2e-pac4j
>> >> >> library,
>> >> >> > > > which
>> >> >> > > > > > > means
>> >> >> > > > > > > > > that
>> >> >> > > > > > > > > > >> almost all the pac4j features are available,
>> >> >> especially
>> >> >> > > both
>> >> >> > > > > > > direct
>> >> >> > > > > > > > > and
>> >> >> > > > > > > > > > >> indirect clients. So it can do what Shiro
>> already
>> >> does
>> >> >> > but
>> >> >> > > > > also,
>> >> >> > > > > > > as
>> >> >> > > > > > > > we
>> >> >> > > > > > > > > > >> agreed together, supports remote
>> authentications.
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > > >> It is only limited by what you can currently
>> >> >> configure.
>> >> >> > > And
>> >> >> > > > > even
>> >> >> > > > > > > > > > >> configuration is a pac4j feature as the CAS
>> server
>> >> has
>> >> >> > the
>> >> >> > > > > same
>> >> >> > > > > > > > need.
>> >> >> > > > > > > > > > >> Everything happens in this class:
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > >
>> >> >> > > > > > > > >
>> >> >> > > > > > > >
>> >> >> > > > > > >
>> >> >> > > > > >
>> >> >> > > > >
>> >> >> > > >
>> >> >> > >
>> >> >> >
>> >> >>
>> >>
>> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java
>> >> >> > > > > > > > > > >> ,
>> >> >> > > > > > > > > > >> which allows you to configure Facebook,
>> Twitter, a
>> >> CAS
>> >> >> > > > > server, a
>> >> >> > > > > > > > SAML
>> >> >> > > > > > > > > > IdP
>> >> >> > > > > > > > > > >> or an OpenID Connect provider. All the provided
>> >> >> > parameters
>> >> >> > > > to
>> >> >> > > > > > the
>> >> >> > > > > > > > > pac4j
>> >> >> > > > > > > > > > >> provider are put into a Map and the
>> >> >> > > ConfigPropertiesFactory
>> >> >> > > > is
>> >> >> > > > > > > built
>> >> >> > > > > > > > > > with
>> >> >> > > > > > > > > > >> this Map to return the built client (=
>> >> authentication
>> >> >> > > > > > mechanism).
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > > >> You have one more specific option for Knox as a
>> >> basic
>> >> >> > > > > > > authentication
>> >> >> > > > > > > > > > popup
>> >> >> > > > > > > > > > >> where the username must match the password,
>> you can
>> >> >> > define
>> >> >> > > > > that
>> >> >> > > > > > > by:
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > > >> <param>
>> >> >> > > > > > > > > > >> <name>clientName</name>
>> >> >> > > > > > > > > > >> <value>testBasicAuth</value>
>> >> >> > > > > > > > > > >> </param>
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > > >> It's for testing only.
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > > >> For a CAS server:
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > > >> <param>
>> >> >> > > > > > > > > > >> <name>cas.loginUrl</name>
>> >> >> > > > > > > > > > >> <value>
>> >> https://casserverpac4j.herokuapp.com/login
>> >> >> > > </value>
>> >> >> > > > > > > > > > >> </param>
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > > >> Here are all the properties available for
>> building
>> >> >> > clients
>> >> >> > > > > > (their
>> >> >> > > > > > > > > > meaning
>> >> >> > > > > > > > > > >> is obvious):
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > > >> facebook.id
>> >> >> > > > > > > > > > >> facebook.secret
>> >> >> > > > > > > > > > >> facebook.scope
>> >> >> > > > > > > > > > >> facebook.fields
>> >> >> > > > > > > > > > >> twitter.id
>> >> >> > > > > > > > > > >> twitter.secret
>> >> >> > > > > > > > > > >> saml.keystorePassword
>> >> >> > > > > > > > > > >> saml.privateKeyPassword
>> >> >> > > > > > > > > > >> saml.keystorePath
>> >> >> > > > > > > > > > >> saml.identityProviderMetadataPath
>> >> >> > > > > > > > > > >> saml.maximumAuthenticationLifetime
>> >> >> > > > > > > > > > >> saml.serviceProviderEntityId
>> >> >> > > > > > > > > > >> saml.serviceProviderMetadataPath
>> >> >> > > > > > > > > > >> cas.loginUrl
>> >> >> > > > > > > > > > >> cas.protocol
>> >> >> > > > > > > > > > >> oidc.id
>> >> >> > > > > > > > > > >> oidc.secret
>> >> >> > > > > > > > > > >> oidc.discoveryUri
>> >> >> > > > > > > > > > >> oidc.customParamKey1
>> >> >> > > > > > > > > > >> oidc.customParamValue1
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > > >> If you define multiple clients, the first one
>> will
>> >> be
>> >> >> > used
>> >> >> > > > for
>> >> >> > > > > > > > > > >> authentication, but you can explicitly choose
>> the
>> >> >> client
>> >> >> > > you
>> >> >> > > > > > want
>> >> >> > > > > > > to
>> >> >> > > > > > > > > use
>> >> >> > > > > > > > > > >> via the clientName parameter, assuming you
>> want to
>> >> >> > switch
>> >> >> > > > from
>> >> >> > > > > > > > client
>> >> >> > > > > > > > > > >> depending on environment for example.
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > > >> So if you want to add some new authentication
>> >> >> mechanism,
>> >> >> > > you
>> >> >> > > > > > must
>> >> >> > > > > > > > > first
>> >> >> > > > > > > > > > >> check that it is available in pac4j (if it's
>> not,
>> >> it's
>> >> >> > > > another
>> >> >> > > > > > > > > > discussion,
>> >> >> > > > > > > > > > >> but generally, it is). Then, you'll need to
>> upgrade
>> >> >> the
>> >> >> > > > > > > > > > >> ConfigPropertiesFactory by submitting a new
>> pull
>> >> >> request
>> >> >> > > to
>> >> >> > > > > the
>> >> >> > > > > > > > pac4j
>> >> >> > > > > > > > > > >> project (I can do it myself, but I'm sure you
>> >> could do
>> >> >> > > that
>> >> >> > > > > > > easily),
>> >> >> > > > > > > > > > >> finally wait for the new pac4j release and
>> switch
>> >> >> pac4j
>> >> >> > > > > versions
>> >> >> > > > > > > in
>> >> >> > > > > > > > > Knox
>> >> >> > > > > > > > > > >> to
>> >> >> > > > > > > > > > >> benefit from the new feature.
>> >> >> > > > > > > > > > >> The good thing is that if someone related to
>> the
>> >> CAS
>> >> >> > > server
>> >> >> > > > > does
>> >> >> > > > > > > the
>> >> >> > > > > > > > > > same
>> >> >> > > > > > > > > > >> thing for CAS (in pac4j), you will
>> automatically
>> >> get
>> >> >> it
>> >> >> > > when
>> >> >> > > > > > > you'll
>> >> >> > > > > > > > > > >> upgrade
>> >> >> > > > > > > > > > >> pac4j.
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > > >> To go even further, replacing LDAP Shiro
>> >> >> authentication
>> >> >> > is
>> >> >> > > > > just
>> >> >> > > > > > a
>> >> >> > > > > > > > > matter
>> >> >> > > > > > > > > > >> of
>> >> >> > > > > > > > > > >> making pac4j LDAP authentication available via
>> >> >> > > configuration
>> >> >> > > > > > > > > parameters.
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > > >> I hope it was clear enough.
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > > >> Thanks.
>> >> >> > > > > > > > > > >> Best regards,
>> >> >> > > > > > > > > > >> Jérôme
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > > >> 2015-12-03 20:45 GMT+01:00 larry mccay <
>> >> >> > > > larry.mccay@gmail.com
>> >> >> > > > > >:
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > > >> > Excellent!
>> >> >> > > > > > > > > > >> >
>> >> >> > > > > > > > > > >> > I will carve out some time to do code review.
>> >> >> > > > > > > > > > >> > We will need to get some insights into how
>> to go
>> >> >> about
>> >> >> > > > > > testing:
>> >> >> > > > > > > > > > >> >
>> >> >> > > > > > > > > > >> > * is the CAS server going to be available for
>> >> >> testing?
>> >> >> > > > > > > > > > >> > * what are the specific and generic/standard
>> (if
>> >> >> any)
>> >> >> > > > > > > > authentication
>> >> >> > > > > > > > > > >> > mechanisms available - for instance:
>> >> >> > > > > > > > > > >> > - Facebook, Google, LinkedIn and CAS are
>> >> >> specifics
>> >> >> > > > > > > > > > >> > - OAuth 2, OpenID Connect, SAML are
>> >> >> > > generic/standards
>> >> >> > > > -
>> >> >> > > > > > that
>> >> >> > > > > > > > may
>> >> >> > > > > > > > > > be
>> >> >> > > > > > > > > > >> > used for the above specifics...
>> >> >> > > > > > > > > > >> > * how do we test things other than CAS - in
>> >> terms of
>> >> >> > > > getting
>> >> >> > > > > > > > > > >> credentials,
>> >> >> > > > > > > > > > >> > configuration, etc
>> >> >> > > > > > > > > > >> >
>> >> >> > > > > > > > > > >> > We could certainly do this is phases as well.
>> >> >> > > > > > > > > > >> >
>> >> >> > > > > > > > > > >> > If you can enumerate the things that should
>> work
>> >> and
>> >> >> > > > provide
>> >> >> > > > > > > some
>> >> >> > > > > > > > > > >> testing
>> >> >> > > > > > > > > > >> > details for CAS or as many as possible and
>> OpenID
>> >> >> > > Connect
>> >> >> > > > > then
>> >> >> > > > > > > we
>> >> >> > > > > > > > > can
>> >> >> > > > > > > > > > >> test
>> >> >> > > > > > > > > > >> > the specific implementations that you
>> provide and
>> >> >> > enable
>> >> >> > > > the
>> >> >> > > > > > > > testing
>> >> >> > > > > > > > > > of
>> >> >> > > > > > > > > > >> > another OpenID Connect effort that is in the
>> >> works
>> >> >> in
>> >> >> > > the
>> >> >> > > > > > > > community.
>> >> >> > > > > > > > > > >> >
>> >> >> > > > > > > > > > >> > I'm not sure whether we want to commit
>> >> contributions
>> >> >> > > that
>> >> >> > > > > are
>> >> >> > > > > > > > > > dependent
>> >> >> > > > > > > > > > >> on
>> >> >> > > > > > > > > > >> > snapshots - we certainly can't release with
>> any
>> >> such
>> >> >> > > > > > > dependencies.
>> >> >> > > > > > > > > > >> > I would hate to add a cleanup task to a
>> release
>> >> to
>> >> >> > make
>> >> >> > > > sure
>> >> >> > > > > > > there
>> >> >> > > > > > > > > are
>> >> >> > > > > > > > > > >> no
>> >> >> > > > > > > > > > >> > snapshots in there.
>> >> >> > > > > > > > > > >> > We will probably wait until after the pac4j
>> >> releases
>> >> >> > to
>> >> >> > > > > > commit.
>> >> >> > > > > > > > > > >> >
>> >> >> > > > > > > > > > >> > I am really happy that this integration is
>> >> happening
>> >> >> > and
>> >> >> > > > > that
>> >> >> > > > > > it
>> >> >> > > > > > > > > went
>> >> >> > > > > > > > > > >> > rather smoothly.
>> >> >> > > > > > > > > > >> > These sorts of authentication protocols are
>> >> complex
>> >> >> > and
>> >> >> > > I
>> >> >> > > > > > think
>> >> >> > > > > > > we
>> >> >> > > > > > > > > > >> lined up
>> >> >> > > > > > > > > > >> > pretty well overall.
>> >> >> > > > > > > > > > >> >
>> >> >> > > > > > > > > > >> > Thanks for your work!
>> >> >> > > > > > > > > > >> >
>> >> >> > > > > > > > > > >> > On Thu, Dec 3, 2015 at 2:28 PM, Jérôme LELEU
>> <
>> >> >> > > > > > leleuj@gmail.com>
>> >> >> > > > > > > > > > wrote:
>> >> >> > > > > > > > > > >> >
>> >> >> > > > > > > > > > >> > > Hi,
>> >> >> > > > > > > > > > >> > >
>> >> >> > > > > > > > > > >> > > I just sync'ed with master, cleaned
>> >> dependencies
>> >> >> and
>> >> >> > > > added
>> >> >> > > > > > > > missing
>> >> >> > > > > > > > > > >> > > Javadocs. Everything works correctly now.
>> Many
>> >> >> > thanks.
>> >> >> > > > > > > > > > >> > >
>> >> >> > > > > > > > > > >> > > The pull request is ready for a full code
>> >> review:
>> >> >> > > > > > > > > > >> > > https://github.com/apache/knox/pull/2
>> >> >> > > > > > > > > > >> > >
>> >> >> > > > > > > > > > >> > > I'll write the documentation after the
>> pac4j
>> >> >> > releases
>> >> >> > > (I
>> >> >> > > > > > hope
>> >> >> > > > > > > > next
>> >> >> > > > > > > > > > >> week).
>> >> >> > > > > > > > > > >> > >
>> >> >> > > > > > > > > > >> > > Thanks.
>> >> >> > > > > > > > > > >> > > Best regards,
>> >> >> > > > > > > > > > >> > > Jérôme
>> >> >> > > > > > > > > > >> > >
>> >> >> > > > > > > > > > >> > >
>> >> >> > > > > > > > > > >> > > 2015-12-02 19:18 GMT+01:00 larry mccay <
>> >> >> > > > > > larry.mccay@gmail.com
>> >> >> > > > > > > >:
>> >> >> > > > > > > > > > >> > >
>> >> >> > > > > > > > > > >> > > > Fixed in
>> >> >> > > > https://issues.apache.org/jira/browse/KNOX-636
>> >> >> > > > > .
>> >> >> > > > > > > > > > >> > > >
>> >> >> > > > > > > > > > >> > > > On Wed, Dec 2, 2015 at 12:42 PM, larry
>> mccay
>> >> <
>> >> >> > > > > > > > > > larry.mccay@gmail.com
>> >> >> > > > > > > > > > >> >
>> >> >> > > > > > > > > > >> > > > wrote:
>> >> >> > > > > > > > > > >> > > >
>> >> >> > > > > > > > > > >> > > > > Sure - I can file a JIRA and commit a
>> fix.
>> >> >> > > > > > > > > > >> > > > >
>> >> >> > > > > > > > > > >> > > > > The secret generation should be done
>> in one
>> >> >> > > instance
>> >> >> > > > > and
>> >> >> > > > > > > > > > >> replicated
>> >> >> > > > > > > > > > >> > > > across
>> >> >> > > > > > > > > > >> > > > > others.
>> >> >> > > > > > > > > > >> > > > > This replication/management of the
>> >> credential
>> >> >> > > stores
>> >> >> > > > > is
>> >> >> > > > > > > > > outside
>> >> >> > > > > > > > > > of
>> >> >> > > > > > > > > > >> > the
>> >> >> > > > > > > > > > >> > > > > scope of Knox itself as of now.
>> >> >> > > > > > > > > > >> > > > >
>> >> >> > > > > > > > > > >> > > > > Documentation is done in markdown and
>> is
>> >> >> > > > contributing
>> >> >> > > > > > > > details
>> >> >> > > > > > > > > > are
>> >> >> > > > > > > > > > >> > > > > available at:
>> >> >> > > > > > > > > > >> > > > >
>> >> >> > > > > > > > > > >> > > >
>> >> >> > > > > > > > > > >> > >
>> >> >> > > > > > > > > > >> >
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > >
>> >> >> > > > > > > > >
>> >> >> > > > > > > >
>> >> >> > > > > > >
>> >> >> > > > > >
>> >> >> > > > >
>> >> >> > > >
>> >> >> > >
>> >> >> >
>> >> >>
>> >>
>> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
>> >> >> > > > > > > > > > >> > > > >
>> >> >> > > > > > > > > > >> > > > > Which should give you a general idea.
>> >> >> > > > > > > > > > >> > > > >
>> >> >> > > > > > > > > > >> > > > > Find an example like:
>> ./trunk/books/0.7.0/
>> >> >> > > > > > > > > > >> > > config_preauth_sso_provider.md
>> >> >> > > > > > > > > > >> > > > >
>> >> >> > > > > > > > > > >> > > > > For an example of typical content and
>> >> format.
>> >> >> > > > > > > > > > >> > > > >
>> >> >> > > > > > > > > > >> > > > > Here is how that example renders:
>> >> >> > > > > > > > > > >> > > > >
>> >> >> > > > > > > > > > >> > > >
>> >> >> > > > > > > > > > >> > >
>> >> >> > > > > > > > > > >> >
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > >
>> >> >> > > > > > > > >
>> >> >> > > > > > > >
>> >> >> > > > > > >
>> >> >> > > > > >
>> >> >> > > > >
>> >> >> > > >
>> >> >> > >
>> >> >> >
>> >> >>
>> >>
>> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
>> >> >> > > > > > > > > > >> > > > >
>> >> >> > > > > > > > > > >> > > > > You'll need to tie it into the rest of
>> the
>> >> >> book
>> >> >> > -
>> >> >> > > > just
>> >> >> > > > > > > grep
>> >> >> > > > > > > > > for
>> >> >> > > > > > > > > > >> where
>> >> >> > > > > > > > > > >> > > > that
>> >> >> > > > > > > > > > >> > > > > filename is referenced.
>> >> >> > > > > > > > > > >> > > > > To test how it renders build the site
>> with:
>> >> >> > "ant"
>> >> >> > > > and
>> >> >> > > > > > note
>> >> >> > > > > > > > the
>> >> >> > > > > > > > > > >> url to
>> >> >> > > > > > > > > > >> > > the
>> >> >> > > > > > > > > > >> > > > > 0.7.0 book.
>> >> >> > > > > > > > > > >> > > > >
>> >> >> > > > > > > > > > >> > > > >
>> >> >> > > > > > > > > > >> > > > > On Wed, Dec 2, 2015 at 12:12 PM, Jérôme
>> >> LELEU
>> >> >> <
>> >> >> > > > > > > > > leleuj@gmail.com
>> >> >> > > > > > > > > > >
>> >> >> > > > > > > > > > >> > > wrote:
>> >> >> > > > > > > > > > >> > > > >
>> >> >> > > > > > > > > > >> > > > >> Hi,
>> >> >> > > > > > > > > > >> > > > >>
>> >> >> > > > > > > > > > >> > > > >> Why it doesn't work for pac4j while it
>> >> works
>> >> >> > for
>> >> >> > > > > others
>> >> >> > > > > > > is
>> >> >> > > > > > > > a
>> >> >> > > > > > > > > > bit
>> >> >> > > > > > > > > > >> > > strange
>> >> >> > > > > > > > > > >> > > > >> to
>> >> >> > > > > > > > > > >> > > > >> me, but if you have the patch in
>> front of
>> >> >> your
>> >> >> > > > eyes,
>> >> >> > > > > > I'd
>> >> >> > > > > > > > > rather
>> >> >> > > > > > > > > > >> > prefer
>> >> >> > > > > > > > > > >> > > > you
>> >> >> > > > > > > > > > >> > > > >> to commit it. In all cases, I'll sync
>> with
>> >> >> the
>> >> >> > > > > master.
>> >> >> > > > > > > > > > >> > > > >>
>> >> >> > > > > > > > > > >> > > > >> There was one question you didn't
>> answer
>> >> >> > > > previously:
>> >> >> > > > > is
>> >> >> > > > > > > the
>> >> >> > > > > > > > > > >> password
>> >> >> > > > > > > > > > >> > > > >> generated for the pac4j provider the
>> same
>> >> >> > across
>> >> >> > > > all
>> >> >> > > > > > > > gateway
>> >> >> > > > > > > > > > >> > > instances?
>> >> >> > > > > > > > > > >> > > > >> Because I expect to have the same
>> value
>> >> as I
>> >> >> > use
>> >> >> > > it
>> >> >> > > > > to
>> >> >> > > > > > > > > encrypt
>> >> >> > > > > > > > > > /
>> >> >> > > > > > > > > > >> > > decrypt
>> >> >> > > > > > > > > > >> > > > >> data.
>> >> >> > > > > > > > > > >> > > > >>
>> >> >> > > > > > > > > > >> > > > >> I will add the Javadoc. After that,
>> you
>> >> can
>> >> >> > > review
>> >> >> > > > > the
>> >> >> > > > > > > pull
>> >> >> > > > > > > > > > >> request
>> >> >> > > > > > > > > > >> > > more
>> >> >> > > > > > > > > > >> > > > >> completely.
>> >> >> > > > > > > > > > >> > > > >>
>> >> >> > > > > > > > > > >> > > > >> What do you expect for the
>> documentation?
>> >> >> > > > > > > > > > >> > > > >>
>> >> >> > > > > > > > > > >> > > > >> Notice that pac4j dependencies are
>> still
>> >> >> > > snapshots,
>> >> >> > > > > but
>> >> >> > > > > > > > they
>> >> >> > > > > > > > > > >> will be
>> >> >> > > > > > > > > > >> > > > >> released in a week or two.
>> >> >> > > > > > > > > > >> > > > >>
>> >> >> > > > > > > > > > >> > > > >> Thanks.
>> >> >> > > > > > > > > > >> > > > >> Best regards,
>> >> >> > > > > > > > > > >> > > > >> Jérôme
>> >> >> > > > > > > > > > >> > > > >>
>> >> >> > > > > > > > > > >> > > > >>
>> >> >> > > > > > > > > > >> > > > >> 2015-12-02 17:51 GMT+01:00 larry
>> mccay <
>> >> >> > > > > > > > > larry.mccay@gmail.com
>> >> >> > > > > > > > > > >:
>> >> >> > > > > > > > > > >> > > > >>
>> >> >> > > > > > > > > > >> > > > >> > Jérôme -
>> >> >> > > > > > > > > > >> > > > >> >
>> >> >> > > > > > > > > > >> > > > >> > If you would like to add that
>> change as
>> >> >> part
>> >> >> > of
>> >> >> > > > > your
>> >> >> > > > > > > > patch
>> >> >> > > > > > > > > or
>> >> >> > > > > > > > > > >> as a
>> >> >> > > > > > > > > > >> > > > >> > separately filed JIRA to fix a bug
>> that
>> >> >> would
>> >> >> > > > > > certainly
>> >> >> > > > > > > > be
>> >> >> > > > > > > > > > >> > welcomed.
>> >> >> > > > > > > > > > >> > > > >> > Otherwise, I can do it.
>> >> >> > > > > > > > > > >> > > > >> >
>> >> >> > > > > > > > > > >> > > > >> > Let me know.
>> >> >> > > > > > > > > > >> > > > >> >
>> >> >> > > > > > > > > > >> > > > >> > thanks,
>> >> >> > > > > > > > > > >> > > > >> >
>> >> >> > > > > > > > > > >> > > > >> > --larry
>> >> >> > > > > > > > > > >> > > > >> >
>> >> >> > > > > > > > > > >> > > > >> > On Wed, Dec 2, 2015 at 11:44 AM,
>> larry
>> >> >> mccay
>> >> >> > <
>> >> >> > > > > > > > > > >> > larry.mccay@gmail.com
>> >> >> > > > > > > > > > >> > > >
>> >> >> > > > > > > > > > >> > > > >> > wrote:
>> >> >> > > > > > > > > > >> > > > >> >
>> >> >> > > > > > > > > > >> > > > >> > > Okay - I had to add an override of
>> >> >> > > > > > getUserPrincipal()
>> >> >> > > > > > > > to
>> >> >> > > > > > > > > > the
>> >> >> > > > > > > > > > >> > > > >> > >
>> >> IdentityAsserterHttpServletRequestWrapper
>> >> >> > and
>> >> >> > > > > > return
>> >> >> > > > > > > > the
>> >> >> > > > > > > > > > >> member
>> >> >> > > > > > > > > > >> > > > >> variable
>> >> >> > > > > > > > > > >> > > > >> > > username and it works like a
>> charm.
>> >> >> > > > > > > > > > >> > > > >> > >
>> >> >> > > > > > > > > > >> > > > >> > > Why I haven't seen this same
>> behavior
>> >> >> with
>> >> >> > > > other
>> >> >> > > > > > > > > providers
>> >> >> > > > > > > > > > >> is a
>> >> >> > > > > > > > > > >> > > bit
>> >> >> > > > > > > > > > >> > > > >> of a
>> >> >> > > > > > > > > > >> > > > >> > > mystery but they must be adding
>> other
>> >> >> > > wrappers
>> >> >> > > > > that
>> >> >> > > > > > > > > handle
>> >> >> > > > > > > > > > >> it.
>> >> >> > > > > > > > > > >> > > > >> > > This is quite cool, Jérôme!
>> >> >> > > > > > > > > > >> > > > >> > >
>> >> >> > > > > > > > > > >> > > > >> > > On Wed, Dec 2, 2015 at 10:41 AM,
>> larry
>> >> >> > mccay
>> >> >> > > <
>> >> >> > > > > > > > > > >> > > larry.mccay@gmail.com
>> >> >> > > > > > > > > > >> > > > >
>> >> >> > > > > > > > > > >> > > > >> > > wrote:
>> >> >> > > > > > > > > > >> > > > >> > >
>> >> >> > > > > > > > > > >> > > > >> > >> That was it - thanks!
>> >> >> > > > > > > > > > >> > > > >> > >>
>> >> >> > > > > > > > > > >> > > > >> > >> On Wed, Dec 2, 2015 at 10:20 AM,
>> >> Jérôme
>> >> >> > > LELEU
>> >> >> > > > <
>> >> >> > > > > > > > > > >> > leleuj@gmail.com>
>> >> >> > > > > > > > > > >> > > > >> wrote:
>> >> >> > > > > > > > > > >> > > > >> > >>
>> >> >> > > > > > > > > > >> > > > >> > >>> This is my exact command line:
>> mvn
>> >> >> > > -Prelease
>> >> >> > > > > > clean
>> >> >> > > > > > > > > > install
>> >> >> > > > > > > > > > >> > > > >> -DskipTests
>> >> >> > > > > > > > > > >> > > > >> > >>>
>> >> >> > > > > > > > > > >> > > > >> > >>> You use an internal Maven
>> >> repository to
>> >> >> > > fetch
>> >> >> > > > > > > > > > dependencies
>> >> >> > > > > > > > > > >> > from
>> >> >> > > > > > > > > > >> > > > >> > internet:
>> >> >> > > > > > > > > > >> > > > >> > >>>
>> >> >> > > > > > > > > > >> > >
>> >> >> > > > > > > >
>> >> >> > >
>> http://nexus-private.hortonworks.com/nexus/content/groups/public/
>> >> >> > > > > > > > > > >> > > > >> > >>>
>> >> >> > > > > > > > > > >> > > > >> > >>> Does this repository have
>> access to
>> >> the
>> >> >> > > > remote
>> >> >> > > > > > > > > Snapshots
>> >> >> > > > > > > > > > >> > > Sonatype
>> >> >> > > > > > > > > > >> > > > >> repo?
>> >> >> > > > > > > > > > >> > > > >> > >>>
>> >> >> > > > > > > > > > >> > > > >> > >>>
>> >> >> > > > > > > > > > >> > > > >> > >>>
>> >> >> > > > > > > > > > >> > > > >> > >>> 2015-12-02 16:16 GMT+01:00 larry
>> >> mccay
>> >> >> <
>> >> >> > > > > > > > > > >> larry.mccay@gmail.com
>> >> >> > > > > > > > > > >> > >:
>> >> >> > > > > > > > > > >> > > > >> > >>>
>> >> >> > > > > > > > > > >> > > > >> > >>> > hmmm - I used:
>> >> >> > > > > > > > > > >> > > > >> > >>> >
>> >> >> > > > > > > > > > >> > > > >> > >>> > mvn clean install
>> -DskipTests=true
>> >> >> > > > -Prelease
>> >> >> > > > > > > > > > >> > > > >> > >>> >
>> >> >> > > > > > > > > > >> > > > >> > >>> > The repository entry is in
>> there
>> >> >> > already.
>> >> >> > > > > > > > > > >> > > > >> > >>> > No worky.
>> >> >> > > > > > > > > > >> > > > >> > >>> >
>> >> >> > > > > > > > > > >> > > > >> > >>> > On Wed, Dec 2, 2015 at 10:12
>> AM,
>> >> >> Jérôme
>> >> >> > > > > LELEU <
>> >> >> > > > > > > > > > >> > > leleuj@gmail.com
>> >> >> > > > > > > > > > >> > > > >
>> >> >> > > > > > > > > > >> > > > >> > >>> wrote:
>> >> >> > > > > > > > > > >> > > > >> > >>> >
>> >> >> > > > > > > > > > >> > > > >> > >>> > > Hi,
>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>> >> >> > > > > > > > > > >> > > > >> > >>> > > You need the j2e-pac4j
>> >> dependencies
>> >> >> > as
>> >> >> > > > well
>> >> >> > > > > > as
>> >> >> > > > > > > > the
>> >> >> > > > > > > > > > >> pac4j-*
>> >> >> > > > > > > > > > >> > > > >> > >>> dependencies,
>> >> >> > > > > > > > > > >> > > > >> > >>> > > but you don't need to build
>> them
>> >> >> > > locally
>> >> >> > > > > > > > > (hopefully).
>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>> >> >> > > > > > > > > > >> > > > >> > >>> > > But you need a dependency
>> on the
>> >> >> > > Sonatype
>> >> >> > > > > > > > snapshots
>> >> >> > > > > > > > > > >> > > repository
>> >> >> > > > > > > > > > >> > > > >> > >>> (where the
>> >> >> > > > > > > > > > >> > > > >> > >>> > > snapshot versions are
>> hosted),
>> >> >> which
>> >> >> > is
>> >> >> > > > > added
>> >> >> > > > > > > for
>> >> >> > > > > > > > > > >> Maven in
>> >> >> > > > > > > > > > >> > > the
>> >> >> > > > > > > > > > >> > > > >> root
>> >> >> > > > > > > > > > >> > > > >> > >>> > > pom.xml:
>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>> >> >> > > > > > > > > > >> > > > >> > >>> >
>> >> >> > > > > > > > > > >> > > > >> > >>>
>> >> >> > > > > > > > > > >> > > > >> >
>> >> >> > > > > > > > > > >> > > > >>
>> >> >> > > > > > > > > > >> > > >
>> >> >> > > > > > > > > > >> > >
>> >> >> > > > > > > > > > >> >
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > >
>> >> >> > > > > > > > >
>> >> >> > > > > > > >
>> >> >> > > > > > >
>> >> >> > > > > >
>> >> >> > > > >
>> >> >> > > >
>> >> >> > >
>> >> >> >
>> >> >>
>> >>
>> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>> >> >> > > > > > > > > > >> > > > >> > >>> > > If you use Ant for the
>> build,
>> >> there
>> >> >> > is
>> >> >> > > > > maybe
>> >> >> > > > > > a
>> >> >> > > > > > > > > glitch
>> >> >> > > > > > > > > > >> to
>> >> >> > > > > > > > > > >> > > find
>> >> >> > > > > > > > > > >> > > > >> the
>> >> >> > > > > > > > > > >> > > > >> > >>> > Sonatype
>> >> >> > > > > > > > > > >> > > > >> > >>> > > Maven repo.
>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>> >> >> > > > > > > > > > >> > > > >> > >>> > > Thanks.
>> >> >> > > > > > > > > > >> > > > >> > >>> > > Best regards,
>> >> >> > > > > > > > > > >> > > > >> > >>> > > Jérôme
>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>> >> >> > > > > > > > > > >> > > > >> > >>> > > 2015-12-02 16:06 GMT+01:00
>> larry
>> >> >> > mccay
>> >> >> > > <
>> >> >> > > > > > > > > > >> > > larry.mccay@gmail.com
>> >> >> > > > > > > > > > >> > > > >:
>> >> >> > > > > > > > > > >> > > > >> > >>> > >
>> >> >> > > > > > > > > > >> > > > >> > >>> > > > 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.mccay@gmail.com>
>> >> >> > > > > > > > > > >> > > > >> > >>> > > > wrote:
>> >> >> > > > > > > > > > >> > > > >> > >>> > > >
>> >> >> > > > > > > > > > >> > > > >> > >>> > > > >
>> >> gateway-provider-security-pac4j
>> >> >> > > > doesn't
>> >> >> > > > > > > > build -
>> >> >> > > > > > > > > > do
>> >> >> > > > > > > > > > >> you
>> >> >> > > > > > > > > > >> > > > have
>> >> >> > > > > > > > > > >> > > > >> a
>> >> >> > > > > > > > > > >> > > > >> > >>> pending
>> >> >> > > > > > > > > > >> > > > >> > >>> > > > > change for your pom.xml
>> or
>> >> >> > > something?
>> >> >> > > > > > > > > > >> > > > >> > >>> > > > >
>> >> >> > > > > > > > > > >> > > > >> > >>> >
>> >> >> > > > > > > > > > >> > > > >> > >>>
>> >> >> > > > > > > > > > >> > > > >> > >>
>> >> >> > > > > > > > > > >> > > > >> > >>
>> >> >> > > > > > > > > > >> > > > >> > >
>> >> >> > > > > > > > > > >> > > > >> >
>> >> >> > > > > > > > > > >> > > > >>
>> >> >> > > > > > > > > > >> > > > >
>> >> >> > > > > > > > > > >> > > > >
>> >> >> > > > > > > > > > >> > > >
>> >> >> > > > > > > > > > >> > >
>> >> >> > > > > > > > > > >> >
>> >> >> > > > > > > > > > >>
>> >> >> > > > > > > > > > >
>> >> >> > > > > > > > > > >
>> >> >> > > > > > > > > >
>> >> >> > > > > > > > >
>> >> >> > > > > > > >
>> >> >> > > > > > >
>> >> >> > > > > >
>> >> >> > > > >
>> >> >> > > >
>> >> >> > >
>> >> >> >
>> >> >>
>> >>
>>
>
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
Jérôme -
Please see the comments on KNOX-641.
thanks,
--larry
On Wed, Jan 6, 2016 at 11:24 AM, Kevin Minder <ke...@hortonworks.com>
wrote:
> I can certainly appreciate the issue of including external resources in
> automated tests. Nothing has driven me more crazy over the years. The
> flip side of this of course is not finding out about a breakage until
> someone is willing to go through the manual testing which will typically
> happen just before a release. Also the implication is that these testing
> procedures must be very will documented so that they can be continue to be
> run once any of us are no longer active in the project.
>
>
>
> On 1/6/16, 2:12 AM, "Jérôme LELEU" <le...@gmail.com> wrote:
>
> >Hi,
> >
> >Yes, you can hit the CAS server at Heroku. Notice it's a Heroku free
> server
> >so it needs to be re-activated first (it takes a couple of seconds). So
> for
> >a UI test, you should first hit it, wait 30 seconds and then perform the
> >test.
> >
> >Just my 2 cents:
> >Using automated UI tests was my first strategy for pac4j but I finally
> >gave up because public providers change very often, at least enough to
> make
> >the maintenance tests a nightmare. Currently, I'm using manual tests (the
> >same for all demos), it takes me around 5 minutes to play them all by hand
> >(for a demo) and I launched manually the UI tests I have for every major
> >pac4j release. Just to say UI tests are not that easy. For a CAS server,
> >it's fairly feasible as the CAS server and protocol change rarely.
> >That's why for Knox, I did some compromise with a simulated web test
> (based
> >on the basic auth). See:
> >
> https://github.com/apache/knox/pull/2/files#diff-d0c880ca71b310dbe57975c577535e97R47
> >
> >Thanks.
> >Best regards,
> >Jérôme
> >
> >
> >
> >2016-01-05 21:20 GMT+01:00 Kevin Minder <ke...@hortonworks.com>:
> >
> >> From my perspective it would be ideal if there were some automatable
> >> functional tests for this. I’m not advocating that these be something
> >> included in “mvn clean install” as that is running too long as it is.
> >> Given that I don’t have as much context as Larry, I have some questions
> >> about what this would take. Lets say we had permission to hit
> >> https://casserverpac4j.herokuapp.com/login as part of some low
> frequency
> >> automated tests (e.g. Once nighty). What static credentials and other
> test
> >> automation infrastructure would need to be implemented in support of
> this?
> >> I understand that the test suite would require at a minimum
> >> 1) a test driver
> >> 2) a protected mock UI and
> >> 3) an appropriately configured Knox
> >> 4) a profile enabled maven module
> >> 5) an Apache jenkins job
> >> but I’m sure I’m missing other things. I’m certainly willing to help
> >> setup the skeleton infrastructure (e.g. test driver, mock UI, maven
> module,
> >> jenkins job)
> >>
> >>
> >>
> >> On 1/5/16, 2:54 PM, "larry mccay" <la...@gmail.com> wrote:
> >>
> >> >Okay, very good.
> >> >I've used TestShib for the picketlink provider - thanks for the
> pointers!
> >> >
> >> >On Tue, Jan 5, 2016 at 1:38 PM, Jérôme LELEU <le...@gmail.com> wrote:
> >> >
> >> >> The online CAS server (https://casserverpac4j.herokuapp.com/login)
> uses
> >> >> the
> >> >> CAS protocol. SAML support can be tested using some online IdP like
> >> Okta,
> >> >> TestShib, OpenFeide, Ssocircle...
> >> >>
> >> >>
> >> >> 2016-01-05 17:32 GMT+01:00 larry mccay <la...@gmail.com>:
> >> >>
> >> >> > Great - thanks for that pointer!
> >> >> >
> >> >> > I will take a look at that and help drive the release related
> testing.
> >> >> > Merge testing will be gated on CAS server (is this SAML or CAS
> >> protocol?)
> >> >> > and testBasicAuth.
> >> >> >
> >> >> > On Tue, Jan 5, 2016 at 10:52 AM, Jérôme LELEU <le...@gmail.com>
> >> wrote:
> >> >> >
> >> >> > > Hi,
> >> >> > >
> >> >> > > Glad to hear back from you!
> >> >> > >
> >> >> > > The core pac4j project is fully tested by unit tests (and some
> >> >> > integration
> >> >> > > tests I run for major version), then all pac4j implementations
> are
> >> each
> >> >> > > tested by the appropriate demo: j2e-pac4j-demo tests j2e-pac4j,
> >> >> > > spring-webmvc-pac4j-demo tests spring-webmvc-pac4j, etc.
> >> >> > >
> >> >> > > So if you take a look at:
> >> >> > >
> >> >> > >
> >> >> >
> >> >>
> >>
> https://github.com/pac4j/j2e-pac4j-demo/blob/master/src/main/java/org/pac4j/demo/j2e/config/DemoConfigFactory.java#L27
> >> >> > > (for example), you have all the required information to test.
> >> >> > >
> >> >> > > I can do that on my own, but it can be good for the Knox
> community
> >> to
> >> >> > start
> >> >> > > working / testing the pac4j support. It's up to yoy.
> >> >> > >
> >> >> > > Thanks.
> >> >> > > Best regards,
> >> >> > > Jérôme
> >> >> > >
> >> >> > >
> >> >> > > 2016-01-05 16:11 GMT+01:00 larry mccay <la...@gmail.com>:
> >> >> > >
> >> >> > > > Hello Jérôme -
> >> >> > > >
> >> >> > > > Happy New Year!
> >> >> > > >
> >> >> > > > I am going to start reviewing your updates today, hopefully.
> >> >> > > > I was thinking that we need to start discussions on what the
> key
> >> >> > usecases
> >> >> > > > are and how to go about testing them.
> >> >> > > > We can certainly test the testBasicAuth and against the hosted
> CAS
> >> >> > server
> >> >> > > > but what about FB, openid, OAuth, etc?
> >> >> > > >
> >> >> > > > I'm not sure that FB would be a key feature but OpenID Connect
> and
> >> >> > OAuth
> >> >> > > > would be - as is SAML.
> >> >> > > > I think CAS buys us SAML testing - assuming that the
> >> configuration of
> >> >> > the
> >> >> > > > hosted server is actually a SAML 2 instance.
> >> >> > > >
> >> >> > > > What about the others?
> >> >> > > >
> >> >> > > > I don't know that we need to be able to test them all before
> merge
> >> >> but
> >> >> > > some
> >> >> > > > sort of manual verification would be great.
> >> >> > > > We would need to be able to test them before the next release
> >> which
> >> >> > would
> >> >> > > > be featuring the pac4j functionality.
> >> >> > > >
> >> >> > > > Maybe you can describe how you go about testing such things for
> >> the
> >> >> > pac4j
> >> >> > > > project itself?
> >> >> > > >
> >> >> > > > thanks,
> >> >> > > >
> >> >> > > > --larry
> >> >> > > >
> >> >> > > >
> >> >> > > > On Tue, Jan 5, 2016 at 9:55 AM, Jérôme LELEU <leleuj@gmail.com
> >
> >> >> wrote:
> >> >> > > >
> >> >> > > > > Hi,
> >> >> > > > >
> >> >> > > > > Happy new year!
> >> >> > > > >
> >> >> > > > > A few days ago, I updated my patch of the pac4j gateway
> provider
> >> >> > > > according
> >> >> > > > > to all comments on
> >> https://issues.apache.org/jira/browse/KNOX-641
> >> >> as
> >> >> > > > well
> >> >> > > > > as the documentation on KNOX-642.
> >> >> > > > >
> >> >> > > > > Is everything ok for the merge?
> >> >> > > > >
> >> >> > > > > Thanks.
> >> >> > > > > Best regards,
> >> >> > > > > Jérôme
> >> >> > > > >
> >> >> > > > >
> >> >> > > > > 2015-12-14 15:28 GMT+01:00 larry mccay <
> larry.mccay@gmail.com>:
> >> >> > > > >
> >> >> > > > > > Hi Jérôme -
> >> >> > > > > >
> >> >> > > > > > Not sure if you saw but I added review comments to
> KNOX-641.
> >> >> > > > > >
> >> >> > > > > > I think that we need to determine whether we want the
> >> >> testBasicAuth
> >> >> > > in
> >> >> > > > > the
> >> >> > > > > > provider itself.
> >> >> > > > > >
> >> >> > > > > > Let's follow up on the JIRA.
> >> >> > > > > >
> >> >> > > > > > thanks,
> >> >> > > > > >
> >> >> > > > > > --larry
> >> >> > > > > >
> >> >> > > > > > On Fri, Dec 11, 2015 at 8:44 AM, Jérôme LELEU <
> >> leleuj@gmail.com>
> >> >> > > > wrote:
> >> >> > > > > >
> >> >> > > > > > > Hi,
> >> >> > > > > > >
> >> >> > > > > > > No problem. It can go into a version 0.8.0 if needed. The
> >> truth
> >> >> > is
> >> >> > > > that
> >> >> > > > > > > there is only one change outside the new pac4j module,
> so I
> >> >> think
> >> >> > > > risks
> >> >> > > > > > are
> >> >> > > > > > > extremly limited.
> >> >> > > > > > >
> >> >> > > > > > > Just let met know.
> >> >> > > > > > >
> >> >> > > > > > > Thanks.
> >> >> > > > > > > Best regards,
> >> >> > > > > > > Jérôme
> >> >> > > > > > >
> >> >> > > > > > >
> >> >> > > > > > > 2015-12-11 14:23 GMT+01:00 larry mccay <
> >> larry.mccay@gmail.com
> >> >> >:
> >> >> > > > > > >
> >> >> > > > > > > > Hi Jérôme -
> >> >> > > > > > > >
> >> >> > > > > > > > I have unfortunately not had a chance to pull, review
> and
> >> >> test
> >> >> > it
> >> >> > > > yet
> >> >> > > > > > and
> >> >> > > > > > > > have intended to do that today.
> >> >> > > > > > > > I apologize for the delay.
> >> >> > > > > > > >
> >> >> > > > > > > > I was actually thinking that this would go into a
> follow
> >> up
> >> >> > > release
> >> >> > > > > > that
> >> >> > > > > > > we
> >> >> > > > > > > > would try and get done rapidly after the 0.7.0 release
> >> but we
> >> >> > can
> >> >> > > > > > discuss
> >> >> > > > > > > > the target and its chances of destabilizing 0.7.0.
> >> >> > > > > > > >
> >> >> > > > > > > > I believe that it is rather self-contained with only a
> few
> >> >> > > changes
> >> >> > > > to
> >> >> > > > > > > > external modules.
> >> >> > > > > > > >
> >> >> > > > > > > > Opening the JIRAs is perfect and I was going to do that
> >> once
> >> >> I
> >> >> > > > > started
> >> >> > > > > > > the
> >> >> > > > > > > > review.
> >> >> > > > > > > >
> >> >> > > > > > > > Let's continue review comments and collaboration on
> those
> >> >> > JIRAs.
> >> >> > > > > > > > I will add you to the contributors list so that we can
> >> assign
> >> >> > > them
> >> >> > > > to
> >> >> > > > > > > you.
> >> >> > > > > > > >
> >> >> > > > > > > > Thank you for your contributions and your patience,
> >> Jérôme!
> >> >> > > > > > > >
> >> >> > > > > > > > --larry
> >> >> > > > > > > >
> >> >> > > > > > > > On Fri, Dec 11, 2015 at 3:00 AM, Jérôme LELEU <
> >> >> > leleuj@gmail.com>
> >> >> > > > > > wrote:
> >> >> > > > > > > >
> >> >> > > > > > > > > Hi,
> >> >> > > > > > > > >
> >> >> > > > > > > > > I didn't get any new feedback on the pull request so
> I
> >> >> assume
> >> >> > > > > > > everything
> >> >> > > > > > > > is
> >> >> > > > > > > > > ok from your point of view.
> >> >> > > > > > > > >
> >> >> > > > > > > > > I released pac4j v1.8.1 and j2e-pac4j v1.2.1 so I
> >> updated
> >> >> the
> >> >> > > > pull
> >> >> > > > > > > > request
> >> >> > > > > > > > > to use them and successfully re-tested everything.
> >> >> > > > > > > > >
> >> >> > > > > > > > > I opened KNOX-641 and submitted the corresponding
> patch.
> >> >> > > > > > > > >
> >> >> > > > > > > > > I also wrote the documentation, opened KNOX-642 and
> >> >> submitted
> >> >> > > the
> >> >> > > > > > > > > corresponding patch (just to let you know that it
> >> doesn't
> >> >> > work
> >> >> > > > out
> >> >> > > > > of
> >> >> > > > > > > the
> >> >> > > > > > > > > box in Windows, I had to replace mvn.bat by mvn.cmd
> to
> >> make
> >> >> > ant
> >> >> > > > > > work).
> >> >> > > > > > > > >
> >> >> > > > > > > > > Even if the branch 0.7.0 has already been created, I
> >> >> assumed
> >> >> > > this
> >> >> > > > > new
> >> >> > > > > > > > pac4j
> >> >> > > > > > > > > provider will go into this version 0.7.0 (dependency
> on
> >> the
> >> >> > > > > > > > 0.7.0-SNAPSHOT
> >> >> > > > > > > > > parent version).
> >> >> > > > > > > > >
> >> >> > > > > > > > > Just let me know if everything is ok and when it's
> >> goind to
> >> >> > be
> >> >> > > > > > merged.
> >> >> > > > > > > > >
> >> >> > > > > > > > > Thanks.
> >> >> > > > > > > > > Best regards,
> >> >> > > > > > > > > Jérôme
> >> >> > > > > > > > >
> >> >> > > > > > > > >
> >> >> > > > > > > > >
> >> >> > > > > > > > >
> >> >> > > > > > > > > 2015-12-04 14:20 GMT+01:00 larry mccay <
> >> >> > larry.mccay@gmail.com
> >> >> > > >:
> >> >> > > > > > > > >
> >> >> > > > > > > > > > That ability to configure multiple mechanisms
> based on
> >> >> > > > clientName
> >> >> > > > > > is
> >> >> > > > > > > > > really
> >> >> > > > > > > > > > interesting for Knox.
> >> >> > > > > > > > > > Currently, we require separate topologies per
> >> >> > authentication
> >> >> > > > > > > mechanism.
> >> >> > > > > > > > > > The ability to configure them all in one is really
> >> great.
> >> >> > > > > > > > > >
> >> >> > > > > > > > > > We would need to think through the best way to
> provide
> >> >> the
> >> >> > > > > > clientName
> >> >> > > > > > > > > > parameter.
> >> >> > > > > > > > > > Since this is targeting KnoxSSO it can actually be
> >> added
> >> >> to
> >> >> > > the
> >> >> > > > > > > > > providerURL
> >> >> > > > > > > > > > used to redirect from the participating
> application.
> >> >> > > > > > > > > > Regardless of the authentication mechanism used
> each
> >> >> > > > application
> >> >> > > > > > will
> >> >> > > > > > > > > still
> >> >> > > > > > > > > > get the same JWT based cookie.
> >> >> > > > > > > > > >
> >> >> > > > > > > > > > I think that should work really nicely.
> >> >> > > > > > > > > >
> >> >> > > > > > > > > >
> >> >> > > > > > > > > > On Fri, Dec 4, 2015 at 7:17 AM, larry mccay <
> >> >> > > > > larry.mccay@gmail.com
> >> >> > > > > > >
> >> >> > > > > > > > > wrote:
> >> >> > > > > > > > > >
> >> >> > > > > > > > > > > Excellent, Jérôme.
> >> >> > > > > > > > > > > Thanks!
> >> >> > > > > > > > > > >
> >> >> > > > > > > > > > > On Fri, Dec 4, 2015 at 2:40 AM, Jérôme LELEU <
> >> >> > > > leleuj@gmail.com
> >> >> > > > > >
> >> >> > > > > > > > wrote:
> >> >> > > > > > > > > > >
> >> >> > > > > > > > > > >> Hi,
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > > >> I will write how to configure the pac4j
> provider in
> >> >> the
> >> >> > > > > > > > documentation,
> >> >> > > > > > > > > > but
> >> >> > > > > > > > > > >> I can already give you some insights.
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > > >> My main goal is always to respect the key design
> >> >> > > principles
> >> >> > > > of
> >> >> > > > > > > pac4j
> >> >> > > > > > > > > > >> whatever the environment / framework in which
> it is
> >> >> > > > > implemented.
> >> >> > > > > > > For
> >> >> > > > > > > > > > Knox,
> >> >> > > > > > > > > > >> I'm pretty happy with the use of the j2e-pac4j
> >> >> library,
> >> >> > > > which
> >> >> > > > > > > means
> >> >> > > > > > > > > that
> >> >> > > > > > > > > > >> almost all the pac4j features are available,
> >> >> especially
> >> >> > > both
> >> >> > > > > > > direct
> >> >> > > > > > > > > and
> >> >> > > > > > > > > > >> indirect clients. So it can do what Shiro
> already
> >> does
> >> >> > but
> >> >> > > > > also,
> >> >> > > > > > > as
> >> >> > > > > > > > we
> >> >> > > > > > > > > > >> agreed together, supports remote
> authentications.
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > > >> It is only limited by what you can currently
> >> >> configure.
> >> >> > > And
> >> >> > > > > even
> >> >> > > > > > > > > > >> configuration is a pac4j feature as the CAS
> server
> >> has
> >> >> > the
> >> >> > > > > same
> >> >> > > > > > > > need.
> >> >> > > > > > > > > > >> Everything happens in this class:
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > >
> >> >> > > > > > > > >
> >> >> > > > > > > >
> >> >> > > > > > >
> >> >> > > > > >
> >> >> > > > >
> >> >> > > >
> >> >> > >
> >> >> >
> >> >>
> >>
> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java
> >> >> > > > > > > > > > >> ,
> >> >> > > > > > > > > > >> which allows you to configure Facebook,
> Twitter, a
> >> CAS
> >> >> > > > > server, a
> >> >> > > > > > > > SAML
> >> >> > > > > > > > > > IdP
> >> >> > > > > > > > > > >> or an OpenID Connect provider. All the provided
> >> >> > parameters
> >> >> > > > to
> >> >> > > > > > the
> >> >> > > > > > > > > pac4j
> >> >> > > > > > > > > > >> provider are put into a Map and the
> >> >> > > ConfigPropertiesFactory
> >> >> > > > is
> >> >> > > > > > > built
> >> >> > > > > > > > > > with
> >> >> > > > > > > > > > >> this Map to return the built client (=
> >> authentication
> >> >> > > > > > mechanism).
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > > >> You have one more specific option for Knox as a
> >> basic
> >> >> > > > > > > authentication
> >> >> > > > > > > > > > popup
> >> >> > > > > > > > > > >> where the username must match the password, you
> can
> >> >> > define
> >> >> > > > > that
> >> >> > > > > > > by:
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > > >> <param>
> >> >> > > > > > > > > > >> <name>clientName</name>
> >> >> > > > > > > > > > >> <value>testBasicAuth</value>
> >> >> > > > > > > > > > >> </param>
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > > >> It's for testing only.
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > > >> For a CAS server:
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > > >> <param>
> >> >> > > > > > > > > > >> <name>cas.loginUrl</name>
> >> >> > > > > > > > > > >> <value>
> >> https://casserverpac4j.herokuapp.com/login
> >> >> > > </value>
> >> >> > > > > > > > > > >> </param>
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > > >> Here are all the properties available for
> building
> >> >> > clients
> >> >> > > > > > (their
> >> >> > > > > > > > > > meaning
> >> >> > > > > > > > > > >> is obvious):
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > > >> facebook.id
> >> >> > > > > > > > > > >> facebook.secret
> >> >> > > > > > > > > > >> facebook.scope
> >> >> > > > > > > > > > >> facebook.fields
> >> >> > > > > > > > > > >> twitter.id
> >> >> > > > > > > > > > >> twitter.secret
> >> >> > > > > > > > > > >> saml.keystorePassword
> >> >> > > > > > > > > > >> saml.privateKeyPassword
> >> >> > > > > > > > > > >> saml.keystorePath
> >> >> > > > > > > > > > >> saml.identityProviderMetadataPath
> >> >> > > > > > > > > > >> saml.maximumAuthenticationLifetime
> >> >> > > > > > > > > > >> saml.serviceProviderEntityId
> >> >> > > > > > > > > > >> saml.serviceProviderMetadataPath
> >> >> > > > > > > > > > >> cas.loginUrl
> >> >> > > > > > > > > > >> cas.protocol
> >> >> > > > > > > > > > >> oidc.id
> >> >> > > > > > > > > > >> oidc.secret
> >> >> > > > > > > > > > >> oidc.discoveryUri
> >> >> > > > > > > > > > >> oidc.customParamKey1
> >> >> > > > > > > > > > >> oidc.customParamValue1
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > > >> If you define multiple clients, the first one
> will
> >> be
> >> >> > used
> >> >> > > > for
> >> >> > > > > > > > > > >> authentication, but you can explicitly choose
> the
> >> >> client
> >> >> > > you
> >> >> > > > > > want
> >> >> > > > > > > to
> >> >> > > > > > > > > use
> >> >> > > > > > > > > > >> via the clientName parameter, assuming you want
> to
> >> >> > switch
> >> >> > > > from
> >> >> > > > > > > > client
> >> >> > > > > > > > > > >> depending on environment for example.
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > > >> So if you want to add some new authentication
> >> >> mechanism,
> >> >> > > you
> >> >> > > > > > must
> >> >> > > > > > > > > first
> >> >> > > > > > > > > > >> check that it is available in pac4j (if it's
> not,
> >> it's
> >> >> > > > another
> >> >> > > > > > > > > > discussion,
> >> >> > > > > > > > > > >> but generally, it is). Then, you'll need to
> upgrade
> >> >> the
> >> >> > > > > > > > > > >> ConfigPropertiesFactory by submitting a new pull
> >> >> request
> >> >> > > to
> >> >> > > > > the
> >> >> > > > > > > > pac4j
> >> >> > > > > > > > > > >> project (I can do it myself, but I'm sure you
> >> could do
> >> >> > > that
> >> >> > > > > > > easily),
> >> >> > > > > > > > > > >> finally wait for the new pac4j release and
> switch
> >> >> pac4j
> >> >> > > > > versions
> >> >> > > > > > > in
> >> >> > > > > > > > > Knox
> >> >> > > > > > > > > > >> to
> >> >> > > > > > > > > > >> benefit from the new feature.
> >> >> > > > > > > > > > >> The good thing is that if someone related to the
> >> CAS
> >> >> > > server
> >> >> > > > > does
> >> >> > > > > > > the
> >> >> > > > > > > > > > same
> >> >> > > > > > > > > > >> thing for CAS (in pac4j), you will automatically
> >> get
> >> >> it
> >> >> > > when
> >> >> > > > > > > you'll
> >> >> > > > > > > > > > >> upgrade
> >> >> > > > > > > > > > >> pac4j.
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > > >> To go even further, replacing LDAP Shiro
> >> >> authentication
> >> >> > is
> >> >> > > > > just
> >> >> > > > > > a
> >> >> > > > > > > > > matter
> >> >> > > > > > > > > > >> of
> >> >> > > > > > > > > > >> making pac4j LDAP authentication available via
> >> >> > > configuration
> >> >> > > > > > > > > parameters.
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > > >> I hope it was clear enough.
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > > >> Thanks.
> >> >> > > > > > > > > > >> Best regards,
> >> >> > > > > > > > > > >> Jérôme
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > > >> 2015-12-03 20:45 GMT+01:00 larry mccay <
> >> >> > > > larry.mccay@gmail.com
> >> >> > > > > >:
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > > >> > Excellent!
> >> >> > > > > > > > > > >> >
> >> >> > > > > > > > > > >> > I will carve out some time to do code review.
> >> >> > > > > > > > > > >> > We will need to get some insights into how to
> go
> >> >> about
> >> >> > > > > > testing:
> >> >> > > > > > > > > > >> >
> >> >> > > > > > > > > > >> > * is the CAS server going to be available for
> >> >> testing?
> >> >> > > > > > > > > > >> > * what are the specific and generic/standard
> (if
> >> >> any)
> >> >> > > > > > > > authentication
> >> >> > > > > > > > > > >> > mechanisms available - for instance:
> >> >> > > > > > > > > > >> > - Facebook, Google, LinkedIn and CAS are
> >> >> specifics
> >> >> > > > > > > > > > >> > - OAuth 2, OpenID Connect, SAML are
> >> >> > > generic/standards
> >> >> > > > -
> >> >> > > > > > that
> >> >> > > > > > > > may
> >> >> > > > > > > > > > be
> >> >> > > > > > > > > > >> > used for the above specifics...
> >> >> > > > > > > > > > >> > * how do we test things other than CAS - in
> >> terms of
> >> >> > > > getting
> >> >> > > > > > > > > > >> credentials,
> >> >> > > > > > > > > > >> > configuration, etc
> >> >> > > > > > > > > > >> >
> >> >> > > > > > > > > > >> > We could certainly do this is phases as well.
> >> >> > > > > > > > > > >> >
> >> >> > > > > > > > > > >> > If you can enumerate the things that should
> work
> >> and
> >> >> > > > provide
> >> >> > > > > > > some
> >> >> > > > > > > > > > >> testing
> >> >> > > > > > > > > > >> > details for CAS or as many as possible and
> OpenID
> >> >> > > Connect
> >> >> > > > > then
> >> >> > > > > > > we
> >> >> > > > > > > > > can
> >> >> > > > > > > > > > >> test
> >> >> > > > > > > > > > >> > the specific implementations that you provide
> and
> >> >> > enable
> >> >> > > > the
> >> >> > > > > > > > testing
> >> >> > > > > > > > > > of
> >> >> > > > > > > > > > >> > another OpenID Connect effort that is in the
> >> works
> >> >> in
> >> >> > > the
> >> >> > > > > > > > community.
> >> >> > > > > > > > > > >> >
> >> >> > > > > > > > > > >> > I'm not sure whether we want to commit
> >> contributions
> >> >> > > that
> >> >> > > > > are
> >> >> > > > > > > > > > dependent
> >> >> > > > > > > > > > >> on
> >> >> > > > > > > > > > >> > snapshots - we certainly can't release with
> any
> >> such
> >> >> > > > > > > dependencies.
> >> >> > > > > > > > > > >> > I would hate to add a cleanup task to a
> release
> >> to
> >> >> > make
> >> >> > > > sure
> >> >> > > > > > > there
> >> >> > > > > > > > > are
> >> >> > > > > > > > > > >> no
> >> >> > > > > > > > > > >> > snapshots in there.
> >> >> > > > > > > > > > >> > We will probably wait until after the pac4j
> >> releases
> >> >> > to
> >> >> > > > > > commit.
> >> >> > > > > > > > > > >> >
> >> >> > > > > > > > > > >> > I am really happy that this integration is
> >> happening
> >> >> > and
> >> >> > > > > that
> >> >> > > > > > it
> >> >> > > > > > > > > went
> >> >> > > > > > > > > > >> > rather smoothly.
> >> >> > > > > > > > > > >> > These sorts of authentication protocols are
> >> complex
> >> >> > and
> >> >> > > I
> >> >> > > > > > think
> >> >> > > > > > > we
> >> >> > > > > > > > > > >> lined up
> >> >> > > > > > > > > > >> > pretty well overall.
> >> >> > > > > > > > > > >> >
> >> >> > > > > > > > > > >> > Thanks for your work!
> >> >> > > > > > > > > > >> >
> >> >> > > > > > > > > > >> > On Thu, Dec 3, 2015 at 2:28 PM, Jérôme LELEU <
> >> >> > > > > > leleuj@gmail.com>
> >> >> > > > > > > > > > wrote:
> >> >> > > > > > > > > > >> >
> >> >> > > > > > > > > > >> > > Hi,
> >> >> > > > > > > > > > >> > >
> >> >> > > > > > > > > > >> > > I just sync'ed with master, cleaned
> >> dependencies
> >> >> and
> >> >> > > > added
> >> >> > > > > > > > missing
> >> >> > > > > > > > > > >> > > Javadocs. Everything works correctly now.
> Many
> >> >> > thanks.
> >> >> > > > > > > > > > >> > >
> >> >> > > > > > > > > > >> > > The pull request is ready for a full code
> >> review:
> >> >> > > > > > > > > > >> > > https://github.com/apache/knox/pull/2
> >> >> > > > > > > > > > >> > >
> >> >> > > > > > > > > > >> > > I'll write the documentation after the pac4j
> >> >> > releases
> >> >> > > (I
> >> >> > > > > > hope
> >> >> > > > > > > > next
> >> >> > > > > > > > > > >> week).
> >> >> > > > > > > > > > >> > >
> >> >> > > > > > > > > > >> > > Thanks.
> >> >> > > > > > > > > > >> > > Best regards,
> >> >> > > > > > > > > > >> > > Jérôme
> >> >> > > > > > > > > > >> > >
> >> >> > > > > > > > > > >> > >
> >> >> > > > > > > > > > >> > > 2015-12-02 19:18 GMT+01:00 larry mccay <
> >> >> > > > > > larry.mccay@gmail.com
> >> >> > > > > > > >:
> >> >> > > > > > > > > > >> > >
> >> >> > > > > > > > > > >> > > > Fixed in
> >> >> > > > https://issues.apache.org/jira/browse/KNOX-636
> >> >> > > > > .
> >> >> > > > > > > > > > >> > > >
> >> >> > > > > > > > > > >> > > > On Wed, Dec 2, 2015 at 12:42 PM, larry
> mccay
> >> <
> >> >> > > > > > > > > > larry.mccay@gmail.com
> >> >> > > > > > > > > > >> >
> >> >> > > > > > > > > > >> > > > wrote:
> >> >> > > > > > > > > > >> > > >
> >> >> > > > > > > > > > >> > > > > Sure - I can file a JIRA and commit a
> fix.
> >> >> > > > > > > > > > >> > > > >
> >> >> > > > > > > > > > >> > > > > The secret generation should be done in
> one
> >> >> > > instance
> >> >> > > > > and
> >> >> > > > > > > > > > >> replicated
> >> >> > > > > > > > > > >> > > > across
> >> >> > > > > > > > > > >> > > > > others.
> >> >> > > > > > > > > > >> > > > > This replication/management of the
> >> credential
> >> >> > > stores
> >> >> > > > > is
> >> >> > > > > > > > > outside
> >> >> > > > > > > > > > of
> >> >> > > > > > > > > > >> > the
> >> >> > > > > > > > > > >> > > > > scope of Knox itself as of now.
> >> >> > > > > > > > > > >> > > > >
> >> >> > > > > > > > > > >> > > > > Documentation is done in markdown and is
> >> >> > > > contributing
> >> >> > > > > > > > details
> >> >> > > > > > > > > > are
> >> >> > > > > > > > > > >> > > > > available at:
> >> >> > > > > > > > > > >> > > > >
> >> >> > > > > > > > > > >> > > >
> >> >> > > > > > > > > > >> > >
> >> >> > > > > > > > > > >> >
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > >
> >> >> > > > > > > > >
> >> >> > > > > > > >
> >> >> > > > > > >
> >> >> > > > > >
> >> >> > > > >
> >> >> > > >
> >> >> > >
> >> >> >
> >> >>
> >>
> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
> >> >> > > > > > > > > > >> > > > >
> >> >> > > > > > > > > > >> > > > > Which should give you a general idea.
> >> >> > > > > > > > > > >> > > > >
> >> >> > > > > > > > > > >> > > > > Find an example like:
> ./trunk/books/0.7.0/
> >> >> > > > > > > > > > >> > > config_preauth_sso_provider.md
> >> >> > > > > > > > > > >> > > > >
> >> >> > > > > > > > > > >> > > > > For an example of typical content and
> >> format.
> >> >> > > > > > > > > > >> > > > >
> >> >> > > > > > > > > > >> > > > > Here is how that example renders:
> >> >> > > > > > > > > > >> > > > >
> >> >> > > > > > > > > > >> > > >
> >> >> > > > > > > > > > >> > >
> >> >> > > > > > > > > > >> >
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > >
> >> >> > > > > > > > >
> >> >> > > > > > > >
> >> >> > > > > > >
> >> >> > > > > >
> >> >> > > > >
> >> >> > > >
> >> >> > >
> >> >> >
> >> >>
> >>
> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
> >> >> > > > > > > > > > >> > > > >
> >> >> > > > > > > > > > >> > > > > You'll need to tie it into the rest of
> the
> >> >> book
> >> >> > -
> >> >> > > > just
> >> >> > > > > > > grep
> >> >> > > > > > > > > for
> >> >> > > > > > > > > > >> where
> >> >> > > > > > > > > > >> > > > that
> >> >> > > > > > > > > > >> > > > > filename is referenced.
> >> >> > > > > > > > > > >> > > > > To test how it renders build the site
> with:
> >> >> > "ant"
> >> >> > > > and
> >> >> > > > > > note
> >> >> > > > > > > > the
> >> >> > > > > > > > > > >> url to
> >> >> > > > > > > > > > >> > > the
> >> >> > > > > > > > > > >> > > > > 0.7.0 book.
> >> >> > > > > > > > > > >> > > > >
> >> >> > > > > > > > > > >> > > > >
> >> >> > > > > > > > > > >> > > > > On Wed, Dec 2, 2015 at 12:12 PM, Jérôme
> >> LELEU
> >> >> <
> >> >> > > > > > > > > leleuj@gmail.com
> >> >> > > > > > > > > > >
> >> >> > > > > > > > > > >> > > wrote:
> >> >> > > > > > > > > > >> > > > >
> >> >> > > > > > > > > > >> > > > >> Hi,
> >> >> > > > > > > > > > >> > > > >>
> >> >> > > > > > > > > > >> > > > >> Why it doesn't work for pac4j while it
> >> works
> >> >> > for
> >> >> > > > > others
> >> >> > > > > > > is
> >> >> > > > > > > > a
> >> >> > > > > > > > > > bit
> >> >> > > > > > > > > > >> > > strange
> >> >> > > > > > > > > > >> > > > >> to
> >> >> > > > > > > > > > >> > > > >> me, but if you have the patch in front
> of
> >> >> your
> >> >> > > > eyes,
> >> >> > > > > > I'd
> >> >> > > > > > > > > rather
> >> >> > > > > > > > > > >> > prefer
> >> >> > > > > > > > > > >> > > > you
> >> >> > > > > > > > > > >> > > > >> to commit it. In all cases, I'll sync
> with
> >> >> the
> >> >> > > > > master.
> >> >> > > > > > > > > > >> > > > >>
> >> >> > > > > > > > > > >> > > > >> There was one question you didn't
> answer
> >> >> > > > previously:
> >> >> > > > > is
> >> >> > > > > > > the
> >> >> > > > > > > > > > >> password
> >> >> > > > > > > > > > >> > > > >> generated for the pac4j provider the
> same
> >> >> > across
> >> >> > > > all
> >> >> > > > > > > > gateway
> >> >> > > > > > > > > > >> > > instances?
> >> >> > > > > > > > > > >> > > > >> Because I expect to have the same value
> >> as I
> >> >> > use
> >> >> > > it
> >> >> > > > > to
> >> >> > > > > > > > > encrypt
> >> >> > > > > > > > > > /
> >> >> > > > > > > > > > >> > > decrypt
> >> >> > > > > > > > > > >> > > > >> data.
> >> >> > > > > > > > > > >> > > > >>
> >> >> > > > > > > > > > >> > > > >> I will add the Javadoc. After that, you
> >> can
> >> >> > > review
> >> >> > > > > the
> >> >> > > > > > > pull
> >> >> > > > > > > > > > >> request
> >> >> > > > > > > > > > >> > > more
> >> >> > > > > > > > > > >> > > > >> completely.
> >> >> > > > > > > > > > >> > > > >>
> >> >> > > > > > > > > > >> > > > >> What do you expect for the
> documentation?
> >> >> > > > > > > > > > >> > > > >>
> >> >> > > > > > > > > > >> > > > >> Notice that pac4j dependencies are
> still
> >> >> > > snapshots,
> >> >> > > > > but
> >> >> > > > > > > > they
> >> >> > > > > > > > > > >> will be
> >> >> > > > > > > > > > >> > > > >> released in a week or two.
> >> >> > > > > > > > > > >> > > > >>
> >> >> > > > > > > > > > >> > > > >> Thanks.
> >> >> > > > > > > > > > >> > > > >> Best regards,
> >> >> > > > > > > > > > >> > > > >> Jérôme
> >> >> > > > > > > > > > >> > > > >>
> >> >> > > > > > > > > > >> > > > >>
> >> >> > > > > > > > > > >> > > > >> 2015-12-02 17:51 GMT+01:00 larry mccay
> <
> >> >> > > > > > > > > larry.mccay@gmail.com
> >> >> > > > > > > > > > >:
> >> >> > > > > > > > > > >> > > > >>
> >> >> > > > > > > > > > >> > > > >> > Jérôme -
> >> >> > > > > > > > > > >> > > > >> >
> >> >> > > > > > > > > > >> > > > >> > If you would like to add that change
> as
> >> >> part
> >> >> > of
> >> >> > > > > your
> >> >> > > > > > > > patch
> >> >> > > > > > > > > or
> >> >> > > > > > > > > > >> as a
> >> >> > > > > > > > > > >> > > > >> > separately filed JIRA to fix a bug
> that
> >> >> would
> >> >> > > > > > certainly
> >> >> > > > > > > > be
> >> >> > > > > > > > > > >> > welcomed.
> >> >> > > > > > > > > > >> > > > >> > Otherwise, I can do it.
> >> >> > > > > > > > > > >> > > > >> >
> >> >> > > > > > > > > > >> > > > >> > Let me know.
> >> >> > > > > > > > > > >> > > > >> >
> >> >> > > > > > > > > > >> > > > >> > thanks,
> >> >> > > > > > > > > > >> > > > >> >
> >> >> > > > > > > > > > >> > > > >> > --larry
> >> >> > > > > > > > > > >> > > > >> >
> >> >> > > > > > > > > > >> > > > >> > On Wed, Dec 2, 2015 at 11:44 AM,
> larry
> >> >> mccay
> >> >> > <
> >> >> > > > > > > > > > >> > larry.mccay@gmail.com
> >> >> > > > > > > > > > >> > > >
> >> >> > > > > > > > > > >> > > > >> > wrote:
> >> >> > > > > > > > > > >> > > > >> >
> >> >> > > > > > > > > > >> > > > >> > > Okay - I had to add an override of
> >> >> > > > > > getUserPrincipal()
> >> >> > > > > > > > to
> >> >> > > > > > > > > > the
> >> >> > > > > > > > > > >> > > > >> > >
> >> IdentityAsserterHttpServletRequestWrapper
> >> >> > and
> >> >> > > > > > return
> >> >> > > > > > > > the
> >> >> > > > > > > > > > >> member
> >> >> > > > > > > > > > >> > > > >> variable
> >> >> > > > > > > > > > >> > > > >> > > username and it works like a charm.
> >> >> > > > > > > > > > >> > > > >> > >
> >> >> > > > > > > > > > >> > > > >> > > Why I haven't seen this same
> behavior
> >> >> with
> >> >> > > > other
> >> >> > > > > > > > > providers
> >> >> > > > > > > > > > >> is a
> >> >> > > > > > > > > > >> > > bit
> >> >> > > > > > > > > > >> > > > >> of a
> >> >> > > > > > > > > > >> > > > >> > > mystery but they must be adding
> other
> >> >> > > wrappers
> >> >> > > > > that
> >> >> > > > > > > > > handle
> >> >> > > > > > > > > > >> it.
> >> >> > > > > > > > > > >> > > > >> > > This is quite cool, Jérôme!
> >> >> > > > > > > > > > >> > > > >> > >
> >> >> > > > > > > > > > >> > > > >> > > On Wed, Dec 2, 2015 at 10:41 AM,
> larry
> >> >> > mccay
> >> >> > > <
> >> >> > > > > > > > > > >> > > larry.mccay@gmail.com
> >> >> > > > > > > > > > >> > > > >
> >> >> > > > > > > > > > >> > > > >> > > wrote:
> >> >> > > > > > > > > > >> > > > >> > >
> >> >> > > > > > > > > > >> > > > >> > >> That was it - thanks!
> >> >> > > > > > > > > > >> > > > >> > >>
> >> >> > > > > > > > > > >> > > > >> > >> On Wed, Dec 2, 2015 at 10:20 AM,
> >> Jérôme
> >> >> > > LELEU
> >> >> > > > <
> >> >> > > > > > > > > > >> > leleuj@gmail.com>
> >> >> > > > > > > > > > >> > > > >> wrote:
> >> >> > > > > > > > > > >> > > > >> > >>
> >> >> > > > > > > > > > >> > > > >> > >>> This is my exact command line:
> mvn
> >> >> > > -Prelease
> >> >> > > > > > clean
> >> >> > > > > > > > > > install
> >> >> > > > > > > > > > >> > > > >> -DskipTests
> >> >> > > > > > > > > > >> > > > >> > >>>
> >> >> > > > > > > > > > >> > > > >> > >>> You use an internal Maven
> >> repository to
> >> >> > > fetch
> >> >> > > > > > > > > > dependencies
> >> >> > > > > > > > > > >> > from
> >> >> > > > > > > > > > >> > > > >> > internet:
> >> >> > > > > > > > > > >> > > > >> > >>>
> >> >> > > > > > > > > > >> > >
> >> >> > > > > > > >
> >> >> > >
> http://nexus-private.hortonworks.com/nexus/content/groups/public/
> >> >> > > > > > > > > > >> > > > >> > >>>
> >> >> > > > > > > > > > >> > > > >> > >>> Does this repository have access
> to
> >> the
> >> >> > > > remote
> >> >> > > > > > > > > Snapshots
> >> >> > > > > > > > > > >> > > Sonatype
> >> >> > > > > > > > > > >> > > > >> repo?
> >> >> > > > > > > > > > >> > > > >> > >>>
> >> >> > > > > > > > > > >> > > > >> > >>>
> >> >> > > > > > > > > > >> > > > >> > >>>
> >> >> > > > > > > > > > >> > > > >> > >>> 2015-12-02 16:16 GMT+01:00 larry
> >> mccay
> >> >> <
> >> >> > > > > > > > > > >> larry.mccay@gmail.com
> >> >> > > > > > > > > > >> > >:
> >> >> > > > > > > > > > >> > > > >> > >>>
> >> >> > > > > > > > > > >> > > > >> > >>> > hmmm - I used:
> >> >> > > > > > > > > > >> > > > >> > >>> >
> >> >> > > > > > > > > > >> > > > >> > >>> > mvn clean install
> -DskipTests=true
> >> >> > > > -Prelease
> >> >> > > > > > > > > > >> > > > >> > >>> >
> >> >> > > > > > > > > > >> > > > >> > >>> > The repository entry is in
> there
> >> >> > already.
> >> >> > > > > > > > > > >> > > > >> > >>> > No worky.
> >> >> > > > > > > > > > >> > > > >> > >>> >
> >> >> > > > > > > > > > >> > > > >> > >>> > On Wed, Dec 2, 2015 at 10:12
> AM,
> >> >> Jérôme
> >> >> > > > > LELEU <
> >> >> > > > > > > > > > >> > > leleuj@gmail.com
> >> >> > > > > > > > > > >> > > > >
> >> >> > > > > > > > > > >> > > > >> > >>> wrote:
> >> >> > > > > > > > > > >> > > > >> > >>> >
> >> >> > > > > > > > > > >> > > > >> > >>> > > Hi,
> >> >> > > > > > > > > > >> > > > >> > >>> > >
> >> >> > > > > > > > > > >> > > > >> > >>> > > You need the j2e-pac4j
> >> dependencies
> >> >> > as
> >> >> > > > well
> >> >> > > > > > as
> >> >> > > > > > > > the
> >> >> > > > > > > > > > >> pac4j-*
> >> >> > > > > > > > > > >> > > > >> > >>> dependencies,
> >> >> > > > > > > > > > >> > > > >> > >>> > > but you don't need to build
> them
> >> >> > > locally
> >> >> > > > > > > > > (hopefully).
> >> >> > > > > > > > > > >> > > > >> > >>> > >
> >> >> > > > > > > > > > >> > > > >> > >>> > > But you need a dependency on
> the
> >> >> > > Sonatype
> >> >> > > > > > > > snapshots
> >> >> > > > > > > > > > >> > > repository
> >> >> > > > > > > > > > >> > > > >> > >>> (where the
> >> >> > > > > > > > > > >> > > > >> > >>> > > snapshot versions are
> hosted),
> >> >> which
> >> >> > is
> >> >> > > > > added
> >> >> > > > > > > for
> >> >> > > > > > > > > > >> Maven in
> >> >> > > > > > > > > > >> > > the
> >> >> > > > > > > > > > >> > > > >> root
> >> >> > > > > > > > > > >> > > > >> > >>> > > pom.xml:
> >> >> > > > > > > > > > >> > > > >> > >>> > >
> >> >> > > > > > > > > > >> > > > >> > >>> > >
> >> >> > > > > > > > > > >> > > > >> > >>> >
> >> >> > > > > > > > > > >> > > > >> > >>>
> >> >> > > > > > > > > > >> > > > >> >
> >> >> > > > > > > > > > >> > > > >>
> >> >> > > > > > > > > > >> > > >
> >> >> > > > > > > > > > >> > >
> >> >> > > > > > > > > > >> >
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > >
> >> >> > > > > > > > >
> >> >> > > > > > > >
> >> >> > > > > > >
> >> >> > > > > >
> >> >> > > > >
> >> >> > > >
> >> >> > >
> >> >> >
> >> >>
> >>
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> >> >> > > > > > > > > > >> > > > >> > >>> > >
> >> >> > > > > > > > > > >> > > > >> > >>> > > If you use Ant for the build,
> >> there
> >> >> > is
> >> >> > > > > maybe
> >> >> > > > > > a
> >> >> > > > > > > > > glitch
> >> >> > > > > > > > > > >> to
> >> >> > > > > > > > > > >> > > find
> >> >> > > > > > > > > > >> > > > >> the
> >> >> > > > > > > > > > >> > > > >> > >>> > Sonatype
> >> >> > > > > > > > > > >> > > > >> > >>> > > Maven repo.
> >> >> > > > > > > > > > >> > > > >> > >>> > >
> >> >> > > > > > > > > > >> > > > >> > >>> > > Thanks.
> >> >> > > > > > > > > > >> > > > >> > >>> > > Best regards,
> >> >> > > > > > > > > > >> > > > >> > >>> > > Jérôme
> >> >> > > > > > > > > > >> > > > >> > >>> > >
> >> >> > > > > > > > > > >> > > > >> > >>> > >
> >> >> > > > > > > > > > >> > > > >> > >>> > > 2015-12-02 16:06 GMT+01:00
> larry
> >> >> > mccay
> >> >> > > <
> >> >> > > > > > > > > > >> > > larry.mccay@gmail.com
> >> >> > > > > > > > > > >> > > > >:
> >> >> > > > > > > > > > >> > > > >> > >>> > >
> >> >> > > > > > > > > > >> > > > >> > >>> > > > 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.mccay@gmail.com>
> >> >> > > > > > > > > > >> > > > >> > >>> > > > wrote:
> >> >> > > > > > > > > > >> > > > >> > >>> > > >
> >> >> > > > > > > > > > >> > > > >> > >>> > > > >
> >> gateway-provider-security-pac4j
> >> >> > > > doesn't
> >> >> > > > > > > > build -
> >> >> > > > > > > > > > do
> >> >> > > > > > > > > > >> you
> >> >> > > > > > > > > > >> > > > have
> >> >> > > > > > > > > > >> > > > >> a
> >> >> > > > > > > > > > >> > > > >> > >>> pending
> >> >> > > > > > > > > > >> > > > >> > >>> > > > > change for your pom.xml
> or
> >> >> > > something?
> >> >> > > > > > > > > > >> > > > >> > >>> > > > >
> >> >> > > > > > > > > > >> > > > >> > >>> >
> >> >> > > > > > > > > > >> > > > >> > >>>
> >> >> > > > > > > > > > >> > > > >> > >>
> >> >> > > > > > > > > > >> > > > >> > >>
> >> >> > > > > > > > > > >> > > > >> > >
> >> >> > > > > > > > > > >> > > > >> >
> >> >> > > > > > > > > > >> > > > >>
> >> >> > > > > > > > > > >> > > > >
> >> >> > > > > > > > > > >> > > > >
> >> >> > > > > > > > > > >> > > >
> >> >> > > > > > > > > > >> > >
> >> >> > > > > > > > > > >> >
> >> >> > > > > > > > > > >>
> >> >> > > > > > > > > > >
> >> >> > > > > > > > > > >
> >> >> > > > > > > > > >
> >> >> > > > > > > > >
> >> >> > > > > > > >
> >> >> > > > > > >
> >> >> > > > > >
> >> >> > > > >
> >> >> > > >
> >> >> > >
> >> >> >
> >> >>
> >>
>
Re: pac4j and Apache Knox
Posted by Kevin Minder <ke...@hortonworks.com>.
I can certainly appreciate the issue of including external resources in automated tests. Nothing has driven me more crazy over the years. The flip side of this of course is not finding out about a breakage until someone is willing to go through the manual testing which will typically happen just before a release. Also the implication is that these testing procedures must be very will documented so that they can be continue to be run once any of us are no longer active in the project.
On 1/6/16, 2:12 AM, "Jérôme LELEU" <le...@gmail.com> wrote:
>Hi,
>
>Yes, you can hit the CAS server at Heroku. Notice it's a Heroku free server
>so it needs to be re-activated first (it takes a couple of seconds). So for
>a UI test, you should first hit it, wait 30 seconds and then perform the
>test.
>
>Just my 2 cents:
>Using automated UI tests was my first strategy for pac4j but I finally
>gave up because public providers change very often, at least enough to make
>the maintenance tests a nightmare. Currently, I'm using manual tests (the
>same for all demos), it takes me around 5 minutes to play them all by hand
>(for a demo) and I launched manually the UI tests I have for every major
>pac4j release. Just to say UI tests are not that easy. For a CAS server,
>it's fairly feasible as the CAS server and protocol change rarely.
>That's why for Knox, I did some compromise with a simulated web test (based
>on the basic auth). See:
>https://github.com/apache/knox/pull/2/files#diff-d0c880ca71b310dbe57975c577535e97R47
>
>Thanks.
>Best regards,
>Jérôme
>
>
>
>2016-01-05 21:20 GMT+01:00 Kevin Minder <ke...@hortonworks.com>:
>
>> From my perspective it would be ideal if there were some automatable
>> functional tests for this. I’m not advocating that these be something
>> included in “mvn clean install” as that is running too long as it is.
>> Given that I don’t have as much context as Larry, I have some questions
>> about what this would take. Lets say we had permission to hit
>> https://casserverpac4j.herokuapp.com/login as part of some low frequency
>> automated tests (e.g. Once nighty). What static credentials and other test
>> automation infrastructure would need to be implemented in support of this?
>> I understand that the test suite would require at a minimum
>> 1) a test driver
>> 2) a protected mock UI and
>> 3) an appropriately configured Knox
>> 4) a profile enabled maven module
>> 5) an Apache jenkins job
>> but I’m sure I’m missing other things. I’m certainly willing to help
>> setup the skeleton infrastructure (e.g. test driver, mock UI, maven module,
>> jenkins job)
>>
>>
>>
>> On 1/5/16, 2:54 PM, "larry mccay" <la...@gmail.com> wrote:
>>
>> >Okay, very good.
>> >I've used TestShib for the picketlink provider - thanks for the pointers!
>> >
>> >On Tue, Jan 5, 2016 at 1:38 PM, Jérôme LELEU <le...@gmail.com> wrote:
>> >
>> >> The online CAS server (https://casserverpac4j.herokuapp.com/login) uses
>> >> the
>> >> CAS protocol. SAML support can be tested using some online IdP like
>> Okta,
>> >> TestShib, OpenFeide, Ssocircle...
>> >>
>> >>
>> >> 2016-01-05 17:32 GMT+01:00 larry mccay <la...@gmail.com>:
>> >>
>> >> > Great - thanks for that pointer!
>> >> >
>> >> > I will take a look at that and help drive the release related testing.
>> >> > Merge testing will be gated on CAS server (is this SAML or CAS
>> protocol?)
>> >> > and testBasicAuth.
>> >> >
>> >> > On Tue, Jan 5, 2016 at 10:52 AM, Jérôme LELEU <le...@gmail.com>
>> wrote:
>> >> >
>> >> > > Hi,
>> >> > >
>> >> > > Glad to hear back from you!
>> >> > >
>> >> > > The core pac4j project is fully tested by unit tests (and some
>> >> > integration
>> >> > > tests I run for major version), then all pac4j implementations are
>> each
>> >> > > tested by the appropriate demo: j2e-pac4j-demo tests j2e-pac4j,
>> >> > > spring-webmvc-pac4j-demo tests spring-webmvc-pac4j, etc.
>> >> > >
>> >> > > So if you take a look at:
>> >> > >
>> >> > >
>> >> >
>> >>
>> https://github.com/pac4j/j2e-pac4j-demo/blob/master/src/main/java/org/pac4j/demo/j2e/config/DemoConfigFactory.java#L27
>> >> > > (for example), you have all the required information to test.
>> >> > >
>> >> > > I can do that on my own, but it can be good for the Knox community
>> to
>> >> > start
>> >> > > working / testing the pac4j support. It's up to yoy.
>> >> > >
>> >> > > Thanks.
>> >> > > Best regards,
>> >> > > Jérôme
>> >> > >
>> >> > >
>> >> > > 2016-01-05 16:11 GMT+01:00 larry mccay <la...@gmail.com>:
>> >> > >
>> >> > > > Hello Jérôme -
>> >> > > >
>> >> > > > Happy New Year!
>> >> > > >
>> >> > > > I am going to start reviewing your updates today, hopefully.
>> >> > > > I was thinking that we need to start discussions on what the key
>> >> > usecases
>> >> > > > are and how to go about testing them.
>> >> > > > We can certainly test the testBasicAuth and against the hosted CAS
>> >> > server
>> >> > > > but what about FB, openid, OAuth, etc?
>> >> > > >
>> >> > > > I'm not sure that FB would be a key feature but OpenID Connect and
>> >> > OAuth
>> >> > > > would be - as is SAML.
>> >> > > > I think CAS buys us SAML testing - assuming that the
>> configuration of
>> >> > the
>> >> > > > hosted server is actually a SAML 2 instance.
>> >> > > >
>> >> > > > What about the others?
>> >> > > >
>> >> > > > I don't know that we need to be able to test them all before merge
>> >> but
>> >> > > some
>> >> > > > sort of manual verification would be great.
>> >> > > > We would need to be able to test them before the next release
>> which
>> >> > would
>> >> > > > be featuring the pac4j functionality.
>> >> > > >
>> >> > > > Maybe you can describe how you go about testing such things for
>> the
>> >> > pac4j
>> >> > > > project itself?
>> >> > > >
>> >> > > > thanks,
>> >> > > >
>> >> > > > --larry
>> >> > > >
>> >> > > >
>> >> > > > On Tue, Jan 5, 2016 at 9:55 AM, Jérôme LELEU <le...@gmail.com>
>> >> wrote:
>> >> > > >
>> >> > > > > Hi,
>> >> > > > >
>> >> > > > > Happy new year!
>> >> > > > >
>> >> > > > > A few days ago, I updated my patch of the pac4j gateway provider
>> >> > > > according
>> >> > > > > to all comments on
>> https://issues.apache.org/jira/browse/KNOX-641
>> >> as
>> >> > > > well
>> >> > > > > as the documentation on KNOX-642.
>> >> > > > >
>> >> > > > > Is everything ok for the merge?
>> >> > > > >
>> >> > > > > Thanks.
>> >> > > > > Best regards,
>> >> > > > > Jérôme
>> >> > > > >
>> >> > > > >
>> >> > > > > 2015-12-14 15:28 GMT+01:00 larry mccay <la...@gmail.com>:
>> >> > > > >
>> >> > > > > > Hi Jérôme -
>> >> > > > > >
>> >> > > > > > Not sure if you saw but I added review comments to KNOX-641.
>> >> > > > > >
>> >> > > > > > I think that we need to determine whether we want the
>> >> testBasicAuth
>> >> > > in
>> >> > > > > the
>> >> > > > > > provider itself.
>> >> > > > > >
>> >> > > > > > Let's follow up on the JIRA.
>> >> > > > > >
>> >> > > > > > thanks,
>> >> > > > > >
>> >> > > > > > --larry
>> >> > > > > >
>> >> > > > > > On Fri, Dec 11, 2015 at 8:44 AM, Jérôme LELEU <
>> leleuj@gmail.com>
>> >> > > > wrote:
>> >> > > > > >
>> >> > > > > > > Hi,
>> >> > > > > > >
>> >> > > > > > > No problem. It can go into a version 0.8.0 if needed. The
>> truth
>> >> > is
>> >> > > > that
>> >> > > > > > > there is only one change outside the new pac4j module, so I
>> >> think
>> >> > > > risks
>> >> > > > > > are
>> >> > > > > > > extremly limited.
>> >> > > > > > >
>> >> > > > > > > Just let met know.
>> >> > > > > > >
>> >> > > > > > > Thanks.
>> >> > > > > > > Best regards,
>> >> > > > > > > Jérôme
>> >> > > > > > >
>> >> > > > > > >
>> >> > > > > > > 2015-12-11 14:23 GMT+01:00 larry mccay <
>> larry.mccay@gmail.com
>> >> >:
>> >> > > > > > >
>> >> > > > > > > > Hi Jérôme -
>> >> > > > > > > >
>> >> > > > > > > > I have unfortunately not had a chance to pull, review and
>> >> test
>> >> > it
>> >> > > > yet
>> >> > > > > > and
>> >> > > > > > > > have intended to do that today.
>> >> > > > > > > > I apologize for the delay.
>> >> > > > > > > >
>> >> > > > > > > > I was actually thinking that this would go into a follow
>> up
>> >> > > release
>> >> > > > > > that
>> >> > > > > > > we
>> >> > > > > > > > would try and get done rapidly after the 0.7.0 release
>> but we
>> >> > can
>> >> > > > > > discuss
>> >> > > > > > > > the target and its chances of destabilizing 0.7.0.
>> >> > > > > > > >
>> >> > > > > > > > I believe that it is rather self-contained with only a few
>> >> > > changes
>> >> > > > to
>> >> > > > > > > > external modules.
>> >> > > > > > > >
>> >> > > > > > > > Opening the JIRAs is perfect and I was going to do that
>> once
>> >> I
>> >> > > > > started
>> >> > > > > > > the
>> >> > > > > > > > review.
>> >> > > > > > > >
>> >> > > > > > > > Let's continue review comments and collaboration on those
>> >> > JIRAs.
>> >> > > > > > > > I will add you to the contributors list so that we can
>> assign
>> >> > > them
>> >> > > > to
>> >> > > > > > > you.
>> >> > > > > > > >
>> >> > > > > > > > Thank you for your contributions and your patience,
>> Jérôme!
>> >> > > > > > > >
>> >> > > > > > > > --larry
>> >> > > > > > > >
>> >> > > > > > > > On Fri, Dec 11, 2015 at 3:00 AM, Jérôme LELEU <
>> >> > leleuj@gmail.com>
>> >> > > > > > wrote:
>> >> > > > > > > >
>> >> > > > > > > > > Hi,
>> >> > > > > > > > >
>> >> > > > > > > > > I didn't get any new feedback on the pull request so I
>> >> assume
>> >> > > > > > > everything
>> >> > > > > > > > is
>> >> > > > > > > > > ok from your point of view.
>> >> > > > > > > > >
>> >> > > > > > > > > I released pac4j v1.8.1 and j2e-pac4j v1.2.1 so I
>> updated
>> >> the
>> >> > > > pull
>> >> > > > > > > > request
>> >> > > > > > > > > to use them and successfully re-tested everything.
>> >> > > > > > > > >
>> >> > > > > > > > > I opened KNOX-641 and submitted the corresponding patch.
>> >> > > > > > > > >
>> >> > > > > > > > > I also wrote the documentation, opened KNOX-642 and
>> >> submitted
>> >> > > the
>> >> > > > > > > > > corresponding patch (just to let you know that it
>> doesn't
>> >> > work
>> >> > > > out
>> >> > > > > of
>> >> > > > > > > the
>> >> > > > > > > > > box in Windows, I had to replace mvn.bat by mvn.cmd to
>> make
>> >> > ant
>> >> > > > > > work).
>> >> > > > > > > > >
>> >> > > > > > > > > Even if the branch 0.7.0 has already been created, I
>> >> assumed
>> >> > > this
>> >> > > > > new
>> >> > > > > > > > pac4j
>> >> > > > > > > > > provider will go into this version 0.7.0 (dependency on
>> the
>> >> > > > > > > > 0.7.0-SNAPSHOT
>> >> > > > > > > > > parent version).
>> >> > > > > > > > >
>> >> > > > > > > > > Just let me know if everything is ok and when it's
>> goind to
>> >> > be
>> >> > > > > > merged.
>> >> > > > > > > > >
>> >> > > > > > > > > Thanks.
>> >> > > > > > > > > Best regards,
>> >> > > > > > > > > Jérôme
>> >> > > > > > > > >
>> >> > > > > > > > >
>> >> > > > > > > > >
>> >> > > > > > > > >
>> >> > > > > > > > > 2015-12-04 14:20 GMT+01:00 larry mccay <
>> >> > larry.mccay@gmail.com
>> >> > > >:
>> >> > > > > > > > >
>> >> > > > > > > > > > That ability to configure multiple mechanisms based on
>> >> > > > clientName
>> >> > > > > > is
>> >> > > > > > > > > really
>> >> > > > > > > > > > interesting for Knox.
>> >> > > > > > > > > > Currently, we require separate topologies per
>> >> > authentication
>> >> > > > > > > mechanism.
>> >> > > > > > > > > > The ability to configure them all in one is really
>> great.
>> >> > > > > > > > > >
>> >> > > > > > > > > > We would need to think through the best way to provide
>> >> the
>> >> > > > > > clientName
>> >> > > > > > > > > > parameter.
>> >> > > > > > > > > > Since this is targeting KnoxSSO it can actually be
>> added
>> >> to
>> >> > > the
>> >> > > > > > > > > providerURL
>> >> > > > > > > > > > used to redirect from the participating application.
>> >> > > > > > > > > > Regardless of the authentication mechanism used each
>> >> > > > application
>> >> > > > > > will
>> >> > > > > > > > > still
>> >> > > > > > > > > > get the same JWT based cookie.
>> >> > > > > > > > > >
>> >> > > > > > > > > > I think that should work really nicely.
>> >> > > > > > > > > >
>> >> > > > > > > > > >
>> >> > > > > > > > > > On Fri, Dec 4, 2015 at 7:17 AM, larry mccay <
>> >> > > > > larry.mccay@gmail.com
>> >> > > > > > >
>> >> > > > > > > > > wrote:
>> >> > > > > > > > > >
>> >> > > > > > > > > > > Excellent, Jérôme.
>> >> > > > > > > > > > > Thanks!
>> >> > > > > > > > > > >
>> >> > > > > > > > > > > On Fri, Dec 4, 2015 at 2:40 AM, Jérôme LELEU <
>> >> > > > leleuj@gmail.com
>> >> > > > > >
>> >> > > > > > > > wrote:
>> >> > > > > > > > > > >
>> >> > > > > > > > > > >> Hi,
>> >> > > > > > > > > > >>
>> >> > > > > > > > > > >> I will write how to configure the pac4j provider in
>> >> the
>> >> > > > > > > > documentation,
>> >> > > > > > > > > > but
>> >> > > > > > > > > > >> I can already give you some insights.
>> >> > > > > > > > > > >>
>> >> > > > > > > > > > >> My main goal is always to respect the key design
>> >> > > principles
>> >> > > > of
>> >> > > > > > > pac4j
>> >> > > > > > > > > > >> whatever the environment / framework in which it is
>> >> > > > > implemented.
>> >> > > > > > > For
>> >> > > > > > > > > > Knox,
>> >> > > > > > > > > > >> I'm pretty happy with the use of the j2e-pac4j
>> >> library,
>> >> > > > which
>> >> > > > > > > means
>> >> > > > > > > > > that
>> >> > > > > > > > > > >> almost all the pac4j features are available,
>> >> especially
>> >> > > both
>> >> > > > > > > direct
>> >> > > > > > > > > and
>> >> > > > > > > > > > >> indirect clients. So it can do what Shiro already
>> does
>> >> > but
>> >> > > > > also,
>> >> > > > > > > as
>> >> > > > > > > > we
>> >> > > > > > > > > > >> agreed together, supports remote authentications.
>> >> > > > > > > > > > >>
>> >> > > > > > > > > > >> It is only limited by what you can currently
>> >> configure.
>> >> > > And
>> >> > > > > even
>> >> > > > > > > > > > >> configuration is a pac4j feature as the CAS server
>> has
>> >> > the
>> >> > > > > same
>> >> > > > > > > > need.
>> >> > > > > > > > > > >> Everything happens in this class:
>> >> > > > > > > > > > >>
>> >> > > > > > > > > > >>
>> >> > > > > > > > > >
>> >> > > > > > > > >
>> >> > > > > > > >
>> >> > > > > > >
>> >> > > > > >
>> >> > > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java
>> >> > > > > > > > > > >> ,
>> >> > > > > > > > > > >> which allows you to configure Facebook, Twitter, a
>> CAS
>> >> > > > > server, a
>> >> > > > > > > > SAML
>> >> > > > > > > > > > IdP
>> >> > > > > > > > > > >> or an OpenID Connect provider. All the provided
>> >> > parameters
>> >> > > > to
>> >> > > > > > the
>> >> > > > > > > > > pac4j
>> >> > > > > > > > > > >> provider are put into a Map and the
>> >> > > ConfigPropertiesFactory
>> >> > > > is
>> >> > > > > > > built
>> >> > > > > > > > > > with
>> >> > > > > > > > > > >> this Map to return the built client (=
>> authentication
>> >> > > > > > mechanism).
>> >> > > > > > > > > > >>
>> >> > > > > > > > > > >> You have one more specific option for Knox as a
>> basic
>> >> > > > > > > authentication
>> >> > > > > > > > > > popup
>> >> > > > > > > > > > >> where the username must match the password, you can
>> >> > define
>> >> > > > > that
>> >> > > > > > > by:
>> >> > > > > > > > > > >>
>> >> > > > > > > > > > >> <param>
>> >> > > > > > > > > > >> <name>clientName</name>
>> >> > > > > > > > > > >> <value>testBasicAuth</value>
>> >> > > > > > > > > > >> </param>
>> >> > > > > > > > > > >>
>> >> > > > > > > > > > >>
>> >> > > > > > > > > > >> It's for testing only.
>> >> > > > > > > > > > >>
>> >> > > > > > > > > > >> For a CAS server:
>> >> > > > > > > > > > >>
>> >> > > > > > > > > > >> <param>
>> >> > > > > > > > > > >> <name>cas.loginUrl</name>
>> >> > > > > > > > > > >> <value>
>> https://casserverpac4j.herokuapp.com/login
>> >> > > </value>
>> >> > > > > > > > > > >> </param>
>> >> > > > > > > > > > >>
>> >> > > > > > > > > > >>
>> >> > > > > > > > > > >> Here are all the properties available for building
>> >> > clients
>> >> > > > > > (their
>> >> > > > > > > > > > meaning
>> >> > > > > > > > > > >> is obvious):
>> >> > > > > > > > > > >>
>> >> > > > > > > > > > >> facebook.id
>> >> > > > > > > > > > >> facebook.secret
>> >> > > > > > > > > > >> facebook.scope
>> >> > > > > > > > > > >> facebook.fields
>> >> > > > > > > > > > >> twitter.id
>> >> > > > > > > > > > >> twitter.secret
>> >> > > > > > > > > > >> saml.keystorePassword
>> >> > > > > > > > > > >> saml.privateKeyPassword
>> >> > > > > > > > > > >> saml.keystorePath
>> >> > > > > > > > > > >> saml.identityProviderMetadataPath
>> >> > > > > > > > > > >> saml.maximumAuthenticationLifetime
>> >> > > > > > > > > > >> saml.serviceProviderEntityId
>> >> > > > > > > > > > >> saml.serviceProviderMetadataPath
>> >> > > > > > > > > > >> cas.loginUrl
>> >> > > > > > > > > > >> cas.protocol
>> >> > > > > > > > > > >> oidc.id
>> >> > > > > > > > > > >> oidc.secret
>> >> > > > > > > > > > >> oidc.discoveryUri
>> >> > > > > > > > > > >> oidc.customParamKey1
>> >> > > > > > > > > > >> oidc.customParamValue1
>> >> > > > > > > > > > >>
>> >> > > > > > > > > > >>
>> >> > > > > > > > > > >> If you define multiple clients, the first one will
>> be
>> >> > used
>> >> > > > for
>> >> > > > > > > > > > >> authentication, but you can explicitly choose the
>> >> client
>> >> > > you
>> >> > > > > > want
>> >> > > > > > > to
>> >> > > > > > > > > use
>> >> > > > > > > > > > >> via the clientName parameter, assuming you want to
>> >> > switch
>> >> > > > from
>> >> > > > > > > > client
>> >> > > > > > > > > > >> depending on environment for example.
>> >> > > > > > > > > > >>
>> >> > > > > > > > > > >> So if you want to add some new authentication
>> >> mechanism,
>> >> > > you
>> >> > > > > > must
>> >> > > > > > > > > first
>> >> > > > > > > > > > >> check that it is available in pac4j (if it's not,
>> it's
>> >> > > > another
>> >> > > > > > > > > > discussion,
>> >> > > > > > > > > > >> but generally, it is). Then, you'll need to upgrade
>> >> the
>> >> > > > > > > > > > >> ConfigPropertiesFactory by submitting a new pull
>> >> request
>> >> > > to
>> >> > > > > the
>> >> > > > > > > > pac4j
>> >> > > > > > > > > > >> project (I can do it myself, but I'm sure you
>> could do
>> >> > > that
>> >> > > > > > > easily),
>> >> > > > > > > > > > >> finally wait for the new pac4j release and switch
>> >> pac4j
>> >> > > > > versions
>> >> > > > > > > in
>> >> > > > > > > > > Knox
>> >> > > > > > > > > > >> to
>> >> > > > > > > > > > >> benefit from the new feature.
>> >> > > > > > > > > > >> The good thing is that if someone related to the
>> CAS
>> >> > > server
>> >> > > > > does
>> >> > > > > > > the
>> >> > > > > > > > > > same
>> >> > > > > > > > > > >> thing for CAS (in pac4j), you will automatically
>> get
>> >> it
>> >> > > when
>> >> > > > > > > you'll
>> >> > > > > > > > > > >> upgrade
>> >> > > > > > > > > > >> pac4j.
>> >> > > > > > > > > > >>
>> >> > > > > > > > > > >> To go even further, replacing LDAP Shiro
>> >> authentication
>> >> > is
>> >> > > > > just
>> >> > > > > > a
>> >> > > > > > > > > matter
>> >> > > > > > > > > > >> of
>> >> > > > > > > > > > >> making pac4j LDAP authentication available via
>> >> > > configuration
>> >> > > > > > > > > parameters.
>> >> > > > > > > > > > >>
>> >> > > > > > > > > > >> I hope it was clear enough.
>> >> > > > > > > > > > >>
>> >> > > > > > > > > > >> Thanks.
>> >> > > > > > > > > > >> Best regards,
>> >> > > > > > > > > > >> Jérôme
>> >> > > > > > > > > > >>
>> >> > > > > > > > > > >>
>> >> > > > > > > > > > >>
>> >> > > > > > > > > > >>
>> >> > > > > > > > > > >> 2015-12-03 20:45 GMT+01:00 larry mccay <
>> >> > > > larry.mccay@gmail.com
>> >> > > > > >:
>> >> > > > > > > > > > >>
>> >> > > > > > > > > > >> > Excellent!
>> >> > > > > > > > > > >> >
>> >> > > > > > > > > > >> > I will carve out some time to do code review.
>> >> > > > > > > > > > >> > We will need to get some insights into how to go
>> >> about
>> >> > > > > > testing:
>> >> > > > > > > > > > >> >
>> >> > > > > > > > > > >> > * is the CAS server going to be available for
>> >> testing?
>> >> > > > > > > > > > >> > * what are the specific and generic/standard (if
>> >> any)
>> >> > > > > > > > authentication
>> >> > > > > > > > > > >> > mechanisms available - for instance:
>> >> > > > > > > > > > >> > - Facebook, Google, LinkedIn and CAS are
>> >> specifics
>> >> > > > > > > > > > >> > - OAuth 2, OpenID Connect, SAML are
>> >> > > generic/standards
>> >> > > > -
>> >> > > > > > that
>> >> > > > > > > > may
>> >> > > > > > > > > > be
>> >> > > > > > > > > > >> > used for the above specifics...
>> >> > > > > > > > > > >> > * how do we test things other than CAS - in
>> terms of
>> >> > > > getting
>> >> > > > > > > > > > >> credentials,
>> >> > > > > > > > > > >> > configuration, etc
>> >> > > > > > > > > > >> >
>> >> > > > > > > > > > >> > We could certainly do this is phases as well.
>> >> > > > > > > > > > >> >
>> >> > > > > > > > > > >> > If you can enumerate the things that should work
>> and
>> >> > > > provide
>> >> > > > > > > some
>> >> > > > > > > > > > >> testing
>> >> > > > > > > > > > >> > details for CAS or as many as possible and OpenID
>> >> > > Connect
>> >> > > > > then
>> >> > > > > > > we
>> >> > > > > > > > > can
>> >> > > > > > > > > > >> test
>> >> > > > > > > > > > >> > the specific implementations that you provide and
>> >> > enable
>> >> > > > the
>> >> > > > > > > > testing
>> >> > > > > > > > > > of
>> >> > > > > > > > > > >> > another OpenID Connect effort that is in the
>> works
>> >> in
>> >> > > the
>> >> > > > > > > > community.
>> >> > > > > > > > > > >> >
>> >> > > > > > > > > > >> > I'm not sure whether we want to commit
>> contributions
>> >> > > that
>> >> > > > > are
>> >> > > > > > > > > > dependent
>> >> > > > > > > > > > >> on
>> >> > > > > > > > > > >> > snapshots - we certainly can't release with any
>> such
>> >> > > > > > > dependencies.
>> >> > > > > > > > > > >> > I would hate to add a cleanup task to a release
>> to
>> >> > make
>> >> > > > sure
>> >> > > > > > > there
>> >> > > > > > > > > are
>> >> > > > > > > > > > >> no
>> >> > > > > > > > > > >> > snapshots in there.
>> >> > > > > > > > > > >> > We will probably wait until after the pac4j
>> releases
>> >> > to
>> >> > > > > > commit.
>> >> > > > > > > > > > >> >
>> >> > > > > > > > > > >> > I am really happy that this integration is
>> happening
>> >> > and
>> >> > > > > that
>> >> > > > > > it
>> >> > > > > > > > > went
>> >> > > > > > > > > > >> > rather smoothly.
>> >> > > > > > > > > > >> > These sorts of authentication protocols are
>> complex
>> >> > and
>> >> > > I
>> >> > > > > > think
>> >> > > > > > > we
>> >> > > > > > > > > > >> lined up
>> >> > > > > > > > > > >> > pretty well overall.
>> >> > > > > > > > > > >> >
>> >> > > > > > > > > > >> > Thanks for your work!
>> >> > > > > > > > > > >> >
>> >> > > > > > > > > > >> > On Thu, Dec 3, 2015 at 2:28 PM, Jérôme LELEU <
>> >> > > > > > leleuj@gmail.com>
>> >> > > > > > > > > > wrote:
>> >> > > > > > > > > > >> >
>> >> > > > > > > > > > >> > > Hi,
>> >> > > > > > > > > > >> > >
>> >> > > > > > > > > > >> > > I just sync'ed with master, cleaned
>> dependencies
>> >> and
>> >> > > > added
>> >> > > > > > > > missing
>> >> > > > > > > > > > >> > > Javadocs. Everything works correctly now. Many
>> >> > thanks.
>> >> > > > > > > > > > >> > >
>> >> > > > > > > > > > >> > > The pull request is ready for a full code
>> review:
>> >> > > > > > > > > > >> > > https://github.com/apache/knox/pull/2
>> >> > > > > > > > > > >> > >
>> >> > > > > > > > > > >> > > I'll write the documentation after the pac4j
>> >> > releases
>> >> > > (I
>> >> > > > > > hope
>> >> > > > > > > > next
>> >> > > > > > > > > > >> week).
>> >> > > > > > > > > > >> > >
>> >> > > > > > > > > > >> > > Thanks.
>> >> > > > > > > > > > >> > > Best regards,
>> >> > > > > > > > > > >> > > Jérôme
>> >> > > > > > > > > > >> > >
>> >> > > > > > > > > > >> > >
>> >> > > > > > > > > > >> > > 2015-12-02 19:18 GMT+01:00 larry mccay <
>> >> > > > > > larry.mccay@gmail.com
>> >> > > > > > > >:
>> >> > > > > > > > > > >> > >
>> >> > > > > > > > > > >> > > > Fixed in
>> >> > > > https://issues.apache.org/jira/browse/KNOX-636
>> >> > > > > .
>> >> > > > > > > > > > >> > > >
>> >> > > > > > > > > > >> > > > On Wed, Dec 2, 2015 at 12:42 PM, larry mccay
>> <
>> >> > > > > > > > > > larry.mccay@gmail.com
>> >> > > > > > > > > > >> >
>> >> > > > > > > > > > >> > > > wrote:
>> >> > > > > > > > > > >> > > >
>> >> > > > > > > > > > >> > > > > Sure - I can file a JIRA and commit a fix.
>> >> > > > > > > > > > >> > > > >
>> >> > > > > > > > > > >> > > > > The secret generation should be done in one
>> >> > > instance
>> >> > > > > and
>> >> > > > > > > > > > >> replicated
>> >> > > > > > > > > > >> > > > across
>> >> > > > > > > > > > >> > > > > others.
>> >> > > > > > > > > > >> > > > > This replication/management of the
>> credential
>> >> > > stores
>> >> > > > > is
>> >> > > > > > > > > outside
>> >> > > > > > > > > > of
>> >> > > > > > > > > > >> > the
>> >> > > > > > > > > > >> > > > > scope of Knox itself as of now.
>> >> > > > > > > > > > >> > > > >
>> >> > > > > > > > > > >> > > > > Documentation is done in markdown and is
>> >> > > > contributing
>> >> > > > > > > > details
>> >> > > > > > > > > > are
>> >> > > > > > > > > > >> > > > > available at:
>> >> > > > > > > > > > >> > > > >
>> >> > > > > > > > > > >> > > >
>> >> > > > > > > > > > >> > >
>> >> > > > > > > > > > >> >
>> >> > > > > > > > > > >>
>> >> > > > > > > > > >
>> >> > > > > > > > >
>> >> > > > > > > >
>> >> > > > > > >
>> >> > > > > >
>> >> > > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
>> >> > > > > > > > > > >> > > > >
>> >> > > > > > > > > > >> > > > > Which should give you a general idea.
>> >> > > > > > > > > > >> > > > >
>> >> > > > > > > > > > >> > > > > Find an example like: ./trunk/books/0.7.0/
>> >> > > > > > > > > > >> > > config_preauth_sso_provider.md
>> >> > > > > > > > > > >> > > > >
>> >> > > > > > > > > > >> > > > > For an example of typical content and
>> format.
>> >> > > > > > > > > > >> > > > >
>> >> > > > > > > > > > >> > > > > Here is how that example renders:
>> >> > > > > > > > > > >> > > > >
>> >> > > > > > > > > > >> > > >
>> >> > > > > > > > > > >> > >
>> >> > > > > > > > > > >> >
>> >> > > > > > > > > > >>
>> >> > > > > > > > > >
>> >> > > > > > > > >
>> >> > > > > > > >
>> >> > > > > > >
>> >> > > > > >
>> >> > > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
>> >> > > > > > > > > > >> > > > >
>> >> > > > > > > > > > >> > > > > You'll need to tie it into the rest of the
>> >> book
>> >> > -
>> >> > > > just
>> >> > > > > > > grep
>> >> > > > > > > > > for
>> >> > > > > > > > > > >> where
>> >> > > > > > > > > > >> > > > that
>> >> > > > > > > > > > >> > > > > filename is referenced.
>> >> > > > > > > > > > >> > > > > To test how it renders build the site with:
>> >> > "ant"
>> >> > > > and
>> >> > > > > > note
>> >> > > > > > > > the
>> >> > > > > > > > > > >> url to
>> >> > > > > > > > > > >> > > the
>> >> > > > > > > > > > >> > > > > 0.7.0 book.
>> >> > > > > > > > > > >> > > > >
>> >> > > > > > > > > > >> > > > >
>> >> > > > > > > > > > >> > > > > On Wed, Dec 2, 2015 at 12:12 PM, Jérôme
>> LELEU
>> >> <
>> >> > > > > > > > > leleuj@gmail.com
>> >> > > > > > > > > > >
>> >> > > > > > > > > > >> > > wrote:
>> >> > > > > > > > > > >> > > > >
>> >> > > > > > > > > > >> > > > >> Hi,
>> >> > > > > > > > > > >> > > > >>
>> >> > > > > > > > > > >> > > > >> Why it doesn't work for pac4j while it
>> works
>> >> > for
>> >> > > > > others
>> >> > > > > > > is
>> >> > > > > > > > a
>> >> > > > > > > > > > bit
>> >> > > > > > > > > > >> > > strange
>> >> > > > > > > > > > >> > > > >> to
>> >> > > > > > > > > > >> > > > >> me, but if you have the patch in front of
>> >> your
>> >> > > > eyes,
>> >> > > > > > I'd
>> >> > > > > > > > > rather
>> >> > > > > > > > > > >> > prefer
>> >> > > > > > > > > > >> > > > you
>> >> > > > > > > > > > >> > > > >> to commit it. In all cases, I'll sync with
>> >> the
>> >> > > > > master.
>> >> > > > > > > > > > >> > > > >>
>> >> > > > > > > > > > >> > > > >> There was one question you didn't answer
>> >> > > > previously:
>> >> > > > > is
>> >> > > > > > > the
>> >> > > > > > > > > > >> password
>> >> > > > > > > > > > >> > > > >> generated for the pac4j provider the same
>> >> > across
>> >> > > > all
>> >> > > > > > > > gateway
>> >> > > > > > > > > > >> > > instances?
>> >> > > > > > > > > > >> > > > >> Because I expect to have the same value
>> as I
>> >> > use
>> >> > > it
>> >> > > > > to
>> >> > > > > > > > > encrypt
>> >> > > > > > > > > > /
>> >> > > > > > > > > > >> > > decrypt
>> >> > > > > > > > > > >> > > > >> data.
>> >> > > > > > > > > > >> > > > >>
>> >> > > > > > > > > > >> > > > >> I will add the Javadoc. After that, you
>> can
>> >> > > review
>> >> > > > > the
>> >> > > > > > > pull
>> >> > > > > > > > > > >> request
>> >> > > > > > > > > > >> > > more
>> >> > > > > > > > > > >> > > > >> completely.
>> >> > > > > > > > > > >> > > > >>
>> >> > > > > > > > > > >> > > > >> What do you expect for the documentation?
>> >> > > > > > > > > > >> > > > >>
>> >> > > > > > > > > > >> > > > >> Notice that pac4j dependencies are still
>> >> > > snapshots,
>> >> > > > > but
>> >> > > > > > > > they
>> >> > > > > > > > > > >> will be
>> >> > > > > > > > > > >> > > > >> released in a week or two.
>> >> > > > > > > > > > >> > > > >>
>> >> > > > > > > > > > >> > > > >> Thanks.
>> >> > > > > > > > > > >> > > > >> Best regards,
>> >> > > > > > > > > > >> > > > >> Jérôme
>> >> > > > > > > > > > >> > > > >>
>> >> > > > > > > > > > >> > > > >>
>> >> > > > > > > > > > >> > > > >> 2015-12-02 17:51 GMT+01:00 larry mccay <
>> >> > > > > > > > > larry.mccay@gmail.com
>> >> > > > > > > > > > >:
>> >> > > > > > > > > > >> > > > >>
>> >> > > > > > > > > > >> > > > >> > Jérôme -
>> >> > > > > > > > > > >> > > > >> >
>> >> > > > > > > > > > >> > > > >> > If you would like to add that change as
>> >> part
>> >> > of
>> >> > > > > your
>> >> > > > > > > > patch
>> >> > > > > > > > > or
>> >> > > > > > > > > > >> as a
>> >> > > > > > > > > > >> > > > >> > separately filed JIRA to fix a bug that
>> >> would
>> >> > > > > > certainly
>> >> > > > > > > > be
>> >> > > > > > > > > > >> > welcomed.
>> >> > > > > > > > > > >> > > > >> > Otherwise, I can do it.
>> >> > > > > > > > > > >> > > > >> >
>> >> > > > > > > > > > >> > > > >> > Let me know.
>> >> > > > > > > > > > >> > > > >> >
>> >> > > > > > > > > > >> > > > >> > thanks,
>> >> > > > > > > > > > >> > > > >> >
>> >> > > > > > > > > > >> > > > >> > --larry
>> >> > > > > > > > > > >> > > > >> >
>> >> > > > > > > > > > >> > > > >> > On Wed, Dec 2, 2015 at 11:44 AM, larry
>> >> mccay
>> >> > <
>> >> > > > > > > > > > >> > larry.mccay@gmail.com
>> >> > > > > > > > > > >> > > >
>> >> > > > > > > > > > >> > > > >> > wrote:
>> >> > > > > > > > > > >> > > > >> >
>> >> > > > > > > > > > >> > > > >> > > Okay - I had to add an override of
>> >> > > > > > getUserPrincipal()
>> >> > > > > > > > to
>> >> > > > > > > > > > the
>> >> > > > > > > > > > >> > > > >> > >
>> IdentityAsserterHttpServletRequestWrapper
>> >> > and
>> >> > > > > > return
>> >> > > > > > > > the
>> >> > > > > > > > > > >> member
>> >> > > > > > > > > > >> > > > >> variable
>> >> > > > > > > > > > >> > > > >> > > username and it works like a charm.
>> >> > > > > > > > > > >> > > > >> > >
>> >> > > > > > > > > > >> > > > >> > > Why I haven't seen this same behavior
>> >> with
>> >> > > > other
>> >> > > > > > > > > providers
>> >> > > > > > > > > > >> is a
>> >> > > > > > > > > > >> > > bit
>> >> > > > > > > > > > >> > > > >> of a
>> >> > > > > > > > > > >> > > > >> > > mystery but they must be adding other
>> >> > > wrappers
>> >> > > > > that
>> >> > > > > > > > > handle
>> >> > > > > > > > > > >> it.
>> >> > > > > > > > > > >> > > > >> > > This is quite cool, Jérôme!
>> >> > > > > > > > > > >> > > > >> > >
>> >> > > > > > > > > > >> > > > >> > > On Wed, Dec 2, 2015 at 10:41 AM, larry
>> >> > mccay
>> >> > > <
>> >> > > > > > > > > > >> > > larry.mccay@gmail.com
>> >> > > > > > > > > > >> > > > >
>> >> > > > > > > > > > >> > > > >> > > wrote:
>> >> > > > > > > > > > >> > > > >> > >
>> >> > > > > > > > > > >> > > > >> > >> That was it - thanks!
>> >> > > > > > > > > > >> > > > >> > >>
>> >> > > > > > > > > > >> > > > >> > >> On Wed, Dec 2, 2015 at 10:20 AM,
>> Jérôme
>> >> > > LELEU
>> >> > > > <
>> >> > > > > > > > > > >> > leleuj@gmail.com>
>> >> > > > > > > > > > >> > > > >> wrote:
>> >> > > > > > > > > > >> > > > >> > >>
>> >> > > > > > > > > > >> > > > >> > >>> This is my exact command line: mvn
>> >> > > -Prelease
>> >> > > > > > clean
>> >> > > > > > > > > > install
>> >> > > > > > > > > > >> > > > >> -DskipTests
>> >> > > > > > > > > > >> > > > >> > >>>
>> >> > > > > > > > > > >> > > > >> > >>> You use an internal Maven
>> repository to
>> >> > > fetch
>> >> > > > > > > > > > dependencies
>> >> > > > > > > > > > >> > from
>> >> > > > > > > > > > >> > > > >> > internet:
>> >> > > > > > > > > > >> > > > >> > >>>
>> >> > > > > > > > > > >> > >
>> >> > > > > > > >
>> >> > > http://nexus-private.hortonworks.com/nexus/content/groups/public/
>> >> > > > > > > > > > >> > > > >> > >>>
>> >> > > > > > > > > > >> > > > >> > >>> Does this repository have access to
>> the
>> >> > > > remote
>> >> > > > > > > > > Snapshots
>> >> > > > > > > > > > >> > > Sonatype
>> >> > > > > > > > > > >> > > > >> repo?
>> >> > > > > > > > > > >> > > > >> > >>>
>> >> > > > > > > > > > >> > > > >> > >>>
>> >> > > > > > > > > > >> > > > >> > >>>
>> >> > > > > > > > > > >> > > > >> > >>> 2015-12-02 16:16 GMT+01:00 larry
>> mccay
>> >> <
>> >> > > > > > > > > > >> larry.mccay@gmail.com
>> >> > > > > > > > > > >> > >:
>> >> > > > > > > > > > >> > > > >> > >>>
>> >> > > > > > > > > > >> > > > >> > >>> > hmmm - I used:
>> >> > > > > > > > > > >> > > > >> > >>> >
>> >> > > > > > > > > > >> > > > >> > >>> > mvn clean install -DskipTests=true
>> >> > > > -Prelease
>> >> > > > > > > > > > >> > > > >> > >>> >
>> >> > > > > > > > > > >> > > > >> > >>> > The repository entry is in there
>> >> > already.
>> >> > > > > > > > > > >> > > > >> > >>> > No worky.
>> >> > > > > > > > > > >> > > > >> > >>> >
>> >> > > > > > > > > > >> > > > >> > >>> > On Wed, Dec 2, 2015 at 10:12 AM,
>> >> Jérôme
>> >> > > > > LELEU <
>> >> > > > > > > > > > >> > > leleuj@gmail.com
>> >> > > > > > > > > > >> > > > >
>> >> > > > > > > > > > >> > > > >> > >>> wrote:
>> >> > > > > > > > > > >> > > > >> > >>> >
>> >> > > > > > > > > > >> > > > >> > >>> > > Hi,
>> >> > > > > > > > > > >> > > > >> > >>> > >
>> >> > > > > > > > > > >> > > > >> > >>> > > You need the j2e-pac4j
>> dependencies
>> >> > as
>> >> > > > well
>> >> > > > > > as
>> >> > > > > > > > the
>> >> > > > > > > > > > >> pac4j-*
>> >> > > > > > > > > > >> > > > >> > >>> dependencies,
>> >> > > > > > > > > > >> > > > >> > >>> > > but you don't need to build them
>> >> > > locally
>> >> > > > > > > > > (hopefully).
>> >> > > > > > > > > > >> > > > >> > >>> > >
>> >> > > > > > > > > > >> > > > >> > >>> > > But you need a dependency on the
>> >> > > Sonatype
>> >> > > > > > > > snapshots
>> >> > > > > > > > > > >> > > repository
>> >> > > > > > > > > > >> > > > >> > >>> (where the
>> >> > > > > > > > > > >> > > > >> > >>> > > snapshot versions are hosted),
>> >> which
>> >> > is
>> >> > > > > added
>> >> > > > > > > for
>> >> > > > > > > > > > >> Maven in
>> >> > > > > > > > > > >> > > the
>> >> > > > > > > > > > >> > > > >> root
>> >> > > > > > > > > > >> > > > >> > >>> > > pom.xml:
>> >> > > > > > > > > > >> > > > >> > >>> > >
>> >> > > > > > > > > > >> > > > >> > >>> > >
>> >> > > > > > > > > > >> > > > >> > >>> >
>> >> > > > > > > > > > >> > > > >> > >>>
>> >> > > > > > > > > > >> > > > >> >
>> >> > > > > > > > > > >> > > > >>
>> >> > > > > > > > > > >> > > >
>> >> > > > > > > > > > >> > >
>> >> > > > > > > > > > >> >
>> >> > > > > > > > > > >>
>> >> > > > > > > > > >
>> >> > > > > > > > >
>> >> > > > > > > >
>> >> > > > > > >
>> >> > > > > >
>> >> > > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
>> >> > > > > > > > > > >> > > > >> > >>> > >
>> >> > > > > > > > > > >> > > > >> > >>> > > If you use Ant for the build,
>> there
>> >> > is
>> >> > > > > maybe
>> >> > > > > > a
>> >> > > > > > > > > glitch
>> >> > > > > > > > > > >> to
>> >> > > > > > > > > > >> > > find
>> >> > > > > > > > > > >> > > > >> the
>> >> > > > > > > > > > >> > > > >> > >>> > Sonatype
>> >> > > > > > > > > > >> > > > >> > >>> > > Maven repo.
>> >> > > > > > > > > > >> > > > >> > >>> > >
>> >> > > > > > > > > > >> > > > >> > >>> > > Thanks.
>> >> > > > > > > > > > >> > > > >> > >>> > > Best regards,
>> >> > > > > > > > > > >> > > > >> > >>> > > Jérôme
>> >> > > > > > > > > > >> > > > >> > >>> > >
>> >> > > > > > > > > > >> > > > >> > >>> > >
>> >> > > > > > > > > > >> > > > >> > >>> > > 2015-12-02 16:06 GMT+01:00 larry
>> >> > mccay
>> >> > > <
>> >> > > > > > > > > > >> > > larry.mccay@gmail.com
>> >> > > > > > > > > > >> > > > >:
>> >> > > > > > > > > > >> > > > >> > >>> > >
>> >> > > > > > > > > > >> > > > >> > >>> > > > 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.mccay@gmail.com>
>> >> > > > > > > > > > >> > > > >> > >>> > > > wrote:
>> >> > > > > > > > > > >> > > > >> > >>> > > >
>> >> > > > > > > > > > >> > > > >> > >>> > > > >
>> gateway-provider-security-pac4j
>> >> > > > doesn't
>> >> > > > > > > > build -
>> >> > > > > > > > > > do
>> >> > > > > > > > > > >> you
>> >> > > > > > > > > > >> > > > have
>> >> > > > > > > > > > >> > > > >> a
>> >> > > > > > > > > > >> > > > >> > >>> pending
>> >> > > > > > > > > > >> > > > >> > >>> > > > > change for your pom.xml or
>> >> > > something?
>> >> > > > > > > > > > >> > > > >> > >>> > > > >
>> >> > > > > > > > > > >> > > > >> > >>> >
>> >> > > > > > > > > > >> > > > >> > >>>
>> >> > > > > > > > > > >> > > > >> > >>
>> >> > > > > > > > > > >> > > > >> > >>
>> >> > > > > > > > > > >> > > > >> > >
>> >> > > > > > > > > > >> > > > >> >
>> >> > > > > > > > > > >> > > > >>
>> >> > > > > > > > > > >> > > > >
>> >> > > > > > > > > > >> > > > >
>> >> > > > > > > > > > >> > > >
>> >> > > > > > > > > > >> > >
>> >> > > > > > > > > > >> >
>> >> > > > > > > > > > >>
>> >> > > > > > > > > > >
>> >> > > > > > > > > > >
>> >> > > > > > > > > >
>> >> > > > > > > > >
>> >> > > > > > > >
>> >> > > > > > >
>> >> > > > > >
>> >> > > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Hi,
Yes, you can hit the CAS server at Heroku. Notice it's a Heroku free server
so it needs to be re-activated first (it takes a couple of seconds). So for
a UI test, you should first hit it, wait 30 seconds and then perform the
test.
Just my 2 cents:
Using automated UI tests was my first strategy for pac4j but I finally
gave up because public providers change very often, at least enough to make
the maintenance tests a nightmare. Currently, I'm using manual tests (the
same for all demos), it takes me around 5 minutes to play them all by hand
(for a demo) and I launched manually the UI tests I have for every major
pac4j release. Just to say UI tests are not that easy. For a CAS server,
it's fairly feasible as the CAS server and protocol change rarely.
That's why for Knox, I did some compromise with a simulated web test (based
on the basic auth). See:
https://github.com/apache/knox/pull/2/files#diff-d0c880ca71b310dbe57975c577535e97R47
Thanks.
Best regards,
Jérôme
2016-01-05 21:20 GMT+01:00 Kevin Minder <ke...@hortonworks.com>:
> From my perspective it would be ideal if there were some automatable
> functional tests for this. I’m not advocating that these be something
> included in “mvn clean install” as that is running too long as it is.
> Given that I don’t have as much context as Larry, I have some questions
> about what this would take. Lets say we had permission to hit
> https://casserverpac4j.herokuapp.com/login as part of some low frequency
> automated tests (e.g. Once nighty). What static credentials and other test
> automation infrastructure would need to be implemented in support of this?
> I understand that the test suite would require at a minimum
> 1) a test driver
> 2) a protected mock UI and
> 3) an appropriately configured Knox
> 4) a profile enabled maven module
> 5) an Apache jenkins job
> but I’m sure I’m missing other things. I’m certainly willing to help
> setup the skeleton infrastructure (e.g. test driver, mock UI, maven module,
> jenkins job)
>
>
>
> On 1/5/16, 2:54 PM, "larry mccay" <la...@gmail.com> wrote:
>
> >Okay, very good.
> >I've used TestShib for the picketlink provider - thanks for the pointers!
> >
> >On Tue, Jan 5, 2016 at 1:38 PM, Jérôme LELEU <le...@gmail.com> wrote:
> >
> >> The online CAS server (https://casserverpac4j.herokuapp.com/login) uses
> >> the
> >> CAS protocol. SAML support can be tested using some online IdP like
> Okta,
> >> TestShib, OpenFeide, Ssocircle...
> >>
> >>
> >> 2016-01-05 17:32 GMT+01:00 larry mccay <la...@gmail.com>:
> >>
> >> > Great - thanks for that pointer!
> >> >
> >> > I will take a look at that and help drive the release related testing.
> >> > Merge testing will be gated on CAS server (is this SAML or CAS
> protocol?)
> >> > and testBasicAuth.
> >> >
> >> > On Tue, Jan 5, 2016 at 10:52 AM, Jérôme LELEU <le...@gmail.com>
> wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > > Glad to hear back from you!
> >> > >
> >> > > The core pac4j project is fully tested by unit tests (and some
> >> > integration
> >> > > tests I run for major version), then all pac4j implementations are
> each
> >> > > tested by the appropriate demo: j2e-pac4j-demo tests j2e-pac4j,
> >> > > spring-webmvc-pac4j-demo tests spring-webmvc-pac4j, etc.
> >> > >
> >> > > So if you take a look at:
> >> > >
> >> > >
> >> >
> >>
> https://github.com/pac4j/j2e-pac4j-demo/blob/master/src/main/java/org/pac4j/demo/j2e/config/DemoConfigFactory.java#L27
> >> > > (for example), you have all the required information to test.
> >> > >
> >> > > I can do that on my own, but it can be good for the Knox community
> to
> >> > start
> >> > > working / testing the pac4j support. It's up to yoy.
> >> > >
> >> > > Thanks.
> >> > > Best regards,
> >> > > Jérôme
> >> > >
> >> > >
> >> > > 2016-01-05 16:11 GMT+01:00 larry mccay <la...@gmail.com>:
> >> > >
> >> > > > Hello Jérôme -
> >> > > >
> >> > > > Happy New Year!
> >> > > >
> >> > > > I am going to start reviewing your updates today, hopefully.
> >> > > > I was thinking that we need to start discussions on what the key
> >> > usecases
> >> > > > are and how to go about testing them.
> >> > > > We can certainly test the testBasicAuth and against the hosted CAS
> >> > server
> >> > > > but what about FB, openid, OAuth, etc?
> >> > > >
> >> > > > I'm not sure that FB would be a key feature but OpenID Connect and
> >> > OAuth
> >> > > > would be - as is SAML.
> >> > > > I think CAS buys us SAML testing - assuming that the
> configuration of
> >> > the
> >> > > > hosted server is actually a SAML 2 instance.
> >> > > >
> >> > > > What about the others?
> >> > > >
> >> > > > I don't know that we need to be able to test them all before merge
> >> but
> >> > > some
> >> > > > sort of manual verification would be great.
> >> > > > We would need to be able to test them before the next release
> which
> >> > would
> >> > > > be featuring the pac4j functionality.
> >> > > >
> >> > > > Maybe you can describe how you go about testing such things for
> the
> >> > pac4j
> >> > > > project itself?
> >> > > >
> >> > > > thanks,
> >> > > >
> >> > > > --larry
> >> > > >
> >> > > >
> >> > > > On Tue, Jan 5, 2016 at 9:55 AM, Jérôme LELEU <le...@gmail.com>
> >> wrote:
> >> > > >
> >> > > > > Hi,
> >> > > > >
> >> > > > > Happy new year!
> >> > > > >
> >> > > > > A few days ago, I updated my patch of the pac4j gateway provider
> >> > > > according
> >> > > > > to all comments on
> https://issues.apache.org/jira/browse/KNOX-641
> >> as
> >> > > > well
> >> > > > > as the documentation on KNOX-642.
> >> > > > >
> >> > > > > Is everything ok for the merge?
> >> > > > >
> >> > > > > Thanks.
> >> > > > > Best regards,
> >> > > > > Jérôme
> >> > > > >
> >> > > > >
> >> > > > > 2015-12-14 15:28 GMT+01:00 larry mccay <la...@gmail.com>:
> >> > > > >
> >> > > > > > Hi Jérôme -
> >> > > > > >
> >> > > > > > Not sure if you saw but I added review comments to KNOX-641.
> >> > > > > >
> >> > > > > > I think that we need to determine whether we want the
> >> testBasicAuth
> >> > > in
> >> > > > > the
> >> > > > > > provider itself.
> >> > > > > >
> >> > > > > > Let's follow up on the JIRA.
> >> > > > > >
> >> > > > > > thanks,
> >> > > > > >
> >> > > > > > --larry
> >> > > > > >
> >> > > > > > On Fri, Dec 11, 2015 at 8:44 AM, Jérôme LELEU <
> leleuj@gmail.com>
> >> > > > wrote:
> >> > > > > >
> >> > > > > > > Hi,
> >> > > > > > >
> >> > > > > > > No problem. It can go into a version 0.8.0 if needed. The
> truth
> >> > is
> >> > > > that
> >> > > > > > > there is only one change outside the new pac4j module, so I
> >> think
> >> > > > risks
> >> > > > > > are
> >> > > > > > > extremly limited.
> >> > > > > > >
> >> > > > > > > Just let met know.
> >> > > > > > >
> >> > > > > > > Thanks.
> >> > > > > > > Best regards,
> >> > > > > > > Jérôme
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > 2015-12-11 14:23 GMT+01:00 larry mccay <
> larry.mccay@gmail.com
> >> >:
> >> > > > > > >
> >> > > > > > > > Hi Jérôme -
> >> > > > > > > >
> >> > > > > > > > I have unfortunately not had a chance to pull, review and
> >> test
> >> > it
> >> > > > yet
> >> > > > > > and
> >> > > > > > > > have intended to do that today.
> >> > > > > > > > I apologize for the delay.
> >> > > > > > > >
> >> > > > > > > > I was actually thinking that this would go into a follow
> up
> >> > > release
> >> > > > > > that
> >> > > > > > > we
> >> > > > > > > > would try and get done rapidly after the 0.7.0 release
> but we
> >> > can
> >> > > > > > discuss
> >> > > > > > > > the target and its chances of destabilizing 0.7.0.
> >> > > > > > > >
> >> > > > > > > > I believe that it is rather self-contained with only a few
> >> > > changes
> >> > > > to
> >> > > > > > > > external modules.
> >> > > > > > > >
> >> > > > > > > > Opening the JIRAs is perfect and I was going to do that
> once
> >> I
> >> > > > > started
> >> > > > > > > the
> >> > > > > > > > review.
> >> > > > > > > >
> >> > > > > > > > Let's continue review comments and collaboration on those
> >> > JIRAs.
> >> > > > > > > > I will add you to the contributors list so that we can
> assign
> >> > > them
> >> > > > to
> >> > > > > > > you.
> >> > > > > > > >
> >> > > > > > > > Thank you for your contributions and your patience,
> Jérôme!
> >> > > > > > > >
> >> > > > > > > > --larry
> >> > > > > > > >
> >> > > > > > > > On Fri, Dec 11, 2015 at 3:00 AM, Jérôme LELEU <
> >> > leleuj@gmail.com>
> >> > > > > > wrote:
> >> > > > > > > >
> >> > > > > > > > > Hi,
> >> > > > > > > > >
> >> > > > > > > > > I didn't get any new feedback on the pull request so I
> >> assume
> >> > > > > > > everything
> >> > > > > > > > is
> >> > > > > > > > > ok from your point of view.
> >> > > > > > > > >
> >> > > > > > > > > I released pac4j v1.8.1 and j2e-pac4j v1.2.1 so I
> updated
> >> the
> >> > > > pull
> >> > > > > > > > request
> >> > > > > > > > > to use them and successfully re-tested everything.
> >> > > > > > > > >
> >> > > > > > > > > I opened KNOX-641 and submitted the corresponding patch.
> >> > > > > > > > >
> >> > > > > > > > > I also wrote the documentation, opened KNOX-642 and
> >> submitted
> >> > > the
> >> > > > > > > > > corresponding patch (just to let you know that it
> doesn't
> >> > work
> >> > > > out
> >> > > > > of
> >> > > > > > > the
> >> > > > > > > > > box in Windows, I had to replace mvn.bat by mvn.cmd to
> make
> >> > ant
> >> > > > > > work).
> >> > > > > > > > >
> >> > > > > > > > > Even if the branch 0.7.0 has already been created, I
> >> assumed
> >> > > this
> >> > > > > new
> >> > > > > > > > pac4j
> >> > > > > > > > > provider will go into this version 0.7.0 (dependency on
> the
> >> > > > > > > > 0.7.0-SNAPSHOT
> >> > > > > > > > > parent version).
> >> > > > > > > > >
> >> > > > > > > > > Just let me know if everything is ok and when it's
> goind to
> >> > be
> >> > > > > > merged.
> >> > > > > > > > >
> >> > > > > > > > > Thanks.
> >> > > > > > > > > Best regards,
> >> > > > > > > > > Jérôme
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > 2015-12-04 14:20 GMT+01:00 larry mccay <
> >> > larry.mccay@gmail.com
> >> > > >:
> >> > > > > > > > >
> >> > > > > > > > > > That ability to configure multiple mechanisms based on
> >> > > > clientName
> >> > > > > > is
> >> > > > > > > > > really
> >> > > > > > > > > > interesting for Knox.
> >> > > > > > > > > > Currently, we require separate topologies per
> >> > authentication
> >> > > > > > > mechanism.
> >> > > > > > > > > > The ability to configure them all in one is really
> great.
> >> > > > > > > > > >
> >> > > > > > > > > > We would need to think through the best way to provide
> >> the
> >> > > > > > clientName
> >> > > > > > > > > > parameter.
> >> > > > > > > > > > Since this is targeting KnoxSSO it can actually be
> added
> >> to
> >> > > the
> >> > > > > > > > > providerURL
> >> > > > > > > > > > used to redirect from the participating application.
> >> > > > > > > > > > Regardless of the authentication mechanism used each
> >> > > > application
> >> > > > > > will
> >> > > > > > > > > still
> >> > > > > > > > > > get the same JWT based cookie.
> >> > > > > > > > > >
> >> > > > > > > > > > I think that should work really nicely.
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > > On Fri, Dec 4, 2015 at 7:17 AM, larry mccay <
> >> > > > > larry.mccay@gmail.com
> >> > > > > > >
> >> > > > > > > > > wrote:
> >> > > > > > > > > >
> >> > > > > > > > > > > Excellent, Jérôme.
> >> > > > > > > > > > > Thanks!
> >> > > > > > > > > > >
> >> > > > > > > > > > > On Fri, Dec 4, 2015 at 2:40 AM, Jérôme LELEU <
> >> > > > leleuj@gmail.com
> >> > > > > >
> >> > > > > > > > wrote:
> >> > > > > > > > > > >
> >> > > > > > > > > > >> Hi,
> >> > > > > > > > > > >>
> >> > > > > > > > > > >> I will write how to configure the pac4j provider in
> >> the
> >> > > > > > > > documentation,
> >> > > > > > > > > > but
> >> > > > > > > > > > >> I can already give you some insights.
> >> > > > > > > > > > >>
> >> > > > > > > > > > >> My main goal is always to respect the key design
> >> > > principles
> >> > > > of
> >> > > > > > > pac4j
> >> > > > > > > > > > >> whatever the environment / framework in which it is
> >> > > > > implemented.
> >> > > > > > > For
> >> > > > > > > > > > Knox,
> >> > > > > > > > > > >> I'm pretty happy with the use of the j2e-pac4j
> >> library,
> >> > > > which
> >> > > > > > > means
> >> > > > > > > > > that
> >> > > > > > > > > > >> almost all the pac4j features are available,
> >> especially
> >> > > both
> >> > > > > > > direct
> >> > > > > > > > > and
> >> > > > > > > > > > >> indirect clients. So it can do what Shiro already
> does
> >> > but
> >> > > > > also,
> >> > > > > > > as
> >> > > > > > > > we
> >> > > > > > > > > > >> agreed together, supports remote authentications.
> >> > > > > > > > > > >>
> >> > > > > > > > > > >> It is only limited by what you can currently
> >> configure.
> >> > > And
> >> > > > > even
> >> > > > > > > > > > >> configuration is a pac4j feature as the CAS server
> has
> >> > the
> >> > > > > same
> >> > > > > > > > need.
> >> > > > > > > > > > >> Everything happens in this class:
> >> > > > > > > > > > >>
> >> > > > > > > > > > >>
> >> > > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java
> >> > > > > > > > > > >> ,
> >> > > > > > > > > > >> which allows you to configure Facebook, Twitter, a
> CAS
> >> > > > > server, a
> >> > > > > > > > SAML
> >> > > > > > > > > > IdP
> >> > > > > > > > > > >> or an OpenID Connect provider. All the provided
> >> > parameters
> >> > > > to
> >> > > > > > the
> >> > > > > > > > > pac4j
> >> > > > > > > > > > >> provider are put into a Map and the
> >> > > ConfigPropertiesFactory
> >> > > > is
> >> > > > > > > built
> >> > > > > > > > > > with
> >> > > > > > > > > > >> this Map to return the built client (=
> authentication
> >> > > > > > mechanism).
> >> > > > > > > > > > >>
> >> > > > > > > > > > >> You have one more specific option for Knox as a
> basic
> >> > > > > > > authentication
> >> > > > > > > > > > popup
> >> > > > > > > > > > >> where the username must match the password, you can
> >> > define
> >> > > > > that
> >> > > > > > > by:
> >> > > > > > > > > > >>
> >> > > > > > > > > > >> <param>
> >> > > > > > > > > > >> <name>clientName</name>
> >> > > > > > > > > > >> <value>testBasicAuth</value>
> >> > > > > > > > > > >> </param>
> >> > > > > > > > > > >>
> >> > > > > > > > > > >>
> >> > > > > > > > > > >> It's for testing only.
> >> > > > > > > > > > >>
> >> > > > > > > > > > >> For a CAS server:
> >> > > > > > > > > > >>
> >> > > > > > > > > > >> <param>
> >> > > > > > > > > > >> <name>cas.loginUrl</name>
> >> > > > > > > > > > >> <value>
> https://casserverpac4j.herokuapp.com/login
> >> > > </value>
> >> > > > > > > > > > >> </param>
> >> > > > > > > > > > >>
> >> > > > > > > > > > >>
> >> > > > > > > > > > >> Here are all the properties available for building
> >> > clients
> >> > > > > > (their
> >> > > > > > > > > > meaning
> >> > > > > > > > > > >> is obvious):
> >> > > > > > > > > > >>
> >> > > > > > > > > > >> facebook.id
> >> > > > > > > > > > >> facebook.secret
> >> > > > > > > > > > >> facebook.scope
> >> > > > > > > > > > >> facebook.fields
> >> > > > > > > > > > >> twitter.id
> >> > > > > > > > > > >> twitter.secret
> >> > > > > > > > > > >> saml.keystorePassword
> >> > > > > > > > > > >> saml.privateKeyPassword
> >> > > > > > > > > > >> saml.keystorePath
> >> > > > > > > > > > >> saml.identityProviderMetadataPath
> >> > > > > > > > > > >> saml.maximumAuthenticationLifetime
> >> > > > > > > > > > >> saml.serviceProviderEntityId
> >> > > > > > > > > > >> saml.serviceProviderMetadataPath
> >> > > > > > > > > > >> cas.loginUrl
> >> > > > > > > > > > >> cas.protocol
> >> > > > > > > > > > >> oidc.id
> >> > > > > > > > > > >> oidc.secret
> >> > > > > > > > > > >> oidc.discoveryUri
> >> > > > > > > > > > >> oidc.customParamKey1
> >> > > > > > > > > > >> oidc.customParamValue1
> >> > > > > > > > > > >>
> >> > > > > > > > > > >>
> >> > > > > > > > > > >> If you define multiple clients, the first one will
> be
> >> > used
> >> > > > for
> >> > > > > > > > > > >> authentication, but you can explicitly choose the
> >> client
> >> > > you
> >> > > > > > want
> >> > > > > > > to
> >> > > > > > > > > use
> >> > > > > > > > > > >> via the clientName parameter, assuming you want to
> >> > switch
> >> > > > from
> >> > > > > > > > client
> >> > > > > > > > > > >> depending on environment for example.
> >> > > > > > > > > > >>
> >> > > > > > > > > > >> So if you want to add some new authentication
> >> mechanism,
> >> > > you
> >> > > > > > must
> >> > > > > > > > > first
> >> > > > > > > > > > >> check that it is available in pac4j (if it's not,
> it's
> >> > > > another
> >> > > > > > > > > > discussion,
> >> > > > > > > > > > >> but generally, it is). Then, you'll need to upgrade
> >> the
> >> > > > > > > > > > >> ConfigPropertiesFactory by submitting a new pull
> >> request
> >> > > to
> >> > > > > the
> >> > > > > > > > pac4j
> >> > > > > > > > > > >> project (I can do it myself, but I'm sure you
> could do
> >> > > that
> >> > > > > > > easily),
> >> > > > > > > > > > >> finally wait for the new pac4j release and switch
> >> pac4j
> >> > > > > versions
> >> > > > > > > in
> >> > > > > > > > > Knox
> >> > > > > > > > > > >> to
> >> > > > > > > > > > >> benefit from the new feature.
> >> > > > > > > > > > >> The good thing is that if someone related to the
> CAS
> >> > > server
> >> > > > > does
> >> > > > > > > the
> >> > > > > > > > > > same
> >> > > > > > > > > > >> thing for CAS (in pac4j), you will automatically
> get
> >> it
> >> > > when
> >> > > > > > > you'll
> >> > > > > > > > > > >> upgrade
> >> > > > > > > > > > >> pac4j.
> >> > > > > > > > > > >>
> >> > > > > > > > > > >> To go even further, replacing LDAP Shiro
> >> authentication
> >> > is
> >> > > > > just
> >> > > > > > a
> >> > > > > > > > > matter
> >> > > > > > > > > > >> of
> >> > > > > > > > > > >> making pac4j LDAP authentication available via
> >> > > configuration
> >> > > > > > > > > parameters.
> >> > > > > > > > > > >>
> >> > > > > > > > > > >> I hope it was clear enough.
> >> > > > > > > > > > >>
> >> > > > > > > > > > >> Thanks.
> >> > > > > > > > > > >> Best regards,
> >> > > > > > > > > > >> Jérôme
> >> > > > > > > > > > >>
> >> > > > > > > > > > >>
> >> > > > > > > > > > >>
> >> > > > > > > > > > >>
> >> > > > > > > > > > >> 2015-12-03 20:45 GMT+01:00 larry mccay <
> >> > > > larry.mccay@gmail.com
> >> > > > > >:
> >> > > > > > > > > > >>
> >> > > > > > > > > > >> > Excellent!
> >> > > > > > > > > > >> >
> >> > > > > > > > > > >> > I will carve out some time to do code review.
> >> > > > > > > > > > >> > We will need to get some insights into how to go
> >> about
> >> > > > > > testing:
> >> > > > > > > > > > >> >
> >> > > > > > > > > > >> > * is the CAS server going to be available for
> >> testing?
> >> > > > > > > > > > >> > * what are the specific and generic/standard (if
> >> any)
> >> > > > > > > > authentication
> >> > > > > > > > > > >> > mechanisms available - for instance:
> >> > > > > > > > > > >> > - Facebook, Google, LinkedIn and CAS are
> >> specifics
> >> > > > > > > > > > >> > - OAuth 2, OpenID Connect, SAML are
> >> > > generic/standards
> >> > > > -
> >> > > > > > that
> >> > > > > > > > may
> >> > > > > > > > > > be
> >> > > > > > > > > > >> > used for the above specifics...
> >> > > > > > > > > > >> > * how do we test things other than CAS - in
> terms of
> >> > > > getting
> >> > > > > > > > > > >> credentials,
> >> > > > > > > > > > >> > configuration, etc
> >> > > > > > > > > > >> >
> >> > > > > > > > > > >> > We could certainly do this is phases as well.
> >> > > > > > > > > > >> >
> >> > > > > > > > > > >> > If you can enumerate the things that should work
> and
> >> > > > provide
> >> > > > > > > some
> >> > > > > > > > > > >> testing
> >> > > > > > > > > > >> > details for CAS or as many as possible and OpenID
> >> > > Connect
> >> > > > > then
> >> > > > > > > we
> >> > > > > > > > > can
> >> > > > > > > > > > >> test
> >> > > > > > > > > > >> > the specific implementations that you provide and
> >> > enable
> >> > > > the
> >> > > > > > > > testing
> >> > > > > > > > > > of
> >> > > > > > > > > > >> > another OpenID Connect effort that is in the
> works
> >> in
> >> > > the
> >> > > > > > > > community.
> >> > > > > > > > > > >> >
> >> > > > > > > > > > >> > I'm not sure whether we want to commit
> contributions
> >> > > that
> >> > > > > are
> >> > > > > > > > > > dependent
> >> > > > > > > > > > >> on
> >> > > > > > > > > > >> > snapshots - we certainly can't release with any
> such
> >> > > > > > > dependencies.
> >> > > > > > > > > > >> > I would hate to add a cleanup task to a release
> to
> >> > make
> >> > > > sure
> >> > > > > > > there
> >> > > > > > > > > are
> >> > > > > > > > > > >> no
> >> > > > > > > > > > >> > snapshots in there.
> >> > > > > > > > > > >> > We will probably wait until after the pac4j
> releases
> >> > to
> >> > > > > > commit.
> >> > > > > > > > > > >> >
> >> > > > > > > > > > >> > I am really happy that this integration is
> happening
> >> > and
> >> > > > > that
> >> > > > > > it
> >> > > > > > > > > went
> >> > > > > > > > > > >> > rather smoothly.
> >> > > > > > > > > > >> > These sorts of authentication protocols are
> complex
> >> > and
> >> > > I
> >> > > > > > think
> >> > > > > > > we
> >> > > > > > > > > > >> lined up
> >> > > > > > > > > > >> > pretty well overall.
> >> > > > > > > > > > >> >
> >> > > > > > > > > > >> > Thanks for your work!
> >> > > > > > > > > > >> >
> >> > > > > > > > > > >> > On Thu, Dec 3, 2015 at 2:28 PM, Jérôme LELEU <
> >> > > > > > leleuj@gmail.com>
> >> > > > > > > > > > wrote:
> >> > > > > > > > > > >> >
> >> > > > > > > > > > >> > > Hi,
> >> > > > > > > > > > >> > >
> >> > > > > > > > > > >> > > I just sync'ed with master, cleaned
> dependencies
> >> and
> >> > > > added
> >> > > > > > > > missing
> >> > > > > > > > > > >> > > Javadocs. Everything works correctly now. Many
> >> > thanks.
> >> > > > > > > > > > >> > >
> >> > > > > > > > > > >> > > The pull request is ready for a full code
> review:
> >> > > > > > > > > > >> > > https://github.com/apache/knox/pull/2
> >> > > > > > > > > > >> > >
> >> > > > > > > > > > >> > > I'll write the documentation after the pac4j
> >> > releases
> >> > > (I
> >> > > > > > hope
> >> > > > > > > > next
> >> > > > > > > > > > >> week).
> >> > > > > > > > > > >> > >
> >> > > > > > > > > > >> > > Thanks.
> >> > > > > > > > > > >> > > Best regards,
> >> > > > > > > > > > >> > > Jérôme
> >> > > > > > > > > > >> > >
> >> > > > > > > > > > >> > >
> >> > > > > > > > > > >> > > 2015-12-02 19:18 GMT+01:00 larry mccay <
> >> > > > > > larry.mccay@gmail.com
> >> > > > > > > >:
> >> > > > > > > > > > >> > >
> >> > > > > > > > > > >> > > > Fixed in
> >> > > > https://issues.apache.org/jira/browse/KNOX-636
> >> > > > > .
> >> > > > > > > > > > >> > > >
> >> > > > > > > > > > >> > > > On Wed, Dec 2, 2015 at 12:42 PM, larry mccay
> <
> >> > > > > > > > > > larry.mccay@gmail.com
> >> > > > > > > > > > >> >
> >> > > > > > > > > > >> > > > wrote:
> >> > > > > > > > > > >> > > >
> >> > > > > > > > > > >> > > > > Sure - I can file a JIRA and commit a fix.
> >> > > > > > > > > > >> > > > >
> >> > > > > > > > > > >> > > > > The secret generation should be done in one
> >> > > instance
> >> > > > > and
> >> > > > > > > > > > >> replicated
> >> > > > > > > > > > >> > > > across
> >> > > > > > > > > > >> > > > > others.
> >> > > > > > > > > > >> > > > > This replication/management of the
> credential
> >> > > stores
> >> > > > > is
> >> > > > > > > > > outside
> >> > > > > > > > > > of
> >> > > > > > > > > > >> > the
> >> > > > > > > > > > >> > > > > scope of Knox itself as of now.
> >> > > > > > > > > > >> > > > >
> >> > > > > > > > > > >> > > > > Documentation is done in markdown and is
> >> > > > contributing
> >> > > > > > > > details
> >> > > > > > > > > > are
> >> > > > > > > > > > >> > > > > available at:
> >> > > > > > > > > > >> > > > >
> >> > > > > > > > > > >> > > >
> >> > > > > > > > > > >> > >
> >> > > > > > > > > > >> >
> >> > > > > > > > > > >>
> >> > > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
> >> > > > > > > > > > >> > > > >
> >> > > > > > > > > > >> > > > > Which should give you a general idea.
> >> > > > > > > > > > >> > > > >
> >> > > > > > > > > > >> > > > > Find an example like: ./trunk/books/0.7.0/
> >> > > > > > > > > > >> > > config_preauth_sso_provider.md
> >> > > > > > > > > > >> > > > >
> >> > > > > > > > > > >> > > > > For an example of typical content and
> format.
> >> > > > > > > > > > >> > > > >
> >> > > > > > > > > > >> > > > > Here is how that example renders:
> >> > > > > > > > > > >> > > > >
> >> > > > > > > > > > >> > > >
> >> > > > > > > > > > >> > >
> >> > > > > > > > > > >> >
> >> > > > > > > > > > >>
> >> > > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
> >> > > > > > > > > > >> > > > >
> >> > > > > > > > > > >> > > > > You'll need to tie it into the rest of the
> >> book
> >> > -
> >> > > > just
> >> > > > > > > grep
> >> > > > > > > > > for
> >> > > > > > > > > > >> where
> >> > > > > > > > > > >> > > > that
> >> > > > > > > > > > >> > > > > filename is referenced.
> >> > > > > > > > > > >> > > > > To test how it renders build the site with:
> >> > "ant"
> >> > > > and
> >> > > > > > note
> >> > > > > > > > the
> >> > > > > > > > > > >> url to
> >> > > > > > > > > > >> > > the
> >> > > > > > > > > > >> > > > > 0.7.0 book.
> >> > > > > > > > > > >> > > > >
> >> > > > > > > > > > >> > > > >
> >> > > > > > > > > > >> > > > > On Wed, Dec 2, 2015 at 12:12 PM, Jérôme
> LELEU
> >> <
> >> > > > > > > > > leleuj@gmail.com
> >> > > > > > > > > > >
> >> > > > > > > > > > >> > > wrote:
> >> > > > > > > > > > >> > > > >
> >> > > > > > > > > > >> > > > >> Hi,
> >> > > > > > > > > > >> > > > >>
> >> > > > > > > > > > >> > > > >> Why it doesn't work for pac4j while it
> works
> >> > for
> >> > > > > others
> >> > > > > > > is
> >> > > > > > > > a
> >> > > > > > > > > > bit
> >> > > > > > > > > > >> > > strange
> >> > > > > > > > > > >> > > > >> to
> >> > > > > > > > > > >> > > > >> me, but if you have the patch in front of
> >> your
> >> > > > eyes,
> >> > > > > > I'd
> >> > > > > > > > > rather
> >> > > > > > > > > > >> > prefer
> >> > > > > > > > > > >> > > > you
> >> > > > > > > > > > >> > > > >> to commit it. In all cases, I'll sync with
> >> the
> >> > > > > master.
> >> > > > > > > > > > >> > > > >>
> >> > > > > > > > > > >> > > > >> There was one question you didn't answer
> >> > > > previously:
> >> > > > > is
> >> > > > > > > the
> >> > > > > > > > > > >> password
> >> > > > > > > > > > >> > > > >> generated for the pac4j provider the same
> >> > across
> >> > > > all
> >> > > > > > > > gateway
> >> > > > > > > > > > >> > > instances?
> >> > > > > > > > > > >> > > > >> Because I expect to have the same value
> as I
> >> > use
> >> > > it
> >> > > > > to
> >> > > > > > > > > encrypt
> >> > > > > > > > > > /
> >> > > > > > > > > > >> > > decrypt
> >> > > > > > > > > > >> > > > >> data.
> >> > > > > > > > > > >> > > > >>
> >> > > > > > > > > > >> > > > >> I will add the Javadoc. After that, you
> can
> >> > > review
> >> > > > > the
> >> > > > > > > pull
> >> > > > > > > > > > >> request
> >> > > > > > > > > > >> > > more
> >> > > > > > > > > > >> > > > >> completely.
> >> > > > > > > > > > >> > > > >>
> >> > > > > > > > > > >> > > > >> What do you expect for the documentation?
> >> > > > > > > > > > >> > > > >>
> >> > > > > > > > > > >> > > > >> Notice that pac4j dependencies are still
> >> > > snapshots,
> >> > > > > but
> >> > > > > > > > they
> >> > > > > > > > > > >> will be
> >> > > > > > > > > > >> > > > >> released in a week or two.
> >> > > > > > > > > > >> > > > >>
> >> > > > > > > > > > >> > > > >> Thanks.
> >> > > > > > > > > > >> > > > >> Best regards,
> >> > > > > > > > > > >> > > > >> Jérôme
> >> > > > > > > > > > >> > > > >>
> >> > > > > > > > > > >> > > > >>
> >> > > > > > > > > > >> > > > >> 2015-12-02 17:51 GMT+01:00 larry mccay <
> >> > > > > > > > > larry.mccay@gmail.com
> >> > > > > > > > > > >:
> >> > > > > > > > > > >> > > > >>
> >> > > > > > > > > > >> > > > >> > Jérôme -
> >> > > > > > > > > > >> > > > >> >
> >> > > > > > > > > > >> > > > >> > If you would like to add that change as
> >> part
> >> > of
> >> > > > > your
> >> > > > > > > > patch
> >> > > > > > > > > or
> >> > > > > > > > > > >> as a
> >> > > > > > > > > > >> > > > >> > separately filed JIRA to fix a bug that
> >> would
> >> > > > > > certainly
> >> > > > > > > > be
> >> > > > > > > > > > >> > welcomed.
> >> > > > > > > > > > >> > > > >> > Otherwise, I can do it.
> >> > > > > > > > > > >> > > > >> >
> >> > > > > > > > > > >> > > > >> > Let me know.
> >> > > > > > > > > > >> > > > >> >
> >> > > > > > > > > > >> > > > >> > thanks,
> >> > > > > > > > > > >> > > > >> >
> >> > > > > > > > > > >> > > > >> > --larry
> >> > > > > > > > > > >> > > > >> >
> >> > > > > > > > > > >> > > > >> > On Wed, Dec 2, 2015 at 11:44 AM, larry
> >> mccay
> >> > <
> >> > > > > > > > > > >> > larry.mccay@gmail.com
> >> > > > > > > > > > >> > > >
> >> > > > > > > > > > >> > > > >> > wrote:
> >> > > > > > > > > > >> > > > >> >
> >> > > > > > > > > > >> > > > >> > > Okay - I had to add an override of
> >> > > > > > getUserPrincipal()
> >> > > > > > > > to
> >> > > > > > > > > > the
> >> > > > > > > > > > >> > > > >> > >
> IdentityAsserterHttpServletRequestWrapper
> >> > and
> >> > > > > > return
> >> > > > > > > > the
> >> > > > > > > > > > >> member
> >> > > > > > > > > > >> > > > >> variable
> >> > > > > > > > > > >> > > > >> > > username and it works like a charm.
> >> > > > > > > > > > >> > > > >> > >
> >> > > > > > > > > > >> > > > >> > > Why I haven't seen this same behavior
> >> with
> >> > > > other
> >> > > > > > > > > providers
> >> > > > > > > > > > >> is a
> >> > > > > > > > > > >> > > bit
> >> > > > > > > > > > >> > > > >> of a
> >> > > > > > > > > > >> > > > >> > > mystery but they must be adding other
> >> > > wrappers
> >> > > > > that
> >> > > > > > > > > handle
> >> > > > > > > > > > >> it.
> >> > > > > > > > > > >> > > > >> > > This is quite cool, Jérôme!
> >> > > > > > > > > > >> > > > >> > >
> >> > > > > > > > > > >> > > > >> > > On Wed, Dec 2, 2015 at 10:41 AM, larry
> >> > mccay
> >> > > <
> >> > > > > > > > > > >> > > larry.mccay@gmail.com
> >> > > > > > > > > > >> > > > >
> >> > > > > > > > > > >> > > > >> > > wrote:
> >> > > > > > > > > > >> > > > >> > >
> >> > > > > > > > > > >> > > > >> > >> That was it - thanks!
> >> > > > > > > > > > >> > > > >> > >>
> >> > > > > > > > > > >> > > > >> > >> On Wed, Dec 2, 2015 at 10:20 AM,
> Jérôme
> >> > > LELEU
> >> > > > <
> >> > > > > > > > > > >> > leleuj@gmail.com>
> >> > > > > > > > > > >> > > > >> wrote:
> >> > > > > > > > > > >> > > > >> > >>
> >> > > > > > > > > > >> > > > >> > >>> This is my exact command line: mvn
> >> > > -Prelease
> >> > > > > > clean
> >> > > > > > > > > > install
> >> > > > > > > > > > >> > > > >> -DskipTests
> >> > > > > > > > > > >> > > > >> > >>>
> >> > > > > > > > > > >> > > > >> > >>> You use an internal Maven
> repository to
> >> > > fetch
> >> > > > > > > > > > dependencies
> >> > > > > > > > > > >> > from
> >> > > > > > > > > > >> > > > >> > internet:
> >> > > > > > > > > > >> > > > >> > >>>
> >> > > > > > > > > > >> > >
> >> > > > > > > >
> >> > > http://nexus-private.hortonworks.com/nexus/content/groups/public/
> >> > > > > > > > > > >> > > > >> > >>>
> >> > > > > > > > > > >> > > > >> > >>> Does this repository have access to
> the
> >> > > > remote
> >> > > > > > > > > Snapshots
> >> > > > > > > > > > >> > > Sonatype
> >> > > > > > > > > > >> > > > >> repo?
> >> > > > > > > > > > >> > > > >> > >>>
> >> > > > > > > > > > >> > > > >> > >>>
> >> > > > > > > > > > >> > > > >> > >>>
> >> > > > > > > > > > >> > > > >> > >>> 2015-12-02 16:16 GMT+01:00 larry
> mccay
> >> <
> >> > > > > > > > > > >> larry.mccay@gmail.com
> >> > > > > > > > > > >> > >:
> >> > > > > > > > > > >> > > > >> > >>>
> >> > > > > > > > > > >> > > > >> > >>> > hmmm - I used:
> >> > > > > > > > > > >> > > > >> > >>> >
> >> > > > > > > > > > >> > > > >> > >>> > mvn clean install -DskipTests=true
> >> > > > -Prelease
> >> > > > > > > > > > >> > > > >> > >>> >
> >> > > > > > > > > > >> > > > >> > >>> > The repository entry is in there
> >> > already.
> >> > > > > > > > > > >> > > > >> > >>> > No worky.
> >> > > > > > > > > > >> > > > >> > >>> >
> >> > > > > > > > > > >> > > > >> > >>> > On Wed, Dec 2, 2015 at 10:12 AM,
> >> Jérôme
> >> > > > > LELEU <
> >> > > > > > > > > > >> > > leleuj@gmail.com
> >> > > > > > > > > > >> > > > >
> >> > > > > > > > > > >> > > > >> > >>> wrote:
> >> > > > > > > > > > >> > > > >> > >>> >
> >> > > > > > > > > > >> > > > >> > >>> > > Hi,
> >> > > > > > > > > > >> > > > >> > >>> > >
> >> > > > > > > > > > >> > > > >> > >>> > > You need the j2e-pac4j
> dependencies
> >> > as
> >> > > > well
> >> > > > > > as
> >> > > > > > > > the
> >> > > > > > > > > > >> pac4j-*
> >> > > > > > > > > > >> > > > >> > >>> dependencies,
> >> > > > > > > > > > >> > > > >> > >>> > > but you don't need to build them
> >> > > locally
> >> > > > > > > > > (hopefully).
> >> > > > > > > > > > >> > > > >> > >>> > >
> >> > > > > > > > > > >> > > > >> > >>> > > But you need a dependency on the
> >> > > Sonatype
> >> > > > > > > > snapshots
> >> > > > > > > > > > >> > > repository
> >> > > > > > > > > > >> > > > >> > >>> (where the
> >> > > > > > > > > > >> > > > >> > >>> > > snapshot versions are hosted),
> >> which
> >> > is
> >> > > > > added
> >> > > > > > > for
> >> > > > > > > > > > >> Maven in
> >> > > > > > > > > > >> > > the
> >> > > > > > > > > > >> > > > >> root
> >> > > > > > > > > > >> > > > >> > >>> > > pom.xml:
> >> > > > > > > > > > >> > > > >> > >>> > >
> >> > > > > > > > > > >> > > > >> > >>> > >
> >> > > > > > > > > > >> > > > >> > >>> >
> >> > > > > > > > > > >> > > > >> > >>>
> >> > > > > > > > > > >> > > > >> >
> >> > > > > > > > > > >> > > > >>
> >> > > > > > > > > > >> > > >
> >> > > > > > > > > > >> > >
> >> > > > > > > > > > >> >
> >> > > > > > > > > > >>
> >> > > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> >> > > > > > > > > > >> > > > >> > >>> > >
> >> > > > > > > > > > >> > > > >> > >>> > > If you use Ant for the build,
> there
> >> > is
> >> > > > > maybe
> >> > > > > > a
> >> > > > > > > > > glitch
> >> > > > > > > > > > >> to
> >> > > > > > > > > > >> > > find
> >> > > > > > > > > > >> > > > >> the
> >> > > > > > > > > > >> > > > >> > >>> > Sonatype
> >> > > > > > > > > > >> > > > >> > >>> > > Maven repo.
> >> > > > > > > > > > >> > > > >> > >>> > >
> >> > > > > > > > > > >> > > > >> > >>> > > Thanks.
> >> > > > > > > > > > >> > > > >> > >>> > > Best regards,
> >> > > > > > > > > > >> > > > >> > >>> > > Jérôme
> >> > > > > > > > > > >> > > > >> > >>> > >
> >> > > > > > > > > > >> > > > >> > >>> > >
> >> > > > > > > > > > >> > > > >> > >>> > > 2015-12-02 16:06 GMT+01:00 larry
> >> > mccay
> >> > > <
> >> > > > > > > > > > >> > > larry.mccay@gmail.com
> >> > > > > > > > > > >> > > > >:
> >> > > > > > > > > > >> > > > >> > >>> > >
> >> > > > > > > > > > >> > > > >> > >>> > > > 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.mccay@gmail.com>
> >> > > > > > > > > > >> > > > >> > >>> > > > wrote:
> >> > > > > > > > > > >> > > > >> > >>> > > >
> >> > > > > > > > > > >> > > > >> > >>> > > > >
> gateway-provider-security-pac4j
> >> > > > doesn't
> >> > > > > > > > build -
> >> > > > > > > > > > do
> >> > > > > > > > > > >> you
> >> > > > > > > > > > >> > > > have
> >> > > > > > > > > > >> > > > >> a
> >> > > > > > > > > > >> > > > >> > >>> pending
> >> > > > > > > > > > >> > > > >> > >>> > > > > change for your pom.xml or
> >> > > something?
> >> > > > > > > > > > >> > > > >> > >>> > > > >
> >> > > > > > > > > > >> > > > >> > >>> >
> >> > > > > > > > > > >> > > > >> > >>>
> >> > > > > > > > > > >> > > > >> > >>
> >> > > > > > > > > > >> > > > >> > >>
> >> > > > > > > > > > >> > > > >> > >
> >> > > > > > > > > > >> > > > >> >
> >> > > > > > > > > > >> > > > >>
> >> > > > > > > > > > >> > > > >
> >> > > > > > > > > > >> > > > >
> >> > > > > > > > > > >> > > >
> >> > > > > > > > > > >> > >
> >> > > > > > > > > > >> >
> >> > > > > > > > > > >>
> >> > > > > > > > > > >
> >> > > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>
Re: pac4j and Apache Knox
Posted by Kevin Minder <ke...@hortonworks.com>.
From my perspective it would be ideal if there were some automatable functional tests for this. I’m not advocating that these be something included in “mvn clean install” as that is running too long as it is. Given that I don’t have as much context as Larry, I have some questions about what this would take. Lets say we had permission to hit https://casserverpac4j.herokuapp.com/login as part of some low frequency automated tests (e.g. Once nighty). What static credentials and other test automation infrastructure would need to be implemented in support of this? I understand that the test suite would require at a minimum
1) a test driver
2) a protected mock UI and
3) an appropriately configured Knox
4) a profile enabled maven module
5) an Apache jenkins job
but I’m sure I’m missing other things. I’m certainly willing to help setup the skeleton infrastructure (e.g. test driver, mock UI, maven module, jenkins job)
On 1/5/16, 2:54 PM, "larry mccay" <la...@gmail.com> wrote:
>Okay, very good.
>I've used TestShib for the picketlink provider - thanks for the pointers!
>
>On Tue, Jan 5, 2016 at 1:38 PM, Jérôme LELEU <le...@gmail.com> wrote:
>
>> The online CAS server (https://casserverpac4j.herokuapp.com/login) uses
>> the
>> CAS protocol. SAML support can be tested using some online IdP like Okta,
>> TestShib, OpenFeide, Ssocircle...
>>
>>
>> 2016-01-05 17:32 GMT+01:00 larry mccay <la...@gmail.com>:
>>
>> > Great - thanks for that pointer!
>> >
>> > I will take a look at that and help drive the release related testing.
>> > Merge testing will be gated on CAS server (is this SAML or CAS protocol?)
>> > and testBasicAuth.
>> >
>> > On Tue, Jan 5, 2016 at 10:52 AM, Jérôme LELEU <le...@gmail.com> wrote:
>> >
>> > > Hi,
>> > >
>> > > Glad to hear back from you!
>> > >
>> > > The core pac4j project is fully tested by unit tests (and some
>> > integration
>> > > tests I run for major version), then all pac4j implementations are each
>> > > tested by the appropriate demo: j2e-pac4j-demo tests j2e-pac4j,
>> > > spring-webmvc-pac4j-demo tests spring-webmvc-pac4j, etc.
>> > >
>> > > So if you take a look at:
>> > >
>> > >
>> >
>> https://github.com/pac4j/j2e-pac4j-demo/blob/master/src/main/java/org/pac4j/demo/j2e/config/DemoConfigFactory.java#L27
>> > > (for example), you have all the required information to test.
>> > >
>> > > I can do that on my own, but it can be good for the Knox community to
>> > start
>> > > working / testing the pac4j support. It's up to yoy.
>> > >
>> > > Thanks.
>> > > Best regards,
>> > > Jérôme
>> > >
>> > >
>> > > 2016-01-05 16:11 GMT+01:00 larry mccay <la...@gmail.com>:
>> > >
>> > > > Hello Jérôme -
>> > > >
>> > > > Happy New Year!
>> > > >
>> > > > I am going to start reviewing your updates today, hopefully.
>> > > > I was thinking that we need to start discussions on what the key
>> > usecases
>> > > > are and how to go about testing them.
>> > > > We can certainly test the testBasicAuth and against the hosted CAS
>> > server
>> > > > but what about FB, openid, OAuth, etc?
>> > > >
>> > > > I'm not sure that FB would be a key feature but OpenID Connect and
>> > OAuth
>> > > > would be - as is SAML.
>> > > > I think CAS buys us SAML testing - assuming that the configuration of
>> > the
>> > > > hosted server is actually a SAML 2 instance.
>> > > >
>> > > > What about the others?
>> > > >
>> > > > I don't know that we need to be able to test them all before merge
>> but
>> > > some
>> > > > sort of manual verification would be great.
>> > > > We would need to be able to test them before the next release which
>> > would
>> > > > be featuring the pac4j functionality.
>> > > >
>> > > > Maybe you can describe how you go about testing such things for the
>> > pac4j
>> > > > project itself?
>> > > >
>> > > > thanks,
>> > > >
>> > > > --larry
>> > > >
>> > > >
>> > > > On Tue, Jan 5, 2016 at 9:55 AM, Jérôme LELEU <le...@gmail.com>
>> wrote:
>> > > >
>> > > > > Hi,
>> > > > >
>> > > > > Happy new year!
>> > > > >
>> > > > > A few days ago, I updated my patch of the pac4j gateway provider
>> > > > according
>> > > > > to all comments on https://issues.apache.org/jira/browse/KNOX-641
>> as
>> > > > well
>> > > > > as the documentation on KNOX-642.
>> > > > >
>> > > > > Is everything ok for the merge?
>> > > > >
>> > > > > Thanks.
>> > > > > Best regards,
>> > > > > Jérôme
>> > > > >
>> > > > >
>> > > > > 2015-12-14 15:28 GMT+01:00 larry mccay <la...@gmail.com>:
>> > > > >
>> > > > > > Hi Jérôme -
>> > > > > >
>> > > > > > Not sure if you saw but I added review comments to KNOX-641.
>> > > > > >
>> > > > > > I think that we need to determine whether we want the
>> testBasicAuth
>> > > in
>> > > > > the
>> > > > > > provider itself.
>> > > > > >
>> > > > > > Let's follow up on the JIRA.
>> > > > > >
>> > > > > > thanks,
>> > > > > >
>> > > > > > --larry
>> > > > > >
>> > > > > > On Fri, Dec 11, 2015 at 8:44 AM, Jérôme LELEU <le...@gmail.com>
>> > > > wrote:
>> > > > > >
>> > > > > > > Hi,
>> > > > > > >
>> > > > > > > No problem. It can go into a version 0.8.0 if needed. The truth
>> > is
>> > > > that
>> > > > > > > there is only one change outside the new pac4j module, so I
>> think
>> > > > risks
>> > > > > > are
>> > > > > > > extremly limited.
>> > > > > > >
>> > > > > > > Just let met know.
>> > > > > > >
>> > > > > > > Thanks.
>> > > > > > > Best regards,
>> > > > > > > Jérôme
>> > > > > > >
>> > > > > > >
>> > > > > > > 2015-12-11 14:23 GMT+01:00 larry mccay <larry.mccay@gmail.com
>> >:
>> > > > > > >
>> > > > > > > > Hi Jérôme -
>> > > > > > > >
>> > > > > > > > I have unfortunately not had a chance to pull, review and
>> test
>> > it
>> > > > yet
>> > > > > > and
>> > > > > > > > have intended to do that today.
>> > > > > > > > I apologize for the delay.
>> > > > > > > >
>> > > > > > > > I was actually thinking that this would go into a follow up
>> > > release
>> > > > > > that
>> > > > > > > we
>> > > > > > > > would try and get done rapidly after the 0.7.0 release but we
>> > can
>> > > > > > discuss
>> > > > > > > > the target and its chances of destabilizing 0.7.0.
>> > > > > > > >
>> > > > > > > > I believe that it is rather self-contained with only a few
>> > > changes
>> > > > to
>> > > > > > > > external modules.
>> > > > > > > >
>> > > > > > > > Opening the JIRAs is perfect and I was going to do that once
>> I
>> > > > > started
>> > > > > > > the
>> > > > > > > > review.
>> > > > > > > >
>> > > > > > > > Let's continue review comments and collaboration on those
>> > JIRAs.
>> > > > > > > > I will add you to the contributors list so that we can assign
>> > > them
>> > > > to
>> > > > > > > you.
>> > > > > > > >
>> > > > > > > > Thank you for your contributions and your patience, Jérôme!
>> > > > > > > >
>> > > > > > > > --larry
>> > > > > > > >
>> > > > > > > > On Fri, Dec 11, 2015 at 3:00 AM, Jérôme LELEU <
>> > leleuj@gmail.com>
>> > > > > > wrote:
>> > > > > > > >
>> > > > > > > > > Hi,
>> > > > > > > > >
>> > > > > > > > > I didn't get any new feedback on the pull request so I
>> assume
>> > > > > > > everything
>> > > > > > > > is
>> > > > > > > > > ok from your point of view.
>> > > > > > > > >
>> > > > > > > > > I released pac4j v1.8.1 and j2e-pac4j v1.2.1 so I updated
>> the
>> > > > pull
>> > > > > > > > request
>> > > > > > > > > to use them and successfully re-tested everything.
>> > > > > > > > >
>> > > > > > > > > I opened KNOX-641 and submitted the corresponding patch.
>> > > > > > > > >
>> > > > > > > > > I also wrote the documentation, opened KNOX-642 and
>> submitted
>> > > the
>> > > > > > > > > corresponding patch (just to let you know that it doesn't
>> > work
>> > > > out
>> > > > > of
>> > > > > > > the
>> > > > > > > > > box in Windows, I had to replace mvn.bat by mvn.cmd to make
>> > ant
>> > > > > > work).
>> > > > > > > > >
>> > > > > > > > > Even if the branch 0.7.0 has already been created, I
>> assumed
>> > > this
>> > > > > new
>> > > > > > > > pac4j
>> > > > > > > > > provider will go into this version 0.7.0 (dependency on the
>> > > > > > > > 0.7.0-SNAPSHOT
>> > > > > > > > > parent version).
>> > > > > > > > >
>> > > > > > > > > Just let me know if everything is ok and when it's goind to
>> > be
>> > > > > > merged.
>> > > > > > > > >
>> > > > > > > > > Thanks.
>> > > > > > > > > Best regards,
>> > > > > > > > > Jérôme
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > 2015-12-04 14:20 GMT+01:00 larry mccay <
>> > larry.mccay@gmail.com
>> > > >:
>> > > > > > > > >
>> > > > > > > > > > That ability to configure multiple mechanisms based on
>> > > > clientName
>> > > > > > is
>> > > > > > > > > really
>> > > > > > > > > > interesting for Knox.
>> > > > > > > > > > Currently, we require separate topologies per
>> > authentication
>> > > > > > > mechanism.
>> > > > > > > > > > The ability to configure them all in one is really great.
>> > > > > > > > > >
>> > > > > > > > > > We would need to think through the best way to provide
>> the
>> > > > > > clientName
>> > > > > > > > > > parameter.
>> > > > > > > > > > Since this is targeting KnoxSSO it can actually be added
>> to
>> > > the
>> > > > > > > > > providerURL
>> > > > > > > > > > used to redirect from the participating application.
>> > > > > > > > > > Regardless of the authentication mechanism used each
>> > > > application
>> > > > > > will
>> > > > > > > > > still
>> > > > > > > > > > get the same JWT based cookie.
>> > > > > > > > > >
>> > > > > > > > > > I think that should work really nicely.
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > On Fri, Dec 4, 2015 at 7:17 AM, larry mccay <
>> > > > > larry.mccay@gmail.com
>> > > > > > >
>> > > > > > > > > wrote:
>> > > > > > > > > >
>> > > > > > > > > > > Excellent, Jérôme.
>> > > > > > > > > > > Thanks!
>> > > > > > > > > > >
>> > > > > > > > > > > On Fri, Dec 4, 2015 at 2:40 AM, Jérôme LELEU <
>> > > > leleuj@gmail.com
>> > > > > >
>> > > > > > > > wrote:
>> > > > > > > > > > >
>> > > > > > > > > > >> Hi,
>> > > > > > > > > > >>
>> > > > > > > > > > >> I will write how to configure the pac4j provider in
>> the
>> > > > > > > > documentation,
>> > > > > > > > > > but
>> > > > > > > > > > >> I can already give you some insights.
>> > > > > > > > > > >>
>> > > > > > > > > > >> My main goal is always to respect the key design
>> > > principles
>> > > > of
>> > > > > > > pac4j
>> > > > > > > > > > >> whatever the environment / framework in which it is
>> > > > > implemented.
>> > > > > > > For
>> > > > > > > > > > Knox,
>> > > > > > > > > > >> I'm pretty happy with the use of the j2e-pac4j
>> library,
>> > > > which
>> > > > > > > means
>> > > > > > > > > that
>> > > > > > > > > > >> almost all the pac4j features are available,
>> especially
>> > > both
>> > > > > > > direct
>> > > > > > > > > and
>> > > > > > > > > > >> indirect clients. So it can do what Shiro already does
>> > but
>> > > > > also,
>> > > > > > > as
>> > > > > > > > we
>> > > > > > > > > > >> agreed together, supports remote authentications.
>> > > > > > > > > > >>
>> > > > > > > > > > >> It is only limited by what you can currently
>> configure.
>> > > And
>> > > > > even
>> > > > > > > > > > >> configuration is a pac4j feature as the CAS server has
>> > the
>> > > > > same
>> > > > > > > > need.
>> > > > > > > > > > >> Everything happens in this class:
>> > > > > > > > > > >>
>> > > > > > > > > > >>
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java
>> > > > > > > > > > >> ,
>> > > > > > > > > > >> which allows you to configure Facebook, Twitter, a CAS
>> > > > > server, a
>> > > > > > > > SAML
>> > > > > > > > > > IdP
>> > > > > > > > > > >> or an OpenID Connect provider. All the provided
>> > parameters
>> > > > to
>> > > > > > the
>> > > > > > > > > pac4j
>> > > > > > > > > > >> provider are put into a Map and the
>> > > ConfigPropertiesFactory
>> > > > is
>> > > > > > > built
>> > > > > > > > > > with
>> > > > > > > > > > >> this Map to return the built client (= authentication
>> > > > > > mechanism).
>> > > > > > > > > > >>
>> > > > > > > > > > >> You have one more specific option for Knox as a basic
>> > > > > > > authentication
>> > > > > > > > > > popup
>> > > > > > > > > > >> where the username must match the password, you can
>> > define
>> > > > > that
>> > > > > > > by:
>> > > > > > > > > > >>
>> > > > > > > > > > >> <param>
>> > > > > > > > > > >> <name>clientName</name>
>> > > > > > > > > > >> <value>testBasicAuth</value>
>> > > > > > > > > > >> </param>
>> > > > > > > > > > >>
>> > > > > > > > > > >>
>> > > > > > > > > > >> It's for testing only.
>> > > > > > > > > > >>
>> > > > > > > > > > >> For a CAS server:
>> > > > > > > > > > >>
>> > > > > > > > > > >> <param>
>> > > > > > > > > > >> <name>cas.loginUrl</name>
>> > > > > > > > > > >> <value>https://casserverpac4j.herokuapp.com/login
>> > > </value>
>> > > > > > > > > > >> </param>
>> > > > > > > > > > >>
>> > > > > > > > > > >>
>> > > > > > > > > > >> Here are all the properties available for building
>> > clients
>> > > > > > (their
>> > > > > > > > > > meaning
>> > > > > > > > > > >> is obvious):
>> > > > > > > > > > >>
>> > > > > > > > > > >> facebook.id
>> > > > > > > > > > >> facebook.secret
>> > > > > > > > > > >> facebook.scope
>> > > > > > > > > > >> facebook.fields
>> > > > > > > > > > >> twitter.id
>> > > > > > > > > > >> twitter.secret
>> > > > > > > > > > >> saml.keystorePassword
>> > > > > > > > > > >> saml.privateKeyPassword
>> > > > > > > > > > >> saml.keystorePath
>> > > > > > > > > > >> saml.identityProviderMetadataPath
>> > > > > > > > > > >> saml.maximumAuthenticationLifetime
>> > > > > > > > > > >> saml.serviceProviderEntityId
>> > > > > > > > > > >> saml.serviceProviderMetadataPath
>> > > > > > > > > > >> cas.loginUrl
>> > > > > > > > > > >> cas.protocol
>> > > > > > > > > > >> oidc.id
>> > > > > > > > > > >> oidc.secret
>> > > > > > > > > > >> oidc.discoveryUri
>> > > > > > > > > > >> oidc.customParamKey1
>> > > > > > > > > > >> oidc.customParamValue1
>> > > > > > > > > > >>
>> > > > > > > > > > >>
>> > > > > > > > > > >> If you define multiple clients, the first one will be
>> > used
>> > > > for
>> > > > > > > > > > >> authentication, but you can explicitly choose the
>> client
>> > > you
>> > > > > > want
>> > > > > > > to
>> > > > > > > > > use
>> > > > > > > > > > >> via the clientName parameter, assuming you want to
>> > switch
>> > > > from
>> > > > > > > > client
>> > > > > > > > > > >> depending on environment for example.
>> > > > > > > > > > >>
>> > > > > > > > > > >> So if you want to add some new authentication
>> mechanism,
>> > > you
>> > > > > > must
>> > > > > > > > > first
>> > > > > > > > > > >> check that it is available in pac4j (if it's not, it's
>> > > > another
>> > > > > > > > > > discussion,
>> > > > > > > > > > >> but generally, it is). Then, you'll need to upgrade
>> the
>> > > > > > > > > > >> ConfigPropertiesFactory by submitting a new pull
>> request
>> > > to
>> > > > > the
>> > > > > > > > pac4j
>> > > > > > > > > > >> project (I can do it myself, but I'm sure you could do
>> > > that
>> > > > > > > easily),
>> > > > > > > > > > >> finally wait for the new pac4j release and switch
>> pac4j
>> > > > > versions
>> > > > > > > in
>> > > > > > > > > Knox
>> > > > > > > > > > >> to
>> > > > > > > > > > >> benefit from the new feature.
>> > > > > > > > > > >> The good thing is that if someone related to the CAS
>> > > server
>> > > > > does
>> > > > > > > the
>> > > > > > > > > > same
>> > > > > > > > > > >> thing for CAS (in pac4j), you will automatically get
>> it
>> > > when
>> > > > > > > you'll
>> > > > > > > > > > >> upgrade
>> > > > > > > > > > >> pac4j.
>> > > > > > > > > > >>
>> > > > > > > > > > >> To go even further, replacing LDAP Shiro
>> authentication
>> > is
>> > > > > just
>> > > > > > a
>> > > > > > > > > matter
>> > > > > > > > > > >> of
>> > > > > > > > > > >> making pac4j LDAP authentication available via
>> > > configuration
>> > > > > > > > > parameters.
>> > > > > > > > > > >>
>> > > > > > > > > > >> I hope it was clear enough.
>> > > > > > > > > > >>
>> > > > > > > > > > >> Thanks.
>> > > > > > > > > > >> Best regards,
>> > > > > > > > > > >> Jérôme
>> > > > > > > > > > >>
>> > > > > > > > > > >>
>> > > > > > > > > > >>
>> > > > > > > > > > >>
>> > > > > > > > > > >> 2015-12-03 20:45 GMT+01:00 larry mccay <
>> > > > larry.mccay@gmail.com
>> > > > > >:
>> > > > > > > > > > >>
>> > > > > > > > > > >> > Excellent!
>> > > > > > > > > > >> >
>> > > > > > > > > > >> > I will carve out some time to do code review.
>> > > > > > > > > > >> > We will need to get some insights into how to go
>> about
>> > > > > > testing:
>> > > > > > > > > > >> >
>> > > > > > > > > > >> > * is the CAS server going to be available for
>> testing?
>> > > > > > > > > > >> > * what are the specific and generic/standard (if
>> any)
>> > > > > > > > authentication
>> > > > > > > > > > >> > mechanisms available - for instance:
>> > > > > > > > > > >> > - Facebook, Google, LinkedIn and CAS are
>> specifics
>> > > > > > > > > > >> > - OAuth 2, OpenID Connect, SAML are
>> > > generic/standards
>> > > > -
>> > > > > > that
>> > > > > > > > may
>> > > > > > > > > > be
>> > > > > > > > > > >> > used for the above specifics...
>> > > > > > > > > > >> > * how do we test things other than CAS - in terms of
>> > > > getting
>> > > > > > > > > > >> credentials,
>> > > > > > > > > > >> > configuration, etc
>> > > > > > > > > > >> >
>> > > > > > > > > > >> > We could certainly do this is phases as well.
>> > > > > > > > > > >> >
>> > > > > > > > > > >> > If you can enumerate the things that should work and
>> > > > provide
>> > > > > > > some
>> > > > > > > > > > >> testing
>> > > > > > > > > > >> > details for CAS or as many as possible and OpenID
>> > > Connect
>> > > > > then
>> > > > > > > we
>> > > > > > > > > can
>> > > > > > > > > > >> test
>> > > > > > > > > > >> > the specific implementations that you provide and
>> > enable
>> > > > the
>> > > > > > > > testing
>> > > > > > > > > > of
>> > > > > > > > > > >> > another OpenID Connect effort that is in the works
>> in
>> > > the
>> > > > > > > > community.
>> > > > > > > > > > >> >
>> > > > > > > > > > >> > I'm not sure whether we want to commit contributions
>> > > that
>> > > > > are
>> > > > > > > > > > dependent
>> > > > > > > > > > >> on
>> > > > > > > > > > >> > snapshots - we certainly can't release with any such
>> > > > > > > dependencies.
>> > > > > > > > > > >> > I would hate to add a cleanup task to a release to
>> > make
>> > > > sure
>> > > > > > > there
>> > > > > > > > > are
>> > > > > > > > > > >> no
>> > > > > > > > > > >> > snapshots in there.
>> > > > > > > > > > >> > We will probably wait until after the pac4j releases
>> > to
>> > > > > > commit.
>> > > > > > > > > > >> >
>> > > > > > > > > > >> > I am really happy that this integration is happening
>> > and
>> > > > > that
>> > > > > > it
>> > > > > > > > > went
>> > > > > > > > > > >> > rather smoothly.
>> > > > > > > > > > >> > These sorts of authentication protocols are complex
>> > and
>> > > I
>> > > > > > think
>> > > > > > > we
>> > > > > > > > > > >> lined up
>> > > > > > > > > > >> > pretty well overall.
>> > > > > > > > > > >> >
>> > > > > > > > > > >> > Thanks for your work!
>> > > > > > > > > > >> >
>> > > > > > > > > > >> > On Thu, Dec 3, 2015 at 2:28 PM, Jérôme LELEU <
>> > > > > > leleuj@gmail.com>
>> > > > > > > > > > wrote:
>> > > > > > > > > > >> >
>> > > > > > > > > > >> > > Hi,
>> > > > > > > > > > >> > >
>> > > > > > > > > > >> > > I just sync'ed with master, cleaned dependencies
>> and
>> > > > added
>> > > > > > > > missing
>> > > > > > > > > > >> > > Javadocs. Everything works correctly now. Many
>> > thanks.
>> > > > > > > > > > >> > >
>> > > > > > > > > > >> > > The pull request is ready for a full code review:
>> > > > > > > > > > >> > > https://github.com/apache/knox/pull/2
>> > > > > > > > > > >> > >
>> > > > > > > > > > >> > > I'll write the documentation after the pac4j
>> > releases
>> > > (I
>> > > > > > hope
>> > > > > > > > next
>> > > > > > > > > > >> week).
>> > > > > > > > > > >> > >
>> > > > > > > > > > >> > > Thanks.
>> > > > > > > > > > >> > > Best regards,
>> > > > > > > > > > >> > > Jérôme
>> > > > > > > > > > >> > >
>> > > > > > > > > > >> > >
>> > > > > > > > > > >> > > 2015-12-02 19:18 GMT+01:00 larry mccay <
>> > > > > > larry.mccay@gmail.com
>> > > > > > > >:
>> > > > > > > > > > >> > >
>> > > > > > > > > > >> > > > Fixed in
>> > > > https://issues.apache.org/jira/browse/KNOX-636
>> > > > > .
>> > > > > > > > > > >> > > >
>> > > > > > > > > > >> > > > On Wed, Dec 2, 2015 at 12:42 PM, larry mccay <
>> > > > > > > > > > larry.mccay@gmail.com
>> > > > > > > > > > >> >
>> > > > > > > > > > >> > > > wrote:
>> > > > > > > > > > >> > > >
>> > > > > > > > > > >> > > > > Sure - I can file a JIRA and commit a fix.
>> > > > > > > > > > >> > > > >
>> > > > > > > > > > >> > > > > The secret generation should be done in one
>> > > instance
>> > > > > and
>> > > > > > > > > > >> replicated
>> > > > > > > > > > >> > > > across
>> > > > > > > > > > >> > > > > others.
>> > > > > > > > > > >> > > > > This replication/management of the credential
>> > > stores
>> > > > > is
>> > > > > > > > > outside
>> > > > > > > > > > of
>> > > > > > > > > > >> > the
>> > > > > > > > > > >> > > > > scope of Knox itself as of now.
>> > > > > > > > > > >> > > > >
>> > > > > > > > > > >> > > > > Documentation is done in markdown and is
>> > > > contributing
>> > > > > > > > details
>> > > > > > > > > > are
>> > > > > > > > > > >> > > > > available at:
>> > > > > > > > > > >> > > > >
>> > > > > > > > > > >> > > >
>> > > > > > > > > > >> > >
>> > > > > > > > > > >> >
>> > > > > > > > > > >>
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
>> > > > > > > > > > >> > > > >
>> > > > > > > > > > >> > > > > Which should give you a general idea.
>> > > > > > > > > > >> > > > >
>> > > > > > > > > > >> > > > > Find an example like: ./trunk/books/0.7.0/
>> > > > > > > > > > >> > > config_preauth_sso_provider.md
>> > > > > > > > > > >> > > > >
>> > > > > > > > > > >> > > > > For an example of typical content and format.
>> > > > > > > > > > >> > > > >
>> > > > > > > > > > >> > > > > Here is how that example renders:
>> > > > > > > > > > >> > > > >
>> > > > > > > > > > >> > > >
>> > > > > > > > > > >> > >
>> > > > > > > > > > >> >
>> > > > > > > > > > >>
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
>> > > > > > > > > > >> > > > >
>> > > > > > > > > > >> > > > > You'll need to tie it into the rest of the
>> book
>> > -
>> > > > just
>> > > > > > > grep
>> > > > > > > > > for
>> > > > > > > > > > >> where
>> > > > > > > > > > >> > > > that
>> > > > > > > > > > >> > > > > filename is referenced.
>> > > > > > > > > > >> > > > > To test how it renders build the site with:
>> > "ant"
>> > > > and
>> > > > > > note
>> > > > > > > > the
>> > > > > > > > > > >> url to
>> > > > > > > > > > >> > > the
>> > > > > > > > > > >> > > > > 0.7.0 book.
>> > > > > > > > > > >> > > > >
>> > > > > > > > > > >> > > > >
>> > > > > > > > > > >> > > > > On Wed, Dec 2, 2015 at 12:12 PM, Jérôme LELEU
>> <
>> > > > > > > > > leleuj@gmail.com
>> > > > > > > > > > >
>> > > > > > > > > > >> > > wrote:
>> > > > > > > > > > >> > > > >
>> > > > > > > > > > >> > > > >> Hi,
>> > > > > > > > > > >> > > > >>
>> > > > > > > > > > >> > > > >> Why it doesn't work for pac4j while it works
>> > for
>> > > > > others
>> > > > > > > is
>> > > > > > > > a
>> > > > > > > > > > bit
>> > > > > > > > > > >> > > strange
>> > > > > > > > > > >> > > > >> to
>> > > > > > > > > > >> > > > >> me, but if you have the patch in front of
>> your
>> > > > eyes,
>> > > > > > I'd
>> > > > > > > > > rather
>> > > > > > > > > > >> > prefer
>> > > > > > > > > > >> > > > you
>> > > > > > > > > > >> > > > >> to commit it. In all cases, I'll sync with
>> the
>> > > > > master.
>> > > > > > > > > > >> > > > >>
>> > > > > > > > > > >> > > > >> There was one question you didn't answer
>> > > > previously:
>> > > > > is
>> > > > > > > the
>> > > > > > > > > > >> password
>> > > > > > > > > > >> > > > >> generated for the pac4j provider the same
>> > across
>> > > > all
>> > > > > > > > gateway
>> > > > > > > > > > >> > > instances?
>> > > > > > > > > > >> > > > >> Because I expect to have the same value as I
>> > use
>> > > it
>> > > > > to
>> > > > > > > > > encrypt
>> > > > > > > > > > /
>> > > > > > > > > > >> > > decrypt
>> > > > > > > > > > >> > > > >> data.
>> > > > > > > > > > >> > > > >>
>> > > > > > > > > > >> > > > >> I will add the Javadoc. After that, you can
>> > > review
>> > > > > the
>> > > > > > > pull
>> > > > > > > > > > >> request
>> > > > > > > > > > >> > > more
>> > > > > > > > > > >> > > > >> completely.
>> > > > > > > > > > >> > > > >>
>> > > > > > > > > > >> > > > >> What do you expect for the documentation?
>> > > > > > > > > > >> > > > >>
>> > > > > > > > > > >> > > > >> Notice that pac4j dependencies are still
>> > > snapshots,
>> > > > > but
>> > > > > > > > they
>> > > > > > > > > > >> will be
>> > > > > > > > > > >> > > > >> released in a week or two.
>> > > > > > > > > > >> > > > >>
>> > > > > > > > > > >> > > > >> Thanks.
>> > > > > > > > > > >> > > > >> Best regards,
>> > > > > > > > > > >> > > > >> Jérôme
>> > > > > > > > > > >> > > > >>
>> > > > > > > > > > >> > > > >>
>> > > > > > > > > > >> > > > >> 2015-12-02 17:51 GMT+01:00 larry mccay <
>> > > > > > > > > larry.mccay@gmail.com
>> > > > > > > > > > >:
>> > > > > > > > > > >> > > > >>
>> > > > > > > > > > >> > > > >> > Jérôme -
>> > > > > > > > > > >> > > > >> >
>> > > > > > > > > > >> > > > >> > If you would like to add that change as
>> part
>> > of
>> > > > > your
>> > > > > > > > patch
>> > > > > > > > > or
>> > > > > > > > > > >> as a
>> > > > > > > > > > >> > > > >> > separately filed JIRA to fix a bug that
>> would
>> > > > > > certainly
>> > > > > > > > be
>> > > > > > > > > > >> > welcomed.
>> > > > > > > > > > >> > > > >> > Otherwise, I can do it.
>> > > > > > > > > > >> > > > >> >
>> > > > > > > > > > >> > > > >> > Let me know.
>> > > > > > > > > > >> > > > >> >
>> > > > > > > > > > >> > > > >> > thanks,
>> > > > > > > > > > >> > > > >> >
>> > > > > > > > > > >> > > > >> > --larry
>> > > > > > > > > > >> > > > >> >
>> > > > > > > > > > >> > > > >> > On Wed, Dec 2, 2015 at 11:44 AM, larry
>> mccay
>> > <
>> > > > > > > > > > >> > larry.mccay@gmail.com
>> > > > > > > > > > >> > > >
>> > > > > > > > > > >> > > > >> > wrote:
>> > > > > > > > > > >> > > > >> >
>> > > > > > > > > > >> > > > >> > > Okay - I had to add an override of
>> > > > > > getUserPrincipal()
>> > > > > > > > to
>> > > > > > > > > > the
>> > > > > > > > > > >> > > > >> > > IdentityAsserterHttpServletRequestWrapper
>> > and
>> > > > > > return
>> > > > > > > > the
>> > > > > > > > > > >> member
>> > > > > > > > > > >> > > > >> variable
>> > > > > > > > > > >> > > > >> > > username and it works like a charm.
>> > > > > > > > > > >> > > > >> > >
>> > > > > > > > > > >> > > > >> > > Why I haven't seen this same behavior
>> with
>> > > > other
>> > > > > > > > > providers
>> > > > > > > > > > >> is a
>> > > > > > > > > > >> > > bit
>> > > > > > > > > > >> > > > >> of a
>> > > > > > > > > > >> > > > >> > > mystery but they must be adding other
>> > > wrappers
>> > > > > that
>> > > > > > > > > handle
>> > > > > > > > > > >> it.
>> > > > > > > > > > >> > > > >> > > This is quite cool, Jérôme!
>> > > > > > > > > > >> > > > >> > >
>> > > > > > > > > > >> > > > >> > > On Wed, Dec 2, 2015 at 10:41 AM, larry
>> > mccay
>> > > <
>> > > > > > > > > > >> > > larry.mccay@gmail.com
>> > > > > > > > > > >> > > > >
>> > > > > > > > > > >> > > > >> > > wrote:
>> > > > > > > > > > >> > > > >> > >
>> > > > > > > > > > >> > > > >> > >> That was it - thanks!
>> > > > > > > > > > >> > > > >> > >>
>> > > > > > > > > > >> > > > >> > >> On Wed, Dec 2, 2015 at 10:20 AM, Jérôme
>> > > LELEU
>> > > > <
>> > > > > > > > > > >> > leleuj@gmail.com>
>> > > > > > > > > > >> > > > >> wrote:
>> > > > > > > > > > >> > > > >> > >>
>> > > > > > > > > > >> > > > >> > >>> This is my exact command line: mvn
>> > > -Prelease
>> > > > > > clean
>> > > > > > > > > > install
>> > > > > > > > > > >> > > > >> -DskipTests
>> > > > > > > > > > >> > > > >> > >>>
>> > > > > > > > > > >> > > > >> > >>> You use an internal Maven repository to
>> > > fetch
>> > > > > > > > > > dependencies
>> > > > > > > > > > >> > from
>> > > > > > > > > > >> > > > >> > internet:
>> > > > > > > > > > >> > > > >> > >>>
>> > > > > > > > > > >> > >
>> > > > > > > >
>> > > http://nexus-private.hortonworks.com/nexus/content/groups/public/
>> > > > > > > > > > >> > > > >> > >>>
>> > > > > > > > > > >> > > > >> > >>> Does this repository have access to the
>> > > > remote
>> > > > > > > > > Snapshots
>> > > > > > > > > > >> > > Sonatype
>> > > > > > > > > > >> > > > >> repo?
>> > > > > > > > > > >> > > > >> > >>>
>> > > > > > > > > > >> > > > >> > >>>
>> > > > > > > > > > >> > > > >> > >>>
>> > > > > > > > > > >> > > > >> > >>> 2015-12-02 16:16 GMT+01:00 larry mccay
>> <
>> > > > > > > > > > >> larry.mccay@gmail.com
>> > > > > > > > > > >> > >:
>> > > > > > > > > > >> > > > >> > >>>
>> > > > > > > > > > >> > > > >> > >>> > hmmm - I used:
>> > > > > > > > > > >> > > > >> > >>> >
>> > > > > > > > > > >> > > > >> > >>> > mvn clean install -DskipTests=true
>> > > > -Prelease
>> > > > > > > > > > >> > > > >> > >>> >
>> > > > > > > > > > >> > > > >> > >>> > The repository entry is in there
>> > already.
>> > > > > > > > > > >> > > > >> > >>> > No worky.
>> > > > > > > > > > >> > > > >> > >>> >
>> > > > > > > > > > >> > > > >> > >>> > On Wed, Dec 2, 2015 at 10:12 AM,
>> Jérôme
>> > > > > LELEU <
>> > > > > > > > > > >> > > leleuj@gmail.com
>> > > > > > > > > > >> > > > >
>> > > > > > > > > > >> > > > >> > >>> wrote:
>> > > > > > > > > > >> > > > >> > >>> >
>> > > > > > > > > > >> > > > >> > >>> > > Hi,
>> > > > > > > > > > >> > > > >> > >>> > >
>> > > > > > > > > > >> > > > >> > >>> > > You need the j2e-pac4j dependencies
>> > as
>> > > > well
>> > > > > > as
>> > > > > > > > the
>> > > > > > > > > > >> pac4j-*
>> > > > > > > > > > >> > > > >> > >>> dependencies,
>> > > > > > > > > > >> > > > >> > >>> > > but you don't need to build them
>> > > locally
>> > > > > > > > > (hopefully).
>> > > > > > > > > > >> > > > >> > >>> > >
>> > > > > > > > > > >> > > > >> > >>> > > But you need a dependency on the
>> > > Sonatype
>> > > > > > > > snapshots
>> > > > > > > > > > >> > > repository
>> > > > > > > > > > >> > > > >> > >>> (where the
>> > > > > > > > > > >> > > > >> > >>> > > snapshot versions are hosted),
>> which
>> > is
>> > > > > added
>> > > > > > > for
>> > > > > > > > > > >> Maven in
>> > > > > > > > > > >> > > the
>> > > > > > > > > > >> > > > >> root
>> > > > > > > > > > >> > > > >> > >>> > > pom.xml:
>> > > > > > > > > > >> > > > >> > >>> > >
>> > > > > > > > > > >> > > > >> > >>> > >
>> > > > > > > > > > >> > > > >> > >>> >
>> > > > > > > > > > >> > > > >> > >>>
>> > > > > > > > > > >> > > > >> >
>> > > > > > > > > > >> > > > >>
>> > > > > > > > > > >> > > >
>> > > > > > > > > > >> > >
>> > > > > > > > > > >> >
>> > > > > > > > > > >>
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
>> > > > > > > > > > >> > > > >> > >>> > >
>> > > > > > > > > > >> > > > >> > >>> > > If you use Ant for the build, there
>> > is
>> > > > > maybe
>> > > > > > a
>> > > > > > > > > glitch
>> > > > > > > > > > >> to
>> > > > > > > > > > >> > > find
>> > > > > > > > > > >> > > > >> the
>> > > > > > > > > > >> > > > >> > >>> > Sonatype
>> > > > > > > > > > >> > > > >> > >>> > > Maven repo.
>> > > > > > > > > > >> > > > >> > >>> > >
>> > > > > > > > > > >> > > > >> > >>> > > Thanks.
>> > > > > > > > > > >> > > > >> > >>> > > Best regards,
>> > > > > > > > > > >> > > > >> > >>> > > Jérôme
>> > > > > > > > > > >> > > > >> > >>> > >
>> > > > > > > > > > >> > > > >> > >>> > >
>> > > > > > > > > > >> > > > >> > >>> > > 2015-12-02 16:06 GMT+01:00 larry
>> > mccay
>> > > <
>> > > > > > > > > > >> > > larry.mccay@gmail.com
>> > > > > > > > > > >> > > > >:
>> > > > > > > > > > >> > > > >> > >>> > >
>> > > > > > > > > > >> > > > >> > >>> > > > 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.mccay@gmail.com>
>> > > > > > > > > > >> > > > >> > >>> > > > wrote:
>> > > > > > > > > > >> > > > >> > >>> > > >
>> > > > > > > > > > >> > > > >> > >>> > > > > gateway-provider-security-pac4j
>> > > > doesn't
>> > > > > > > > build -
>> > > > > > > > > > do
>> > > > > > > > > > >> you
>> > > > > > > > > > >> > > > have
>> > > > > > > > > > >> > > > >> a
>> > > > > > > > > > >> > > > >> > >>> pending
>> > > > > > > > > > >> > > > >> > >>> > > > > change for your pom.xml or
>> > > something?
>> > > > > > > > > > >> > > > >> > >>> > > > >
>> > > > > > > > > > >> > > > >> > >>> >
>> > > > > > > > > > >> > > > >> > >>>
>> > > > > > > > > > >> > > > >> > >>
>> > > > > > > > > > >> > > > >> > >>
>> > > > > > > > > > >> > > > >> > >
>> > > > > > > > > > >> > > > >> >
>> > > > > > > > > > >> > > > >>
>> > > > > > > > > > >> > > > >
>> > > > > > > > > > >> > > > >
>> > > > > > > > > > >> > > >
>> > > > > > > > > > >> > >
>> > > > > > > > > > >> >
>> > > > > > > > > > >>
>> > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
Okay, very good.
I've used TestShib for the picketlink provider - thanks for the pointers!
On Tue, Jan 5, 2016 at 1:38 PM, Jérôme LELEU <le...@gmail.com> wrote:
> The online CAS server (https://casserverpac4j.herokuapp.com/login) uses
> the
> CAS protocol. SAML support can be tested using some online IdP like Okta,
> TestShib, OpenFeide, Ssocircle...
>
>
> 2016-01-05 17:32 GMT+01:00 larry mccay <la...@gmail.com>:
>
> > Great - thanks for that pointer!
> >
> > I will take a look at that and help drive the release related testing.
> > Merge testing will be gated on CAS server (is this SAML or CAS protocol?)
> > and testBasicAuth.
> >
> > On Tue, Jan 5, 2016 at 10:52 AM, Jérôme LELEU <le...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > Glad to hear back from you!
> > >
> > > The core pac4j project is fully tested by unit tests (and some
> > integration
> > > tests I run for major version), then all pac4j implementations are each
> > > tested by the appropriate demo: j2e-pac4j-demo tests j2e-pac4j,
> > > spring-webmvc-pac4j-demo tests spring-webmvc-pac4j, etc.
> > >
> > > So if you take a look at:
> > >
> > >
> >
> https://github.com/pac4j/j2e-pac4j-demo/blob/master/src/main/java/org/pac4j/demo/j2e/config/DemoConfigFactory.java#L27
> > > (for example), you have all the required information to test.
> > >
> > > I can do that on my own, but it can be good for the Knox community to
> > start
> > > working / testing the pac4j support. It's up to yoy.
> > >
> > > Thanks.
> > > Best regards,
> > > Jérôme
> > >
> > >
> > > 2016-01-05 16:11 GMT+01:00 larry mccay <la...@gmail.com>:
> > >
> > > > Hello Jérôme -
> > > >
> > > > Happy New Year!
> > > >
> > > > I am going to start reviewing your updates today, hopefully.
> > > > I was thinking that we need to start discussions on what the key
> > usecases
> > > > are and how to go about testing them.
> > > > We can certainly test the testBasicAuth and against the hosted CAS
> > server
> > > > but what about FB, openid, OAuth, etc?
> > > >
> > > > I'm not sure that FB would be a key feature but OpenID Connect and
> > OAuth
> > > > would be - as is SAML.
> > > > I think CAS buys us SAML testing - assuming that the configuration of
> > the
> > > > hosted server is actually a SAML 2 instance.
> > > >
> > > > What about the others?
> > > >
> > > > I don't know that we need to be able to test them all before merge
> but
> > > some
> > > > sort of manual verification would be great.
> > > > We would need to be able to test them before the next release which
> > would
> > > > be featuring the pac4j functionality.
> > > >
> > > > Maybe you can describe how you go about testing such things for the
> > pac4j
> > > > project itself?
> > > >
> > > > thanks,
> > > >
> > > > --larry
> > > >
> > > >
> > > > On Tue, Jan 5, 2016 at 9:55 AM, Jérôme LELEU <le...@gmail.com>
> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Happy new year!
> > > > >
> > > > > A few days ago, I updated my patch of the pac4j gateway provider
> > > > according
> > > > > to all comments on https://issues.apache.org/jira/browse/KNOX-641
> as
> > > > well
> > > > > as the documentation on KNOX-642.
> > > > >
> > > > > Is everything ok for the merge?
> > > > >
> > > > > Thanks.
> > > > > Best regards,
> > > > > Jérôme
> > > > >
> > > > >
> > > > > 2015-12-14 15:28 GMT+01:00 larry mccay <la...@gmail.com>:
> > > > >
> > > > > > Hi Jérôme -
> > > > > >
> > > > > > Not sure if you saw but I added review comments to KNOX-641.
> > > > > >
> > > > > > I think that we need to determine whether we want the
> testBasicAuth
> > > in
> > > > > the
> > > > > > provider itself.
> > > > > >
> > > > > > Let's follow up on the JIRA.
> > > > > >
> > > > > > thanks,
> > > > > >
> > > > > > --larry
> > > > > >
> > > > > > On Fri, Dec 11, 2015 at 8:44 AM, Jérôme LELEU <le...@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > No problem. It can go into a version 0.8.0 if needed. The truth
> > is
> > > > that
> > > > > > > there is only one change outside the new pac4j module, so I
> think
> > > > risks
> > > > > > are
> > > > > > > extremly limited.
> > > > > > >
> > > > > > > Just let met know.
> > > > > > >
> > > > > > > Thanks.
> > > > > > > Best regards,
> > > > > > > Jérôme
> > > > > > >
> > > > > > >
> > > > > > > 2015-12-11 14:23 GMT+01:00 larry mccay <larry.mccay@gmail.com
> >:
> > > > > > >
> > > > > > > > Hi Jérôme -
> > > > > > > >
> > > > > > > > I have unfortunately not had a chance to pull, review and
> test
> > it
> > > > yet
> > > > > > and
> > > > > > > > have intended to do that today.
> > > > > > > > I apologize for the delay.
> > > > > > > >
> > > > > > > > I was actually thinking that this would go into a follow up
> > > release
> > > > > > that
> > > > > > > we
> > > > > > > > would try and get done rapidly after the 0.7.0 release but we
> > can
> > > > > > discuss
> > > > > > > > the target and its chances of destabilizing 0.7.0.
> > > > > > > >
> > > > > > > > I believe that it is rather self-contained with only a few
> > > changes
> > > > to
> > > > > > > > external modules.
> > > > > > > >
> > > > > > > > Opening the JIRAs is perfect and I was going to do that once
> I
> > > > > started
> > > > > > > the
> > > > > > > > review.
> > > > > > > >
> > > > > > > > Let's continue review comments and collaboration on those
> > JIRAs.
> > > > > > > > I will add you to the contributors list so that we can assign
> > > them
> > > > to
> > > > > > > you.
> > > > > > > >
> > > > > > > > Thank you for your contributions and your patience, Jérôme!
> > > > > > > >
> > > > > > > > --larry
> > > > > > > >
> > > > > > > > On Fri, Dec 11, 2015 at 3:00 AM, Jérôme LELEU <
> > leleuj@gmail.com>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > I didn't get any new feedback on the pull request so I
> assume
> > > > > > > everything
> > > > > > > > is
> > > > > > > > > ok from your point of view.
> > > > > > > > >
> > > > > > > > > I released pac4j v1.8.1 and j2e-pac4j v1.2.1 so I updated
> the
> > > > pull
> > > > > > > > request
> > > > > > > > > to use them and successfully re-tested everything.
> > > > > > > > >
> > > > > > > > > I opened KNOX-641 and submitted the corresponding patch.
> > > > > > > > >
> > > > > > > > > I also wrote the documentation, opened KNOX-642 and
> submitted
> > > the
> > > > > > > > > corresponding patch (just to let you know that it doesn't
> > work
> > > > out
> > > > > of
> > > > > > > the
> > > > > > > > > box in Windows, I had to replace mvn.bat by mvn.cmd to make
> > ant
> > > > > > work).
> > > > > > > > >
> > > > > > > > > Even if the branch 0.7.0 has already been created, I
> assumed
> > > this
> > > > > new
> > > > > > > > pac4j
> > > > > > > > > provider will go into this version 0.7.0 (dependency on the
> > > > > > > > 0.7.0-SNAPSHOT
> > > > > > > > > parent version).
> > > > > > > > >
> > > > > > > > > Just let me know if everything is ok and when it's goind to
> > be
> > > > > > merged.
> > > > > > > > >
> > > > > > > > > Thanks.
> > > > > > > > > Best regards,
> > > > > > > > > Jérôme
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 2015-12-04 14:20 GMT+01:00 larry mccay <
> > larry.mccay@gmail.com
> > > >:
> > > > > > > > >
> > > > > > > > > > That ability to configure multiple mechanisms based on
> > > > clientName
> > > > > > is
> > > > > > > > > really
> > > > > > > > > > interesting for Knox.
> > > > > > > > > > Currently, we require separate topologies per
> > authentication
> > > > > > > mechanism.
> > > > > > > > > > The ability to configure them all in one is really great.
> > > > > > > > > >
> > > > > > > > > > We would need to think through the best way to provide
> the
> > > > > > clientName
> > > > > > > > > > parameter.
> > > > > > > > > > Since this is targeting KnoxSSO it can actually be added
> to
> > > the
> > > > > > > > > providerURL
> > > > > > > > > > used to redirect from the participating application.
> > > > > > > > > > Regardless of the authentication mechanism used each
> > > > application
> > > > > > will
> > > > > > > > > still
> > > > > > > > > > get the same JWT based cookie.
> > > > > > > > > >
> > > > > > > > > > I think that should work really nicely.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Fri, Dec 4, 2015 at 7:17 AM, larry mccay <
> > > > > larry.mccay@gmail.com
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Excellent, Jérôme.
> > > > > > > > > > > Thanks!
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Dec 4, 2015 at 2:40 AM, Jérôme LELEU <
> > > > leleuj@gmail.com
> > > > > >
> > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > >> Hi,
> > > > > > > > > > >>
> > > > > > > > > > >> I will write how to configure the pac4j provider in
> the
> > > > > > > > documentation,
> > > > > > > > > > but
> > > > > > > > > > >> I can already give you some insights.
> > > > > > > > > > >>
> > > > > > > > > > >> My main goal is always to respect the key design
> > > principles
> > > > of
> > > > > > > pac4j
> > > > > > > > > > >> whatever the environment / framework in which it is
> > > > > implemented.
> > > > > > > For
> > > > > > > > > > Knox,
> > > > > > > > > > >> I'm pretty happy with the use of the j2e-pac4j
> library,
> > > > which
> > > > > > > means
> > > > > > > > > that
> > > > > > > > > > >> almost all the pac4j features are available,
> especially
> > > both
> > > > > > > direct
> > > > > > > > > and
> > > > > > > > > > >> indirect clients. So it can do what Shiro already does
> > but
> > > > > also,
> > > > > > > as
> > > > > > > > we
> > > > > > > > > > >> agreed together, supports remote authentications.
> > > > > > > > > > >>
> > > > > > > > > > >> It is only limited by what you can currently
> configure.
> > > And
> > > > > even
> > > > > > > > > > >> configuration is a pac4j feature as the CAS server has
> > the
> > > > > same
> > > > > > > > need.
> > > > > > > > > > >> Everything happens in this class:
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java
> > > > > > > > > > >> ,
> > > > > > > > > > >> which allows you to configure Facebook, Twitter, a CAS
> > > > > server, a
> > > > > > > > SAML
> > > > > > > > > > IdP
> > > > > > > > > > >> or an OpenID Connect provider. All the provided
> > parameters
> > > > to
> > > > > > the
> > > > > > > > > pac4j
> > > > > > > > > > >> provider are put into a Map and the
> > > ConfigPropertiesFactory
> > > > is
> > > > > > > built
> > > > > > > > > > with
> > > > > > > > > > >> this Map to return the built client (= authentication
> > > > > > mechanism).
> > > > > > > > > > >>
> > > > > > > > > > >> You have one more specific option for Knox as a basic
> > > > > > > authentication
> > > > > > > > > > popup
> > > > > > > > > > >> where the username must match the password, you can
> > define
> > > > > that
> > > > > > > by:
> > > > > > > > > > >>
> > > > > > > > > > >> <param>
> > > > > > > > > > >> <name>clientName</name>
> > > > > > > > > > >> <value>testBasicAuth</value>
> > > > > > > > > > >> </param>
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >> It's for testing only.
> > > > > > > > > > >>
> > > > > > > > > > >> For a CAS server:
> > > > > > > > > > >>
> > > > > > > > > > >> <param>
> > > > > > > > > > >> <name>cas.loginUrl</name>
> > > > > > > > > > >> <value>https://casserverpac4j.herokuapp.com/login
> > > </value>
> > > > > > > > > > >> </param>
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >> Here are all the properties available for building
> > clients
> > > > > > (their
> > > > > > > > > > meaning
> > > > > > > > > > >> is obvious):
> > > > > > > > > > >>
> > > > > > > > > > >> facebook.id
> > > > > > > > > > >> facebook.secret
> > > > > > > > > > >> facebook.scope
> > > > > > > > > > >> facebook.fields
> > > > > > > > > > >> twitter.id
> > > > > > > > > > >> twitter.secret
> > > > > > > > > > >> saml.keystorePassword
> > > > > > > > > > >> saml.privateKeyPassword
> > > > > > > > > > >> saml.keystorePath
> > > > > > > > > > >> saml.identityProviderMetadataPath
> > > > > > > > > > >> saml.maximumAuthenticationLifetime
> > > > > > > > > > >> saml.serviceProviderEntityId
> > > > > > > > > > >> saml.serviceProviderMetadataPath
> > > > > > > > > > >> cas.loginUrl
> > > > > > > > > > >> cas.protocol
> > > > > > > > > > >> oidc.id
> > > > > > > > > > >> oidc.secret
> > > > > > > > > > >> oidc.discoveryUri
> > > > > > > > > > >> oidc.customParamKey1
> > > > > > > > > > >> oidc.customParamValue1
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >> If you define multiple clients, the first one will be
> > used
> > > > for
> > > > > > > > > > >> authentication, but you can explicitly choose the
> client
> > > you
> > > > > > want
> > > > > > > to
> > > > > > > > > use
> > > > > > > > > > >> via the clientName parameter, assuming you want to
> > switch
> > > > from
> > > > > > > > client
> > > > > > > > > > >> depending on environment for example.
> > > > > > > > > > >>
> > > > > > > > > > >> So if you want to add some new authentication
> mechanism,
> > > you
> > > > > > must
> > > > > > > > > first
> > > > > > > > > > >> check that it is available in pac4j (if it's not, it's
> > > > another
> > > > > > > > > > discussion,
> > > > > > > > > > >> but generally, it is). Then, you'll need to upgrade
> the
> > > > > > > > > > >> ConfigPropertiesFactory by submitting a new pull
> request
> > > to
> > > > > the
> > > > > > > > pac4j
> > > > > > > > > > >> project (I can do it myself, but I'm sure you could do
> > > that
> > > > > > > easily),
> > > > > > > > > > >> finally wait for the new pac4j release and switch
> pac4j
> > > > > versions
> > > > > > > in
> > > > > > > > > Knox
> > > > > > > > > > >> to
> > > > > > > > > > >> benefit from the new feature.
> > > > > > > > > > >> The good thing is that if someone related to the CAS
> > > server
> > > > > does
> > > > > > > the
> > > > > > > > > > same
> > > > > > > > > > >> thing for CAS (in pac4j), you will automatically get
> it
> > > when
> > > > > > > you'll
> > > > > > > > > > >> upgrade
> > > > > > > > > > >> pac4j.
> > > > > > > > > > >>
> > > > > > > > > > >> To go even further, replacing LDAP Shiro
> authentication
> > is
> > > > > just
> > > > > > a
> > > > > > > > > matter
> > > > > > > > > > >> of
> > > > > > > > > > >> making pac4j LDAP authentication available via
> > > configuration
> > > > > > > > > parameters.
> > > > > > > > > > >>
> > > > > > > > > > >> I hope it was clear enough.
> > > > > > > > > > >>
> > > > > > > > > > >> Thanks.
> > > > > > > > > > >> Best regards,
> > > > > > > > > > >> Jérôme
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >> 2015-12-03 20:45 GMT+01:00 larry mccay <
> > > > larry.mccay@gmail.com
> > > > > >:
> > > > > > > > > > >>
> > > > > > > > > > >> > Excellent!
> > > > > > > > > > >> >
> > > > > > > > > > >> > I will carve out some time to do code review.
> > > > > > > > > > >> > We will need to get some insights into how to go
> about
> > > > > > testing:
> > > > > > > > > > >> >
> > > > > > > > > > >> > * is the CAS server going to be available for
> testing?
> > > > > > > > > > >> > * what are the specific and generic/standard (if
> any)
> > > > > > > > authentication
> > > > > > > > > > >> > mechanisms available - for instance:
> > > > > > > > > > >> > - Facebook, Google, LinkedIn and CAS are
> specifics
> > > > > > > > > > >> > - OAuth 2, OpenID Connect, SAML are
> > > generic/standards
> > > > -
> > > > > > that
> > > > > > > > may
> > > > > > > > > > be
> > > > > > > > > > >> > used for the above specifics...
> > > > > > > > > > >> > * how do we test things other than CAS - in terms of
> > > > getting
> > > > > > > > > > >> credentials,
> > > > > > > > > > >> > configuration, etc
> > > > > > > > > > >> >
> > > > > > > > > > >> > We could certainly do this is phases as well.
> > > > > > > > > > >> >
> > > > > > > > > > >> > If you can enumerate the things that should work and
> > > > provide
> > > > > > > some
> > > > > > > > > > >> testing
> > > > > > > > > > >> > details for CAS or as many as possible and OpenID
> > > Connect
> > > > > then
> > > > > > > we
> > > > > > > > > can
> > > > > > > > > > >> test
> > > > > > > > > > >> > the specific implementations that you provide and
> > enable
> > > > the
> > > > > > > > testing
> > > > > > > > > > of
> > > > > > > > > > >> > another OpenID Connect effort that is in the works
> in
> > > the
> > > > > > > > community.
> > > > > > > > > > >> >
> > > > > > > > > > >> > I'm not sure whether we want to commit contributions
> > > that
> > > > > are
> > > > > > > > > > dependent
> > > > > > > > > > >> on
> > > > > > > > > > >> > snapshots - we certainly can't release with any such
> > > > > > > dependencies.
> > > > > > > > > > >> > I would hate to add a cleanup task to a release to
> > make
> > > > sure
> > > > > > > there
> > > > > > > > > are
> > > > > > > > > > >> no
> > > > > > > > > > >> > snapshots in there.
> > > > > > > > > > >> > We will probably wait until after the pac4j releases
> > to
> > > > > > commit.
> > > > > > > > > > >> >
> > > > > > > > > > >> > I am really happy that this integration is happening
> > and
> > > > > that
> > > > > > it
> > > > > > > > > went
> > > > > > > > > > >> > rather smoothly.
> > > > > > > > > > >> > These sorts of authentication protocols are complex
> > and
> > > I
> > > > > > think
> > > > > > > we
> > > > > > > > > > >> lined up
> > > > > > > > > > >> > pretty well overall.
> > > > > > > > > > >> >
> > > > > > > > > > >> > Thanks for your work!
> > > > > > > > > > >> >
> > > > > > > > > > >> > On Thu, Dec 3, 2015 at 2:28 PM, Jérôme LELEU <
> > > > > > leleuj@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > > >> >
> > > > > > > > > > >> > > Hi,
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > I just sync'ed with master, cleaned dependencies
> and
> > > > added
> > > > > > > > missing
> > > > > > > > > > >> > > Javadocs. Everything works correctly now. Many
> > thanks.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > The pull request is ready for a full code review:
> > > > > > > > > > >> > > https://github.com/apache/knox/pull/2
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > I'll write the documentation after the pac4j
> > releases
> > > (I
> > > > > > hope
> > > > > > > > next
> > > > > > > > > > >> week).
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > Thanks.
> > > > > > > > > > >> > > Best regards,
> > > > > > > > > > >> > > Jérôme
> > > > > > > > > > >> > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > 2015-12-02 19:18 GMT+01:00 larry mccay <
> > > > > > larry.mccay@gmail.com
> > > > > > > >:
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > > Fixed in
> > > > https://issues.apache.org/jira/browse/KNOX-636
> > > > > .
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > On Wed, Dec 2, 2015 at 12:42 PM, larry mccay <
> > > > > > > > > > larry.mccay@gmail.com
> > > > > > > > > > >> >
> > > > > > > > > > >> > > > wrote:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > > Sure - I can file a JIRA and commit a fix.
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > > > The secret generation should be done in one
> > > instance
> > > > > and
> > > > > > > > > > >> replicated
> > > > > > > > > > >> > > > across
> > > > > > > > > > >> > > > > others.
> > > > > > > > > > >> > > > > This replication/management of the credential
> > > stores
> > > > > is
> > > > > > > > > outside
> > > > > > > > > > of
> > > > > > > > > > >> > the
> > > > > > > > > > >> > > > > scope of Knox itself as of now.
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > > > Documentation is done in markdown and is
> > > > contributing
> > > > > > > > details
> > > > > > > > > > are
> > > > > > > > > > >> > > > > available at:
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > > > Which should give you a general idea.
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > > > Find an example like: ./trunk/books/0.7.0/
> > > > > > > > > > >> > > config_preauth_sso_provider.md
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > > > For an example of typical content and format.
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > > > Here is how that example renders:
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > > > You'll need to tie it into the rest of the
> book
> > -
> > > > just
> > > > > > > grep
> > > > > > > > > for
> > > > > > > > > > >> where
> > > > > > > > > > >> > > > that
> > > > > > > > > > >> > > > > filename is referenced.
> > > > > > > > > > >> > > > > To test how it renders build the site with:
> > "ant"
> > > > and
> > > > > > note
> > > > > > > > the
> > > > > > > > > > >> url to
> > > > > > > > > > >> > > the
> > > > > > > > > > >> > > > > 0.7.0 book.
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > > > On Wed, Dec 2, 2015 at 12:12 PM, Jérôme LELEU
> <
> > > > > > > > > leleuj@gmail.com
> > > > > > > > > > >
> > > > > > > > > > >> > > wrote:
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > > >> Hi,
> > > > > > > > > > >> > > > >>
> > > > > > > > > > >> > > > >> Why it doesn't work for pac4j while it works
> > for
> > > > > others
> > > > > > > is
> > > > > > > > a
> > > > > > > > > > bit
> > > > > > > > > > >> > > strange
> > > > > > > > > > >> > > > >> to
> > > > > > > > > > >> > > > >> me, but if you have the patch in front of
> your
> > > > eyes,
> > > > > > I'd
> > > > > > > > > rather
> > > > > > > > > > >> > prefer
> > > > > > > > > > >> > > > you
> > > > > > > > > > >> > > > >> to commit it. In all cases, I'll sync with
> the
> > > > > master.
> > > > > > > > > > >> > > > >>
> > > > > > > > > > >> > > > >> There was one question you didn't answer
> > > > previously:
> > > > > is
> > > > > > > the
> > > > > > > > > > >> password
> > > > > > > > > > >> > > > >> generated for the pac4j provider the same
> > across
> > > > all
> > > > > > > > gateway
> > > > > > > > > > >> > > instances?
> > > > > > > > > > >> > > > >> Because I expect to have the same value as I
> > use
> > > it
> > > > > to
> > > > > > > > > encrypt
> > > > > > > > > > /
> > > > > > > > > > >> > > decrypt
> > > > > > > > > > >> > > > >> data.
> > > > > > > > > > >> > > > >>
> > > > > > > > > > >> > > > >> I will add the Javadoc. After that, you can
> > > review
> > > > > the
> > > > > > > pull
> > > > > > > > > > >> request
> > > > > > > > > > >> > > more
> > > > > > > > > > >> > > > >> completely.
> > > > > > > > > > >> > > > >>
> > > > > > > > > > >> > > > >> What do you expect for the documentation?
> > > > > > > > > > >> > > > >>
> > > > > > > > > > >> > > > >> Notice that pac4j dependencies are still
> > > snapshots,
> > > > > but
> > > > > > > > they
> > > > > > > > > > >> will be
> > > > > > > > > > >> > > > >> released in a week or two.
> > > > > > > > > > >> > > > >>
> > > > > > > > > > >> > > > >> Thanks.
> > > > > > > > > > >> > > > >> Best regards,
> > > > > > > > > > >> > > > >> Jérôme
> > > > > > > > > > >> > > > >>
> > > > > > > > > > >> > > > >>
> > > > > > > > > > >> > > > >> 2015-12-02 17:51 GMT+01:00 larry mccay <
> > > > > > > > > larry.mccay@gmail.com
> > > > > > > > > > >:
> > > > > > > > > > >> > > > >>
> > > > > > > > > > >> > > > >> > Jérôme -
> > > > > > > > > > >> > > > >> >
> > > > > > > > > > >> > > > >> > If you would like to add that change as
> part
> > of
> > > > > your
> > > > > > > > patch
> > > > > > > > > or
> > > > > > > > > > >> as a
> > > > > > > > > > >> > > > >> > separately filed JIRA to fix a bug that
> would
> > > > > > certainly
> > > > > > > > be
> > > > > > > > > > >> > welcomed.
> > > > > > > > > > >> > > > >> > Otherwise, I can do it.
> > > > > > > > > > >> > > > >> >
> > > > > > > > > > >> > > > >> > Let me know.
> > > > > > > > > > >> > > > >> >
> > > > > > > > > > >> > > > >> > thanks,
> > > > > > > > > > >> > > > >> >
> > > > > > > > > > >> > > > >> > --larry
> > > > > > > > > > >> > > > >> >
> > > > > > > > > > >> > > > >> > On Wed, Dec 2, 2015 at 11:44 AM, larry
> mccay
> > <
> > > > > > > > > > >> > larry.mccay@gmail.com
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > >> > wrote:
> > > > > > > > > > >> > > > >> >
> > > > > > > > > > >> > > > >> > > Okay - I had to add an override of
> > > > > > getUserPrincipal()
> > > > > > > > to
> > > > > > > > > > the
> > > > > > > > > > >> > > > >> > > IdentityAsserterHttpServletRequestWrapper
> > and
> > > > > > return
> > > > > > > > the
> > > > > > > > > > >> member
> > > > > > > > > > >> > > > >> variable
> > > > > > > > > > >> > > > >> > > username and it works like a charm.
> > > > > > > > > > >> > > > >> > >
> > > > > > > > > > >> > > > >> > > Why I haven't seen this same behavior
> with
> > > > other
> > > > > > > > > providers
> > > > > > > > > > >> is a
> > > > > > > > > > >> > > bit
> > > > > > > > > > >> > > > >> of a
> > > > > > > > > > >> > > > >> > > mystery but they must be adding other
> > > wrappers
> > > > > that
> > > > > > > > > handle
> > > > > > > > > > >> it.
> > > > > > > > > > >> > > > >> > > This is quite cool, Jérôme!
> > > > > > > > > > >> > > > >> > >
> > > > > > > > > > >> > > > >> > > On Wed, Dec 2, 2015 at 10:41 AM, larry
> > mccay
> > > <
> > > > > > > > > > >> > > larry.mccay@gmail.com
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > > >> > > wrote:
> > > > > > > > > > >> > > > >> > >
> > > > > > > > > > >> > > > >> > >> That was it - thanks!
> > > > > > > > > > >> > > > >> > >>
> > > > > > > > > > >> > > > >> > >> On Wed, Dec 2, 2015 at 10:20 AM, Jérôme
> > > LELEU
> > > > <
> > > > > > > > > > >> > leleuj@gmail.com>
> > > > > > > > > > >> > > > >> wrote:
> > > > > > > > > > >> > > > >> > >>
> > > > > > > > > > >> > > > >> > >>> This is my exact command line: mvn
> > > -Prelease
> > > > > > clean
> > > > > > > > > > install
> > > > > > > > > > >> > > > >> -DskipTests
> > > > > > > > > > >> > > > >> > >>>
> > > > > > > > > > >> > > > >> > >>> You use an internal Maven repository to
> > > fetch
> > > > > > > > > > dependencies
> > > > > > > > > > >> > from
> > > > > > > > > > >> > > > >> > internet:
> > > > > > > > > > >> > > > >> > >>>
> > > > > > > > > > >> > >
> > > > > > > >
> > > http://nexus-private.hortonworks.com/nexus/content/groups/public/
> > > > > > > > > > >> > > > >> > >>>
> > > > > > > > > > >> > > > >> > >>> Does this repository have access to the
> > > > remote
> > > > > > > > > Snapshots
> > > > > > > > > > >> > > Sonatype
> > > > > > > > > > >> > > > >> repo?
> > > > > > > > > > >> > > > >> > >>>
> > > > > > > > > > >> > > > >> > >>>
> > > > > > > > > > >> > > > >> > >>>
> > > > > > > > > > >> > > > >> > >>> 2015-12-02 16:16 GMT+01:00 larry mccay
> <
> > > > > > > > > > >> larry.mccay@gmail.com
> > > > > > > > > > >> > >:
> > > > > > > > > > >> > > > >> > >>>
> > > > > > > > > > >> > > > >> > >>> > hmmm - I used:
> > > > > > > > > > >> > > > >> > >>> >
> > > > > > > > > > >> > > > >> > >>> > mvn clean install -DskipTests=true
> > > > -Prelease
> > > > > > > > > > >> > > > >> > >>> >
> > > > > > > > > > >> > > > >> > >>> > The repository entry is in there
> > already.
> > > > > > > > > > >> > > > >> > >>> > No worky.
> > > > > > > > > > >> > > > >> > >>> >
> > > > > > > > > > >> > > > >> > >>> > On Wed, Dec 2, 2015 at 10:12 AM,
> Jérôme
> > > > > LELEU <
> > > > > > > > > > >> > > leleuj@gmail.com
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > > >> > >>> wrote:
> > > > > > > > > > >> > > > >> > >>> >
> > > > > > > > > > >> > > > >> > >>> > > Hi,
> > > > > > > > > > >> > > > >> > >>> > >
> > > > > > > > > > >> > > > >> > >>> > > You need the j2e-pac4j dependencies
> > as
> > > > well
> > > > > > as
> > > > > > > > the
> > > > > > > > > > >> pac4j-*
> > > > > > > > > > >> > > > >> > >>> dependencies,
> > > > > > > > > > >> > > > >> > >>> > > but you don't need to build them
> > > locally
> > > > > > > > > (hopefully).
> > > > > > > > > > >> > > > >> > >>> > >
> > > > > > > > > > >> > > > >> > >>> > > But you need a dependency on the
> > > Sonatype
> > > > > > > > snapshots
> > > > > > > > > > >> > > repository
> > > > > > > > > > >> > > > >> > >>> (where the
> > > > > > > > > > >> > > > >> > >>> > > snapshot versions are hosted),
> which
> > is
> > > > > added
> > > > > > > for
> > > > > > > > > > >> Maven in
> > > > > > > > > > >> > > the
> > > > > > > > > > >> > > > >> root
> > > > > > > > > > >> > > > >> > >>> > > pom.xml:
> > > > > > > > > > >> > > > >> > >>> > >
> > > > > > > > > > >> > > > >> > >>> > >
> > > > > > > > > > >> > > > >> > >>> >
> > > > > > > > > > >> > > > >> > >>>
> > > > > > > > > > >> > > > >> >
> > > > > > > > > > >> > > > >>
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> > > > > > > > > > >> > > > >> > >>> > >
> > > > > > > > > > >> > > > >> > >>> > > If you use Ant for the build, there
> > is
> > > > > maybe
> > > > > > a
> > > > > > > > > glitch
> > > > > > > > > > >> to
> > > > > > > > > > >> > > find
> > > > > > > > > > >> > > > >> the
> > > > > > > > > > >> > > > >> > >>> > Sonatype
> > > > > > > > > > >> > > > >> > >>> > > Maven repo.
> > > > > > > > > > >> > > > >> > >>> > >
> > > > > > > > > > >> > > > >> > >>> > > Thanks.
> > > > > > > > > > >> > > > >> > >>> > > Best regards,
> > > > > > > > > > >> > > > >> > >>> > > Jérôme
> > > > > > > > > > >> > > > >> > >>> > >
> > > > > > > > > > >> > > > >> > >>> > >
> > > > > > > > > > >> > > > >> > >>> > > 2015-12-02 16:06 GMT+01:00 larry
> > mccay
> > > <
> > > > > > > > > > >> > > larry.mccay@gmail.com
> > > > > > > > > > >> > > > >:
> > > > > > > > > > >> > > > >> > >>> > >
> > > > > > > > > > >> > > > >> > >>> > > > 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.mccay@gmail.com>
> > > > > > > > > > >> > > > >> > >>> > > > wrote:
> > > > > > > > > > >> > > > >> > >>> > > >
> > > > > > > > > > >> > > > >> > >>> > > > > gateway-provider-security-pac4j
> > > > doesn't
> > > > > > > > build -
> > > > > > > > > > do
> > > > > > > > > > >> you
> > > > > > > > > > >> > > > have
> > > > > > > > > > >> > > > >> a
> > > > > > > > > > >> > > > >> > >>> pending
> > > > > > > > > > >> > > > >> > >>> > > > > change for your pom.xml or
> > > something?
> > > > > > > > > > >> > > > >> > >>> > > > >
> > > > > > > > > > >> > > > >> > >>> >
> > > > > > > > > > >> > > > >> > >>>
> > > > > > > > > > >> > > > >> > >>
> > > > > > > > > > >> > > > >> > >>
> > > > > > > > > > >> > > > >> > >
> > > > > > > > > > >> > > > >> >
> > > > > > > > > > >> > > > >>
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
The online CAS server (https://casserverpac4j.herokuapp.com/login) uses the
CAS protocol. SAML support can be tested using some online IdP like Okta,
TestShib, OpenFeide, Ssocircle...
2016-01-05 17:32 GMT+01:00 larry mccay <la...@gmail.com>:
> Great - thanks for that pointer!
>
> I will take a look at that and help drive the release related testing.
> Merge testing will be gated on CAS server (is this SAML or CAS protocol?)
> and testBasicAuth.
>
> On Tue, Jan 5, 2016 at 10:52 AM, Jérôme LELEU <le...@gmail.com> wrote:
>
> > Hi,
> >
> > Glad to hear back from you!
> >
> > The core pac4j project is fully tested by unit tests (and some
> integration
> > tests I run for major version), then all pac4j implementations are each
> > tested by the appropriate demo: j2e-pac4j-demo tests j2e-pac4j,
> > spring-webmvc-pac4j-demo tests spring-webmvc-pac4j, etc.
> >
> > So if you take a look at:
> >
> >
> https://github.com/pac4j/j2e-pac4j-demo/blob/master/src/main/java/org/pac4j/demo/j2e/config/DemoConfigFactory.java#L27
> > (for example), you have all the required information to test.
> >
> > I can do that on my own, but it can be good for the Knox community to
> start
> > working / testing the pac4j support. It's up to yoy.
> >
> > Thanks.
> > Best regards,
> > Jérôme
> >
> >
> > 2016-01-05 16:11 GMT+01:00 larry mccay <la...@gmail.com>:
> >
> > > Hello Jérôme -
> > >
> > > Happy New Year!
> > >
> > > I am going to start reviewing your updates today, hopefully.
> > > I was thinking that we need to start discussions on what the key
> usecases
> > > are and how to go about testing them.
> > > We can certainly test the testBasicAuth and against the hosted CAS
> server
> > > but what about FB, openid, OAuth, etc?
> > >
> > > I'm not sure that FB would be a key feature but OpenID Connect and
> OAuth
> > > would be - as is SAML.
> > > I think CAS buys us SAML testing - assuming that the configuration of
> the
> > > hosted server is actually a SAML 2 instance.
> > >
> > > What about the others?
> > >
> > > I don't know that we need to be able to test them all before merge but
> > some
> > > sort of manual verification would be great.
> > > We would need to be able to test them before the next release which
> would
> > > be featuring the pac4j functionality.
> > >
> > > Maybe you can describe how you go about testing such things for the
> pac4j
> > > project itself?
> > >
> > > thanks,
> > >
> > > --larry
> > >
> > >
> > > On Tue, Jan 5, 2016 at 9:55 AM, Jérôme LELEU <le...@gmail.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > Happy new year!
> > > >
> > > > A few days ago, I updated my patch of the pac4j gateway provider
> > > according
> > > > to all comments on https://issues.apache.org/jira/browse/KNOX-641 as
> > > well
> > > > as the documentation on KNOX-642.
> > > >
> > > > Is everything ok for the merge?
> > > >
> > > > Thanks.
> > > > Best regards,
> > > > Jérôme
> > > >
> > > >
> > > > 2015-12-14 15:28 GMT+01:00 larry mccay <la...@gmail.com>:
> > > >
> > > > > Hi Jérôme -
> > > > >
> > > > > Not sure if you saw but I added review comments to KNOX-641.
> > > > >
> > > > > I think that we need to determine whether we want the testBasicAuth
> > in
> > > > the
> > > > > provider itself.
> > > > >
> > > > > Let's follow up on the JIRA.
> > > > >
> > > > > thanks,
> > > > >
> > > > > --larry
> > > > >
> > > > > On Fri, Dec 11, 2015 at 8:44 AM, Jérôme LELEU <le...@gmail.com>
> > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > No problem. It can go into a version 0.8.0 if needed. The truth
> is
> > > that
> > > > > > there is only one change outside the new pac4j module, so I think
> > > risks
> > > > > are
> > > > > > extremly limited.
> > > > > >
> > > > > > Just let met know.
> > > > > >
> > > > > > Thanks.
> > > > > > Best regards,
> > > > > > Jérôme
> > > > > >
> > > > > >
> > > > > > 2015-12-11 14:23 GMT+01:00 larry mccay <la...@gmail.com>:
> > > > > >
> > > > > > > Hi Jérôme -
> > > > > > >
> > > > > > > I have unfortunately not had a chance to pull, review and test
> it
> > > yet
> > > > > and
> > > > > > > have intended to do that today.
> > > > > > > I apologize for the delay.
> > > > > > >
> > > > > > > I was actually thinking that this would go into a follow up
> > release
> > > > > that
> > > > > > we
> > > > > > > would try and get done rapidly after the 0.7.0 release but we
> can
> > > > > discuss
> > > > > > > the target and its chances of destabilizing 0.7.0.
> > > > > > >
> > > > > > > I believe that it is rather self-contained with only a few
> > changes
> > > to
> > > > > > > external modules.
> > > > > > >
> > > > > > > Opening the JIRAs is perfect and I was going to do that once I
> > > > started
> > > > > > the
> > > > > > > review.
> > > > > > >
> > > > > > > Let's continue review comments and collaboration on those
> JIRAs.
> > > > > > > I will add you to the contributors list so that we can assign
> > them
> > > to
> > > > > > you.
> > > > > > >
> > > > > > > Thank you for your contributions and your patience, Jérôme!
> > > > > > >
> > > > > > > --larry
> > > > > > >
> > > > > > > On Fri, Dec 11, 2015 at 3:00 AM, Jérôme LELEU <
> leleuj@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I didn't get any new feedback on the pull request so I assume
> > > > > > everything
> > > > > > > is
> > > > > > > > ok from your point of view.
> > > > > > > >
> > > > > > > > I released pac4j v1.8.1 and j2e-pac4j v1.2.1 so I updated the
> > > pull
> > > > > > > request
> > > > > > > > to use them and successfully re-tested everything.
> > > > > > > >
> > > > > > > > I opened KNOX-641 and submitted the corresponding patch.
> > > > > > > >
> > > > > > > > I also wrote the documentation, opened KNOX-642 and submitted
> > the
> > > > > > > > corresponding patch (just to let you know that it doesn't
> work
> > > out
> > > > of
> > > > > > the
> > > > > > > > box in Windows, I had to replace mvn.bat by mvn.cmd to make
> ant
> > > > > work).
> > > > > > > >
> > > > > > > > Even if the branch 0.7.0 has already been created, I assumed
> > this
> > > > new
> > > > > > > pac4j
> > > > > > > > provider will go into this version 0.7.0 (dependency on the
> > > > > > > 0.7.0-SNAPSHOT
> > > > > > > > parent version).
> > > > > > > >
> > > > > > > > Just let me know if everything is ok and when it's goind to
> be
> > > > > merged.
> > > > > > > >
> > > > > > > > Thanks.
> > > > > > > > Best regards,
> > > > > > > > Jérôme
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 2015-12-04 14:20 GMT+01:00 larry mccay <
> larry.mccay@gmail.com
> > >:
> > > > > > > >
> > > > > > > > > That ability to configure multiple mechanisms based on
> > > clientName
> > > > > is
> > > > > > > > really
> > > > > > > > > interesting for Knox.
> > > > > > > > > Currently, we require separate topologies per
> authentication
> > > > > > mechanism.
> > > > > > > > > The ability to configure them all in one is really great.
> > > > > > > > >
> > > > > > > > > We would need to think through the best way to provide the
> > > > > clientName
> > > > > > > > > parameter.
> > > > > > > > > Since this is targeting KnoxSSO it can actually be added to
> > the
> > > > > > > > providerURL
> > > > > > > > > used to redirect from the participating application.
> > > > > > > > > Regardless of the authentication mechanism used each
> > > application
> > > > > will
> > > > > > > > still
> > > > > > > > > get the same JWT based cookie.
> > > > > > > > >
> > > > > > > > > I think that should work really nicely.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Fri, Dec 4, 2015 at 7:17 AM, larry mccay <
> > > > larry.mccay@gmail.com
> > > > > >
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Excellent, Jérôme.
> > > > > > > > > > Thanks!
> > > > > > > > > >
> > > > > > > > > > On Fri, Dec 4, 2015 at 2:40 AM, Jérôme LELEU <
> > > leleuj@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > >> Hi,
> > > > > > > > > >>
> > > > > > > > > >> I will write how to configure the pac4j provider in the
> > > > > > > documentation,
> > > > > > > > > but
> > > > > > > > > >> I can already give you some insights.
> > > > > > > > > >>
> > > > > > > > > >> My main goal is always to respect the key design
> > principles
> > > of
> > > > > > pac4j
> > > > > > > > > >> whatever the environment / framework in which it is
> > > > implemented.
> > > > > > For
> > > > > > > > > Knox,
> > > > > > > > > >> I'm pretty happy with the use of the j2e-pac4j library,
> > > which
> > > > > > means
> > > > > > > > that
> > > > > > > > > >> almost all the pac4j features are available, especially
> > both
> > > > > > direct
> > > > > > > > and
> > > > > > > > > >> indirect clients. So it can do what Shiro already does
> but
> > > > also,
> > > > > > as
> > > > > > > we
> > > > > > > > > >> agreed together, supports remote authentications.
> > > > > > > > > >>
> > > > > > > > > >> It is only limited by what you can currently configure.
> > And
> > > > even
> > > > > > > > > >> configuration is a pac4j feature as the CAS server has
> the
> > > > same
> > > > > > > need.
> > > > > > > > > >> Everything happens in this class:
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java
> > > > > > > > > >> ,
> > > > > > > > > >> which allows you to configure Facebook, Twitter, a CAS
> > > > server, a
> > > > > > > SAML
> > > > > > > > > IdP
> > > > > > > > > >> or an OpenID Connect provider. All the provided
> parameters
> > > to
> > > > > the
> > > > > > > > pac4j
> > > > > > > > > >> provider are put into a Map and the
> > ConfigPropertiesFactory
> > > is
> > > > > > built
> > > > > > > > > with
> > > > > > > > > >> this Map to return the built client (= authentication
> > > > > mechanism).
> > > > > > > > > >>
> > > > > > > > > >> You have one more specific option for Knox as a basic
> > > > > > authentication
> > > > > > > > > popup
> > > > > > > > > >> where the username must match the password, you can
> define
> > > > that
> > > > > > by:
> > > > > > > > > >>
> > > > > > > > > >> <param>
> > > > > > > > > >> <name>clientName</name>
> > > > > > > > > >> <value>testBasicAuth</value>
> > > > > > > > > >> </param>
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >> It's for testing only.
> > > > > > > > > >>
> > > > > > > > > >> For a CAS server:
> > > > > > > > > >>
> > > > > > > > > >> <param>
> > > > > > > > > >> <name>cas.loginUrl</name>
> > > > > > > > > >> <value>https://casserverpac4j.herokuapp.com/login
> > </value>
> > > > > > > > > >> </param>
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >> Here are all the properties available for building
> clients
> > > > > (their
> > > > > > > > > meaning
> > > > > > > > > >> is obvious):
> > > > > > > > > >>
> > > > > > > > > >> facebook.id
> > > > > > > > > >> facebook.secret
> > > > > > > > > >> facebook.scope
> > > > > > > > > >> facebook.fields
> > > > > > > > > >> twitter.id
> > > > > > > > > >> twitter.secret
> > > > > > > > > >> saml.keystorePassword
> > > > > > > > > >> saml.privateKeyPassword
> > > > > > > > > >> saml.keystorePath
> > > > > > > > > >> saml.identityProviderMetadataPath
> > > > > > > > > >> saml.maximumAuthenticationLifetime
> > > > > > > > > >> saml.serviceProviderEntityId
> > > > > > > > > >> saml.serviceProviderMetadataPath
> > > > > > > > > >> cas.loginUrl
> > > > > > > > > >> cas.protocol
> > > > > > > > > >> oidc.id
> > > > > > > > > >> oidc.secret
> > > > > > > > > >> oidc.discoveryUri
> > > > > > > > > >> oidc.customParamKey1
> > > > > > > > > >> oidc.customParamValue1
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >> If you define multiple clients, the first one will be
> used
> > > for
> > > > > > > > > >> authentication, but you can explicitly choose the client
> > you
> > > > > want
> > > > > > to
> > > > > > > > use
> > > > > > > > > >> via the clientName parameter, assuming you want to
> switch
> > > from
> > > > > > > client
> > > > > > > > > >> depending on environment for example.
> > > > > > > > > >>
> > > > > > > > > >> So if you want to add some new authentication mechanism,
> > you
> > > > > must
> > > > > > > > first
> > > > > > > > > >> check that it is available in pac4j (if it's not, it's
> > > another
> > > > > > > > > discussion,
> > > > > > > > > >> but generally, it is). Then, you'll need to upgrade the
> > > > > > > > > >> ConfigPropertiesFactory by submitting a new pull request
> > to
> > > > the
> > > > > > > pac4j
> > > > > > > > > >> project (I can do it myself, but I'm sure you could do
> > that
> > > > > > easily),
> > > > > > > > > >> finally wait for the new pac4j release and switch pac4j
> > > > versions
> > > > > > in
> > > > > > > > Knox
> > > > > > > > > >> to
> > > > > > > > > >> benefit from the new feature.
> > > > > > > > > >> The good thing is that if someone related to the CAS
> > server
> > > > does
> > > > > > the
> > > > > > > > > same
> > > > > > > > > >> thing for CAS (in pac4j), you will automatically get it
> > when
> > > > > > you'll
> > > > > > > > > >> upgrade
> > > > > > > > > >> pac4j.
> > > > > > > > > >>
> > > > > > > > > >> To go even further, replacing LDAP Shiro authentication
> is
> > > > just
> > > > > a
> > > > > > > > matter
> > > > > > > > > >> of
> > > > > > > > > >> making pac4j LDAP authentication available via
> > configuration
> > > > > > > > parameters.
> > > > > > > > > >>
> > > > > > > > > >> I hope it was clear enough.
> > > > > > > > > >>
> > > > > > > > > >> Thanks.
> > > > > > > > > >> Best regards,
> > > > > > > > > >> Jérôme
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >> 2015-12-03 20:45 GMT+01:00 larry mccay <
> > > larry.mccay@gmail.com
> > > > >:
> > > > > > > > > >>
> > > > > > > > > >> > Excellent!
> > > > > > > > > >> >
> > > > > > > > > >> > I will carve out some time to do code review.
> > > > > > > > > >> > We will need to get some insights into how to go about
> > > > > testing:
> > > > > > > > > >> >
> > > > > > > > > >> > * is the CAS server going to be available for testing?
> > > > > > > > > >> > * what are the specific and generic/standard (if any)
> > > > > > > authentication
> > > > > > > > > >> > mechanisms available - for instance:
> > > > > > > > > >> > - Facebook, Google, LinkedIn and CAS are specifics
> > > > > > > > > >> > - OAuth 2, OpenID Connect, SAML are
> > generic/standards
> > > -
> > > > > that
> > > > > > > may
> > > > > > > > > be
> > > > > > > > > >> > used for the above specifics...
> > > > > > > > > >> > * how do we test things other than CAS - in terms of
> > > getting
> > > > > > > > > >> credentials,
> > > > > > > > > >> > configuration, etc
> > > > > > > > > >> >
> > > > > > > > > >> > We could certainly do this is phases as well.
> > > > > > > > > >> >
> > > > > > > > > >> > If you can enumerate the things that should work and
> > > provide
> > > > > > some
> > > > > > > > > >> testing
> > > > > > > > > >> > details for CAS or as many as possible and OpenID
> > Connect
> > > > then
> > > > > > we
> > > > > > > > can
> > > > > > > > > >> test
> > > > > > > > > >> > the specific implementations that you provide and
> enable
> > > the
> > > > > > > testing
> > > > > > > > > of
> > > > > > > > > >> > another OpenID Connect effort that is in the works in
> > the
> > > > > > > community.
> > > > > > > > > >> >
> > > > > > > > > >> > I'm not sure whether we want to commit contributions
> > that
> > > > are
> > > > > > > > > dependent
> > > > > > > > > >> on
> > > > > > > > > >> > snapshots - we certainly can't release with any such
> > > > > > dependencies.
> > > > > > > > > >> > I would hate to add a cleanup task to a release to
> make
> > > sure
> > > > > > there
> > > > > > > > are
> > > > > > > > > >> no
> > > > > > > > > >> > snapshots in there.
> > > > > > > > > >> > We will probably wait until after the pac4j releases
> to
> > > > > commit.
> > > > > > > > > >> >
> > > > > > > > > >> > I am really happy that this integration is happening
> and
> > > > that
> > > > > it
> > > > > > > > went
> > > > > > > > > >> > rather smoothly.
> > > > > > > > > >> > These sorts of authentication protocols are complex
> and
> > I
> > > > > think
> > > > > > we
> > > > > > > > > >> lined up
> > > > > > > > > >> > pretty well overall.
> > > > > > > > > >> >
> > > > > > > > > >> > Thanks for your work!
> > > > > > > > > >> >
> > > > > > > > > >> > On Thu, Dec 3, 2015 at 2:28 PM, Jérôme LELEU <
> > > > > leleuj@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > > >> >
> > > > > > > > > >> > > Hi,
> > > > > > > > > >> > >
> > > > > > > > > >> > > I just sync'ed with master, cleaned dependencies and
> > > added
> > > > > > > missing
> > > > > > > > > >> > > Javadocs. Everything works correctly now. Many
> thanks.
> > > > > > > > > >> > >
> > > > > > > > > >> > > The pull request is ready for a full code review:
> > > > > > > > > >> > > https://github.com/apache/knox/pull/2
> > > > > > > > > >> > >
> > > > > > > > > >> > > I'll write the documentation after the pac4j
> releases
> > (I
> > > > > hope
> > > > > > > next
> > > > > > > > > >> week).
> > > > > > > > > >> > >
> > > > > > > > > >> > > Thanks.
> > > > > > > > > >> > > Best regards,
> > > > > > > > > >> > > Jérôme
> > > > > > > > > >> > >
> > > > > > > > > >> > >
> > > > > > > > > >> > > 2015-12-02 19:18 GMT+01:00 larry mccay <
> > > > > larry.mccay@gmail.com
> > > > > > >:
> > > > > > > > > >> > >
> > > > > > > > > >> > > > Fixed in
> > > https://issues.apache.org/jira/browse/KNOX-636
> > > > .
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > On Wed, Dec 2, 2015 at 12:42 PM, larry mccay <
> > > > > > > > > larry.mccay@gmail.com
> > > > > > > > > >> >
> > > > > > > > > >> > > > wrote:
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > > Sure - I can file a JIRA and commit a fix.
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > > The secret generation should be done in one
> > instance
> > > > and
> > > > > > > > > >> replicated
> > > > > > > > > >> > > > across
> > > > > > > > > >> > > > > others.
> > > > > > > > > >> > > > > This replication/management of the credential
> > stores
> > > > is
> > > > > > > > outside
> > > > > > > > > of
> > > > > > > > > >> > the
> > > > > > > > > >> > > > > scope of Knox itself as of now.
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > > Documentation is done in markdown and is
> > > contributing
> > > > > > > details
> > > > > > > > > are
> > > > > > > > > >> > > > > available at:
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > >
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > > Which should give you a general idea.
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > > Find an example like: ./trunk/books/0.7.0/
> > > > > > > > > >> > > config_preauth_sso_provider.md
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > > For an example of typical content and format.
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > > Here is how that example renders:
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > >
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > > You'll need to tie it into the rest of the book
> -
> > > just
> > > > > > grep
> > > > > > > > for
> > > > > > > > > >> where
> > > > > > > > > >> > > > that
> > > > > > > > > >> > > > > filename is referenced.
> > > > > > > > > >> > > > > To test how it renders build the site with:
> "ant"
> > > and
> > > > > note
> > > > > > > the
> > > > > > > > > >> url to
> > > > > > > > > >> > > the
> > > > > > > > > >> > > > > 0.7.0 book.
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > > On Wed, Dec 2, 2015 at 12:12 PM, Jérôme LELEU <
> > > > > > > > leleuj@gmail.com
> > > > > > > > > >
> > > > > > > > > >> > > wrote:
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > >> Hi,
> > > > > > > > > >> > > > >>
> > > > > > > > > >> > > > >> Why it doesn't work for pac4j while it works
> for
> > > > others
> > > > > > is
> > > > > > > a
> > > > > > > > > bit
> > > > > > > > > >> > > strange
> > > > > > > > > >> > > > >> to
> > > > > > > > > >> > > > >> me, but if you have the patch in front of your
> > > eyes,
> > > > > I'd
> > > > > > > > rather
> > > > > > > > > >> > prefer
> > > > > > > > > >> > > > you
> > > > > > > > > >> > > > >> to commit it. In all cases, I'll sync with the
> > > > master.
> > > > > > > > > >> > > > >>
> > > > > > > > > >> > > > >> There was one question you didn't answer
> > > previously:
> > > > is
> > > > > > the
> > > > > > > > > >> password
> > > > > > > > > >> > > > >> generated for the pac4j provider the same
> across
> > > all
> > > > > > > gateway
> > > > > > > > > >> > > instances?
> > > > > > > > > >> > > > >> Because I expect to have the same value as I
> use
> > it
> > > > to
> > > > > > > > encrypt
> > > > > > > > > /
> > > > > > > > > >> > > decrypt
> > > > > > > > > >> > > > >> data.
> > > > > > > > > >> > > > >>
> > > > > > > > > >> > > > >> I will add the Javadoc. After that, you can
> > review
> > > > the
> > > > > > pull
> > > > > > > > > >> request
> > > > > > > > > >> > > more
> > > > > > > > > >> > > > >> completely.
> > > > > > > > > >> > > > >>
> > > > > > > > > >> > > > >> What do you expect for the documentation?
> > > > > > > > > >> > > > >>
> > > > > > > > > >> > > > >> Notice that pac4j dependencies are still
> > snapshots,
> > > > but
> > > > > > > they
> > > > > > > > > >> will be
> > > > > > > > > >> > > > >> released in a week or two.
> > > > > > > > > >> > > > >>
> > > > > > > > > >> > > > >> Thanks.
> > > > > > > > > >> > > > >> Best regards,
> > > > > > > > > >> > > > >> Jérôme
> > > > > > > > > >> > > > >>
> > > > > > > > > >> > > > >>
> > > > > > > > > >> > > > >> 2015-12-02 17:51 GMT+01:00 larry mccay <
> > > > > > > > larry.mccay@gmail.com
> > > > > > > > > >:
> > > > > > > > > >> > > > >>
> > > > > > > > > >> > > > >> > Jérôme -
> > > > > > > > > >> > > > >> >
> > > > > > > > > >> > > > >> > If you would like to add that change as part
> of
> > > > your
> > > > > > > patch
> > > > > > > > or
> > > > > > > > > >> as a
> > > > > > > > > >> > > > >> > separately filed JIRA to fix a bug that would
> > > > > certainly
> > > > > > > be
> > > > > > > > > >> > welcomed.
> > > > > > > > > >> > > > >> > Otherwise, I can do it.
> > > > > > > > > >> > > > >> >
> > > > > > > > > >> > > > >> > Let me know.
> > > > > > > > > >> > > > >> >
> > > > > > > > > >> > > > >> > thanks,
> > > > > > > > > >> > > > >> >
> > > > > > > > > >> > > > >> > --larry
> > > > > > > > > >> > > > >> >
> > > > > > > > > >> > > > >> > On Wed, Dec 2, 2015 at 11:44 AM, larry mccay
> <
> > > > > > > > > >> > larry.mccay@gmail.com
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > >> > wrote:
> > > > > > > > > >> > > > >> >
> > > > > > > > > >> > > > >> > > Okay - I had to add an override of
> > > > > getUserPrincipal()
> > > > > > > to
> > > > > > > > > the
> > > > > > > > > >> > > > >> > > IdentityAsserterHttpServletRequestWrapper
> and
> > > > > return
> > > > > > > the
> > > > > > > > > >> member
> > > > > > > > > >> > > > >> variable
> > > > > > > > > >> > > > >> > > username and it works like a charm.
> > > > > > > > > >> > > > >> > >
> > > > > > > > > >> > > > >> > > Why I haven't seen this same behavior with
> > > other
> > > > > > > > providers
> > > > > > > > > >> is a
> > > > > > > > > >> > > bit
> > > > > > > > > >> > > > >> of a
> > > > > > > > > >> > > > >> > > mystery but they must be adding other
> > wrappers
> > > > that
> > > > > > > > handle
> > > > > > > > > >> it.
> > > > > > > > > >> > > > >> > > This is quite cool, Jérôme!
> > > > > > > > > >> > > > >> > >
> > > > > > > > > >> > > > >> > > On Wed, Dec 2, 2015 at 10:41 AM, larry
> mccay
> > <
> > > > > > > > > >> > > larry.mccay@gmail.com
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > >> > > wrote:
> > > > > > > > > >> > > > >> > >
> > > > > > > > > >> > > > >> > >> That was it - thanks!
> > > > > > > > > >> > > > >> > >>
> > > > > > > > > >> > > > >> > >> On Wed, Dec 2, 2015 at 10:20 AM, Jérôme
> > LELEU
> > > <
> > > > > > > > > >> > leleuj@gmail.com>
> > > > > > > > > >> > > > >> wrote:
> > > > > > > > > >> > > > >> > >>
> > > > > > > > > >> > > > >> > >>> This is my exact command line: mvn
> > -Prelease
> > > > > clean
> > > > > > > > > install
> > > > > > > > > >> > > > >> -DskipTests
> > > > > > > > > >> > > > >> > >>>
> > > > > > > > > >> > > > >> > >>> You use an internal Maven repository to
> > fetch
> > > > > > > > > dependencies
> > > > > > > > > >> > from
> > > > > > > > > >> > > > >> > internet:
> > > > > > > > > >> > > > >> > >>>
> > > > > > > > > >> > >
> > > > > > >
> > http://nexus-private.hortonworks.com/nexus/content/groups/public/
> > > > > > > > > >> > > > >> > >>>
> > > > > > > > > >> > > > >> > >>> Does this repository have access to the
> > > remote
> > > > > > > > Snapshots
> > > > > > > > > >> > > Sonatype
> > > > > > > > > >> > > > >> repo?
> > > > > > > > > >> > > > >> > >>>
> > > > > > > > > >> > > > >> > >>>
> > > > > > > > > >> > > > >> > >>>
> > > > > > > > > >> > > > >> > >>> 2015-12-02 16:16 GMT+01:00 larry mccay <
> > > > > > > > > >> larry.mccay@gmail.com
> > > > > > > > > >> > >:
> > > > > > > > > >> > > > >> > >>>
> > > > > > > > > >> > > > >> > >>> > hmmm - I used:
> > > > > > > > > >> > > > >> > >>> >
> > > > > > > > > >> > > > >> > >>> > mvn clean install -DskipTests=true
> > > -Prelease
> > > > > > > > > >> > > > >> > >>> >
> > > > > > > > > >> > > > >> > >>> > The repository entry is in there
> already.
> > > > > > > > > >> > > > >> > >>> > No worky.
> > > > > > > > > >> > > > >> > >>> >
> > > > > > > > > >> > > > >> > >>> > On Wed, Dec 2, 2015 at 10:12 AM, Jérôme
> > > > LELEU <
> > > > > > > > > >> > > leleuj@gmail.com
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > >> > >>> wrote:
> > > > > > > > > >> > > > >> > >>> >
> > > > > > > > > >> > > > >> > >>> > > Hi,
> > > > > > > > > >> > > > >> > >>> > >
> > > > > > > > > >> > > > >> > >>> > > You need the j2e-pac4j dependencies
> as
> > > well
> > > > > as
> > > > > > > the
> > > > > > > > > >> pac4j-*
> > > > > > > > > >> > > > >> > >>> dependencies,
> > > > > > > > > >> > > > >> > >>> > > but you don't need to build them
> > locally
> > > > > > > > (hopefully).
> > > > > > > > > >> > > > >> > >>> > >
> > > > > > > > > >> > > > >> > >>> > > But you need a dependency on the
> > Sonatype
> > > > > > > snapshots
> > > > > > > > > >> > > repository
> > > > > > > > > >> > > > >> > >>> (where the
> > > > > > > > > >> > > > >> > >>> > > snapshot versions are hosted), which
> is
> > > > added
> > > > > > for
> > > > > > > > > >> Maven in
> > > > > > > > > >> > > the
> > > > > > > > > >> > > > >> root
> > > > > > > > > >> > > > >> > >>> > > pom.xml:
> > > > > > > > > >> > > > >> > >>> > >
> > > > > > > > > >> > > > >> > >>> > >
> > > > > > > > > >> > > > >> > >>> >
> > > > > > > > > >> > > > >> > >>>
> > > > > > > > > >> > > > >> >
> > > > > > > > > >> > > > >>
> > > > > > > > > >> > > >
> > > > > > > > > >> > >
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> > > > > > > > > >> > > > >> > >>> > >
> > > > > > > > > >> > > > >> > >>> > > If you use Ant for the build, there
> is
> > > > maybe
> > > > > a
> > > > > > > > glitch
> > > > > > > > > >> to
> > > > > > > > > >> > > find
> > > > > > > > > >> > > > >> the
> > > > > > > > > >> > > > >> > >>> > Sonatype
> > > > > > > > > >> > > > >> > >>> > > Maven repo.
> > > > > > > > > >> > > > >> > >>> > >
> > > > > > > > > >> > > > >> > >>> > > Thanks.
> > > > > > > > > >> > > > >> > >>> > > Best regards,
> > > > > > > > > >> > > > >> > >>> > > Jérôme
> > > > > > > > > >> > > > >> > >>> > >
> > > > > > > > > >> > > > >> > >>> > >
> > > > > > > > > >> > > > >> > >>> > > 2015-12-02 16:06 GMT+01:00 larry
> mccay
> > <
> > > > > > > > > >> > > larry.mccay@gmail.com
> > > > > > > > > >> > > > >:
> > > > > > > > > >> > > > >> > >>> > >
> > > > > > > > > >> > > > >> > >>> > > > 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.mccay@gmail.com>
> > > > > > > > > >> > > > >> > >>> > > > wrote:
> > > > > > > > > >> > > > >> > >>> > > >
> > > > > > > > > >> > > > >> > >>> > > > > gateway-provider-security-pac4j
> > > doesn't
> > > > > > > build -
> > > > > > > > > do
> > > > > > > > > >> you
> > > > > > > > > >> > > > have
> > > > > > > > > >> > > > >> a
> > > > > > > > > >> > > > >> > >>> pending
> > > > > > > > > >> > > > >> > >>> > > > > change for your pom.xml or
> > something?
> > > > > > > > > >> > > > >> > >>> > > > >
> > > > > > > > > >> > > > >> > >>> >
> > > > > > > > > >> > > > >> > >>>
> > > > > > > > > >> > > > >> > >>
> > > > > > > > > >> > > > >> > >>
> > > > > > > > > >> > > > >> > >
> > > > > > > > > >> > > > >> >
> > > > > > > > > >> > > > >>
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > >
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
Great - thanks for that pointer!
I will take a look at that and help drive the release related testing.
Merge testing will be gated on CAS server (is this SAML or CAS protocol?)
and testBasicAuth.
On Tue, Jan 5, 2016 at 10:52 AM, Jérôme LELEU <le...@gmail.com> wrote:
> Hi,
>
> Glad to hear back from you!
>
> The core pac4j project is fully tested by unit tests (and some integration
> tests I run for major version), then all pac4j implementations are each
> tested by the appropriate demo: j2e-pac4j-demo tests j2e-pac4j,
> spring-webmvc-pac4j-demo tests spring-webmvc-pac4j, etc.
>
> So if you take a look at:
>
> https://github.com/pac4j/j2e-pac4j-demo/blob/master/src/main/java/org/pac4j/demo/j2e/config/DemoConfigFactory.java#L27
> (for example), you have all the required information to test.
>
> I can do that on my own, but it can be good for the Knox community to start
> working / testing the pac4j support. It's up to yoy.
>
> Thanks.
> Best regards,
> Jérôme
>
>
> 2016-01-05 16:11 GMT+01:00 larry mccay <la...@gmail.com>:
>
> > Hello Jérôme -
> >
> > Happy New Year!
> >
> > I am going to start reviewing your updates today, hopefully.
> > I was thinking that we need to start discussions on what the key usecases
> > are and how to go about testing them.
> > We can certainly test the testBasicAuth and against the hosted CAS server
> > but what about FB, openid, OAuth, etc?
> >
> > I'm not sure that FB would be a key feature but OpenID Connect and OAuth
> > would be - as is SAML.
> > I think CAS buys us SAML testing - assuming that the configuration of the
> > hosted server is actually a SAML 2 instance.
> >
> > What about the others?
> >
> > I don't know that we need to be able to test them all before merge but
> some
> > sort of manual verification would be great.
> > We would need to be able to test them before the next release which would
> > be featuring the pac4j functionality.
> >
> > Maybe you can describe how you go about testing such things for the pac4j
> > project itself?
> >
> > thanks,
> >
> > --larry
> >
> >
> > On Tue, Jan 5, 2016 at 9:55 AM, Jérôme LELEU <le...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > Happy new year!
> > >
> > > A few days ago, I updated my patch of the pac4j gateway provider
> > according
> > > to all comments on https://issues.apache.org/jira/browse/KNOX-641 as
> > well
> > > as the documentation on KNOX-642.
> > >
> > > Is everything ok for the merge?
> > >
> > > Thanks.
> > > Best regards,
> > > Jérôme
> > >
> > >
> > > 2015-12-14 15:28 GMT+01:00 larry mccay <la...@gmail.com>:
> > >
> > > > Hi Jérôme -
> > > >
> > > > Not sure if you saw but I added review comments to KNOX-641.
> > > >
> > > > I think that we need to determine whether we want the testBasicAuth
> in
> > > the
> > > > provider itself.
> > > >
> > > > Let's follow up on the JIRA.
> > > >
> > > > thanks,
> > > >
> > > > --larry
> > > >
> > > > On Fri, Dec 11, 2015 at 8:44 AM, Jérôme LELEU <le...@gmail.com>
> > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > No problem. It can go into a version 0.8.0 if needed. The truth is
> > that
> > > > > there is only one change outside the new pac4j module, so I think
> > risks
> > > > are
> > > > > extremly limited.
> > > > >
> > > > > Just let met know.
> > > > >
> > > > > Thanks.
> > > > > Best regards,
> > > > > Jérôme
> > > > >
> > > > >
> > > > > 2015-12-11 14:23 GMT+01:00 larry mccay <la...@gmail.com>:
> > > > >
> > > > > > Hi Jérôme -
> > > > > >
> > > > > > I have unfortunately not had a chance to pull, review and test it
> > yet
> > > > and
> > > > > > have intended to do that today.
> > > > > > I apologize for the delay.
> > > > > >
> > > > > > I was actually thinking that this would go into a follow up
> release
> > > > that
> > > > > we
> > > > > > would try and get done rapidly after the 0.7.0 release but we can
> > > > discuss
> > > > > > the target and its chances of destabilizing 0.7.0.
> > > > > >
> > > > > > I believe that it is rather self-contained with only a few
> changes
> > to
> > > > > > external modules.
> > > > > >
> > > > > > Opening the JIRAs is perfect and I was going to do that once I
> > > started
> > > > > the
> > > > > > review.
> > > > > >
> > > > > > Let's continue review comments and collaboration on those JIRAs.
> > > > > > I will add you to the contributors list so that we can assign
> them
> > to
> > > > > you.
> > > > > >
> > > > > > Thank you for your contributions and your patience, Jérôme!
> > > > > >
> > > > > > --larry
> > > > > >
> > > > > > On Fri, Dec 11, 2015 at 3:00 AM, Jérôme LELEU <le...@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I didn't get any new feedback on the pull request so I assume
> > > > > everything
> > > > > > is
> > > > > > > ok from your point of view.
> > > > > > >
> > > > > > > I released pac4j v1.8.1 and j2e-pac4j v1.2.1 so I updated the
> > pull
> > > > > > request
> > > > > > > to use them and successfully re-tested everything.
> > > > > > >
> > > > > > > I opened KNOX-641 and submitted the corresponding patch.
> > > > > > >
> > > > > > > I also wrote the documentation, opened KNOX-642 and submitted
> the
> > > > > > > corresponding patch (just to let you know that it doesn't work
> > out
> > > of
> > > > > the
> > > > > > > box in Windows, I had to replace mvn.bat by mvn.cmd to make ant
> > > > work).
> > > > > > >
> > > > > > > Even if the branch 0.7.0 has already been created, I assumed
> this
> > > new
> > > > > > pac4j
> > > > > > > provider will go into this version 0.7.0 (dependency on the
> > > > > > 0.7.0-SNAPSHOT
> > > > > > > parent version).
> > > > > > >
> > > > > > > Just let me know if everything is ok and when it's goind to be
> > > > merged.
> > > > > > >
> > > > > > > Thanks.
> > > > > > > Best regards,
> > > > > > > Jérôme
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 2015-12-04 14:20 GMT+01:00 larry mccay <larry.mccay@gmail.com
> >:
> > > > > > >
> > > > > > > > That ability to configure multiple mechanisms based on
> > clientName
> > > > is
> > > > > > > really
> > > > > > > > interesting for Knox.
> > > > > > > > Currently, we require separate topologies per authentication
> > > > > mechanism.
> > > > > > > > The ability to configure them all in one is really great.
> > > > > > > >
> > > > > > > > We would need to think through the best way to provide the
> > > > clientName
> > > > > > > > parameter.
> > > > > > > > Since this is targeting KnoxSSO it can actually be added to
> the
> > > > > > > providerURL
> > > > > > > > used to redirect from the participating application.
> > > > > > > > Regardless of the authentication mechanism used each
> > application
> > > > will
> > > > > > > still
> > > > > > > > get the same JWT based cookie.
> > > > > > > >
> > > > > > > > I think that should work really nicely.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Dec 4, 2015 at 7:17 AM, larry mccay <
> > > larry.mccay@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Excellent, Jérôme.
> > > > > > > > > Thanks!
> > > > > > > > >
> > > > > > > > > On Fri, Dec 4, 2015 at 2:40 AM, Jérôme LELEU <
> > leleuj@gmail.com
> > > >
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > >> Hi,
> > > > > > > > >>
> > > > > > > > >> I will write how to configure the pac4j provider in the
> > > > > > documentation,
> > > > > > > > but
> > > > > > > > >> I can already give you some insights.
> > > > > > > > >>
> > > > > > > > >> My main goal is always to respect the key design
> principles
> > of
> > > > > pac4j
> > > > > > > > >> whatever the environment / framework in which it is
> > > implemented.
> > > > > For
> > > > > > > > Knox,
> > > > > > > > >> I'm pretty happy with the use of the j2e-pac4j library,
> > which
> > > > > means
> > > > > > > that
> > > > > > > > >> almost all the pac4j features are available, especially
> both
> > > > > direct
> > > > > > > and
> > > > > > > > >> indirect clients. So it can do what Shiro already does but
> > > also,
> > > > > as
> > > > > > we
> > > > > > > > >> agreed together, supports remote authentications.
> > > > > > > > >>
> > > > > > > > >> It is only limited by what you can currently configure.
> And
> > > even
> > > > > > > > >> configuration is a pac4j feature as the CAS server has the
> > > same
> > > > > > need.
> > > > > > > > >> Everything happens in this class:
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java
> > > > > > > > >> ,
> > > > > > > > >> which allows you to configure Facebook, Twitter, a CAS
> > > server, a
> > > > > > SAML
> > > > > > > > IdP
> > > > > > > > >> or an OpenID Connect provider. All the provided parameters
> > to
> > > > the
> > > > > > > pac4j
> > > > > > > > >> provider are put into a Map and the
> ConfigPropertiesFactory
> > is
> > > > > built
> > > > > > > > with
> > > > > > > > >> this Map to return the built client (= authentication
> > > > mechanism).
> > > > > > > > >>
> > > > > > > > >> You have one more specific option for Knox as a basic
> > > > > authentication
> > > > > > > > popup
> > > > > > > > >> where the username must match the password, you can define
> > > that
> > > > > by:
> > > > > > > > >>
> > > > > > > > >> <param>
> > > > > > > > >> <name>clientName</name>
> > > > > > > > >> <value>testBasicAuth</value>
> > > > > > > > >> </param>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> It's for testing only.
> > > > > > > > >>
> > > > > > > > >> For a CAS server:
> > > > > > > > >>
> > > > > > > > >> <param>
> > > > > > > > >> <name>cas.loginUrl</name>
> > > > > > > > >> <value>https://casserverpac4j.herokuapp.com/login
> </value>
> > > > > > > > >> </param>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> Here are all the properties available for building clients
> > > > (their
> > > > > > > > meaning
> > > > > > > > >> is obvious):
> > > > > > > > >>
> > > > > > > > >> facebook.id
> > > > > > > > >> facebook.secret
> > > > > > > > >> facebook.scope
> > > > > > > > >> facebook.fields
> > > > > > > > >> twitter.id
> > > > > > > > >> twitter.secret
> > > > > > > > >> saml.keystorePassword
> > > > > > > > >> saml.privateKeyPassword
> > > > > > > > >> saml.keystorePath
> > > > > > > > >> saml.identityProviderMetadataPath
> > > > > > > > >> saml.maximumAuthenticationLifetime
> > > > > > > > >> saml.serviceProviderEntityId
> > > > > > > > >> saml.serviceProviderMetadataPath
> > > > > > > > >> cas.loginUrl
> > > > > > > > >> cas.protocol
> > > > > > > > >> oidc.id
> > > > > > > > >> oidc.secret
> > > > > > > > >> oidc.discoveryUri
> > > > > > > > >> oidc.customParamKey1
> > > > > > > > >> oidc.customParamValue1
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> If you define multiple clients, the first one will be used
> > for
> > > > > > > > >> authentication, but you can explicitly choose the client
> you
> > > > want
> > > > > to
> > > > > > > use
> > > > > > > > >> via the clientName parameter, assuming you want to switch
> > from
> > > > > > client
> > > > > > > > >> depending on environment for example.
> > > > > > > > >>
> > > > > > > > >> So if you want to add some new authentication mechanism,
> you
> > > > must
> > > > > > > first
> > > > > > > > >> check that it is available in pac4j (if it's not, it's
> > another
> > > > > > > > discussion,
> > > > > > > > >> but generally, it is). Then, you'll need to upgrade the
> > > > > > > > >> ConfigPropertiesFactory by submitting a new pull request
> to
> > > the
> > > > > > pac4j
> > > > > > > > >> project (I can do it myself, but I'm sure you could do
> that
> > > > > easily),
> > > > > > > > >> finally wait for the new pac4j release and switch pac4j
> > > versions
> > > > > in
> > > > > > > Knox
> > > > > > > > >> to
> > > > > > > > >> benefit from the new feature.
> > > > > > > > >> The good thing is that if someone related to the CAS
> server
> > > does
> > > > > the
> > > > > > > > same
> > > > > > > > >> thing for CAS (in pac4j), you will automatically get it
> when
> > > > > you'll
> > > > > > > > >> upgrade
> > > > > > > > >> pac4j.
> > > > > > > > >>
> > > > > > > > >> To go even further, replacing LDAP Shiro authentication is
> > > just
> > > > a
> > > > > > > matter
> > > > > > > > >> of
> > > > > > > > >> making pac4j LDAP authentication available via
> configuration
> > > > > > > parameters.
> > > > > > > > >>
> > > > > > > > >> I hope it was clear enough.
> > > > > > > > >>
> > > > > > > > >> Thanks.
> > > > > > > > >> Best regards,
> > > > > > > > >> Jérôme
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> 2015-12-03 20:45 GMT+01:00 larry mccay <
> > larry.mccay@gmail.com
> > > >:
> > > > > > > > >>
> > > > > > > > >> > Excellent!
> > > > > > > > >> >
> > > > > > > > >> > I will carve out some time to do code review.
> > > > > > > > >> > We will need to get some insights into how to go about
> > > > testing:
> > > > > > > > >> >
> > > > > > > > >> > * is the CAS server going to be available for testing?
> > > > > > > > >> > * what are the specific and generic/standard (if any)
> > > > > > authentication
> > > > > > > > >> > mechanisms available - for instance:
> > > > > > > > >> > - Facebook, Google, LinkedIn and CAS are specifics
> > > > > > > > >> > - OAuth 2, OpenID Connect, SAML are
> generic/standards
> > -
> > > > that
> > > > > > may
> > > > > > > > be
> > > > > > > > >> > used for the above specifics...
> > > > > > > > >> > * how do we test things other than CAS - in terms of
> > getting
> > > > > > > > >> credentials,
> > > > > > > > >> > configuration, etc
> > > > > > > > >> >
> > > > > > > > >> > We could certainly do this is phases as well.
> > > > > > > > >> >
> > > > > > > > >> > If you can enumerate the things that should work and
> > provide
> > > > > some
> > > > > > > > >> testing
> > > > > > > > >> > details for CAS or as many as possible and OpenID
> Connect
> > > then
> > > > > we
> > > > > > > can
> > > > > > > > >> test
> > > > > > > > >> > the specific implementations that you provide and enable
> > the
> > > > > > testing
> > > > > > > > of
> > > > > > > > >> > another OpenID Connect effort that is in the works in
> the
> > > > > > community.
> > > > > > > > >> >
> > > > > > > > >> > I'm not sure whether we want to commit contributions
> that
> > > are
> > > > > > > > dependent
> > > > > > > > >> on
> > > > > > > > >> > snapshots - we certainly can't release with any such
> > > > > dependencies.
> > > > > > > > >> > I would hate to add a cleanup task to a release to make
> > sure
> > > > > there
> > > > > > > are
> > > > > > > > >> no
> > > > > > > > >> > snapshots in there.
> > > > > > > > >> > We will probably wait until after the pac4j releases to
> > > > commit.
> > > > > > > > >> >
> > > > > > > > >> > I am really happy that this integration is happening and
> > > that
> > > > it
> > > > > > > went
> > > > > > > > >> > rather smoothly.
> > > > > > > > >> > These sorts of authentication protocols are complex and
> I
> > > > think
> > > > > we
> > > > > > > > >> lined up
> > > > > > > > >> > pretty well overall.
> > > > > > > > >> >
> > > > > > > > >> > Thanks for your work!
> > > > > > > > >> >
> > > > > > > > >> > On Thu, Dec 3, 2015 at 2:28 PM, Jérôme LELEU <
> > > > leleuj@gmail.com>
> > > > > > > > wrote:
> > > > > > > > >> >
> > > > > > > > >> > > Hi,
> > > > > > > > >> > >
> > > > > > > > >> > > I just sync'ed with master, cleaned dependencies and
> > added
> > > > > > missing
> > > > > > > > >> > > Javadocs. Everything works correctly now. Many thanks.
> > > > > > > > >> > >
> > > > > > > > >> > > The pull request is ready for a full code review:
> > > > > > > > >> > > https://github.com/apache/knox/pull/2
> > > > > > > > >> > >
> > > > > > > > >> > > I'll write the documentation after the pac4j releases
> (I
> > > > hope
> > > > > > next
> > > > > > > > >> week).
> > > > > > > > >> > >
> > > > > > > > >> > > Thanks.
> > > > > > > > >> > > Best regards,
> > > > > > > > >> > > Jérôme
> > > > > > > > >> > >
> > > > > > > > >> > >
> > > > > > > > >> > > 2015-12-02 19:18 GMT+01:00 larry mccay <
> > > > larry.mccay@gmail.com
> > > > > >:
> > > > > > > > >> > >
> > > > > > > > >> > > > Fixed in
> > https://issues.apache.org/jira/browse/KNOX-636
> > > .
> > > > > > > > >> > > >
> > > > > > > > >> > > > On Wed, Dec 2, 2015 at 12:42 PM, larry mccay <
> > > > > > > > larry.mccay@gmail.com
> > > > > > > > >> >
> > > > > > > > >> > > > wrote:
> > > > > > > > >> > > >
> > > > > > > > >> > > > > Sure - I can file a JIRA and commit a fix.
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > The secret generation should be done in one
> instance
> > > and
> > > > > > > > >> replicated
> > > > > > > > >> > > > across
> > > > > > > > >> > > > > others.
> > > > > > > > >> > > > > This replication/management of the credential
> stores
> > > is
> > > > > > > outside
> > > > > > > > of
> > > > > > > > >> > the
> > > > > > > > >> > > > > scope of Knox itself as of now.
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > Documentation is done in markdown and is
> > contributing
> > > > > > details
> > > > > > > > are
> > > > > > > > >> > > > > available at:
> > > > > > > > >> > > > >
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > Which should give you a general idea.
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > Find an example like: ./trunk/books/0.7.0/
> > > > > > > > >> > > config_preauth_sso_provider.md
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > For an example of typical content and format.
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > Here is how that example renders:
> > > > > > > > >> > > > >
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > You'll need to tie it into the rest of the book -
> > just
> > > > > grep
> > > > > > > for
> > > > > > > > >> where
> > > > > > > > >> > > > that
> > > > > > > > >> > > > > filename is referenced.
> > > > > > > > >> > > > > To test how it renders build the site with: "ant"
> > and
> > > > note
> > > > > > the
> > > > > > > > >> url to
> > > > > > > > >> > > the
> > > > > > > > >> > > > > 0.7.0 book.
> > > > > > > > >> > > > >
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > On Wed, Dec 2, 2015 at 12:12 PM, Jérôme LELEU <
> > > > > > > leleuj@gmail.com
> > > > > > > > >
> > > > > > > > >> > > wrote:
> > > > > > > > >> > > > >
> > > > > > > > >> > > > >> Hi,
> > > > > > > > >> > > > >>
> > > > > > > > >> > > > >> Why it doesn't work for pac4j while it works for
> > > others
> > > > > is
> > > > > > a
> > > > > > > > bit
> > > > > > > > >> > > strange
> > > > > > > > >> > > > >> to
> > > > > > > > >> > > > >> me, but if you have the patch in front of your
> > eyes,
> > > > I'd
> > > > > > > rather
> > > > > > > > >> > prefer
> > > > > > > > >> > > > you
> > > > > > > > >> > > > >> to commit it. In all cases, I'll sync with the
> > > master.
> > > > > > > > >> > > > >>
> > > > > > > > >> > > > >> There was one question you didn't answer
> > previously:
> > > is
> > > > > the
> > > > > > > > >> password
> > > > > > > > >> > > > >> generated for the pac4j provider the same across
> > all
> > > > > > gateway
> > > > > > > > >> > > instances?
> > > > > > > > >> > > > >> Because I expect to have the same value as I use
> it
> > > to
> > > > > > > encrypt
> > > > > > > > /
> > > > > > > > >> > > decrypt
> > > > > > > > >> > > > >> data.
> > > > > > > > >> > > > >>
> > > > > > > > >> > > > >> I will add the Javadoc. After that, you can
> review
> > > the
> > > > > pull
> > > > > > > > >> request
> > > > > > > > >> > > more
> > > > > > > > >> > > > >> completely.
> > > > > > > > >> > > > >>
> > > > > > > > >> > > > >> What do you expect for the documentation?
> > > > > > > > >> > > > >>
> > > > > > > > >> > > > >> Notice that pac4j dependencies are still
> snapshots,
> > > but
> > > > > > they
> > > > > > > > >> will be
> > > > > > > > >> > > > >> released in a week or two.
> > > > > > > > >> > > > >>
> > > > > > > > >> > > > >> Thanks.
> > > > > > > > >> > > > >> Best regards,
> > > > > > > > >> > > > >> Jérôme
> > > > > > > > >> > > > >>
> > > > > > > > >> > > > >>
> > > > > > > > >> > > > >> 2015-12-02 17:51 GMT+01:00 larry mccay <
> > > > > > > larry.mccay@gmail.com
> > > > > > > > >:
> > > > > > > > >> > > > >>
> > > > > > > > >> > > > >> > Jérôme -
> > > > > > > > >> > > > >> >
> > > > > > > > >> > > > >> > If you would like to add that change as part of
> > > your
> > > > > > patch
> > > > > > > or
> > > > > > > > >> as a
> > > > > > > > >> > > > >> > separately filed JIRA to fix a bug that would
> > > > certainly
> > > > > > be
> > > > > > > > >> > welcomed.
> > > > > > > > >> > > > >> > Otherwise, I can do it.
> > > > > > > > >> > > > >> >
> > > > > > > > >> > > > >> > Let me know.
> > > > > > > > >> > > > >> >
> > > > > > > > >> > > > >> > thanks,
> > > > > > > > >> > > > >> >
> > > > > > > > >> > > > >> > --larry
> > > > > > > > >> > > > >> >
> > > > > > > > >> > > > >> > On Wed, Dec 2, 2015 at 11:44 AM, larry mccay <
> > > > > > > > >> > larry.mccay@gmail.com
> > > > > > > > >> > > >
> > > > > > > > >> > > > >> > wrote:
> > > > > > > > >> > > > >> >
> > > > > > > > >> > > > >> > > Okay - I had to add an override of
> > > > getUserPrincipal()
> > > > > > to
> > > > > > > > the
> > > > > > > > >> > > > >> > > IdentityAsserterHttpServletRequestWrapper and
> > > > return
> > > > > > the
> > > > > > > > >> member
> > > > > > > > >> > > > >> variable
> > > > > > > > >> > > > >> > > username and it works like a charm.
> > > > > > > > >> > > > >> > >
> > > > > > > > >> > > > >> > > Why I haven't seen this same behavior with
> > other
> > > > > > > providers
> > > > > > > > >> is a
> > > > > > > > >> > > bit
> > > > > > > > >> > > > >> of a
> > > > > > > > >> > > > >> > > mystery but they must be adding other
> wrappers
> > > that
> > > > > > > handle
> > > > > > > > >> it.
> > > > > > > > >> > > > >> > > This is quite cool, Jérôme!
> > > > > > > > >> > > > >> > >
> > > > > > > > >> > > > >> > > On Wed, Dec 2, 2015 at 10:41 AM, larry mccay
> <
> > > > > > > > >> > > larry.mccay@gmail.com
> > > > > > > > >> > > > >
> > > > > > > > >> > > > >> > > wrote:
> > > > > > > > >> > > > >> > >
> > > > > > > > >> > > > >> > >> That was it - thanks!
> > > > > > > > >> > > > >> > >>
> > > > > > > > >> > > > >> > >> On Wed, Dec 2, 2015 at 10:20 AM, Jérôme
> LELEU
> > <
> > > > > > > > >> > leleuj@gmail.com>
> > > > > > > > >> > > > >> wrote:
> > > > > > > > >> > > > >> > >>
> > > > > > > > >> > > > >> > >>> This is my exact command line: mvn
> -Prelease
> > > > clean
> > > > > > > > install
> > > > > > > > >> > > > >> -DskipTests
> > > > > > > > >> > > > >> > >>>
> > > > > > > > >> > > > >> > >>> You use an internal Maven repository to
> fetch
> > > > > > > > dependencies
> > > > > > > > >> > from
> > > > > > > > >> > > > >> > internet:
> > > > > > > > >> > > > >> > >>>
> > > > > > > > >> > >
> > > > > >
> http://nexus-private.hortonworks.com/nexus/content/groups/public/
> > > > > > > > >> > > > >> > >>>
> > > > > > > > >> > > > >> > >>> Does this repository have access to the
> > remote
> > > > > > > Snapshots
> > > > > > > > >> > > Sonatype
> > > > > > > > >> > > > >> repo?
> > > > > > > > >> > > > >> > >>>
> > > > > > > > >> > > > >> > >>>
> > > > > > > > >> > > > >> > >>>
> > > > > > > > >> > > > >> > >>> 2015-12-02 16:16 GMT+01:00 larry mccay <
> > > > > > > > >> larry.mccay@gmail.com
> > > > > > > > >> > >:
> > > > > > > > >> > > > >> > >>>
> > > > > > > > >> > > > >> > >>> > hmmm - I used:
> > > > > > > > >> > > > >> > >>> >
> > > > > > > > >> > > > >> > >>> > mvn clean install -DskipTests=true
> > -Prelease
> > > > > > > > >> > > > >> > >>> >
> > > > > > > > >> > > > >> > >>> > The repository entry is in there already.
> > > > > > > > >> > > > >> > >>> > No worky.
> > > > > > > > >> > > > >> > >>> >
> > > > > > > > >> > > > >> > >>> > On Wed, Dec 2, 2015 at 10:12 AM, Jérôme
> > > LELEU <
> > > > > > > > >> > > leleuj@gmail.com
> > > > > > > > >> > > > >
> > > > > > > > >> > > > >> > >>> wrote:
> > > > > > > > >> > > > >> > >>> >
> > > > > > > > >> > > > >> > >>> > > Hi,
> > > > > > > > >> > > > >> > >>> > >
> > > > > > > > >> > > > >> > >>> > > You need the j2e-pac4j dependencies as
> > well
> > > > as
> > > > > > the
> > > > > > > > >> pac4j-*
> > > > > > > > >> > > > >> > >>> dependencies,
> > > > > > > > >> > > > >> > >>> > > but you don't need to build them
> locally
> > > > > > > (hopefully).
> > > > > > > > >> > > > >> > >>> > >
> > > > > > > > >> > > > >> > >>> > > But you need a dependency on the
> Sonatype
> > > > > > snapshots
> > > > > > > > >> > > repository
> > > > > > > > >> > > > >> > >>> (where the
> > > > > > > > >> > > > >> > >>> > > snapshot versions are hosted), which is
> > > added
> > > > > for
> > > > > > > > >> Maven in
> > > > > > > > >> > > the
> > > > > > > > >> > > > >> root
> > > > > > > > >> > > > >> > >>> > > pom.xml:
> > > > > > > > >> > > > >> > >>> > >
> > > > > > > > >> > > > >> > >>> > >
> > > > > > > > >> > > > >> > >>> >
> > > > > > > > >> > > > >> > >>>
> > > > > > > > >> > > > >> >
> > > > > > > > >> > > > >>
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> > > > > > > > >> > > > >> > >>> > >
> > > > > > > > >> > > > >> > >>> > > If you use Ant for the build, there is
> > > maybe
> > > > a
> > > > > > > glitch
> > > > > > > > >> to
> > > > > > > > >> > > find
> > > > > > > > >> > > > >> the
> > > > > > > > >> > > > >> > >>> > Sonatype
> > > > > > > > >> > > > >> > >>> > > Maven repo.
> > > > > > > > >> > > > >> > >>> > >
> > > > > > > > >> > > > >> > >>> > > Thanks.
> > > > > > > > >> > > > >> > >>> > > Best regards,
> > > > > > > > >> > > > >> > >>> > > Jérôme
> > > > > > > > >> > > > >> > >>> > >
> > > > > > > > >> > > > >> > >>> > >
> > > > > > > > >> > > > >> > >>> > > 2015-12-02 16:06 GMT+01:00 larry mccay
> <
> > > > > > > > >> > > larry.mccay@gmail.com
> > > > > > > > >> > > > >:
> > > > > > > > >> > > > >> > >>> > >
> > > > > > > > >> > > > >> > >>> > > > 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.mccay@gmail.com>
> > > > > > > > >> > > > >> > >>> > > > wrote:
> > > > > > > > >> > > > >> > >>> > > >
> > > > > > > > >> > > > >> > >>> > > > > gateway-provider-security-pac4j
> > doesn't
> > > > > > build -
> > > > > > > > do
> > > > > > > > >> you
> > > > > > > > >> > > > have
> > > > > > > > >> > > > >> a
> > > > > > > > >> > > > >> > >>> pending
> > > > > > > > >> > > > >> > >>> > > > > change for your pom.xml or
> something?
> > > > > > > > >> > > > >> > >>> > > > >
> > > > > > > > >> > > > >> > >>> >
> > > > > > > > >> > > > >> > >>>
> > > > > > > > >> > > > >> > >>
> > > > > > > > >> > > > >> > >>
> > > > > > > > >> > > > >> > >
> > > > > > > > >> > > > >> >
> > > > > > > > >> > > > >>
> > > > > > > > >> > > > >
> > > > > > > > >> > > > >
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Hi,
Glad to hear back from you!
The core pac4j project is fully tested by unit tests (and some integration
tests I run for major version), then all pac4j implementations are each
tested by the appropriate demo: j2e-pac4j-demo tests j2e-pac4j,
spring-webmvc-pac4j-demo tests spring-webmvc-pac4j, etc.
So if you take a look at:
https://github.com/pac4j/j2e-pac4j-demo/blob/master/src/main/java/org/pac4j/demo/j2e/config/DemoConfigFactory.java#L27
(for example), you have all the required information to test.
I can do that on my own, but it can be good for the Knox community to start
working / testing the pac4j support. It's up to yoy.
Thanks.
Best regards,
Jérôme
2016-01-05 16:11 GMT+01:00 larry mccay <la...@gmail.com>:
> Hello Jérôme -
>
> Happy New Year!
>
> I am going to start reviewing your updates today, hopefully.
> I was thinking that we need to start discussions on what the key usecases
> are and how to go about testing them.
> We can certainly test the testBasicAuth and against the hosted CAS server
> but what about FB, openid, OAuth, etc?
>
> I'm not sure that FB would be a key feature but OpenID Connect and OAuth
> would be - as is SAML.
> I think CAS buys us SAML testing - assuming that the configuration of the
> hosted server is actually a SAML 2 instance.
>
> What about the others?
>
> I don't know that we need to be able to test them all before merge but some
> sort of manual verification would be great.
> We would need to be able to test them before the next release which would
> be featuring the pac4j functionality.
>
> Maybe you can describe how you go about testing such things for the pac4j
> project itself?
>
> thanks,
>
> --larry
>
>
> On Tue, Jan 5, 2016 at 9:55 AM, Jérôme LELEU <le...@gmail.com> wrote:
>
> > Hi,
> >
> > Happy new year!
> >
> > A few days ago, I updated my patch of the pac4j gateway provider
> according
> > to all comments on https://issues.apache.org/jira/browse/KNOX-641 as
> well
> > as the documentation on KNOX-642.
> >
> > Is everything ok for the merge?
> >
> > Thanks.
> > Best regards,
> > Jérôme
> >
> >
> > 2015-12-14 15:28 GMT+01:00 larry mccay <la...@gmail.com>:
> >
> > > Hi Jérôme -
> > >
> > > Not sure if you saw but I added review comments to KNOX-641.
> > >
> > > I think that we need to determine whether we want the testBasicAuth in
> > the
> > > provider itself.
> > >
> > > Let's follow up on the JIRA.
> > >
> > > thanks,
> > >
> > > --larry
> > >
> > > On Fri, Dec 11, 2015 at 8:44 AM, Jérôme LELEU <le...@gmail.com>
> wrote:
> > >
> > > > Hi,
> > > >
> > > > No problem. It can go into a version 0.8.0 if needed. The truth is
> that
> > > > there is only one change outside the new pac4j module, so I think
> risks
> > > are
> > > > extremly limited.
> > > >
> > > > Just let met know.
> > > >
> > > > Thanks.
> > > > Best regards,
> > > > Jérôme
> > > >
> > > >
> > > > 2015-12-11 14:23 GMT+01:00 larry mccay <la...@gmail.com>:
> > > >
> > > > > Hi Jérôme -
> > > > >
> > > > > I have unfortunately not had a chance to pull, review and test it
> yet
> > > and
> > > > > have intended to do that today.
> > > > > I apologize for the delay.
> > > > >
> > > > > I was actually thinking that this would go into a follow up release
> > > that
> > > > we
> > > > > would try and get done rapidly after the 0.7.0 release but we can
> > > discuss
> > > > > the target and its chances of destabilizing 0.7.0.
> > > > >
> > > > > I believe that it is rather self-contained with only a few changes
> to
> > > > > external modules.
> > > > >
> > > > > Opening the JIRAs is perfect and I was going to do that once I
> > started
> > > > the
> > > > > review.
> > > > >
> > > > > Let's continue review comments and collaboration on those JIRAs.
> > > > > I will add you to the contributors list so that we can assign them
> to
> > > > you.
> > > > >
> > > > > Thank you for your contributions and your patience, Jérôme!
> > > > >
> > > > > --larry
> > > > >
> > > > > On Fri, Dec 11, 2015 at 3:00 AM, Jérôme LELEU <le...@gmail.com>
> > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I didn't get any new feedback on the pull request so I assume
> > > > everything
> > > > > is
> > > > > > ok from your point of view.
> > > > > >
> > > > > > I released pac4j v1.8.1 and j2e-pac4j v1.2.1 so I updated the
> pull
> > > > > request
> > > > > > to use them and successfully re-tested everything.
> > > > > >
> > > > > > I opened KNOX-641 and submitted the corresponding patch.
> > > > > >
> > > > > > I also wrote the documentation, opened KNOX-642 and submitted the
> > > > > > corresponding patch (just to let you know that it doesn't work
> out
> > of
> > > > the
> > > > > > box in Windows, I had to replace mvn.bat by mvn.cmd to make ant
> > > work).
> > > > > >
> > > > > > Even if the branch 0.7.0 has already been created, I assumed this
> > new
> > > > > pac4j
> > > > > > provider will go into this version 0.7.0 (dependency on the
> > > > > 0.7.0-SNAPSHOT
> > > > > > parent version).
> > > > > >
> > > > > > Just let me know if everything is ok and when it's goind to be
> > > merged.
> > > > > >
> > > > > > Thanks.
> > > > > > Best regards,
> > > > > > Jérôme
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2015-12-04 14:20 GMT+01:00 larry mccay <la...@gmail.com>:
> > > > > >
> > > > > > > That ability to configure multiple mechanisms based on
> clientName
> > > is
> > > > > > really
> > > > > > > interesting for Knox.
> > > > > > > Currently, we require separate topologies per authentication
> > > > mechanism.
> > > > > > > The ability to configure them all in one is really great.
> > > > > > >
> > > > > > > We would need to think through the best way to provide the
> > > clientName
> > > > > > > parameter.
> > > > > > > Since this is targeting KnoxSSO it can actually be added to the
> > > > > > providerURL
> > > > > > > used to redirect from the participating application.
> > > > > > > Regardless of the authentication mechanism used each
> application
> > > will
> > > > > > still
> > > > > > > get the same JWT based cookie.
> > > > > > >
> > > > > > > I think that should work really nicely.
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Dec 4, 2015 at 7:17 AM, larry mccay <
> > larry.mccay@gmail.com
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > > Excellent, Jérôme.
> > > > > > > > Thanks!
> > > > > > > >
> > > > > > > > On Fri, Dec 4, 2015 at 2:40 AM, Jérôme LELEU <
> leleuj@gmail.com
> > >
> > > > > wrote:
> > > > > > > >
> > > > > > > >> Hi,
> > > > > > > >>
> > > > > > > >> I will write how to configure the pac4j provider in the
> > > > > documentation,
> > > > > > > but
> > > > > > > >> I can already give you some insights.
> > > > > > > >>
> > > > > > > >> My main goal is always to respect the key design principles
> of
> > > > pac4j
> > > > > > > >> whatever the environment / framework in which it is
> > implemented.
> > > > For
> > > > > > > Knox,
> > > > > > > >> I'm pretty happy with the use of the j2e-pac4j library,
> which
> > > > means
> > > > > > that
> > > > > > > >> almost all the pac4j features are available, especially both
> > > > direct
> > > > > > and
> > > > > > > >> indirect clients. So it can do what Shiro already does but
> > also,
> > > > as
> > > > > we
> > > > > > > >> agreed together, supports remote authentications.
> > > > > > > >>
> > > > > > > >> It is only limited by what you can currently configure. And
> > even
> > > > > > > >> configuration is a pac4j feature as the CAS server has the
> > same
> > > > > need.
> > > > > > > >> Everything happens in this class:
> > > > > > > >>
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java
> > > > > > > >> ,
> > > > > > > >> which allows you to configure Facebook, Twitter, a CAS
> > server, a
> > > > > SAML
> > > > > > > IdP
> > > > > > > >> or an OpenID Connect provider. All the provided parameters
> to
> > > the
> > > > > > pac4j
> > > > > > > >> provider are put into a Map and the ConfigPropertiesFactory
> is
> > > > built
> > > > > > > with
> > > > > > > >> this Map to return the built client (= authentication
> > > mechanism).
> > > > > > > >>
> > > > > > > >> You have one more specific option for Knox as a basic
> > > > authentication
> > > > > > > popup
> > > > > > > >> where the username must match the password, you can define
> > that
> > > > by:
> > > > > > > >>
> > > > > > > >> <param>
> > > > > > > >> <name>clientName</name>
> > > > > > > >> <value>testBasicAuth</value>
> > > > > > > >> </param>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> It's for testing only.
> > > > > > > >>
> > > > > > > >> For a CAS server:
> > > > > > > >>
> > > > > > > >> <param>
> > > > > > > >> <name>cas.loginUrl</name>
> > > > > > > >> <value>https://casserverpac4j.herokuapp.com/login</value>
> > > > > > > >> </param>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> Here are all the properties available for building clients
> > > (their
> > > > > > > meaning
> > > > > > > >> is obvious):
> > > > > > > >>
> > > > > > > >> facebook.id
> > > > > > > >> facebook.secret
> > > > > > > >> facebook.scope
> > > > > > > >> facebook.fields
> > > > > > > >> twitter.id
> > > > > > > >> twitter.secret
> > > > > > > >> saml.keystorePassword
> > > > > > > >> saml.privateKeyPassword
> > > > > > > >> saml.keystorePath
> > > > > > > >> saml.identityProviderMetadataPath
> > > > > > > >> saml.maximumAuthenticationLifetime
> > > > > > > >> saml.serviceProviderEntityId
> > > > > > > >> saml.serviceProviderMetadataPath
> > > > > > > >> cas.loginUrl
> > > > > > > >> cas.protocol
> > > > > > > >> oidc.id
> > > > > > > >> oidc.secret
> > > > > > > >> oidc.discoveryUri
> > > > > > > >> oidc.customParamKey1
> > > > > > > >> oidc.customParamValue1
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> If you define multiple clients, the first one will be used
> for
> > > > > > > >> authentication, but you can explicitly choose the client you
> > > want
> > > > to
> > > > > > use
> > > > > > > >> via the clientName parameter, assuming you want to switch
> from
> > > > > client
> > > > > > > >> depending on environment for example.
> > > > > > > >>
> > > > > > > >> So if you want to add some new authentication mechanism, you
> > > must
> > > > > > first
> > > > > > > >> check that it is available in pac4j (if it's not, it's
> another
> > > > > > > discussion,
> > > > > > > >> but generally, it is). Then, you'll need to upgrade the
> > > > > > > >> ConfigPropertiesFactory by submitting a new pull request to
> > the
> > > > > pac4j
> > > > > > > >> project (I can do it myself, but I'm sure you could do that
> > > > easily),
> > > > > > > >> finally wait for the new pac4j release and switch pac4j
> > versions
> > > > in
> > > > > > Knox
> > > > > > > >> to
> > > > > > > >> benefit from the new feature.
> > > > > > > >> The good thing is that if someone related to the CAS server
> > does
> > > > the
> > > > > > > same
> > > > > > > >> thing for CAS (in pac4j), you will automatically get it when
> > > > you'll
> > > > > > > >> upgrade
> > > > > > > >> pac4j.
> > > > > > > >>
> > > > > > > >> To go even further, replacing LDAP Shiro authentication is
> > just
> > > a
> > > > > > matter
> > > > > > > >> of
> > > > > > > >> making pac4j LDAP authentication available via configuration
> > > > > > parameters.
> > > > > > > >>
> > > > > > > >> I hope it was clear enough.
> > > > > > > >>
> > > > > > > >> Thanks.
> > > > > > > >> Best regards,
> > > > > > > >> Jérôme
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> 2015-12-03 20:45 GMT+01:00 larry mccay <
> larry.mccay@gmail.com
> > >:
> > > > > > > >>
> > > > > > > >> > Excellent!
> > > > > > > >> >
> > > > > > > >> > I will carve out some time to do code review.
> > > > > > > >> > We will need to get some insights into how to go about
> > > testing:
> > > > > > > >> >
> > > > > > > >> > * is the CAS server going to be available for testing?
> > > > > > > >> > * what are the specific and generic/standard (if any)
> > > > > authentication
> > > > > > > >> > mechanisms available - for instance:
> > > > > > > >> > - Facebook, Google, LinkedIn and CAS are specifics
> > > > > > > >> > - OAuth 2, OpenID Connect, SAML are generic/standards
> -
> > > that
> > > > > may
> > > > > > > be
> > > > > > > >> > used for the above specifics...
> > > > > > > >> > * how do we test things other than CAS - in terms of
> getting
> > > > > > > >> credentials,
> > > > > > > >> > configuration, etc
> > > > > > > >> >
> > > > > > > >> > We could certainly do this is phases as well.
> > > > > > > >> >
> > > > > > > >> > If you can enumerate the things that should work and
> provide
> > > > some
> > > > > > > >> testing
> > > > > > > >> > details for CAS or as many as possible and OpenID Connect
> > then
> > > > we
> > > > > > can
> > > > > > > >> test
> > > > > > > >> > the specific implementations that you provide and enable
> the
> > > > > testing
> > > > > > > of
> > > > > > > >> > another OpenID Connect effort that is in the works in the
> > > > > community.
> > > > > > > >> >
> > > > > > > >> > I'm not sure whether we want to commit contributions that
> > are
> > > > > > > dependent
> > > > > > > >> on
> > > > > > > >> > snapshots - we certainly can't release with any such
> > > > dependencies.
> > > > > > > >> > I would hate to add a cleanup task to a release to make
> sure
> > > > there
> > > > > > are
> > > > > > > >> no
> > > > > > > >> > snapshots in there.
> > > > > > > >> > We will probably wait until after the pac4j releases to
> > > commit.
> > > > > > > >> >
> > > > > > > >> > I am really happy that this integration is happening and
> > that
> > > it
> > > > > > went
> > > > > > > >> > rather smoothly.
> > > > > > > >> > These sorts of authentication protocols are complex and I
> > > think
> > > > we
> > > > > > > >> lined up
> > > > > > > >> > pretty well overall.
> > > > > > > >> >
> > > > > > > >> > Thanks for your work!
> > > > > > > >> >
> > > > > > > >> > On Thu, Dec 3, 2015 at 2:28 PM, Jérôme LELEU <
> > > leleuj@gmail.com>
> > > > > > > wrote:
> > > > > > > >> >
> > > > > > > >> > > Hi,
> > > > > > > >> > >
> > > > > > > >> > > I just sync'ed with master, cleaned dependencies and
> added
> > > > > missing
> > > > > > > >> > > Javadocs. Everything works correctly now. Many thanks.
> > > > > > > >> > >
> > > > > > > >> > > The pull request is ready for a full code review:
> > > > > > > >> > > https://github.com/apache/knox/pull/2
> > > > > > > >> > >
> > > > > > > >> > > I'll write the documentation after the pac4j releases (I
> > > hope
> > > > > next
> > > > > > > >> week).
> > > > > > > >> > >
> > > > > > > >> > > Thanks.
> > > > > > > >> > > Best regards,
> > > > > > > >> > > Jérôme
> > > > > > > >> > >
> > > > > > > >> > >
> > > > > > > >> > > 2015-12-02 19:18 GMT+01:00 larry mccay <
> > > larry.mccay@gmail.com
> > > > >:
> > > > > > > >> > >
> > > > > > > >> > > > Fixed in
> https://issues.apache.org/jira/browse/KNOX-636
> > .
> > > > > > > >> > > >
> > > > > > > >> > > > On Wed, Dec 2, 2015 at 12:42 PM, larry mccay <
> > > > > > > larry.mccay@gmail.com
> > > > > > > >> >
> > > > > > > >> > > > wrote:
> > > > > > > >> > > >
> > > > > > > >> > > > > Sure - I can file a JIRA and commit a fix.
> > > > > > > >> > > > >
> > > > > > > >> > > > > The secret generation should be done in one instance
> > and
> > > > > > > >> replicated
> > > > > > > >> > > > across
> > > > > > > >> > > > > others.
> > > > > > > >> > > > > This replication/management of the credential stores
> > is
> > > > > > outside
> > > > > > > of
> > > > > > > >> > the
> > > > > > > >> > > > > scope of Knox itself as of now.
> > > > > > > >> > > > >
> > > > > > > >> > > > > Documentation is done in markdown and is
> contributing
> > > > > details
> > > > > > > are
> > > > > > > >> > > > > available at:
> > > > > > > >> > > > >
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
> > > > > > > >> > > > >
> > > > > > > >> > > > > Which should give you a general idea.
> > > > > > > >> > > > >
> > > > > > > >> > > > > Find an example like: ./trunk/books/0.7.0/
> > > > > > > >> > > config_preauth_sso_provider.md
> > > > > > > >> > > > >
> > > > > > > >> > > > > For an example of typical content and format.
> > > > > > > >> > > > >
> > > > > > > >> > > > > Here is how that example renders:
> > > > > > > >> > > > >
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
> > > > > > > >> > > > >
> > > > > > > >> > > > > You'll need to tie it into the rest of the book -
> just
> > > > grep
> > > > > > for
> > > > > > > >> where
> > > > > > > >> > > > that
> > > > > > > >> > > > > filename is referenced.
> > > > > > > >> > > > > To test how it renders build the site with: "ant"
> and
> > > note
> > > > > the
> > > > > > > >> url to
> > > > > > > >> > > the
> > > > > > > >> > > > > 0.7.0 book.
> > > > > > > >> > > > >
> > > > > > > >> > > > >
> > > > > > > >> > > > > On Wed, Dec 2, 2015 at 12:12 PM, Jérôme LELEU <
> > > > > > leleuj@gmail.com
> > > > > > > >
> > > > > > > >> > > wrote:
> > > > > > > >> > > > >
> > > > > > > >> > > > >> Hi,
> > > > > > > >> > > > >>
> > > > > > > >> > > > >> Why it doesn't work for pac4j while it works for
> > others
> > > > is
> > > > > a
> > > > > > > bit
> > > > > > > >> > > strange
> > > > > > > >> > > > >> to
> > > > > > > >> > > > >> me, but if you have the patch in front of your
> eyes,
> > > I'd
> > > > > > rather
> > > > > > > >> > prefer
> > > > > > > >> > > > you
> > > > > > > >> > > > >> to commit it. In all cases, I'll sync with the
> > master.
> > > > > > > >> > > > >>
> > > > > > > >> > > > >> There was one question you didn't answer
> previously:
> > is
> > > > the
> > > > > > > >> password
> > > > > > > >> > > > >> generated for the pac4j provider the same across
> all
> > > > > gateway
> > > > > > > >> > > instances?
> > > > > > > >> > > > >> Because I expect to have the same value as I use it
> > to
> > > > > > encrypt
> > > > > > > /
> > > > > > > >> > > decrypt
> > > > > > > >> > > > >> data.
> > > > > > > >> > > > >>
> > > > > > > >> > > > >> I will add the Javadoc. After that, you can review
> > the
> > > > pull
> > > > > > > >> request
> > > > > > > >> > > more
> > > > > > > >> > > > >> completely.
> > > > > > > >> > > > >>
> > > > > > > >> > > > >> What do you expect for the documentation?
> > > > > > > >> > > > >>
> > > > > > > >> > > > >> Notice that pac4j dependencies are still snapshots,
> > but
> > > > > they
> > > > > > > >> will be
> > > > > > > >> > > > >> released in a week or two.
> > > > > > > >> > > > >>
> > > > > > > >> > > > >> Thanks.
> > > > > > > >> > > > >> Best regards,
> > > > > > > >> > > > >> Jérôme
> > > > > > > >> > > > >>
> > > > > > > >> > > > >>
> > > > > > > >> > > > >> 2015-12-02 17:51 GMT+01:00 larry mccay <
> > > > > > larry.mccay@gmail.com
> > > > > > > >:
> > > > > > > >> > > > >>
> > > > > > > >> > > > >> > Jérôme -
> > > > > > > >> > > > >> >
> > > > > > > >> > > > >> > If you would like to add that change as part of
> > your
> > > > > patch
> > > > > > or
> > > > > > > >> as a
> > > > > > > >> > > > >> > separately filed JIRA to fix a bug that would
> > > certainly
> > > > > be
> > > > > > > >> > welcomed.
> > > > > > > >> > > > >> > Otherwise, I can do it.
> > > > > > > >> > > > >> >
> > > > > > > >> > > > >> > Let me know.
> > > > > > > >> > > > >> >
> > > > > > > >> > > > >> > thanks,
> > > > > > > >> > > > >> >
> > > > > > > >> > > > >> > --larry
> > > > > > > >> > > > >> >
> > > > > > > >> > > > >> > On Wed, Dec 2, 2015 at 11:44 AM, larry mccay <
> > > > > > > >> > larry.mccay@gmail.com
> > > > > > > >> > > >
> > > > > > > >> > > > >> > wrote:
> > > > > > > >> > > > >> >
> > > > > > > >> > > > >> > > Okay - I had to add an override of
> > > getUserPrincipal()
> > > > > to
> > > > > > > the
> > > > > > > >> > > > >> > > IdentityAsserterHttpServletRequestWrapper and
> > > return
> > > > > the
> > > > > > > >> member
> > > > > > > >> > > > >> variable
> > > > > > > >> > > > >> > > username and it works like a charm.
> > > > > > > >> > > > >> > >
> > > > > > > >> > > > >> > > Why I haven't seen this same behavior with
> other
> > > > > > providers
> > > > > > > >> is a
> > > > > > > >> > > bit
> > > > > > > >> > > > >> of a
> > > > > > > >> > > > >> > > mystery but they must be adding other wrappers
> > that
> > > > > > handle
> > > > > > > >> it.
> > > > > > > >> > > > >> > > This is quite cool, Jérôme!
> > > > > > > >> > > > >> > >
> > > > > > > >> > > > >> > > On Wed, Dec 2, 2015 at 10:41 AM, larry mccay <
> > > > > > > >> > > larry.mccay@gmail.com
> > > > > > > >> > > > >
> > > > > > > >> > > > >> > > wrote:
> > > > > > > >> > > > >> > >
> > > > > > > >> > > > >> > >> That was it - thanks!
> > > > > > > >> > > > >> > >>
> > > > > > > >> > > > >> > >> On Wed, Dec 2, 2015 at 10:20 AM, Jérôme LELEU
> <
> > > > > > > >> > leleuj@gmail.com>
> > > > > > > >> > > > >> wrote:
> > > > > > > >> > > > >> > >>
> > > > > > > >> > > > >> > >>> This is my exact command line: mvn -Prelease
> > > clean
> > > > > > > install
> > > > > > > >> > > > >> -DskipTests
> > > > > > > >> > > > >> > >>>
> > > > > > > >> > > > >> > >>> You use an internal Maven repository to fetch
> > > > > > > dependencies
> > > > > > > >> > from
> > > > > > > >> > > > >> > internet:
> > > > > > > >> > > > >> > >>>
> > > > > > > >> > >
> > > > > http://nexus-private.hortonworks.com/nexus/content/groups/public/
> > > > > > > >> > > > >> > >>>
> > > > > > > >> > > > >> > >>> Does this repository have access to the
> remote
> > > > > > Snapshots
> > > > > > > >> > > Sonatype
> > > > > > > >> > > > >> repo?
> > > > > > > >> > > > >> > >>>
> > > > > > > >> > > > >> > >>>
> > > > > > > >> > > > >> > >>>
> > > > > > > >> > > > >> > >>> 2015-12-02 16:16 GMT+01:00 larry mccay <
> > > > > > > >> larry.mccay@gmail.com
> > > > > > > >> > >:
> > > > > > > >> > > > >> > >>>
> > > > > > > >> > > > >> > >>> > hmmm - I used:
> > > > > > > >> > > > >> > >>> >
> > > > > > > >> > > > >> > >>> > mvn clean install -DskipTests=true
> -Prelease
> > > > > > > >> > > > >> > >>> >
> > > > > > > >> > > > >> > >>> > The repository entry is in there already.
> > > > > > > >> > > > >> > >>> > No worky.
> > > > > > > >> > > > >> > >>> >
> > > > > > > >> > > > >> > >>> > On Wed, Dec 2, 2015 at 10:12 AM, Jérôme
> > LELEU <
> > > > > > > >> > > leleuj@gmail.com
> > > > > > > >> > > > >
> > > > > > > >> > > > >> > >>> wrote:
> > > > > > > >> > > > >> > >>> >
> > > > > > > >> > > > >> > >>> > > Hi,
> > > > > > > >> > > > >> > >>> > >
> > > > > > > >> > > > >> > >>> > > You need the j2e-pac4j dependencies as
> well
> > > as
> > > > > the
> > > > > > > >> pac4j-*
> > > > > > > >> > > > >> > >>> dependencies,
> > > > > > > >> > > > >> > >>> > > but you don't need to build them locally
> > > > > > (hopefully).
> > > > > > > >> > > > >> > >>> > >
> > > > > > > >> > > > >> > >>> > > But you need a dependency on the Sonatype
> > > > > snapshots
> > > > > > > >> > > repository
> > > > > > > >> > > > >> > >>> (where the
> > > > > > > >> > > > >> > >>> > > snapshot versions are hosted), which is
> > added
> > > > for
> > > > > > > >> Maven in
> > > > > > > >> > > the
> > > > > > > >> > > > >> root
> > > > > > > >> > > > >> > >>> > > pom.xml:
> > > > > > > >> > > > >> > >>> > >
> > > > > > > >> > > > >> > >>> > >
> > > > > > > >> > > > >> > >>> >
> > > > > > > >> > > > >> > >>>
> > > > > > > >> > > > >> >
> > > > > > > >> > > > >>
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> > > > > > > >> > > > >> > >>> > >
> > > > > > > >> > > > >> > >>> > > If you use Ant for the build, there is
> > maybe
> > > a
> > > > > > glitch
> > > > > > > >> to
> > > > > > > >> > > find
> > > > > > > >> > > > >> the
> > > > > > > >> > > > >> > >>> > Sonatype
> > > > > > > >> > > > >> > >>> > > Maven repo.
> > > > > > > >> > > > >> > >>> > >
> > > > > > > >> > > > >> > >>> > > Thanks.
> > > > > > > >> > > > >> > >>> > > Best regards,
> > > > > > > >> > > > >> > >>> > > Jérôme
> > > > > > > >> > > > >> > >>> > >
> > > > > > > >> > > > >> > >>> > >
> > > > > > > >> > > > >> > >>> > > 2015-12-02 16:06 GMT+01:00 larry mccay <
> > > > > > > >> > > larry.mccay@gmail.com
> > > > > > > >> > > > >:
> > > > > > > >> > > > >> > >>> > >
> > > > > > > >> > > > >> > >>> > > > 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.mccay@gmail.com>
> > > > > > > >> > > > >> > >>> > > > wrote:
> > > > > > > >> > > > >> > >>> > > >
> > > > > > > >> > > > >> > >>> > > > > gateway-provider-security-pac4j
> doesn't
> > > > > build -
> > > > > > > do
> > > > > > > >> you
> > > > > > > >> > > > have
> > > > > > > >> > > > >> a
> > > > > > > >> > > > >> > >>> pending
> > > > > > > >> > > > >> > >>> > > > > change for your pom.xml or something?
> > > > > > > >> > > > >> > >>> > > > >
> > > > > > > >> > > > >> > >>> >
> > > > > > > >> > > > >> > >>>
> > > > > > > >> > > > >> > >>
> > > > > > > >> > > > >> > >>
> > > > > > > >> > > > >> > >
> > > > > > > >> > > > >> >
> > > > > > > >> > > > >>
> > > > > > > >> > > > >
> > > > > > > >> > > > >
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
Hello Jérôme -
Happy New Year!
I am going to start reviewing your updates today, hopefully.
I was thinking that we need to start discussions on what the key usecases
are and how to go about testing them.
We can certainly test the testBasicAuth and against the hosted CAS server
but what about FB, openid, OAuth, etc?
I'm not sure that FB would be a key feature but OpenID Connect and OAuth
would be - as is SAML.
I think CAS buys us SAML testing - assuming that the configuration of the
hosted server is actually a SAML 2 instance.
What about the others?
I don't know that we need to be able to test them all before merge but some
sort of manual verification would be great.
We would need to be able to test them before the next release which would
be featuring the pac4j functionality.
Maybe you can describe how you go about testing such things for the pac4j
project itself?
thanks,
--larry
On Tue, Jan 5, 2016 at 9:55 AM, Jérôme LELEU <le...@gmail.com> wrote:
> Hi,
>
> Happy new year!
>
> A few days ago, I updated my patch of the pac4j gateway provider according
> to all comments on https://issues.apache.org/jira/browse/KNOX-641 as well
> as the documentation on KNOX-642.
>
> Is everything ok for the merge?
>
> Thanks.
> Best regards,
> Jérôme
>
>
> 2015-12-14 15:28 GMT+01:00 larry mccay <la...@gmail.com>:
>
> > Hi Jérôme -
> >
> > Not sure if you saw but I added review comments to KNOX-641.
> >
> > I think that we need to determine whether we want the testBasicAuth in
> the
> > provider itself.
> >
> > Let's follow up on the JIRA.
> >
> > thanks,
> >
> > --larry
> >
> > On Fri, Dec 11, 2015 at 8:44 AM, Jérôme LELEU <le...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > No problem. It can go into a version 0.8.0 if needed. The truth is that
> > > there is only one change outside the new pac4j module, so I think risks
> > are
> > > extremly limited.
> > >
> > > Just let met know.
> > >
> > > Thanks.
> > > Best regards,
> > > Jérôme
> > >
> > >
> > > 2015-12-11 14:23 GMT+01:00 larry mccay <la...@gmail.com>:
> > >
> > > > Hi Jérôme -
> > > >
> > > > I have unfortunately not had a chance to pull, review and test it yet
> > and
> > > > have intended to do that today.
> > > > I apologize for the delay.
> > > >
> > > > I was actually thinking that this would go into a follow up release
> > that
> > > we
> > > > would try and get done rapidly after the 0.7.0 release but we can
> > discuss
> > > > the target and its chances of destabilizing 0.7.0.
> > > >
> > > > I believe that it is rather self-contained with only a few changes to
> > > > external modules.
> > > >
> > > > Opening the JIRAs is perfect and I was going to do that once I
> started
> > > the
> > > > review.
> > > >
> > > > Let's continue review comments and collaboration on those JIRAs.
> > > > I will add you to the contributors list so that we can assign them to
> > > you.
> > > >
> > > > Thank you for your contributions and your patience, Jérôme!
> > > >
> > > > --larry
> > > >
> > > > On Fri, Dec 11, 2015 at 3:00 AM, Jérôme LELEU <le...@gmail.com>
> > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I didn't get any new feedback on the pull request so I assume
> > > everything
> > > > is
> > > > > ok from your point of view.
> > > > >
> > > > > I released pac4j v1.8.1 and j2e-pac4j v1.2.1 so I updated the pull
> > > > request
> > > > > to use them and successfully re-tested everything.
> > > > >
> > > > > I opened KNOX-641 and submitted the corresponding patch.
> > > > >
> > > > > I also wrote the documentation, opened KNOX-642 and submitted the
> > > > > corresponding patch (just to let you know that it doesn't work out
> of
> > > the
> > > > > box in Windows, I had to replace mvn.bat by mvn.cmd to make ant
> > work).
> > > > >
> > > > > Even if the branch 0.7.0 has already been created, I assumed this
> new
> > > > pac4j
> > > > > provider will go into this version 0.7.0 (dependency on the
> > > > 0.7.0-SNAPSHOT
> > > > > parent version).
> > > > >
> > > > > Just let me know if everything is ok and when it's goind to be
> > merged.
> > > > >
> > > > > Thanks.
> > > > > Best regards,
> > > > > Jérôme
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 2015-12-04 14:20 GMT+01:00 larry mccay <la...@gmail.com>:
> > > > >
> > > > > > That ability to configure multiple mechanisms based on clientName
> > is
> > > > > really
> > > > > > interesting for Knox.
> > > > > > Currently, we require separate topologies per authentication
> > > mechanism.
> > > > > > The ability to configure them all in one is really great.
> > > > > >
> > > > > > We would need to think through the best way to provide the
> > clientName
> > > > > > parameter.
> > > > > > Since this is targeting KnoxSSO it can actually be added to the
> > > > > providerURL
> > > > > > used to redirect from the participating application.
> > > > > > Regardless of the authentication mechanism used each application
> > will
> > > > > still
> > > > > > get the same JWT based cookie.
> > > > > >
> > > > > > I think that should work really nicely.
> > > > > >
> > > > > >
> > > > > > On Fri, Dec 4, 2015 at 7:17 AM, larry mccay <
> larry.mccay@gmail.com
> > >
> > > > > wrote:
> > > > > >
> > > > > > > Excellent, Jérôme.
> > > > > > > Thanks!
> > > > > > >
> > > > > > > On Fri, Dec 4, 2015 at 2:40 AM, Jérôme LELEU <leleuj@gmail.com
> >
> > > > wrote:
> > > > > > >
> > > > > > >> Hi,
> > > > > > >>
> > > > > > >> I will write how to configure the pac4j provider in the
> > > > documentation,
> > > > > > but
> > > > > > >> I can already give you some insights.
> > > > > > >>
> > > > > > >> My main goal is always to respect the key design principles of
> > > pac4j
> > > > > > >> whatever the environment / framework in which it is
> implemented.
> > > For
> > > > > > Knox,
> > > > > > >> I'm pretty happy with the use of the j2e-pac4j library, which
> > > means
> > > > > that
> > > > > > >> almost all the pac4j features are available, especially both
> > > direct
> > > > > and
> > > > > > >> indirect clients. So it can do what Shiro already does but
> also,
> > > as
> > > > we
> > > > > > >> agreed together, supports remote authentications.
> > > > > > >>
> > > > > > >> It is only limited by what you can currently configure. And
> even
> > > > > > >> configuration is a pac4j feature as the CAS server has the
> same
> > > > need.
> > > > > > >> Everything happens in this class:
> > > > > > >>
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java
> > > > > > >> ,
> > > > > > >> which allows you to configure Facebook, Twitter, a CAS
> server, a
> > > > SAML
> > > > > > IdP
> > > > > > >> or an OpenID Connect provider. All the provided parameters to
> > the
> > > > > pac4j
> > > > > > >> provider are put into a Map and the ConfigPropertiesFactory is
> > > built
> > > > > > with
> > > > > > >> this Map to return the built client (= authentication
> > mechanism).
> > > > > > >>
> > > > > > >> You have one more specific option for Knox as a basic
> > > authentication
> > > > > > popup
> > > > > > >> where the username must match the password, you can define
> that
> > > by:
> > > > > > >>
> > > > > > >> <param>
> > > > > > >> <name>clientName</name>
> > > > > > >> <value>testBasicAuth</value>
> > > > > > >> </param>
> > > > > > >>
> > > > > > >>
> > > > > > >> It's for testing only.
> > > > > > >>
> > > > > > >> For a CAS server:
> > > > > > >>
> > > > > > >> <param>
> > > > > > >> <name>cas.loginUrl</name>
> > > > > > >> <value>https://casserverpac4j.herokuapp.com/login</value>
> > > > > > >> </param>
> > > > > > >>
> > > > > > >>
> > > > > > >> Here are all the properties available for building clients
> > (their
> > > > > > meaning
> > > > > > >> is obvious):
> > > > > > >>
> > > > > > >> facebook.id
> > > > > > >> facebook.secret
> > > > > > >> facebook.scope
> > > > > > >> facebook.fields
> > > > > > >> twitter.id
> > > > > > >> twitter.secret
> > > > > > >> saml.keystorePassword
> > > > > > >> saml.privateKeyPassword
> > > > > > >> saml.keystorePath
> > > > > > >> saml.identityProviderMetadataPath
> > > > > > >> saml.maximumAuthenticationLifetime
> > > > > > >> saml.serviceProviderEntityId
> > > > > > >> saml.serviceProviderMetadataPath
> > > > > > >> cas.loginUrl
> > > > > > >> cas.protocol
> > > > > > >> oidc.id
> > > > > > >> oidc.secret
> > > > > > >> oidc.discoveryUri
> > > > > > >> oidc.customParamKey1
> > > > > > >> oidc.customParamValue1
> > > > > > >>
> > > > > > >>
> > > > > > >> If you define multiple clients, the first one will be used for
> > > > > > >> authentication, but you can explicitly choose the client you
> > want
> > > to
> > > > > use
> > > > > > >> via the clientName parameter, assuming you want to switch from
> > > > client
> > > > > > >> depending on environment for example.
> > > > > > >>
> > > > > > >> So if you want to add some new authentication mechanism, you
> > must
> > > > > first
> > > > > > >> check that it is available in pac4j (if it's not, it's another
> > > > > > discussion,
> > > > > > >> but generally, it is). Then, you'll need to upgrade the
> > > > > > >> ConfigPropertiesFactory by submitting a new pull request to
> the
> > > > pac4j
> > > > > > >> project (I can do it myself, but I'm sure you could do that
> > > easily),
> > > > > > >> finally wait for the new pac4j release and switch pac4j
> versions
> > > in
> > > > > Knox
> > > > > > >> to
> > > > > > >> benefit from the new feature.
> > > > > > >> The good thing is that if someone related to the CAS server
> does
> > > the
> > > > > > same
> > > > > > >> thing for CAS (in pac4j), you will automatically get it when
> > > you'll
> > > > > > >> upgrade
> > > > > > >> pac4j.
> > > > > > >>
> > > > > > >> To go even further, replacing LDAP Shiro authentication is
> just
> > a
> > > > > matter
> > > > > > >> of
> > > > > > >> making pac4j LDAP authentication available via configuration
> > > > > parameters.
> > > > > > >>
> > > > > > >> I hope it was clear enough.
> > > > > > >>
> > > > > > >> Thanks.
> > > > > > >> Best regards,
> > > > > > >> Jérôme
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> 2015-12-03 20:45 GMT+01:00 larry mccay <larry.mccay@gmail.com
> >:
> > > > > > >>
> > > > > > >> > Excellent!
> > > > > > >> >
> > > > > > >> > I will carve out some time to do code review.
> > > > > > >> > We will need to get some insights into how to go about
> > testing:
> > > > > > >> >
> > > > > > >> > * is the CAS server going to be available for testing?
> > > > > > >> > * what are the specific and generic/standard (if any)
> > > > authentication
> > > > > > >> > mechanisms available - for instance:
> > > > > > >> > - Facebook, Google, LinkedIn and CAS are specifics
> > > > > > >> > - OAuth 2, OpenID Connect, SAML are generic/standards -
> > that
> > > > may
> > > > > > be
> > > > > > >> > used for the above specifics...
> > > > > > >> > * how do we test things other than CAS - in terms of getting
> > > > > > >> credentials,
> > > > > > >> > configuration, etc
> > > > > > >> >
> > > > > > >> > We could certainly do this is phases as well.
> > > > > > >> >
> > > > > > >> > If you can enumerate the things that should work and provide
> > > some
> > > > > > >> testing
> > > > > > >> > details for CAS or as many as possible and OpenID Connect
> then
> > > we
> > > > > can
> > > > > > >> test
> > > > > > >> > the specific implementations that you provide and enable the
> > > > testing
> > > > > > of
> > > > > > >> > another OpenID Connect effort that is in the works in the
> > > > community.
> > > > > > >> >
> > > > > > >> > I'm not sure whether we want to commit contributions that
> are
> > > > > > dependent
> > > > > > >> on
> > > > > > >> > snapshots - we certainly can't release with any such
> > > dependencies.
> > > > > > >> > I would hate to add a cleanup task to a release to make sure
> > > there
> > > > > are
> > > > > > >> no
> > > > > > >> > snapshots in there.
> > > > > > >> > We will probably wait until after the pac4j releases to
> > commit.
> > > > > > >> >
> > > > > > >> > I am really happy that this integration is happening and
> that
> > it
> > > > > went
> > > > > > >> > rather smoothly.
> > > > > > >> > These sorts of authentication protocols are complex and I
> > think
> > > we
> > > > > > >> lined up
> > > > > > >> > pretty well overall.
> > > > > > >> >
> > > > > > >> > Thanks for your work!
> > > > > > >> >
> > > > > > >> > On Thu, Dec 3, 2015 at 2:28 PM, Jérôme LELEU <
> > leleuj@gmail.com>
> > > > > > wrote:
> > > > > > >> >
> > > > > > >> > > Hi,
> > > > > > >> > >
> > > > > > >> > > I just sync'ed with master, cleaned dependencies and added
> > > > missing
> > > > > > >> > > Javadocs. Everything works correctly now. Many thanks.
> > > > > > >> > >
> > > > > > >> > > The pull request is ready for a full code review:
> > > > > > >> > > https://github.com/apache/knox/pull/2
> > > > > > >> > >
> > > > > > >> > > I'll write the documentation after the pac4j releases (I
> > hope
> > > > next
> > > > > > >> week).
> > > > > > >> > >
> > > > > > >> > > Thanks.
> > > > > > >> > > Best regards,
> > > > > > >> > > Jérôme
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > 2015-12-02 19:18 GMT+01:00 larry mccay <
> > larry.mccay@gmail.com
> > > >:
> > > > > > >> > >
> > > > > > >> > > > Fixed in https://issues.apache.org/jira/browse/KNOX-636
> .
> > > > > > >> > > >
> > > > > > >> > > > On Wed, Dec 2, 2015 at 12:42 PM, larry mccay <
> > > > > > larry.mccay@gmail.com
> > > > > > >> >
> > > > > > >> > > > wrote:
> > > > > > >> > > >
> > > > > > >> > > > > Sure - I can file a JIRA and commit a fix.
> > > > > > >> > > > >
> > > > > > >> > > > > The secret generation should be done in one instance
> and
> > > > > > >> replicated
> > > > > > >> > > > across
> > > > > > >> > > > > others.
> > > > > > >> > > > > This replication/management of the credential stores
> is
> > > > > outside
> > > > > > of
> > > > > > >> > the
> > > > > > >> > > > > scope of Knox itself as of now.
> > > > > > >> > > > >
> > > > > > >> > > > > Documentation is done in markdown and is contributing
> > > > details
> > > > > > are
> > > > > > >> > > > > available at:
> > > > > > >> > > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
> > > > > > >> > > > >
> > > > > > >> > > > > Which should give you a general idea.
> > > > > > >> > > > >
> > > > > > >> > > > > Find an example like: ./trunk/books/0.7.0/
> > > > > > >> > > config_preauth_sso_provider.md
> > > > > > >> > > > >
> > > > > > >> > > > > For an example of typical content and format.
> > > > > > >> > > > >
> > > > > > >> > > > > Here is how that example renders:
> > > > > > >> > > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
> > > > > > >> > > > >
> > > > > > >> > > > > You'll need to tie it into the rest of the book - just
> > > grep
> > > > > for
> > > > > > >> where
> > > > > > >> > > > that
> > > > > > >> > > > > filename is referenced.
> > > > > > >> > > > > To test how it renders build the site with: "ant" and
> > note
> > > > the
> > > > > > >> url to
> > > > > > >> > > the
> > > > > > >> > > > > 0.7.0 book.
> > > > > > >> > > > >
> > > > > > >> > > > >
> > > > > > >> > > > > On Wed, Dec 2, 2015 at 12:12 PM, Jérôme LELEU <
> > > > > leleuj@gmail.com
> > > > > > >
> > > > > > >> > > wrote:
> > > > > > >> > > > >
> > > > > > >> > > > >> Hi,
> > > > > > >> > > > >>
> > > > > > >> > > > >> Why it doesn't work for pac4j while it works for
> others
> > > is
> > > > a
> > > > > > bit
> > > > > > >> > > strange
> > > > > > >> > > > >> to
> > > > > > >> > > > >> me, but if you have the patch in front of your eyes,
> > I'd
> > > > > rather
> > > > > > >> > prefer
> > > > > > >> > > > you
> > > > > > >> > > > >> to commit it. In all cases, I'll sync with the
> master.
> > > > > > >> > > > >>
> > > > > > >> > > > >> There was one question you didn't answer previously:
> is
> > > the
> > > > > > >> password
> > > > > > >> > > > >> generated for the pac4j provider the same across all
> > > > gateway
> > > > > > >> > > instances?
> > > > > > >> > > > >> Because I expect to have the same value as I use it
> to
> > > > > encrypt
> > > > > > /
> > > > > > >> > > decrypt
> > > > > > >> > > > >> data.
> > > > > > >> > > > >>
> > > > > > >> > > > >> I will add the Javadoc. After that, you can review
> the
> > > pull
> > > > > > >> request
> > > > > > >> > > more
> > > > > > >> > > > >> completely.
> > > > > > >> > > > >>
> > > > > > >> > > > >> What do you expect for the documentation?
> > > > > > >> > > > >>
> > > > > > >> > > > >> Notice that pac4j dependencies are still snapshots,
> but
> > > > they
> > > > > > >> will be
> > > > > > >> > > > >> released in a week or two.
> > > > > > >> > > > >>
> > > > > > >> > > > >> Thanks.
> > > > > > >> > > > >> Best regards,
> > > > > > >> > > > >> Jérôme
> > > > > > >> > > > >>
> > > > > > >> > > > >>
> > > > > > >> > > > >> 2015-12-02 17:51 GMT+01:00 larry mccay <
> > > > > larry.mccay@gmail.com
> > > > > > >:
> > > > > > >> > > > >>
> > > > > > >> > > > >> > Jérôme -
> > > > > > >> > > > >> >
> > > > > > >> > > > >> > If you would like to add that change as part of
> your
> > > > patch
> > > > > or
> > > > > > >> as a
> > > > > > >> > > > >> > separately filed JIRA to fix a bug that would
> > certainly
> > > > be
> > > > > > >> > welcomed.
> > > > > > >> > > > >> > Otherwise, I can do it.
> > > > > > >> > > > >> >
> > > > > > >> > > > >> > Let me know.
> > > > > > >> > > > >> >
> > > > > > >> > > > >> > thanks,
> > > > > > >> > > > >> >
> > > > > > >> > > > >> > --larry
> > > > > > >> > > > >> >
> > > > > > >> > > > >> > On Wed, Dec 2, 2015 at 11:44 AM, larry mccay <
> > > > > > >> > larry.mccay@gmail.com
> > > > > > >> > > >
> > > > > > >> > > > >> > wrote:
> > > > > > >> > > > >> >
> > > > > > >> > > > >> > > Okay - I had to add an override of
> > getUserPrincipal()
> > > > to
> > > > > > the
> > > > > > >> > > > >> > > IdentityAsserterHttpServletRequestWrapper and
> > return
> > > > the
> > > > > > >> member
> > > > > > >> > > > >> variable
> > > > > > >> > > > >> > > username and it works like a charm.
> > > > > > >> > > > >> > >
> > > > > > >> > > > >> > > Why I haven't seen this same behavior with other
> > > > > providers
> > > > > > >> is a
> > > > > > >> > > bit
> > > > > > >> > > > >> of a
> > > > > > >> > > > >> > > mystery but they must be adding other wrappers
> that
> > > > > handle
> > > > > > >> it.
> > > > > > >> > > > >> > > This is quite cool, Jérôme!
> > > > > > >> > > > >> > >
> > > > > > >> > > > >> > > On Wed, Dec 2, 2015 at 10:41 AM, larry mccay <
> > > > > > >> > > larry.mccay@gmail.com
> > > > > > >> > > > >
> > > > > > >> > > > >> > > wrote:
> > > > > > >> > > > >> > >
> > > > > > >> > > > >> > >> That was it - thanks!
> > > > > > >> > > > >> > >>
> > > > > > >> > > > >> > >> On Wed, Dec 2, 2015 at 10:20 AM, Jérôme LELEU <
> > > > > > >> > leleuj@gmail.com>
> > > > > > >> > > > >> wrote:
> > > > > > >> > > > >> > >>
> > > > > > >> > > > >> > >>> This is my exact command line: mvn -Prelease
> > clean
> > > > > > install
> > > > > > >> > > > >> -DskipTests
> > > > > > >> > > > >> > >>>
> > > > > > >> > > > >> > >>> You use an internal Maven repository to fetch
> > > > > > dependencies
> > > > > > >> > from
> > > > > > >> > > > >> > internet:
> > > > > > >> > > > >> > >>>
> > > > > > >> > >
> > > > http://nexus-private.hortonworks.com/nexus/content/groups/public/
> > > > > > >> > > > >> > >>>
> > > > > > >> > > > >> > >>> Does this repository have access to the remote
> > > > > Snapshots
> > > > > > >> > > Sonatype
> > > > > > >> > > > >> repo?
> > > > > > >> > > > >> > >>>
> > > > > > >> > > > >> > >>>
> > > > > > >> > > > >> > >>>
> > > > > > >> > > > >> > >>> 2015-12-02 16:16 GMT+01:00 larry mccay <
> > > > > > >> larry.mccay@gmail.com
> > > > > > >> > >:
> > > > > > >> > > > >> > >>>
> > > > > > >> > > > >> > >>> > hmmm - I used:
> > > > > > >> > > > >> > >>> >
> > > > > > >> > > > >> > >>> > mvn clean install -DskipTests=true -Prelease
> > > > > > >> > > > >> > >>> >
> > > > > > >> > > > >> > >>> > The repository entry is in there already.
> > > > > > >> > > > >> > >>> > No worky.
> > > > > > >> > > > >> > >>> >
> > > > > > >> > > > >> > >>> > On Wed, Dec 2, 2015 at 10:12 AM, Jérôme
> LELEU <
> > > > > > >> > > leleuj@gmail.com
> > > > > > >> > > > >
> > > > > > >> > > > >> > >>> wrote:
> > > > > > >> > > > >> > >>> >
> > > > > > >> > > > >> > >>> > > Hi,
> > > > > > >> > > > >> > >>> > >
> > > > > > >> > > > >> > >>> > > You need the j2e-pac4j dependencies as well
> > as
> > > > the
> > > > > > >> pac4j-*
> > > > > > >> > > > >> > >>> dependencies,
> > > > > > >> > > > >> > >>> > > but you don't need to build them locally
> > > > > (hopefully).
> > > > > > >> > > > >> > >>> > >
> > > > > > >> > > > >> > >>> > > But you need a dependency on the Sonatype
> > > > snapshots
> > > > > > >> > > repository
> > > > > > >> > > > >> > >>> (where the
> > > > > > >> > > > >> > >>> > > snapshot versions are hosted), which is
> added
> > > for
> > > > > > >> Maven in
> > > > > > >> > > the
> > > > > > >> > > > >> root
> > > > > > >> > > > >> > >>> > > pom.xml:
> > > > > > >> > > > >> > >>> > >
> > > > > > >> > > > >> > >>> > >
> > > > > > >> > > > >> > >>> >
> > > > > > >> > > > >> > >>>
> > > > > > >> > > > >> >
> > > > > > >> > > > >>
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> > > > > > >> > > > >> > >>> > >
> > > > > > >> > > > >> > >>> > > If you use Ant for the build, there is
> maybe
> > a
> > > > > glitch
> > > > > > >> to
> > > > > > >> > > find
> > > > > > >> > > > >> the
> > > > > > >> > > > >> > >>> > Sonatype
> > > > > > >> > > > >> > >>> > > Maven repo.
> > > > > > >> > > > >> > >>> > >
> > > > > > >> > > > >> > >>> > > Thanks.
> > > > > > >> > > > >> > >>> > > Best regards,
> > > > > > >> > > > >> > >>> > > Jérôme
> > > > > > >> > > > >> > >>> > >
> > > > > > >> > > > >> > >>> > >
> > > > > > >> > > > >> > >>> > > 2015-12-02 16:06 GMT+01:00 larry mccay <
> > > > > > >> > > larry.mccay@gmail.com
> > > > > > >> > > > >:
> > > > > > >> > > > >> > >>> > >
> > > > > > >> > > > >> > >>> > > > 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.mccay@gmail.com>
> > > > > > >> > > > >> > >>> > > > wrote:
> > > > > > >> > > > >> > >>> > > >
> > > > > > >> > > > >> > >>> > > > > gateway-provider-security-pac4j doesn't
> > > > build -
> > > > > > do
> > > > > > >> you
> > > > > > >> > > > have
> > > > > > >> > > > >> a
> > > > > > >> > > > >> > >>> pending
> > > > > > >> > > > >> > >>> > > > > change for your pom.xml or something?
> > > > > > >> > > > >> > >>> > > > >
> > > > > > >> > > > >> > >>> >
> > > > > > >> > > > >> > >>>
> > > > > > >> > > > >> > >>
> > > > > > >> > > > >> > >>
> > > > > > >> > > > >> > >
> > > > > > >> > > > >> >
> > > > > > >> > > > >>
> > > > > > >> > > > >
> > > > > > >> > > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Hi,
Happy new year!
A few days ago, I updated my patch of the pac4j gateway provider according
to all comments on https://issues.apache.org/jira/browse/KNOX-641 as well
as the documentation on KNOX-642.
Is everything ok for the merge?
Thanks.
Best regards,
Jérôme
2015-12-14 15:28 GMT+01:00 larry mccay <la...@gmail.com>:
> Hi Jérôme -
>
> Not sure if you saw but I added review comments to KNOX-641.
>
> I think that we need to determine whether we want the testBasicAuth in the
> provider itself.
>
> Let's follow up on the JIRA.
>
> thanks,
>
> --larry
>
> On Fri, Dec 11, 2015 at 8:44 AM, Jérôme LELEU <le...@gmail.com> wrote:
>
> > Hi,
> >
> > No problem. It can go into a version 0.8.0 if needed. The truth is that
> > there is only one change outside the new pac4j module, so I think risks
> are
> > extremly limited.
> >
> > Just let met know.
> >
> > Thanks.
> > Best regards,
> > Jérôme
> >
> >
> > 2015-12-11 14:23 GMT+01:00 larry mccay <la...@gmail.com>:
> >
> > > Hi Jérôme -
> > >
> > > I have unfortunately not had a chance to pull, review and test it yet
> and
> > > have intended to do that today.
> > > I apologize for the delay.
> > >
> > > I was actually thinking that this would go into a follow up release
> that
> > we
> > > would try and get done rapidly after the 0.7.0 release but we can
> discuss
> > > the target and its chances of destabilizing 0.7.0.
> > >
> > > I believe that it is rather self-contained with only a few changes to
> > > external modules.
> > >
> > > Opening the JIRAs is perfect and I was going to do that once I started
> > the
> > > review.
> > >
> > > Let's continue review comments and collaboration on those JIRAs.
> > > I will add you to the contributors list so that we can assign them to
> > you.
> > >
> > > Thank you for your contributions and your patience, Jérôme!
> > >
> > > --larry
> > >
> > > On Fri, Dec 11, 2015 at 3:00 AM, Jérôme LELEU <le...@gmail.com>
> wrote:
> > >
> > > > Hi,
> > > >
> > > > I didn't get any new feedback on the pull request so I assume
> > everything
> > > is
> > > > ok from your point of view.
> > > >
> > > > I released pac4j v1.8.1 and j2e-pac4j v1.2.1 so I updated the pull
> > > request
> > > > to use them and successfully re-tested everything.
> > > >
> > > > I opened KNOX-641 and submitted the corresponding patch.
> > > >
> > > > I also wrote the documentation, opened KNOX-642 and submitted the
> > > > corresponding patch (just to let you know that it doesn't work out of
> > the
> > > > box in Windows, I had to replace mvn.bat by mvn.cmd to make ant
> work).
> > > >
> > > > Even if the branch 0.7.0 has already been created, I assumed this new
> > > pac4j
> > > > provider will go into this version 0.7.0 (dependency on the
> > > 0.7.0-SNAPSHOT
> > > > parent version).
> > > >
> > > > Just let me know if everything is ok and when it's goind to be
> merged.
> > > >
> > > > Thanks.
> > > > Best regards,
> > > > Jérôme
> > > >
> > > >
> > > >
> > > >
> > > > 2015-12-04 14:20 GMT+01:00 larry mccay <la...@gmail.com>:
> > > >
> > > > > That ability to configure multiple mechanisms based on clientName
> is
> > > > really
> > > > > interesting for Knox.
> > > > > Currently, we require separate topologies per authentication
> > mechanism.
> > > > > The ability to configure them all in one is really great.
> > > > >
> > > > > We would need to think through the best way to provide the
> clientName
> > > > > parameter.
> > > > > Since this is targeting KnoxSSO it can actually be added to the
> > > > providerURL
> > > > > used to redirect from the participating application.
> > > > > Regardless of the authentication mechanism used each application
> will
> > > > still
> > > > > get the same JWT based cookie.
> > > > >
> > > > > I think that should work really nicely.
> > > > >
> > > > >
> > > > > On Fri, Dec 4, 2015 at 7:17 AM, larry mccay <larry.mccay@gmail.com
> >
> > > > wrote:
> > > > >
> > > > > > Excellent, Jérôme.
> > > > > > Thanks!
> > > > > >
> > > > > > On Fri, Dec 4, 2015 at 2:40 AM, Jérôme LELEU <le...@gmail.com>
> > > wrote:
> > > > > >
> > > > > >> Hi,
> > > > > >>
> > > > > >> I will write how to configure the pac4j provider in the
> > > documentation,
> > > > > but
> > > > > >> I can already give you some insights.
> > > > > >>
> > > > > >> My main goal is always to respect the key design principles of
> > pac4j
> > > > > >> whatever the environment / framework in which it is implemented.
> > For
> > > > > Knox,
> > > > > >> I'm pretty happy with the use of the j2e-pac4j library, which
> > means
> > > > that
> > > > > >> almost all the pac4j features are available, especially both
> > direct
> > > > and
> > > > > >> indirect clients. So it can do what Shiro already does but also,
> > as
> > > we
> > > > > >> agreed together, supports remote authentications.
> > > > > >>
> > > > > >> It is only limited by what you can currently configure. And even
> > > > > >> configuration is a pac4j feature as the CAS server has the same
> > > need.
> > > > > >> Everything happens in this class:
> > > > > >>
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java
> > > > > >> ,
> > > > > >> which allows you to configure Facebook, Twitter, a CAS server, a
> > > SAML
> > > > > IdP
> > > > > >> or an OpenID Connect provider. All the provided parameters to
> the
> > > > pac4j
> > > > > >> provider are put into a Map and the ConfigPropertiesFactory is
> > built
> > > > > with
> > > > > >> this Map to return the built client (= authentication
> mechanism).
> > > > > >>
> > > > > >> You have one more specific option for Knox as a basic
> > authentication
> > > > > popup
> > > > > >> where the username must match the password, you can define that
> > by:
> > > > > >>
> > > > > >> <param>
> > > > > >> <name>clientName</name>
> > > > > >> <value>testBasicAuth</value>
> > > > > >> </param>
> > > > > >>
> > > > > >>
> > > > > >> It's for testing only.
> > > > > >>
> > > > > >> For a CAS server:
> > > > > >>
> > > > > >> <param>
> > > > > >> <name>cas.loginUrl</name>
> > > > > >> <value>https://casserverpac4j.herokuapp.com/login</value>
> > > > > >> </param>
> > > > > >>
> > > > > >>
> > > > > >> Here are all the properties available for building clients
> (their
> > > > > meaning
> > > > > >> is obvious):
> > > > > >>
> > > > > >> facebook.id
> > > > > >> facebook.secret
> > > > > >> facebook.scope
> > > > > >> facebook.fields
> > > > > >> twitter.id
> > > > > >> twitter.secret
> > > > > >> saml.keystorePassword
> > > > > >> saml.privateKeyPassword
> > > > > >> saml.keystorePath
> > > > > >> saml.identityProviderMetadataPath
> > > > > >> saml.maximumAuthenticationLifetime
> > > > > >> saml.serviceProviderEntityId
> > > > > >> saml.serviceProviderMetadataPath
> > > > > >> cas.loginUrl
> > > > > >> cas.protocol
> > > > > >> oidc.id
> > > > > >> oidc.secret
> > > > > >> oidc.discoveryUri
> > > > > >> oidc.customParamKey1
> > > > > >> oidc.customParamValue1
> > > > > >>
> > > > > >>
> > > > > >> If you define multiple clients, the first one will be used for
> > > > > >> authentication, but you can explicitly choose the client you
> want
> > to
> > > > use
> > > > > >> via the clientName parameter, assuming you want to switch from
> > > client
> > > > > >> depending on environment for example.
> > > > > >>
> > > > > >> So if you want to add some new authentication mechanism, you
> must
> > > > first
> > > > > >> check that it is available in pac4j (if it's not, it's another
> > > > > discussion,
> > > > > >> but generally, it is). Then, you'll need to upgrade the
> > > > > >> ConfigPropertiesFactory by submitting a new pull request to the
> > > pac4j
> > > > > >> project (I can do it myself, but I'm sure you could do that
> > easily),
> > > > > >> finally wait for the new pac4j release and switch pac4j versions
> > in
> > > > Knox
> > > > > >> to
> > > > > >> benefit from the new feature.
> > > > > >> The good thing is that if someone related to the CAS server does
> > the
> > > > > same
> > > > > >> thing for CAS (in pac4j), you will automatically get it when
> > you'll
> > > > > >> upgrade
> > > > > >> pac4j.
> > > > > >>
> > > > > >> To go even further, replacing LDAP Shiro authentication is just
> a
> > > > matter
> > > > > >> of
> > > > > >> making pac4j LDAP authentication available via configuration
> > > > parameters.
> > > > > >>
> > > > > >> I hope it was clear enough.
> > > > > >>
> > > > > >> Thanks.
> > > > > >> Best regards,
> > > > > >> Jérôme
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> 2015-12-03 20:45 GMT+01:00 larry mccay <la...@gmail.com>:
> > > > > >>
> > > > > >> > Excellent!
> > > > > >> >
> > > > > >> > I will carve out some time to do code review.
> > > > > >> > We will need to get some insights into how to go about
> testing:
> > > > > >> >
> > > > > >> > * is the CAS server going to be available for testing?
> > > > > >> > * what are the specific and generic/standard (if any)
> > > authentication
> > > > > >> > mechanisms available - for instance:
> > > > > >> > - Facebook, Google, LinkedIn and CAS are specifics
> > > > > >> > - OAuth 2, OpenID Connect, SAML are generic/standards -
> that
> > > may
> > > > > be
> > > > > >> > used for the above specifics...
> > > > > >> > * how do we test things other than CAS - in terms of getting
> > > > > >> credentials,
> > > > > >> > configuration, etc
> > > > > >> >
> > > > > >> > We could certainly do this is phases as well.
> > > > > >> >
> > > > > >> > If you can enumerate the things that should work and provide
> > some
> > > > > >> testing
> > > > > >> > details for CAS or as many as possible and OpenID Connect then
> > we
> > > > can
> > > > > >> test
> > > > > >> > the specific implementations that you provide and enable the
> > > testing
> > > > > of
> > > > > >> > another OpenID Connect effort that is in the works in the
> > > community.
> > > > > >> >
> > > > > >> > I'm not sure whether we want to commit contributions that are
> > > > > dependent
> > > > > >> on
> > > > > >> > snapshots - we certainly can't release with any such
> > dependencies.
> > > > > >> > I would hate to add a cleanup task to a release to make sure
> > there
> > > > are
> > > > > >> no
> > > > > >> > snapshots in there.
> > > > > >> > We will probably wait until after the pac4j releases to
> commit.
> > > > > >> >
> > > > > >> > I am really happy that this integration is happening and that
> it
> > > > went
> > > > > >> > rather smoothly.
> > > > > >> > These sorts of authentication protocols are complex and I
> think
> > we
> > > > > >> lined up
> > > > > >> > pretty well overall.
> > > > > >> >
> > > > > >> > Thanks for your work!
> > > > > >> >
> > > > > >> > On Thu, Dec 3, 2015 at 2:28 PM, Jérôme LELEU <
> leleuj@gmail.com>
> > > > > wrote:
> > > > > >> >
> > > > > >> > > Hi,
> > > > > >> > >
> > > > > >> > > I just sync'ed with master, cleaned dependencies and added
> > > missing
> > > > > >> > > Javadocs. Everything works correctly now. Many thanks.
> > > > > >> > >
> > > > > >> > > The pull request is ready for a full code review:
> > > > > >> > > https://github.com/apache/knox/pull/2
> > > > > >> > >
> > > > > >> > > I'll write the documentation after the pac4j releases (I
> hope
> > > next
> > > > > >> week).
> > > > > >> > >
> > > > > >> > > Thanks.
> > > > > >> > > Best regards,
> > > > > >> > > Jérôme
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > 2015-12-02 19:18 GMT+01:00 larry mccay <
> larry.mccay@gmail.com
> > >:
> > > > > >> > >
> > > > > >> > > > Fixed in https://issues.apache.org/jira/browse/KNOX-636.
> > > > > >> > > >
> > > > > >> > > > On Wed, Dec 2, 2015 at 12:42 PM, larry mccay <
> > > > > larry.mccay@gmail.com
> > > > > >> >
> > > > > >> > > > wrote:
> > > > > >> > > >
> > > > > >> > > > > Sure - I can file a JIRA and commit a fix.
> > > > > >> > > > >
> > > > > >> > > > > The secret generation should be done in one instance and
> > > > > >> replicated
> > > > > >> > > > across
> > > > > >> > > > > others.
> > > > > >> > > > > This replication/management of the credential stores is
> > > > outside
> > > > > of
> > > > > >> > the
> > > > > >> > > > > scope of Knox itself as of now.
> > > > > >> > > > >
> > > > > >> > > > > Documentation is done in markdown and is contributing
> > > details
> > > > > are
> > > > > >> > > > > available at:
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
> > > > > >> > > > >
> > > > > >> > > > > Which should give you a general idea.
> > > > > >> > > > >
> > > > > >> > > > > Find an example like: ./trunk/books/0.7.0/
> > > > > >> > > config_preauth_sso_provider.md
> > > > > >> > > > >
> > > > > >> > > > > For an example of typical content and format.
> > > > > >> > > > >
> > > > > >> > > > > Here is how that example renders:
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
> > > > > >> > > > >
> > > > > >> > > > > You'll need to tie it into the rest of the book - just
> > grep
> > > > for
> > > > > >> where
> > > > > >> > > > that
> > > > > >> > > > > filename is referenced.
> > > > > >> > > > > To test how it renders build the site with: "ant" and
> note
> > > the
> > > > > >> url to
> > > > > >> > > the
> > > > > >> > > > > 0.7.0 book.
> > > > > >> > > > >
> > > > > >> > > > >
> > > > > >> > > > > On Wed, Dec 2, 2015 at 12:12 PM, Jérôme LELEU <
> > > > leleuj@gmail.com
> > > > > >
> > > > > >> > > wrote:
> > > > > >> > > > >
> > > > > >> > > > >> Hi,
> > > > > >> > > > >>
> > > > > >> > > > >> Why it doesn't work for pac4j while it works for others
> > is
> > > a
> > > > > bit
> > > > > >> > > strange
> > > > > >> > > > >> to
> > > > > >> > > > >> me, but if you have the patch in front of your eyes,
> I'd
> > > > rather
> > > > > >> > prefer
> > > > > >> > > > you
> > > > > >> > > > >> to commit it. In all cases, I'll sync with the master.
> > > > > >> > > > >>
> > > > > >> > > > >> There was one question you didn't answer previously: is
> > the
> > > > > >> password
> > > > > >> > > > >> generated for the pac4j provider the same across all
> > > gateway
> > > > > >> > > instances?
> > > > > >> > > > >> Because I expect to have the same value as I use it to
> > > > encrypt
> > > > > /
> > > > > >> > > decrypt
> > > > > >> > > > >> data.
> > > > > >> > > > >>
> > > > > >> > > > >> I will add the Javadoc. After that, you can review the
> > pull
> > > > > >> request
> > > > > >> > > more
> > > > > >> > > > >> completely.
> > > > > >> > > > >>
> > > > > >> > > > >> What do you expect for the documentation?
> > > > > >> > > > >>
> > > > > >> > > > >> Notice that pac4j dependencies are still snapshots, but
> > > they
> > > > > >> will be
> > > > > >> > > > >> released in a week or two.
> > > > > >> > > > >>
> > > > > >> > > > >> Thanks.
> > > > > >> > > > >> Best regards,
> > > > > >> > > > >> Jérôme
> > > > > >> > > > >>
> > > > > >> > > > >>
> > > > > >> > > > >> 2015-12-02 17:51 GMT+01:00 larry mccay <
> > > > larry.mccay@gmail.com
> > > > > >:
> > > > > >> > > > >>
> > > > > >> > > > >> > Jérôme -
> > > > > >> > > > >> >
> > > > > >> > > > >> > If you would like to add that change as part of your
> > > patch
> > > > or
> > > > > >> as a
> > > > > >> > > > >> > separately filed JIRA to fix a bug that would
> certainly
> > > be
> > > > > >> > welcomed.
> > > > > >> > > > >> > Otherwise, I can do it.
> > > > > >> > > > >> >
> > > > > >> > > > >> > Let me know.
> > > > > >> > > > >> >
> > > > > >> > > > >> > thanks,
> > > > > >> > > > >> >
> > > > > >> > > > >> > --larry
> > > > > >> > > > >> >
> > > > > >> > > > >> > On Wed, Dec 2, 2015 at 11:44 AM, larry mccay <
> > > > > >> > larry.mccay@gmail.com
> > > > > >> > > >
> > > > > >> > > > >> > wrote:
> > > > > >> > > > >> >
> > > > > >> > > > >> > > Okay - I had to add an override of
> getUserPrincipal()
> > > to
> > > > > the
> > > > > >> > > > >> > > IdentityAsserterHttpServletRequestWrapper and
> return
> > > the
> > > > > >> member
> > > > > >> > > > >> variable
> > > > > >> > > > >> > > username and it works like a charm.
> > > > > >> > > > >> > >
> > > > > >> > > > >> > > Why I haven't seen this same behavior with other
> > > > providers
> > > > > >> is a
> > > > > >> > > bit
> > > > > >> > > > >> of a
> > > > > >> > > > >> > > mystery but they must be adding other wrappers that
> > > > handle
> > > > > >> it.
> > > > > >> > > > >> > > This is quite cool, Jérôme!
> > > > > >> > > > >> > >
> > > > > >> > > > >> > > On Wed, Dec 2, 2015 at 10:41 AM, larry mccay <
> > > > > >> > > larry.mccay@gmail.com
> > > > > >> > > > >
> > > > > >> > > > >> > > wrote:
> > > > > >> > > > >> > >
> > > > > >> > > > >> > >> That was it - thanks!
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >> On Wed, Dec 2, 2015 at 10:20 AM, Jérôme LELEU <
> > > > > >> > leleuj@gmail.com>
> > > > > >> > > > >> wrote:
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >>> This is my exact command line: mvn -Prelease
> clean
> > > > > install
> > > > > >> > > > >> -DskipTests
> > > > > >> > > > >> > >>>
> > > > > >> > > > >> > >>> You use an internal Maven repository to fetch
> > > > > dependencies
> > > > > >> > from
> > > > > >> > > > >> > internet:
> > > > > >> > > > >> > >>>
> > > > > >> > >
> > > http://nexus-private.hortonworks.com/nexus/content/groups/public/
> > > > > >> > > > >> > >>>
> > > > > >> > > > >> > >>> Does this repository have access to the remote
> > > > Snapshots
> > > > > >> > > Sonatype
> > > > > >> > > > >> repo?
> > > > > >> > > > >> > >>>
> > > > > >> > > > >> > >>>
> > > > > >> > > > >> > >>>
> > > > > >> > > > >> > >>> 2015-12-02 16:16 GMT+01:00 larry mccay <
> > > > > >> larry.mccay@gmail.com
> > > > > >> > >:
> > > > > >> > > > >> > >>>
> > > > > >> > > > >> > >>> > hmmm - I used:
> > > > > >> > > > >> > >>> >
> > > > > >> > > > >> > >>> > mvn clean install -DskipTests=true -Prelease
> > > > > >> > > > >> > >>> >
> > > > > >> > > > >> > >>> > The repository entry is in there already.
> > > > > >> > > > >> > >>> > No worky.
> > > > > >> > > > >> > >>> >
> > > > > >> > > > >> > >>> > On Wed, Dec 2, 2015 at 10:12 AM, Jérôme LELEU <
> > > > > >> > > leleuj@gmail.com
> > > > > >> > > > >
> > > > > >> > > > >> > >>> wrote:
> > > > > >> > > > >> > >>> >
> > > > > >> > > > >> > >>> > > Hi,
> > > > > >> > > > >> > >>> > >
> > > > > >> > > > >> > >>> > > You need the j2e-pac4j dependencies as well
> as
> > > the
> > > > > >> pac4j-*
> > > > > >> > > > >> > >>> dependencies,
> > > > > >> > > > >> > >>> > > but you don't need to build them locally
> > > > (hopefully).
> > > > > >> > > > >> > >>> > >
> > > > > >> > > > >> > >>> > > But you need a dependency on the Sonatype
> > > snapshots
> > > > > >> > > repository
> > > > > >> > > > >> > >>> (where the
> > > > > >> > > > >> > >>> > > snapshot versions are hosted), which is added
> > for
> > > > > >> Maven in
> > > > > >> > > the
> > > > > >> > > > >> root
> > > > > >> > > > >> > >>> > > pom.xml:
> > > > > >> > > > >> > >>> > >
> > > > > >> > > > >> > >>> > >
> > > > > >> > > > >> > >>> >
> > > > > >> > > > >> > >>>
> > > > > >> > > > >> >
> > > > > >> > > > >>
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> > > > > >> > > > >> > >>> > >
> > > > > >> > > > >> > >>> > > If you use Ant for the build, there is maybe
> a
> > > > glitch
> > > > > >> to
> > > > > >> > > find
> > > > > >> > > > >> the
> > > > > >> > > > >> > >>> > Sonatype
> > > > > >> > > > >> > >>> > > Maven repo.
> > > > > >> > > > >> > >>> > >
> > > > > >> > > > >> > >>> > > Thanks.
> > > > > >> > > > >> > >>> > > Best regards,
> > > > > >> > > > >> > >>> > > Jérôme
> > > > > >> > > > >> > >>> > >
> > > > > >> > > > >> > >>> > >
> > > > > >> > > > >> > >>> > > 2015-12-02 16:06 GMT+01:00 larry mccay <
> > > > > >> > > larry.mccay@gmail.com
> > > > > >> > > > >:
> > > > > >> > > > >> > >>> > >
> > > > > >> > > > >> > >>> > > > 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.mccay@gmail.com>
> > > > > >> > > > >> > >>> > > > wrote:
> > > > > >> > > > >> > >>> > > >
> > > > > >> > > > >> > >>> > > > > gateway-provider-security-pac4j doesn't
> > > build -
> > > > > do
> > > > > >> you
> > > > > >> > > > have
> > > > > >> > > > >> a
> > > > > >> > > > >> > >>> pending
> > > > > >> > > > >> > >>> > > > > change for your pom.xml or something?
> > > > > >> > > > >> > >>> > > > >
> > > > > >> > > > >> > >>> >
> > > > > >> > > > >> > >>>
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >>
> > > > > >> > > > >> > >
> > > > > >> > > > >> >
> > > > > >> > > > >>
> > > > > >> > > > >
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
Hi Jérôme -
Not sure if you saw but I added review comments to KNOX-641.
I think that we need to determine whether we want the testBasicAuth in the
provider itself.
Let's follow up on the JIRA.
thanks,
--larry
On Fri, Dec 11, 2015 at 8:44 AM, Jérôme LELEU <le...@gmail.com> wrote:
> Hi,
>
> No problem. It can go into a version 0.8.0 if needed. The truth is that
> there is only one change outside the new pac4j module, so I think risks are
> extremly limited.
>
> Just let met know.
>
> Thanks.
> Best regards,
> Jérôme
>
>
> 2015-12-11 14:23 GMT+01:00 larry mccay <la...@gmail.com>:
>
> > Hi Jérôme -
> >
> > I have unfortunately not had a chance to pull, review and test it yet and
> > have intended to do that today.
> > I apologize for the delay.
> >
> > I was actually thinking that this would go into a follow up release that
> we
> > would try and get done rapidly after the 0.7.0 release but we can discuss
> > the target and its chances of destabilizing 0.7.0.
> >
> > I believe that it is rather self-contained with only a few changes to
> > external modules.
> >
> > Opening the JIRAs is perfect and I was going to do that once I started
> the
> > review.
> >
> > Let's continue review comments and collaboration on those JIRAs.
> > I will add you to the contributors list so that we can assign them to
> you.
> >
> > Thank you for your contributions and your patience, Jérôme!
> >
> > --larry
> >
> > On Fri, Dec 11, 2015 at 3:00 AM, Jérôme LELEU <le...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > I didn't get any new feedback on the pull request so I assume
> everything
> > is
> > > ok from your point of view.
> > >
> > > I released pac4j v1.8.1 and j2e-pac4j v1.2.1 so I updated the pull
> > request
> > > to use them and successfully re-tested everything.
> > >
> > > I opened KNOX-641 and submitted the corresponding patch.
> > >
> > > I also wrote the documentation, opened KNOX-642 and submitted the
> > > corresponding patch (just to let you know that it doesn't work out of
> the
> > > box in Windows, I had to replace mvn.bat by mvn.cmd to make ant work).
> > >
> > > Even if the branch 0.7.0 has already been created, I assumed this new
> > pac4j
> > > provider will go into this version 0.7.0 (dependency on the
> > 0.7.0-SNAPSHOT
> > > parent version).
> > >
> > > Just let me know if everything is ok and when it's goind to be merged.
> > >
> > > Thanks.
> > > Best regards,
> > > Jérôme
> > >
> > >
> > >
> > >
> > > 2015-12-04 14:20 GMT+01:00 larry mccay <la...@gmail.com>:
> > >
> > > > That ability to configure multiple mechanisms based on clientName is
> > > really
> > > > interesting for Knox.
> > > > Currently, we require separate topologies per authentication
> mechanism.
> > > > The ability to configure them all in one is really great.
> > > >
> > > > We would need to think through the best way to provide the clientName
> > > > parameter.
> > > > Since this is targeting KnoxSSO it can actually be added to the
> > > providerURL
> > > > used to redirect from the participating application.
> > > > Regardless of the authentication mechanism used each application will
> > > still
> > > > get the same JWT based cookie.
> > > >
> > > > I think that should work really nicely.
> > > >
> > > >
> > > > On Fri, Dec 4, 2015 at 7:17 AM, larry mccay <la...@gmail.com>
> > > wrote:
> > > >
> > > > > Excellent, Jérôme.
> > > > > Thanks!
> > > > >
> > > > > On Fri, Dec 4, 2015 at 2:40 AM, Jérôme LELEU <le...@gmail.com>
> > wrote:
> > > > >
> > > > >> Hi,
> > > > >>
> > > > >> I will write how to configure the pac4j provider in the
> > documentation,
> > > > but
> > > > >> I can already give you some insights.
> > > > >>
> > > > >> My main goal is always to respect the key design principles of
> pac4j
> > > > >> whatever the environment / framework in which it is implemented.
> For
> > > > Knox,
> > > > >> I'm pretty happy with the use of the j2e-pac4j library, which
> means
> > > that
> > > > >> almost all the pac4j features are available, especially both
> direct
> > > and
> > > > >> indirect clients. So it can do what Shiro already does but also,
> as
> > we
> > > > >> agreed together, supports remote authentications.
> > > > >>
> > > > >> It is only limited by what you can currently configure. And even
> > > > >> configuration is a pac4j feature as the CAS server has the same
> > need.
> > > > >> Everything happens in this class:
> > > > >>
> > > > >>
> > > >
> > >
> >
> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java
> > > > >> ,
> > > > >> which allows you to configure Facebook, Twitter, a CAS server, a
> > SAML
> > > > IdP
> > > > >> or an OpenID Connect provider. All the provided parameters to the
> > > pac4j
> > > > >> provider are put into a Map and the ConfigPropertiesFactory is
> built
> > > > with
> > > > >> this Map to return the built client (= authentication mechanism).
> > > > >>
> > > > >> You have one more specific option for Knox as a basic
> authentication
> > > > popup
> > > > >> where the username must match the password, you can define that
> by:
> > > > >>
> > > > >> <param>
> > > > >> <name>clientName</name>
> > > > >> <value>testBasicAuth</value>
> > > > >> </param>
> > > > >>
> > > > >>
> > > > >> It's for testing only.
> > > > >>
> > > > >> For a CAS server:
> > > > >>
> > > > >> <param>
> > > > >> <name>cas.loginUrl</name>
> > > > >> <value>https://casserverpac4j.herokuapp.com/login</value>
> > > > >> </param>
> > > > >>
> > > > >>
> > > > >> Here are all the properties available for building clients (their
> > > > meaning
> > > > >> is obvious):
> > > > >>
> > > > >> facebook.id
> > > > >> facebook.secret
> > > > >> facebook.scope
> > > > >> facebook.fields
> > > > >> twitter.id
> > > > >> twitter.secret
> > > > >> saml.keystorePassword
> > > > >> saml.privateKeyPassword
> > > > >> saml.keystorePath
> > > > >> saml.identityProviderMetadataPath
> > > > >> saml.maximumAuthenticationLifetime
> > > > >> saml.serviceProviderEntityId
> > > > >> saml.serviceProviderMetadataPath
> > > > >> cas.loginUrl
> > > > >> cas.protocol
> > > > >> oidc.id
> > > > >> oidc.secret
> > > > >> oidc.discoveryUri
> > > > >> oidc.customParamKey1
> > > > >> oidc.customParamValue1
> > > > >>
> > > > >>
> > > > >> If you define multiple clients, the first one will be used for
> > > > >> authentication, but you can explicitly choose the client you want
> to
> > > use
> > > > >> via the clientName parameter, assuming you want to switch from
> > client
> > > > >> depending on environment for example.
> > > > >>
> > > > >> So if you want to add some new authentication mechanism, you must
> > > first
> > > > >> check that it is available in pac4j (if it's not, it's another
> > > > discussion,
> > > > >> but generally, it is). Then, you'll need to upgrade the
> > > > >> ConfigPropertiesFactory by submitting a new pull request to the
> > pac4j
> > > > >> project (I can do it myself, but I'm sure you could do that
> easily),
> > > > >> finally wait for the new pac4j release and switch pac4j versions
> in
> > > Knox
> > > > >> to
> > > > >> benefit from the new feature.
> > > > >> The good thing is that if someone related to the CAS server does
> the
> > > > same
> > > > >> thing for CAS (in pac4j), you will automatically get it when
> you'll
> > > > >> upgrade
> > > > >> pac4j.
> > > > >>
> > > > >> To go even further, replacing LDAP Shiro authentication is just a
> > > matter
> > > > >> of
> > > > >> making pac4j LDAP authentication available via configuration
> > > parameters.
> > > > >>
> > > > >> I hope it was clear enough.
> > > > >>
> > > > >> Thanks.
> > > > >> Best regards,
> > > > >> Jérôme
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> 2015-12-03 20:45 GMT+01:00 larry mccay <la...@gmail.com>:
> > > > >>
> > > > >> > Excellent!
> > > > >> >
> > > > >> > I will carve out some time to do code review.
> > > > >> > We will need to get some insights into how to go about testing:
> > > > >> >
> > > > >> > * is the CAS server going to be available for testing?
> > > > >> > * what are the specific and generic/standard (if any)
> > authentication
> > > > >> > mechanisms available - for instance:
> > > > >> > - Facebook, Google, LinkedIn and CAS are specifics
> > > > >> > - OAuth 2, OpenID Connect, SAML are generic/standards - that
> > may
> > > > be
> > > > >> > used for the above specifics...
> > > > >> > * how do we test things other than CAS - in terms of getting
> > > > >> credentials,
> > > > >> > configuration, etc
> > > > >> >
> > > > >> > We could certainly do this is phases as well.
> > > > >> >
> > > > >> > If you can enumerate the things that should work and provide
> some
> > > > >> testing
> > > > >> > details for CAS or as many as possible and OpenID Connect then
> we
> > > can
> > > > >> test
> > > > >> > the specific implementations that you provide and enable the
> > testing
> > > > of
> > > > >> > another OpenID Connect effort that is in the works in the
> > community.
> > > > >> >
> > > > >> > I'm not sure whether we want to commit contributions that are
> > > > dependent
> > > > >> on
> > > > >> > snapshots - we certainly can't release with any such
> dependencies.
> > > > >> > I would hate to add a cleanup task to a release to make sure
> there
> > > are
> > > > >> no
> > > > >> > snapshots in there.
> > > > >> > We will probably wait until after the pac4j releases to commit.
> > > > >> >
> > > > >> > I am really happy that this integration is happening and that it
> > > went
> > > > >> > rather smoothly.
> > > > >> > These sorts of authentication protocols are complex and I think
> we
> > > > >> lined up
> > > > >> > pretty well overall.
> > > > >> >
> > > > >> > Thanks for your work!
> > > > >> >
> > > > >> > On Thu, Dec 3, 2015 at 2:28 PM, Jérôme LELEU <le...@gmail.com>
> > > > wrote:
> > > > >> >
> > > > >> > > Hi,
> > > > >> > >
> > > > >> > > I just sync'ed with master, cleaned dependencies and added
> > missing
> > > > >> > > Javadocs. Everything works correctly now. Many thanks.
> > > > >> > >
> > > > >> > > The pull request is ready for a full code review:
> > > > >> > > https://github.com/apache/knox/pull/2
> > > > >> > >
> > > > >> > > I'll write the documentation after the pac4j releases (I hope
> > next
> > > > >> week).
> > > > >> > >
> > > > >> > > Thanks.
> > > > >> > > Best regards,
> > > > >> > > Jérôme
> > > > >> > >
> > > > >> > >
> > > > >> > > 2015-12-02 19:18 GMT+01:00 larry mccay <larry.mccay@gmail.com
> >:
> > > > >> > >
> > > > >> > > > Fixed in https://issues.apache.org/jira/browse/KNOX-636.
> > > > >> > > >
> > > > >> > > > On Wed, Dec 2, 2015 at 12:42 PM, larry mccay <
> > > > larry.mccay@gmail.com
> > > > >> >
> > > > >> > > > wrote:
> > > > >> > > >
> > > > >> > > > > Sure - I can file a JIRA and commit a fix.
> > > > >> > > > >
> > > > >> > > > > The secret generation should be done in one instance and
> > > > >> replicated
> > > > >> > > > across
> > > > >> > > > > others.
> > > > >> > > > > This replication/management of the credential stores is
> > > outside
> > > > of
> > > > >> > the
> > > > >> > > > > scope of Knox itself as of now.
> > > > >> > > > >
> > > > >> > > > > Documentation is done in markdown and is contributing
> > details
> > > > are
> > > > >> > > > > available at:
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
> > > > >> > > > >
> > > > >> > > > > Which should give you a general idea.
> > > > >> > > > >
> > > > >> > > > > Find an example like: ./trunk/books/0.7.0/
> > > > >> > > config_preauth_sso_provider.md
> > > > >> > > > >
> > > > >> > > > > For an example of typical content and format.
> > > > >> > > > >
> > > > >> > > > > Here is how that example renders:
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
> > > > >> > > > >
> > > > >> > > > > You'll need to tie it into the rest of the book - just
> grep
> > > for
> > > > >> where
> > > > >> > > > that
> > > > >> > > > > filename is referenced.
> > > > >> > > > > To test how it renders build the site with: "ant" and note
> > the
> > > > >> url to
> > > > >> > > the
> > > > >> > > > > 0.7.0 book.
> > > > >> > > > >
> > > > >> > > > >
> > > > >> > > > > On Wed, Dec 2, 2015 at 12:12 PM, Jérôme LELEU <
> > > leleuj@gmail.com
> > > > >
> > > > >> > > wrote:
> > > > >> > > > >
> > > > >> > > > >> Hi,
> > > > >> > > > >>
> > > > >> > > > >> Why it doesn't work for pac4j while it works for others
> is
> > a
> > > > bit
> > > > >> > > strange
> > > > >> > > > >> to
> > > > >> > > > >> me, but if you have the patch in front of your eyes, I'd
> > > rather
> > > > >> > prefer
> > > > >> > > > you
> > > > >> > > > >> to commit it. In all cases, I'll sync with the master.
> > > > >> > > > >>
> > > > >> > > > >> There was one question you didn't answer previously: is
> the
> > > > >> password
> > > > >> > > > >> generated for the pac4j provider the same across all
> > gateway
> > > > >> > > instances?
> > > > >> > > > >> Because I expect to have the same value as I use it to
> > > encrypt
> > > > /
> > > > >> > > decrypt
> > > > >> > > > >> data.
> > > > >> > > > >>
> > > > >> > > > >> I will add the Javadoc. After that, you can review the
> pull
> > > > >> request
> > > > >> > > more
> > > > >> > > > >> completely.
> > > > >> > > > >>
> > > > >> > > > >> What do you expect for the documentation?
> > > > >> > > > >>
> > > > >> > > > >> Notice that pac4j dependencies are still snapshots, but
> > they
> > > > >> will be
> > > > >> > > > >> released in a week or two.
> > > > >> > > > >>
> > > > >> > > > >> Thanks.
> > > > >> > > > >> Best regards,
> > > > >> > > > >> Jérôme
> > > > >> > > > >>
> > > > >> > > > >>
> > > > >> > > > >> 2015-12-02 17:51 GMT+01:00 larry mccay <
> > > larry.mccay@gmail.com
> > > > >:
> > > > >> > > > >>
> > > > >> > > > >> > Jérôme -
> > > > >> > > > >> >
> > > > >> > > > >> > If you would like to add that change as part of your
> > patch
> > > or
> > > > >> as a
> > > > >> > > > >> > separately filed JIRA to fix a bug that would certainly
> > be
> > > > >> > welcomed.
> > > > >> > > > >> > Otherwise, I can do it.
> > > > >> > > > >> >
> > > > >> > > > >> > Let me know.
> > > > >> > > > >> >
> > > > >> > > > >> > thanks,
> > > > >> > > > >> >
> > > > >> > > > >> > --larry
> > > > >> > > > >> >
> > > > >> > > > >> > On Wed, Dec 2, 2015 at 11:44 AM, larry mccay <
> > > > >> > larry.mccay@gmail.com
> > > > >> > > >
> > > > >> > > > >> > wrote:
> > > > >> > > > >> >
> > > > >> > > > >> > > Okay - I had to add an override of getUserPrincipal()
> > to
> > > > the
> > > > >> > > > >> > > IdentityAsserterHttpServletRequestWrapper and return
> > the
> > > > >> member
> > > > >> > > > >> variable
> > > > >> > > > >> > > username and it works like a charm.
> > > > >> > > > >> > >
> > > > >> > > > >> > > Why I haven't seen this same behavior with other
> > > providers
> > > > >> is a
> > > > >> > > bit
> > > > >> > > > >> of a
> > > > >> > > > >> > > mystery but they must be adding other wrappers that
> > > handle
> > > > >> it.
> > > > >> > > > >> > > This is quite cool, Jérôme!
> > > > >> > > > >> > >
> > > > >> > > > >> > > On Wed, Dec 2, 2015 at 10:41 AM, larry mccay <
> > > > >> > > larry.mccay@gmail.com
> > > > >> > > > >
> > > > >> > > > >> > > wrote:
> > > > >> > > > >> > >
> > > > >> > > > >> > >> That was it - thanks!
> > > > >> > > > >> > >>
> > > > >> > > > >> > >> On Wed, Dec 2, 2015 at 10:20 AM, Jérôme LELEU <
> > > > >> > leleuj@gmail.com>
> > > > >> > > > >> wrote:
> > > > >> > > > >> > >>
> > > > >> > > > >> > >>> This is my exact command line: mvn -Prelease clean
> > > > install
> > > > >> > > > >> -DskipTests
> > > > >> > > > >> > >>>
> > > > >> > > > >> > >>> You use an internal Maven repository to fetch
> > > > dependencies
> > > > >> > from
> > > > >> > > > >> > internet:
> > > > >> > > > >> > >>>
> > > > >> > >
> > http://nexus-private.hortonworks.com/nexus/content/groups/public/
> > > > >> > > > >> > >>>
> > > > >> > > > >> > >>> Does this repository have access to the remote
> > > Snapshots
> > > > >> > > Sonatype
> > > > >> > > > >> repo?
> > > > >> > > > >> > >>>
> > > > >> > > > >> > >>>
> > > > >> > > > >> > >>>
> > > > >> > > > >> > >>> 2015-12-02 16:16 GMT+01:00 larry mccay <
> > > > >> larry.mccay@gmail.com
> > > > >> > >:
> > > > >> > > > >> > >>>
> > > > >> > > > >> > >>> > hmmm - I used:
> > > > >> > > > >> > >>> >
> > > > >> > > > >> > >>> > mvn clean install -DskipTests=true -Prelease
> > > > >> > > > >> > >>> >
> > > > >> > > > >> > >>> > The repository entry is in there already.
> > > > >> > > > >> > >>> > No worky.
> > > > >> > > > >> > >>> >
> > > > >> > > > >> > >>> > On Wed, Dec 2, 2015 at 10:12 AM, Jérôme LELEU <
> > > > >> > > leleuj@gmail.com
> > > > >> > > > >
> > > > >> > > > >> > >>> wrote:
> > > > >> > > > >> > >>> >
> > > > >> > > > >> > >>> > > Hi,
> > > > >> > > > >> > >>> > >
> > > > >> > > > >> > >>> > > You need the j2e-pac4j dependencies as well as
> > the
> > > > >> pac4j-*
> > > > >> > > > >> > >>> dependencies,
> > > > >> > > > >> > >>> > > but you don't need to build them locally
> > > (hopefully).
> > > > >> > > > >> > >>> > >
> > > > >> > > > >> > >>> > > But you need a dependency on the Sonatype
> > snapshots
> > > > >> > > repository
> > > > >> > > > >> > >>> (where the
> > > > >> > > > >> > >>> > > snapshot versions are hosted), which is added
> for
> > > > >> Maven in
> > > > >> > > the
> > > > >> > > > >> root
> > > > >> > > > >> > >>> > > pom.xml:
> > > > >> > > > >> > >>> > >
> > > > >> > > > >> > >>> > >
> > > > >> > > > >> > >>> >
> > > > >> > > > >> > >>>
> > > > >> > > > >> >
> > > > >> > > > >>
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> > > > >> > > > >> > >>> > >
> > > > >> > > > >> > >>> > > If you use Ant for the build, there is maybe a
> > > glitch
> > > > >> to
> > > > >> > > find
> > > > >> > > > >> the
> > > > >> > > > >> > >>> > Sonatype
> > > > >> > > > >> > >>> > > Maven repo.
> > > > >> > > > >> > >>> > >
> > > > >> > > > >> > >>> > > Thanks.
> > > > >> > > > >> > >>> > > Best regards,
> > > > >> > > > >> > >>> > > Jérôme
> > > > >> > > > >> > >>> > >
> > > > >> > > > >> > >>> > >
> > > > >> > > > >> > >>> > > 2015-12-02 16:06 GMT+01:00 larry mccay <
> > > > >> > > larry.mccay@gmail.com
> > > > >> > > > >:
> > > > >> > > > >> > >>> > >
> > > > >> > > > >> > >>> > > > 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.mccay@gmail.com>
> > > > >> > > > >> > >>> > > > wrote:
> > > > >> > > > >> > >>> > > >
> > > > >> > > > >> > >>> > > > > gateway-provider-security-pac4j doesn't
> > build -
> > > > do
> > > > >> you
> > > > >> > > > have
> > > > >> > > > >> a
> > > > >> > > > >> > >>> pending
> > > > >> > > > >> > >>> > > > > change for your pom.xml or something?
> > > > >> > > > >> > >>> > > > >
> > > > >> > > > >> > >>> >
> > > > >> > > > >> > >>>
> > > > >> > > > >> > >>
> > > > >> > > > >> > >>
> > > > >> > > > >> > >
> > > > >> > > > >> >
> > > > >> > > > >>
> > > > >> > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Hi,
No problem. It can go into a version 0.8.0 if needed. The truth is that
there is only one change outside the new pac4j module, so I think risks are
extremly limited.
Just let met know.
Thanks.
Best regards,
Jérôme
2015-12-11 14:23 GMT+01:00 larry mccay <la...@gmail.com>:
> Hi Jérôme -
>
> I have unfortunately not had a chance to pull, review and test it yet and
> have intended to do that today.
> I apologize for the delay.
>
> I was actually thinking that this would go into a follow up release that we
> would try and get done rapidly after the 0.7.0 release but we can discuss
> the target and its chances of destabilizing 0.7.0.
>
> I believe that it is rather self-contained with only a few changes to
> external modules.
>
> Opening the JIRAs is perfect and I was going to do that once I started the
> review.
>
> Let's continue review comments and collaboration on those JIRAs.
> I will add you to the contributors list so that we can assign them to you.
>
> Thank you for your contributions and your patience, Jérôme!
>
> --larry
>
> On Fri, Dec 11, 2015 at 3:00 AM, Jérôme LELEU <le...@gmail.com> wrote:
>
> > Hi,
> >
> > I didn't get any new feedback on the pull request so I assume everything
> is
> > ok from your point of view.
> >
> > I released pac4j v1.8.1 and j2e-pac4j v1.2.1 so I updated the pull
> request
> > to use them and successfully re-tested everything.
> >
> > I opened KNOX-641 and submitted the corresponding patch.
> >
> > I also wrote the documentation, opened KNOX-642 and submitted the
> > corresponding patch (just to let you know that it doesn't work out of the
> > box in Windows, I had to replace mvn.bat by mvn.cmd to make ant work).
> >
> > Even if the branch 0.7.0 has already been created, I assumed this new
> pac4j
> > provider will go into this version 0.7.0 (dependency on the
> 0.7.0-SNAPSHOT
> > parent version).
> >
> > Just let me know if everything is ok and when it's goind to be merged.
> >
> > Thanks.
> > Best regards,
> > Jérôme
> >
> >
> >
> >
> > 2015-12-04 14:20 GMT+01:00 larry mccay <la...@gmail.com>:
> >
> > > That ability to configure multiple mechanisms based on clientName is
> > really
> > > interesting for Knox.
> > > Currently, we require separate topologies per authentication mechanism.
> > > The ability to configure them all in one is really great.
> > >
> > > We would need to think through the best way to provide the clientName
> > > parameter.
> > > Since this is targeting KnoxSSO it can actually be added to the
> > providerURL
> > > used to redirect from the participating application.
> > > Regardless of the authentication mechanism used each application will
> > still
> > > get the same JWT based cookie.
> > >
> > > I think that should work really nicely.
> > >
> > >
> > > On Fri, Dec 4, 2015 at 7:17 AM, larry mccay <la...@gmail.com>
> > wrote:
> > >
> > > > Excellent, Jérôme.
> > > > Thanks!
> > > >
> > > > On Fri, Dec 4, 2015 at 2:40 AM, Jérôme LELEU <le...@gmail.com>
> wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> I will write how to configure the pac4j provider in the
> documentation,
> > > but
> > > >> I can already give you some insights.
> > > >>
> > > >> My main goal is always to respect the key design principles of pac4j
> > > >> whatever the environment / framework in which it is implemented. For
> > > Knox,
> > > >> I'm pretty happy with the use of the j2e-pac4j library, which means
> > that
> > > >> almost all the pac4j features are available, especially both direct
> > and
> > > >> indirect clients. So it can do what Shiro already does but also, as
> we
> > > >> agreed together, supports remote authentications.
> > > >>
> > > >> It is only limited by what you can currently configure. And even
> > > >> configuration is a pac4j feature as the CAS server has the same
> need.
> > > >> Everything happens in this class:
> > > >>
> > > >>
> > >
> >
> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java
> > > >> ,
> > > >> which allows you to configure Facebook, Twitter, a CAS server, a
> SAML
> > > IdP
> > > >> or an OpenID Connect provider. All the provided parameters to the
> > pac4j
> > > >> provider are put into a Map and the ConfigPropertiesFactory is built
> > > with
> > > >> this Map to return the built client (= authentication mechanism).
> > > >>
> > > >> You have one more specific option for Knox as a basic authentication
> > > popup
> > > >> where the username must match the password, you can define that by:
> > > >>
> > > >> <param>
> > > >> <name>clientName</name>
> > > >> <value>testBasicAuth</value>
> > > >> </param>
> > > >>
> > > >>
> > > >> It's for testing only.
> > > >>
> > > >> For a CAS server:
> > > >>
> > > >> <param>
> > > >> <name>cas.loginUrl</name>
> > > >> <value>https://casserverpac4j.herokuapp.com/login</value>
> > > >> </param>
> > > >>
> > > >>
> > > >> Here are all the properties available for building clients (their
> > > meaning
> > > >> is obvious):
> > > >>
> > > >> facebook.id
> > > >> facebook.secret
> > > >> facebook.scope
> > > >> facebook.fields
> > > >> twitter.id
> > > >> twitter.secret
> > > >> saml.keystorePassword
> > > >> saml.privateKeyPassword
> > > >> saml.keystorePath
> > > >> saml.identityProviderMetadataPath
> > > >> saml.maximumAuthenticationLifetime
> > > >> saml.serviceProviderEntityId
> > > >> saml.serviceProviderMetadataPath
> > > >> cas.loginUrl
> > > >> cas.protocol
> > > >> oidc.id
> > > >> oidc.secret
> > > >> oidc.discoveryUri
> > > >> oidc.customParamKey1
> > > >> oidc.customParamValue1
> > > >>
> > > >>
> > > >> If you define multiple clients, the first one will be used for
> > > >> authentication, but you can explicitly choose the client you want to
> > use
> > > >> via the clientName parameter, assuming you want to switch from
> client
> > > >> depending on environment for example.
> > > >>
> > > >> So if you want to add some new authentication mechanism, you must
> > first
> > > >> check that it is available in pac4j (if it's not, it's another
> > > discussion,
> > > >> but generally, it is). Then, you'll need to upgrade the
> > > >> ConfigPropertiesFactory by submitting a new pull request to the
> pac4j
> > > >> project (I can do it myself, but I'm sure you could do that easily),
> > > >> finally wait for the new pac4j release and switch pac4j versions in
> > Knox
> > > >> to
> > > >> benefit from the new feature.
> > > >> The good thing is that if someone related to the CAS server does the
> > > same
> > > >> thing for CAS (in pac4j), you will automatically get it when you'll
> > > >> upgrade
> > > >> pac4j.
> > > >>
> > > >> To go even further, replacing LDAP Shiro authentication is just a
> > matter
> > > >> of
> > > >> making pac4j LDAP authentication available via configuration
> > parameters.
> > > >>
> > > >> I hope it was clear enough.
> > > >>
> > > >> Thanks.
> > > >> Best regards,
> > > >> Jérôme
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> 2015-12-03 20:45 GMT+01:00 larry mccay <la...@gmail.com>:
> > > >>
> > > >> > Excellent!
> > > >> >
> > > >> > I will carve out some time to do code review.
> > > >> > We will need to get some insights into how to go about testing:
> > > >> >
> > > >> > * is the CAS server going to be available for testing?
> > > >> > * what are the specific and generic/standard (if any)
> authentication
> > > >> > mechanisms available - for instance:
> > > >> > - Facebook, Google, LinkedIn and CAS are specifics
> > > >> > - OAuth 2, OpenID Connect, SAML are generic/standards - that
> may
> > > be
> > > >> > used for the above specifics...
> > > >> > * how do we test things other than CAS - in terms of getting
> > > >> credentials,
> > > >> > configuration, etc
> > > >> >
> > > >> > We could certainly do this is phases as well.
> > > >> >
> > > >> > If you can enumerate the things that should work and provide some
> > > >> testing
> > > >> > details for CAS or as many as possible and OpenID Connect then we
> > can
> > > >> test
> > > >> > the specific implementations that you provide and enable the
> testing
> > > of
> > > >> > another OpenID Connect effort that is in the works in the
> community.
> > > >> >
> > > >> > I'm not sure whether we want to commit contributions that are
> > > dependent
> > > >> on
> > > >> > snapshots - we certainly can't release with any such dependencies.
> > > >> > I would hate to add a cleanup task to a release to make sure there
> > are
> > > >> no
> > > >> > snapshots in there.
> > > >> > We will probably wait until after the pac4j releases to commit.
> > > >> >
> > > >> > I am really happy that this integration is happening and that it
> > went
> > > >> > rather smoothly.
> > > >> > These sorts of authentication protocols are complex and I think we
> > > >> lined up
> > > >> > pretty well overall.
> > > >> >
> > > >> > Thanks for your work!
> > > >> >
> > > >> > On Thu, Dec 3, 2015 at 2:28 PM, Jérôme LELEU <le...@gmail.com>
> > > wrote:
> > > >> >
> > > >> > > Hi,
> > > >> > >
> > > >> > > I just sync'ed with master, cleaned dependencies and added
> missing
> > > >> > > Javadocs. Everything works correctly now. Many thanks.
> > > >> > >
> > > >> > > The pull request is ready for a full code review:
> > > >> > > https://github.com/apache/knox/pull/2
> > > >> > >
> > > >> > > I'll write the documentation after the pac4j releases (I hope
> next
> > > >> week).
> > > >> > >
> > > >> > > Thanks.
> > > >> > > Best regards,
> > > >> > > Jérôme
> > > >> > >
> > > >> > >
> > > >> > > 2015-12-02 19:18 GMT+01:00 larry mccay <la...@gmail.com>:
> > > >> > >
> > > >> > > > Fixed in https://issues.apache.org/jira/browse/KNOX-636.
> > > >> > > >
> > > >> > > > On Wed, Dec 2, 2015 at 12:42 PM, larry mccay <
> > > larry.mccay@gmail.com
> > > >> >
> > > >> > > > wrote:
> > > >> > > >
> > > >> > > > > Sure - I can file a JIRA and commit a fix.
> > > >> > > > >
> > > >> > > > > The secret generation should be done in one instance and
> > > >> replicated
> > > >> > > > across
> > > >> > > > > others.
> > > >> > > > > This replication/management of the credential stores is
> > outside
> > > of
> > > >> > the
> > > >> > > > > scope of Knox itself as of now.
> > > >> > > > >
> > > >> > > > > Documentation is done in markdown and is contributing
> details
> > > are
> > > >> > > > > available at:
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
> > > >> > > > >
> > > >> > > > > Which should give you a general idea.
> > > >> > > > >
> > > >> > > > > Find an example like: ./trunk/books/0.7.0/
> > > >> > > config_preauth_sso_provider.md
> > > >> > > > >
> > > >> > > > > For an example of typical content and format.
> > > >> > > > >
> > > >> > > > > Here is how that example renders:
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
> > > >> > > > >
> > > >> > > > > You'll need to tie it into the rest of the book - just grep
> > for
> > > >> where
> > > >> > > > that
> > > >> > > > > filename is referenced.
> > > >> > > > > To test how it renders build the site with: "ant" and note
> the
> > > >> url to
> > > >> > > the
> > > >> > > > > 0.7.0 book.
> > > >> > > > >
> > > >> > > > >
> > > >> > > > > On Wed, Dec 2, 2015 at 12:12 PM, Jérôme LELEU <
> > leleuj@gmail.com
> > > >
> > > >> > > wrote:
> > > >> > > > >
> > > >> > > > >> Hi,
> > > >> > > > >>
> > > >> > > > >> Why it doesn't work for pac4j while it works for others is
> a
> > > bit
> > > >> > > strange
> > > >> > > > >> to
> > > >> > > > >> me, but if you have the patch in front of your eyes, I'd
> > rather
> > > >> > prefer
> > > >> > > > you
> > > >> > > > >> to commit it. In all cases, I'll sync with the master.
> > > >> > > > >>
> > > >> > > > >> There was one question you didn't answer previously: is the
> > > >> password
> > > >> > > > >> generated for the pac4j provider the same across all
> gateway
> > > >> > > instances?
> > > >> > > > >> Because I expect to have the same value as I use it to
> > encrypt
> > > /
> > > >> > > decrypt
> > > >> > > > >> data.
> > > >> > > > >>
> > > >> > > > >> I will add the Javadoc. After that, you can review the pull
> > > >> request
> > > >> > > more
> > > >> > > > >> completely.
> > > >> > > > >>
> > > >> > > > >> What do you expect for the documentation?
> > > >> > > > >>
> > > >> > > > >> Notice that pac4j dependencies are still snapshots, but
> they
> > > >> will be
> > > >> > > > >> released in a week or two.
> > > >> > > > >>
> > > >> > > > >> Thanks.
> > > >> > > > >> Best regards,
> > > >> > > > >> Jérôme
> > > >> > > > >>
> > > >> > > > >>
> > > >> > > > >> 2015-12-02 17:51 GMT+01:00 larry mccay <
> > larry.mccay@gmail.com
> > > >:
> > > >> > > > >>
> > > >> > > > >> > Jérôme -
> > > >> > > > >> >
> > > >> > > > >> > If you would like to add that change as part of your
> patch
> > or
> > > >> as a
> > > >> > > > >> > separately filed JIRA to fix a bug that would certainly
> be
> > > >> > welcomed.
> > > >> > > > >> > Otherwise, I can do it.
> > > >> > > > >> >
> > > >> > > > >> > Let me know.
> > > >> > > > >> >
> > > >> > > > >> > thanks,
> > > >> > > > >> >
> > > >> > > > >> > --larry
> > > >> > > > >> >
> > > >> > > > >> > On Wed, Dec 2, 2015 at 11:44 AM, larry mccay <
> > > >> > larry.mccay@gmail.com
> > > >> > > >
> > > >> > > > >> > wrote:
> > > >> > > > >> >
> > > >> > > > >> > > Okay - I had to add an override of getUserPrincipal()
> to
> > > the
> > > >> > > > >> > > IdentityAsserterHttpServletRequestWrapper and return
> the
> > > >> member
> > > >> > > > >> variable
> > > >> > > > >> > > username and it works like a charm.
> > > >> > > > >> > >
> > > >> > > > >> > > Why I haven't seen this same behavior with other
> > providers
> > > >> is a
> > > >> > > bit
> > > >> > > > >> of a
> > > >> > > > >> > > mystery but they must be adding other wrappers that
> > handle
> > > >> it.
> > > >> > > > >> > > This is quite cool, Jérôme!
> > > >> > > > >> > >
> > > >> > > > >> > > On Wed, Dec 2, 2015 at 10:41 AM, larry mccay <
> > > >> > > larry.mccay@gmail.com
> > > >> > > > >
> > > >> > > > >> > > wrote:
> > > >> > > > >> > >
> > > >> > > > >> > >> That was it - thanks!
> > > >> > > > >> > >>
> > > >> > > > >> > >> On Wed, Dec 2, 2015 at 10:20 AM, Jérôme LELEU <
> > > >> > leleuj@gmail.com>
> > > >> > > > >> wrote:
> > > >> > > > >> > >>
> > > >> > > > >> > >>> This is my exact command line: mvn -Prelease clean
> > > install
> > > >> > > > >> -DskipTests
> > > >> > > > >> > >>>
> > > >> > > > >> > >>> You use an internal Maven repository to fetch
> > > dependencies
> > > >> > from
> > > >> > > > >> > internet:
> > > >> > > > >> > >>>
> > > >> > >
> http://nexus-private.hortonworks.com/nexus/content/groups/public/
> > > >> > > > >> > >>>
> > > >> > > > >> > >>> Does this repository have access to the remote
> > Snapshots
> > > >> > > Sonatype
> > > >> > > > >> repo?
> > > >> > > > >> > >>>
> > > >> > > > >> > >>>
> > > >> > > > >> > >>>
> > > >> > > > >> > >>> 2015-12-02 16:16 GMT+01:00 larry mccay <
> > > >> larry.mccay@gmail.com
> > > >> > >:
> > > >> > > > >> > >>>
> > > >> > > > >> > >>> > hmmm - I used:
> > > >> > > > >> > >>> >
> > > >> > > > >> > >>> > mvn clean install -DskipTests=true -Prelease
> > > >> > > > >> > >>> >
> > > >> > > > >> > >>> > The repository entry is in there already.
> > > >> > > > >> > >>> > No worky.
> > > >> > > > >> > >>> >
> > > >> > > > >> > >>> > On Wed, Dec 2, 2015 at 10:12 AM, Jérôme LELEU <
> > > >> > > leleuj@gmail.com
> > > >> > > > >
> > > >> > > > >> > >>> wrote:
> > > >> > > > >> > >>> >
> > > >> > > > >> > >>> > > Hi,
> > > >> > > > >> > >>> > >
> > > >> > > > >> > >>> > > You need the j2e-pac4j dependencies as well as
> the
> > > >> pac4j-*
> > > >> > > > >> > >>> dependencies,
> > > >> > > > >> > >>> > > but you don't need to build them locally
> > (hopefully).
> > > >> > > > >> > >>> > >
> > > >> > > > >> > >>> > > But you need a dependency on the Sonatype
> snapshots
> > > >> > > repository
> > > >> > > > >> > >>> (where the
> > > >> > > > >> > >>> > > snapshot versions are hosted), which is added for
> > > >> Maven in
> > > >> > > the
> > > >> > > > >> root
> > > >> > > > >> > >>> > > pom.xml:
> > > >> > > > >> > >>> > >
> > > >> > > > >> > >>> > >
> > > >> > > > >> > >>> >
> > > >> > > > >> > >>>
> > > >> > > > >> >
> > > >> > > > >>
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> > > >> > > > >> > >>> > >
> > > >> > > > >> > >>> > > If you use Ant for the build, there is maybe a
> > glitch
> > > >> to
> > > >> > > find
> > > >> > > > >> the
> > > >> > > > >> > >>> > Sonatype
> > > >> > > > >> > >>> > > Maven repo.
> > > >> > > > >> > >>> > >
> > > >> > > > >> > >>> > > Thanks.
> > > >> > > > >> > >>> > > Best regards,
> > > >> > > > >> > >>> > > Jérôme
> > > >> > > > >> > >>> > >
> > > >> > > > >> > >>> > >
> > > >> > > > >> > >>> > > 2015-12-02 16:06 GMT+01:00 larry mccay <
> > > >> > > larry.mccay@gmail.com
> > > >> > > > >:
> > > >> > > > >> > >>> > >
> > > >> > > > >> > >>> > > > 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.mccay@gmail.com>
> > > >> > > > >> > >>> > > > wrote:
> > > >> > > > >> > >>> > > >
> > > >> > > > >> > >>> > > > > gateway-provider-security-pac4j doesn't
> build -
> > > do
> > > >> you
> > > >> > > > have
> > > >> > > > >> a
> > > >> > > > >> > >>> pending
> > > >> > > > >> > >>> > > > > change for your pom.xml or something?
> > > >> > > > >> > >>> > > > >
> > > >> > > > >> > >>> >
> > > >> > > > >> > >>>
> > > >> > > > >> > >>
> > > >> > > > >> > >>
> > > >> > > > >> > >
> > > >> > > > >> >
> > > >> > > > >>
> > > >> > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
Hi Jérôme -
I have unfortunately not had a chance to pull, review and test it yet and
have intended to do that today.
I apologize for the delay.
I was actually thinking that this would go into a follow up release that we
would try and get done rapidly after the 0.7.0 release but we can discuss
the target and its chances of destabilizing 0.7.0.
I believe that it is rather self-contained with only a few changes to
external modules.
Opening the JIRAs is perfect and I was going to do that once I started the
review.
Let's continue review comments and collaboration on those JIRAs.
I will add you to the contributors list so that we can assign them to you.
Thank you for your contributions and your patience, Jérôme!
--larry
On Fri, Dec 11, 2015 at 3:00 AM, Jérôme LELEU <le...@gmail.com> wrote:
> Hi,
>
> I didn't get any new feedback on the pull request so I assume everything is
> ok from your point of view.
>
> I released pac4j v1.8.1 and j2e-pac4j v1.2.1 so I updated the pull request
> to use them and successfully re-tested everything.
>
> I opened KNOX-641 and submitted the corresponding patch.
>
> I also wrote the documentation, opened KNOX-642 and submitted the
> corresponding patch (just to let you know that it doesn't work out of the
> box in Windows, I had to replace mvn.bat by mvn.cmd to make ant work).
>
> Even if the branch 0.7.0 has already been created, I assumed this new pac4j
> provider will go into this version 0.7.0 (dependency on the 0.7.0-SNAPSHOT
> parent version).
>
> Just let me know if everything is ok and when it's goind to be merged.
>
> Thanks.
> Best regards,
> Jérôme
>
>
>
>
> 2015-12-04 14:20 GMT+01:00 larry mccay <la...@gmail.com>:
>
> > That ability to configure multiple mechanisms based on clientName is
> really
> > interesting for Knox.
> > Currently, we require separate topologies per authentication mechanism.
> > The ability to configure them all in one is really great.
> >
> > We would need to think through the best way to provide the clientName
> > parameter.
> > Since this is targeting KnoxSSO it can actually be added to the
> providerURL
> > used to redirect from the participating application.
> > Regardless of the authentication mechanism used each application will
> still
> > get the same JWT based cookie.
> >
> > I think that should work really nicely.
> >
> >
> > On Fri, Dec 4, 2015 at 7:17 AM, larry mccay <la...@gmail.com>
> wrote:
> >
> > > Excellent, Jérôme.
> > > Thanks!
> > >
> > > On Fri, Dec 4, 2015 at 2:40 AM, Jérôme LELEU <le...@gmail.com> wrote:
> > >
> > >> Hi,
> > >>
> > >> I will write how to configure the pac4j provider in the documentation,
> > but
> > >> I can already give you some insights.
> > >>
> > >> My main goal is always to respect the key design principles of pac4j
> > >> whatever the environment / framework in which it is implemented. For
> > Knox,
> > >> I'm pretty happy with the use of the j2e-pac4j library, which means
> that
> > >> almost all the pac4j features are available, especially both direct
> and
> > >> indirect clients. So it can do what Shiro already does but also, as we
> > >> agreed together, supports remote authentications.
> > >>
> > >> It is only limited by what you can currently configure. And even
> > >> configuration is a pac4j feature as the CAS server has the same need.
> > >> Everything happens in this class:
> > >>
> > >>
> >
> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java
> > >> ,
> > >> which allows you to configure Facebook, Twitter, a CAS server, a SAML
> > IdP
> > >> or an OpenID Connect provider. All the provided parameters to the
> pac4j
> > >> provider are put into a Map and the ConfigPropertiesFactory is built
> > with
> > >> this Map to return the built client (= authentication mechanism).
> > >>
> > >> You have one more specific option for Knox as a basic authentication
> > popup
> > >> where the username must match the password, you can define that by:
> > >>
> > >> <param>
> > >> <name>clientName</name>
> > >> <value>testBasicAuth</value>
> > >> </param>
> > >>
> > >>
> > >> It's for testing only.
> > >>
> > >> For a CAS server:
> > >>
> > >> <param>
> > >> <name>cas.loginUrl</name>
> > >> <value>https://casserverpac4j.herokuapp.com/login</value>
> > >> </param>
> > >>
> > >>
> > >> Here are all the properties available for building clients (their
> > meaning
> > >> is obvious):
> > >>
> > >> facebook.id
> > >> facebook.secret
> > >> facebook.scope
> > >> facebook.fields
> > >> twitter.id
> > >> twitter.secret
> > >> saml.keystorePassword
> > >> saml.privateKeyPassword
> > >> saml.keystorePath
> > >> saml.identityProviderMetadataPath
> > >> saml.maximumAuthenticationLifetime
> > >> saml.serviceProviderEntityId
> > >> saml.serviceProviderMetadataPath
> > >> cas.loginUrl
> > >> cas.protocol
> > >> oidc.id
> > >> oidc.secret
> > >> oidc.discoveryUri
> > >> oidc.customParamKey1
> > >> oidc.customParamValue1
> > >>
> > >>
> > >> If you define multiple clients, the first one will be used for
> > >> authentication, but you can explicitly choose the client you want to
> use
> > >> via the clientName parameter, assuming you want to switch from client
> > >> depending on environment for example.
> > >>
> > >> So if you want to add some new authentication mechanism, you must
> first
> > >> check that it is available in pac4j (if it's not, it's another
> > discussion,
> > >> but generally, it is). Then, you'll need to upgrade the
> > >> ConfigPropertiesFactory by submitting a new pull request to the pac4j
> > >> project (I can do it myself, but I'm sure you could do that easily),
> > >> finally wait for the new pac4j release and switch pac4j versions in
> Knox
> > >> to
> > >> benefit from the new feature.
> > >> The good thing is that if someone related to the CAS server does the
> > same
> > >> thing for CAS (in pac4j), you will automatically get it when you'll
> > >> upgrade
> > >> pac4j.
> > >>
> > >> To go even further, replacing LDAP Shiro authentication is just a
> matter
> > >> of
> > >> making pac4j LDAP authentication available via configuration
> parameters.
> > >>
> > >> I hope it was clear enough.
> > >>
> > >> Thanks.
> > >> Best regards,
> > >> Jérôme
> > >>
> > >>
> > >>
> > >>
> > >> 2015-12-03 20:45 GMT+01:00 larry mccay <la...@gmail.com>:
> > >>
> > >> > Excellent!
> > >> >
> > >> > I will carve out some time to do code review.
> > >> > We will need to get some insights into how to go about testing:
> > >> >
> > >> > * is the CAS server going to be available for testing?
> > >> > * what are the specific and generic/standard (if any) authentication
> > >> > mechanisms available - for instance:
> > >> > - Facebook, Google, LinkedIn and CAS are specifics
> > >> > - OAuth 2, OpenID Connect, SAML are generic/standards - that may
> > be
> > >> > used for the above specifics...
> > >> > * how do we test things other than CAS - in terms of getting
> > >> credentials,
> > >> > configuration, etc
> > >> >
> > >> > We could certainly do this is phases as well.
> > >> >
> > >> > If you can enumerate the things that should work and provide some
> > >> testing
> > >> > details for CAS or as many as possible and OpenID Connect then we
> can
> > >> test
> > >> > the specific implementations that you provide and enable the testing
> > of
> > >> > another OpenID Connect effort that is in the works in the community.
> > >> >
> > >> > I'm not sure whether we want to commit contributions that are
> > dependent
> > >> on
> > >> > snapshots - we certainly can't release with any such dependencies.
> > >> > I would hate to add a cleanup task to a release to make sure there
> are
> > >> no
> > >> > snapshots in there.
> > >> > We will probably wait until after the pac4j releases to commit.
> > >> >
> > >> > I am really happy that this integration is happening and that it
> went
> > >> > rather smoothly.
> > >> > These sorts of authentication protocols are complex and I think we
> > >> lined up
> > >> > pretty well overall.
> > >> >
> > >> > Thanks for your work!
> > >> >
> > >> > On Thu, Dec 3, 2015 at 2:28 PM, Jérôme LELEU <le...@gmail.com>
> > wrote:
> > >> >
> > >> > > Hi,
> > >> > >
> > >> > > I just sync'ed with master, cleaned dependencies and added missing
> > >> > > Javadocs. Everything works correctly now. Many thanks.
> > >> > >
> > >> > > The pull request is ready for a full code review:
> > >> > > https://github.com/apache/knox/pull/2
> > >> > >
> > >> > > I'll write the documentation after the pac4j releases (I hope next
> > >> week).
> > >> > >
> > >> > > Thanks.
> > >> > > Best regards,
> > >> > > Jérôme
> > >> > >
> > >> > >
> > >> > > 2015-12-02 19:18 GMT+01:00 larry mccay <la...@gmail.com>:
> > >> > >
> > >> > > > Fixed in https://issues.apache.org/jira/browse/KNOX-636.
> > >> > > >
> > >> > > > On Wed, Dec 2, 2015 at 12:42 PM, larry mccay <
> > larry.mccay@gmail.com
> > >> >
> > >> > > > wrote:
> > >> > > >
> > >> > > > > Sure - I can file a JIRA and commit a fix.
> > >> > > > >
> > >> > > > > The secret generation should be done in one instance and
> > >> replicated
> > >> > > > across
> > >> > > > > others.
> > >> > > > > This replication/management of the credential stores is
> outside
> > of
> > >> > the
> > >> > > > > scope of Knox itself as of now.
> > >> > > > >
> > >> > > > > Documentation is done in markdown and is contributing details
> > are
> > >> > > > > available at:
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
> > >> > > > >
> > >> > > > > Which should give you a general idea.
> > >> > > > >
> > >> > > > > Find an example like: ./trunk/books/0.7.0/
> > >> > > config_preauth_sso_provider.md
> > >> > > > >
> > >> > > > > For an example of typical content and format.
> > >> > > > >
> > >> > > > > Here is how that example renders:
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
> > >> > > > >
> > >> > > > > You'll need to tie it into the rest of the book - just grep
> for
> > >> where
> > >> > > > that
> > >> > > > > filename is referenced.
> > >> > > > > To test how it renders build the site with: "ant" and note the
> > >> url to
> > >> > > the
> > >> > > > > 0.7.0 book.
> > >> > > > >
> > >> > > > >
> > >> > > > > On Wed, Dec 2, 2015 at 12:12 PM, Jérôme LELEU <
> leleuj@gmail.com
> > >
> > >> > > wrote:
> > >> > > > >
> > >> > > > >> Hi,
> > >> > > > >>
> > >> > > > >> Why it doesn't work for pac4j while it works for others is a
> > bit
> > >> > > strange
> > >> > > > >> to
> > >> > > > >> me, but if you have the patch in front of your eyes, I'd
> rather
> > >> > prefer
> > >> > > > you
> > >> > > > >> to commit it. In all cases, I'll sync with the master.
> > >> > > > >>
> > >> > > > >> There was one question you didn't answer previously: is the
> > >> password
> > >> > > > >> generated for the pac4j provider the same across all gateway
> > >> > > instances?
> > >> > > > >> Because I expect to have the same value as I use it to
> encrypt
> > /
> > >> > > decrypt
> > >> > > > >> data.
> > >> > > > >>
> > >> > > > >> I will add the Javadoc. After that, you can review the pull
> > >> request
> > >> > > more
> > >> > > > >> completely.
> > >> > > > >>
> > >> > > > >> What do you expect for the documentation?
> > >> > > > >>
> > >> > > > >> Notice that pac4j dependencies are still snapshots, but they
> > >> will be
> > >> > > > >> released in a week or two.
> > >> > > > >>
> > >> > > > >> Thanks.
> > >> > > > >> Best regards,
> > >> > > > >> Jérôme
> > >> > > > >>
> > >> > > > >>
> > >> > > > >> 2015-12-02 17:51 GMT+01:00 larry mccay <
> larry.mccay@gmail.com
> > >:
> > >> > > > >>
> > >> > > > >> > Jérôme -
> > >> > > > >> >
> > >> > > > >> > If you would like to add that change as part of your patch
> or
> > >> as a
> > >> > > > >> > separately filed JIRA to fix a bug that would certainly be
> > >> > welcomed.
> > >> > > > >> > Otherwise, I can do it.
> > >> > > > >> >
> > >> > > > >> > Let me know.
> > >> > > > >> >
> > >> > > > >> > thanks,
> > >> > > > >> >
> > >> > > > >> > --larry
> > >> > > > >> >
> > >> > > > >> > On Wed, Dec 2, 2015 at 11:44 AM, larry mccay <
> > >> > larry.mccay@gmail.com
> > >> > > >
> > >> > > > >> > wrote:
> > >> > > > >> >
> > >> > > > >> > > Okay - I had to add an override of getUserPrincipal() to
> > the
> > >> > > > >> > > IdentityAsserterHttpServletRequestWrapper and return the
> > >> member
> > >> > > > >> variable
> > >> > > > >> > > username and it works like a charm.
> > >> > > > >> > >
> > >> > > > >> > > Why I haven't seen this same behavior with other
> providers
> > >> is a
> > >> > > bit
> > >> > > > >> of a
> > >> > > > >> > > mystery but they must be adding other wrappers that
> handle
> > >> it.
> > >> > > > >> > > This is quite cool, Jérôme!
> > >> > > > >> > >
> > >> > > > >> > > On Wed, Dec 2, 2015 at 10:41 AM, larry mccay <
> > >> > > larry.mccay@gmail.com
> > >> > > > >
> > >> > > > >> > > wrote:
> > >> > > > >> > >
> > >> > > > >> > >> That was it - thanks!
> > >> > > > >> > >>
> > >> > > > >> > >> On Wed, Dec 2, 2015 at 10:20 AM, Jérôme LELEU <
> > >> > leleuj@gmail.com>
> > >> > > > >> wrote:
> > >> > > > >> > >>
> > >> > > > >> > >>> This is my exact command line: mvn -Prelease clean
> > install
> > >> > > > >> -DskipTests
> > >> > > > >> > >>>
> > >> > > > >> > >>> You use an internal Maven repository to fetch
> > dependencies
> > >> > from
> > >> > > > >> > internet:
> > >> > > > >> > >>>
> > >> > > http://nexus-private.hortonworks.com/nexus/content/groups/public/
> > >> > > > >> > >>>
> > >> > > > >> > >>> Does this repository have access to the remote
> Snapshots
> > >> > > Sonatype
> > >> > > > >> repo?
> > >> > > > >> > >>>
> > >> > > > >> > >>>
> > >> > > > >> > >>>
> > >> > > > >> > >>> 2015-12-02 16:16 GMT+01:00 larry mccay <
> > >> larry.mccay@gmail.com
> > >> > >:
> > >> > > > >> > >>>
> > >> > > > >> > >>> > hmmm - I used:
> > >> > > > >> > >>> >
> > >> > > > >> > >>> > mvn clean install -DskipTests=true -Prelease
> > >> > > > >> > >>> >
> > >> > > > >> > >>> > The repository entry is in there already.
> > >> > > > >> > >>> > No worky.
> > >> > > > >> > >>> >
> > >> > > > >> > >>> > On Wed, Dec 2, 2015 at 10:12 AM, Jérôme LELEU <
> > >> > > leleuj@gmail.com
> > >> > > > >
> > >> > > > >> > >>> wrote:
> > >> > > > >> > >>> >
> > >> > > > >> > >>> > > Hi,
> > >> > > > >> > >>> > >
> > >> > > > >> > >>> > > You need the j2e-pac4j dependencies as well as the
> > >> pac4j-*
> > >> > > > >> > >>> dependencies,
> > >> > > > >> > >>> > > but you don't need to build them locally
> (hopefully).
> > >> > > > >> > >>> > >
> > >> > > > >> > >>> > > But you need a dependency on the Sonatype snapshots
> > >> > > repository
> > >> > > > >> > >>> (where the
> > >> > > > >> > >>> > > snapshot versions are hosted), which is added for
> > >> Maven in
> > >> > > the
> > >> > > > >> root
> > >> > > > >> > >>> > > pom.xml:
> > >> > > > >> > >>> > >
> > >> > > > >> > >>> > >
> > >> > > > >> > >>> >
> > >> > > > >> > >>>
> > >> > > > >> >
> > >> > > > >>
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> > >> > > > >> > >>> > >
> > >> > > > >> > >>> > > If you use Ant for the build, there is maybe a
> glitch
> > >> to
> > >> > > find
> > >> > > > >> the
> > >> > > > >> > >>> > Sonatype
> > >> > > > >> > >>> > > Maven repo.
> > >> > > > >> > >>> > >
> > >> > > > >> > >>> > > Thanks.
> > >> > > > >> > >>> > > Best regards,
> > >> > > > >> > >>> > > Jérôme
> > >> > > > >> > >>> > >
> > >> > > > >> > >>> > >
> > >> > > > >> > >>> > > 2015-12-02 16:06 GMT+01:00 larry mccay <
> > >> > > larry.mccay@gmail.com
> > >> > > > >:
> > >> > > > >> > >>> > >
> > >> > > > >> > >>> > > > 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.mccay@gmail.com>
> > >> > > > >> > >>> > > > wrote:
> > >> > > > >> > >>> > > >
> > >> > > > >> > >>> > > > > gateway-provider-security-pac4j doesn't build -
> > do
> > >> you
> > >> > > > have
> > >> > > > >> a
> > >> > > > >> > >>> pending
> > >> > > > >> > >>> > > > > change for your pom.xml or something?
> > >> > > > >> > >>> > > > >
> > >> > > > >> > >>> >
> > >> > > > >> > >>>
> > >> > > > >> > >>
> > >> > > > >> > >>
> > >> > > > >> > >
> > >> > > > >> >
> > >> > > > >>
> > >> > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Hi,
I didn't get any new feedback on the pull request so I assume everything is
ok from your point of view.
I released pac4j v1.8.1 and j2e-pac4j v1.2.1 so I updated the pull request
to use them and successfully re-tested everything.
I opened KNOX-641 and submitted the corresponding patch.
I also wrote the documentation, opened KNOX-642 and submitted the
corresponding patch (just to let you know that it doesn't work out of the
box in Windows, I had to replace mvn.bat by mvn.cmd to make ant work).
Even if the branch 0.7.0 has already been created, I assumed this new pac4j
provider will go into this version 0.7.0 (dependency on the 0.7.0-SNAPSHOT
parent version).
Just let me know if everything is ok and when it's goind to be merged.
Thanks.
Best regards,
Jérôme
2015-12-04 14:20 GMT+01:00 larry mccay <la...@gmail.com>:
> That ability to configure multiple mechanisms based on clientName is really
> interesting for Knox.
> Currently, we require separate topologies per authentication mechanism.
> The ability to configure them all in one is really great.
>
> We would need to think through the best way to provide the clientName
> parameter.
> Since this is targeting KnoxSSO it can actually be added to the providerURL
> used to redirect from the participating application.
> Regardless of the authentication mechanism used each application will still
> get the same JWT based cookie.
>
> I think that should work really nicely.
>
>
> On Fri, Dec 4, 2015 at 7:17 AM, larry mccay <la...@gmail.com> wrote:
>
> > Excellent, Jérôme.
> > Thanks!
> >
> > On Fri, Dec 4, 2015 at 2:40 AM, Jérôme LELEU <le...@gmail.com> wrote:
> >
> >> Hi,
> >>
> >> I will write how to configure the pac4j provider in the documentation,
> but
> >> I can already give you some insights.
> >>
> >> My main goal is always to respect the key design principles of pac4j
> >> whatever the environment / framework in which it is implemented. For
> Knox,
> >> I'm pretty happy with the use of the j2e-pac4j library, which means that
> >> almost all the pac4j features are available, especially both direct and
> >> indirect clients. So it can do what Shiro already does but also, as we
> >> agreed together, supports remote authentications.
> >>
> >> It is only limited by what you can currently configure. And even
> >> configuration is a pac4j feature as the CAS server has the same need.
> >> Everything happens in this class:
> >>
> >>
> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java
> >> ,
> >> which allows you to configure Facebook, Twitter, a CAS server, a SAML
> IdP
> >> or an OpenID Connect provider. All the provided parameters to the pac4j
> >> provider are put into a Map and the ConfigPropertiesFactory is built
> with
> >> this Map to return the built client (= authentication mechanism).
> >>
> >> You have one more specific option for Knox as a basic authentication
> popup
> >> where the username must match the password, you can define that by:
> >>
> >> <param>
> >> <name>clientName</name>
> >> <value>testBasicAuth</value>
> >> </param>
> >>
> >>
> >> It's for testing only.
> >>
> >> For a CAS server:
> >>
> >> <param>
> >> <name>cas.loginUrl</name>
> >> <value>https://casserverpac4j.herokuapp.com/login</value>
> >> </param>
> >>
> >>
> >> Here are all the properties available for building clients (their
> meaning
> >> is obvious):
> >>
> >> facebook.id
> >> facebook.secret
> >> facebook.scope
> >> facebook.fields
> >> twitter.id
> >> twitter.secret
> >> saml.keystorePassword
> >> saml.privateKeyPassword
> >> saml.keystorePath
> >> saml.identityProviderMetadataPath
> >> saml.maximumAuthenticationLifetime
> >> saml.serviceProviderEntityId
> >> saml.serviceProviderMetadataPath
> >> cas.loginUrl
> >> cas.protocol
> >> oidc.id
> >> oidc.secret
> >> oidc.discoveryUri
> >> oidc.customParamKey1
> >> oidc.customParamValue1
> >>
> >>
> >> If you define multiple clients, the first one will be used for
> >> authentication, but you can explicitly choose the client you want to use
> >> via the clientName parameter, assuming you want to switch from client
> >> depending on environment for example.
> >>
> >> So if you want to add some new authentication mechanism, you must first
> >> check that it is available in pac4j (if it's not, it's another
> discussion,
> >> but generally, it is). Then, you'll need to upgrade the
> >> ConfigPropertiesFactory by submitting a new pull request to the pac4j
> >> project (I can do it myself, but I'm sure you could do that easily),
> >> finally wait for the new pac4j release and switch pac4j versions in Knox
> >> to
> >> benefit from the new feature.
> >> The good thing is that if someone related to the CAS server does the
> same
> >> thing for CAS (in pac4j), you will automatically get it when you'll
> >> upgrade
> >> pac4j.
> >>
> >> To go even further, replacing LDAP Shiro authentication is just a matter
> >> of
> >> making pac4j LDAP authentication available via configuration parameters.
> >>
> >> I hope it was clear enough.
> >>
> >> Thanks.
> >> Best regards,
> >> Jérôme
> >>
> >>
> >>
> >>
> >> 2015-12-03 20:45 GMT+01:00 larry mccay <la...@gmail.com>:
> >>
> >> > Excellent!
> >> >
> >> > I will carve out some time to do code review.
> >> > We will need to get some insights into how to go about testing:
> >> >
> >> > * is the CAS server going to be available for testing?
> >> > * what are the specific and generic/standard (if any) authentication
> >> > mechanisms available - for instance:
> >> > - Facebook, Google, LinkedIn and CAS are specifics
> >> > - OAuth 2, OpenID Connect, SAML are generic/standards - that may
> be
> >> > used for the above specifics...
> >> > * how do we test things other than CAS - in terms of getting
> >> credentials,
> >> > configuration, etc
> >> >
> >> > We could certainly do this is phases as well.
> >> >
> >> > If you can enumerate the things that should work and provide some
> >> testing
> >> > details for CAS or as many as possible and OpenID Connect then we can
> >> test
> >> > the specific implementations that you provide and enable the testing
> of
> >> > another OpenID Connect effort that is in the works in the community.
> >> >
> >> > I'm not sure whether we want to commit contributions that are
> dependent
> >> on
> >> > snapshots - we certainly can't release with any such dependencies.
> >> > I would hate to add a cleanup task to a release to make sure there are
> >> no
> >> > snapshots in there.
> >> > We will probably wait until after the pac4j releases to commit.
> >> >
> >> > I am really happy that this integration is happening and that it went
> >> > rather smoothly.
> >> > These sorts of authentication protocols are complex and I think we
> >> lined up
> >> > pretty well overall.
> >> >
> >> > Thanks for your work!
> >> >
> >> > On Thu, Dec 3, 2015 at 2:28 PM, Jérôme LELEU <le...@gmail.com>
> wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > > I just sync'ed with master, cleaned dependencies and added missing
> >> > > Javadocs. Everything works correctly now. Many thanks.
> >> > >
> >> > > The pull request is ready for a full code review:
> >> > > https://github.com/apache/knox/pull/2
> >> > >
> >> > > I'll write the documentation after the pac4j releases (I hope next
> >> week).
> >> > >
> >> > > Thanks.
> >> > > Best regards,
> >> > > Jérôme
> >> > >
> >> > >
> >> > > 2015-12-02 19:18 GMT+01:00 larry mccay <la...@gmail.com>:
> >> > >
> >> > > > Fixed in https://issues.apache.org/jira/browse/KNOX-636.
> >> > > >
> >> > > > On Wed, Dec 2, 2015 at 12:42 PM, larry mccay <
> larry.mccay@gmail.com
> >> >
> >> > > > wrote:
> >> > > >
> >> > > > > Sure - I can file a JIRA and commit a fix.
> >> > > > >
> >> > > > > The secret generation should be done in one instance and
> >> replicated
> >> > > > across
> >> > > > > others.
> >> > > > > This replication/management of the credential stores is outside
> of
> >> > the
> >> > > > > scope of Knox itself as of now.
> >> > > > >
> >> > > > > Documentation is done in markdown and is contributing details
> are
> >> > > > > available at:
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
> >> > > > >
> >> > > > > Which should give you a general idea.
> >> > > > >
> >> > > > > Find an example like: ./trunk/books/0.7.0/
> >> > > config_preauth_sso_provider.md
> >> > > > >
> >> > > > > For an example of typical content and format.
> >> > > > >
> >> > > > > Here is how that example renders:
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
> >> > > > >
> >> > > > > You'll need to tie it into the rest of the book - just grep for
> >> where
> >> > > > that
> >> > > > > filename is referenced.
> >> > > > > To test how it renders build the site with: "ant" and note the
> >> url to
> >> > > the
> >> > > > > 0.7.0 book.
> >> > > > >
> >> > > > >
> >> > > > > On Wed, Dec 2, 2015 at 12:12 PM, Jérôme LELEU <leleuj@gmail.com
> >
> >> > > wrote:
> >> > > > >
> >> > > > >> Hi,
> >> > > > >>
> >> > > > >> Why it doesn't work for pac4j while it works for others is a
> bit
> >> > > strange
> >> > > > >> to
> >> > > > >> me, but if you have the patch in front of your eyes, I'd rather
> >> > prefer
> >> > > > you
> >> > > > >> to commit it. In all cases, I'll sync with the master.
> >> > > > >>
> >> > > > >> There was one question you didn't answer previously: is the
> >> password
> >> > > > >> generated for the pac4j provider the same across all gateway
> >> > > instances?
> >> > > > >> Because I expect to have the same value as I use it to encrypt
> /
> >> > > decrypt
> >> > > > >> data.
> >> > > > >>
> >> > > > >> I will add the Javadoc. After that, you can review the pull
> >> request
> >> > > more
> >> > > > >> completely.
> >> > > > >>
> >> > > > >> What do you expect for the documentation?
> >> > > > >>
> >> > > > >> Notice that pac4j dependencies are still snapshots, but they
> >> will be
> >> > > > >> released in a week or two.
> >> > > > >>
> >> > > > >> Thanks.
> >> > > > >> Best regards,
> >> > > > >> Jérôme
> >> > > > >>
> >> > > > >>
> >> > > > >> 2015-12-02 17:51 GMT+01:00 larry mccay <larry.mccay@gmail.com
> >:
> >> > > > >>
> >> > > > >> > Jérôme -
> >> > > > >> >
> >> > > > >> > If you would like to add that change as part of your patch or
> >> as a
> >> > > > >> > separately filed JIRA to fix a bug that would certainly be
> >> > welcomed.
> >> > > > >> > Otherwise, I can do it.
> >> > > > >> >
> >> > > > >> > Let me know.
> >> > > > >> >
> >> > > > >> > thanks,
> >> > > > >> >
> >> > > > >> > --larry
> >> > > > >> >
> >> > > > >> > On Wed, Dec 2, 2015 at 11:44 AM, larry mccay <
> >> > larry.mccay@gmail.com
> >> > > >
> >> > > > >> > wrote:
> >> > > > >> >
> >> > > > >> > > Okay - I had to add an override of getUserPrincipal() to
> the
> >> > > > >> > > IdentityAsserterHttpServletRequestWrapper and return the
> >> member
> >> > > > >> variable
> >> > > > >> > > username and it works like a charm.
> >> > > > >> > >
> >> > > > >> > > Why I haven't seen this same behavior with other providers
> >> is a
> >> > > bit
> >> > > > >> of a
> >> > > > >> > > mystery but they must be adding other wrappers that handle
> >> it.
> >> > > > >> > > This is quite cool, Jérôme!
> >> > > > >> > >
> >> > > > >> > > On Wed, Dec 2, 2015 at 10:41 AM, larry mccay <
> >> > > larry.mccay@gmail.com
> >> > > > >
> >> > > > >> > > wrote:
> >> > > > >> > >
> >> > > > >> > >> That was it - thanks!
> >> > > > >> > >>
> >> > > > >> > >> On Wed, Dec 2, 2015 at 10:20 AM, Jérôme LELEU <
> >> > leleuj@gmail.com>
> >> > > > >> wrote:
> >> > > > >> > >>
> >> > > > >> > >>> This is my exact command line: mvn -Prelease clean
> install
> >> > > > >> -DskipTests
> >> > > > >> > >>>
> >> > > > >> > >>> You use an internal Maven repository to fetch
> dependencies
> >> > from
> >> > > > >> > internet:
> >> > > > >> > >>>
> >> > > http://nexus-private.hortonworks.com/nexus/content/groups/public/
> >> > > > >> > >>>
> >> > > > >> > >>> Does this repository have access to the remote Snapshots
> >> > > Sonatype
> >> > > > >> repo?
> >> > > > >> > >>>
> >> > > > >> > >>>
> >> > > > >> > >>>
> >> > > > >> > >>> 2015-12-02 16:16 GMT+01:00 larry mccay <
> >> larry.mccay@gmail.com
> >> > >:
> >> > > > >> > >>>
> >> > > > >> > >>> > hmmm - I used:
> >> > > > >> > >>> >
> >> > > > >> > >>> > mvn clean install -DskipTests=true -Prelease
> >> > > > >> > >>> >
> >> > > > >> > >>> > The repository entry is in there already.
> >> > > > >> > >>> > No worky.
> >> > > > >> > >>> >
> >> > > > >> > >>> > On Wed, Dec 2, 2015 at 10:12 AM, Jérôme LELEU <
> >> > > leleuj@gmail.com
> >> > > > >
> >> > > > >> > >>> wrote:
> >> > > > >> > >>> >
> >> > > > >> > >>> > > Hi,
> >> > > > >> > >>> > >
> >> > > > >> > >>> > > You need the j2e-pac4j dependencies as well as the
> >> pac4j-*
> >> > > > >> > >>> dependencies,
> >> > > > >> > >>> > > but you don't need to build them locally (hopefully).
> >> > > > >> > >>> > >
> >> > > > >> > >>> > > But you need a dependency on the Sonatype snapshots
> >> > > repository
> >> > > > >> > >>> (where the
> >> > > > >> > >>> > > snapshot versions are hosted), which is added for
> >> Maven in
> >> > > the
> >> > > > >> root
> >> > > > >> > >>> > > pom.xml:
> >> > > > >> > >>> > >
> >> > > > >> > >>> > >
> >> > > > >> > >>> >
> >> > > > >> > >>>
> >> > > > >> >
> >> > > > >>
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> >> > > > >> > >>> > >
> >> > > > >> > >>> > > If you use Ant for the build, there is maybe a glitch
> >> to
> >> > > find
> >> > > > >> the
> >> > > > >> > >>> > Sonatype
> >> > > > >> > >>> > > Maven repo.
> >> > > > >> > >>> > >
> >> > > > >> > >>> > > Thanks.
> >> > > > >> > >>> > > Best regards,
> >> > > > >> > >>> > > Jérôme
> >> > > > >> > >>> > >
> >> > > > >> > >>> > >
> >> > > > >> > >>> > > 2015-12-02 16:06 GMT+01:00 larry mccay <
> >> > > larry.mccay@gmail.com
> >> > > > >:
> >> > > > >> > >>> > >
> >> > > > >> > >>> > > > 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.mccay@gmail.com>
> >> > > > >> > >>> > > > wrote:
> >> > > > >> > >>> > > >
> >> > > > >> > >>> > > > > gateway-provider-security-pac4j doesn't build -
> do
> >> you
> >> > > > have
> >> > > > >> a
> >> > > > >> > >>> pending
> >> > > > >> > >>> > > > > change for your pom.xml or something?
> >> > > > >> > >>> > > > >
> >> > > > >> > >>> >
> >> > > > >> > >>>
> >> > > > >> > >>
> >> > > > >> > >>
> >> > > > >> > >
> >> > > > >> >
> >> > > > >>
> >> > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
That ability to configure multiple mechanisms based on clientName is really
interesting for Knox.
Currently, we require separate topologies per authentication mechanism.
The ability to configure them all in one is really great.
We would need to think through the best way to provide the clientName
parameter.
Since this is targeting KnoxSSO it can actually be added to the providerURL
used to redirect from the participating application.
Regardless of the authentication mechanism used each application will still
get the same JWT based cookie.
I think that should work really nicely.
On Fri, Dec 4, 2015 at 7:17 AM, larry mccay <la...@gmail.com> wrote:
> Excellent, Jérôme.
> Thanks!
>
> On Fri, Dec 4, 2015 at 2:40 AM, Jérôme LELEU <le...@gmail.com> wrote:
>
>> Hi,
>>
>> I will write how to configure the pac4j provider in the documentation, but
>> I can already give you some insights.
>>
>> My main goal is always to respect the key design principles of pac4j
>> whatever the environment / framework in which it is implemented. For Knox,
>> I'm pretty happy with the use of the j2e-pac4j library, which means that
>> almost all the pac4j features are available, especially both direct and
>> indirect clients. So it can do what Shiro already does but also, as we
>> agreed together, supports remote authentications.
>>
>> It is only limited by what you can currently configure. And even
>> configuration is a pac4j feature as the CAS server has the same need.
>> Everything happens in this class:
>>
>> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java
>> ,
>> which allows you to configure Facebook, Twitter, a CAS server, a SAML IdP
>> or an OpenID Connect provider. All the provided parameters to the pac4j
>> provider are put into a Map and the ConfigPropertiesFactory is built with
>> this Map to return the built client (= authentication mechanism).
>>
>> You have one more specific option for Knox as a basic authentication popup
>> where the username must match the password, you can define that by:
>>
>> <param>
>> <name>clientName</name>
>> <value>testBasicAuth</value>
>> </param>
>>
>>
>> It's for testing only.
>>
>> For a CAS server:
>>
>> <param>
>> <name>cas.loginUrl</name>
>> <value>https://casserverpac4j.herokuapp.com/login</value>
>> </param>
>>
>>
>> Here are all the properties available for building clients (their meaning
>> is obvious):
>>
>> facebook.id
>> facebook.secret
>> facebook.scope
>> facebook.fields
>> twitter.id
>> twitter.secret
>> saml.keystorePassword
>> saml.privateKeyPassword
>> saml.keystorePath
>> saml.identityProviderMetadataPath
>> saml.maximumAuthenticationLifetime
>> saml.serviceProviderEntityId
>> saml.serviceProviderMetadataPath
>> cas.loginUrl
>> cas.protocol
>> oidc.id
>> oidc.secret
>> oidc.discoveryUri
>> oidc.customParamKey1
>> oidc.customParamValue1
>>
>>
>> If you define multiple clients, the first one will be used for
>> authentication, but you can explicitly choose the client you want to use
>> via the clientName parameter, assuming you want to switch from client
>> depending on environment for example.
>>
>> So if you want to add some new authentication mechanism, you must first
>> check that it is available in pac4j (if it's not, it's another discussion,
>> but generally, it is). Then, you'll need to upgrade the
>> ConfigPropertiesFactory by submitting a new pull request to the pac4j
>> project (I can do it myself, but I'm sure you could do that easily),
>> finally wait for the new pac4j release and switch pac4j versions in Knox
>> to
>> benefit from the new feature.
>> The good thing is that if someone related to the CAS server does the same
>> thing for CAS (in pac4j), you will automatically get it when you'll
>> upgrade
>> pac4j.
>>
>> To go even further, replacing LDAP Shiro authentication is just a matter
>> of
>> making pac4j LDAP authentication available via configuration parameters.
>>
>> I hope it was clear enough.
>>
>> Thanks.
>> Best regards,
>> Jérôme
>>
>>
>>
>>
>> 2015-12-03 20:45 GMT+01:00 larry mccay <la...@gmail.com>:
>>
>> > Excellent!
>> >
>> > I will carve out some time to do code review.
>> > We will need to get some insights into how to go about testing:
>> >
>> > * is the CAS server going to be available for testing?
>> > * what are the specific and generic/standard (if any) authentication
>> > mechanisms available - for instance:
>> > - Facebook, Google, LinkedIn and CAS are specifics
>> > - OAuth 2, OpenID Connect, SAML are generic/standards - that may be
>> > used for the above specifics...
>> > * how do we test things other than CAS - in terms of getting
>> credentials,
>> > configuration, etc
>> >
>> > We could certainly do this is phases as well.
>> >
>> > If you can enumerate the things that should work and provide some
>> testing
>> > details for CAS or as many as possible and OpenID Connect then we can
>> test
>> > the specific implementations that you provide and enable the testing of
>> > another OpenID Connect effort that is in the works in the community.
>> >
>> > I'm not sure whether we want to commit contributions that are dependent
>> on
>> > snapshots - we certainly can't release with any such dependencies.
>> > I would hate to add a cleanup task to a release to make sure there are
>> no
>> > snapshots in there.
>> > We will probably wait until after the pac4j releases to commit.
>> >
>> > I am really happy that this integration is happening and that it went
>> > rather smoothly.
>> > These sorts of authentication protocols are complex and I think we
>> lined up
>> > pretty well overall.
>> >
>> > Thanks for your work!
>> >
>> > On Thu, Dec 3, 2015 at 2:28 PM, Jérôme LELEU <le...@gmail.com> wrote:
>> >
>> > > Hi,
>> > >
>> > > I just sync'ed with master, cleaned dependencies and added missing
>> > > Javadocs. Everything works correctly now. Many thanks.
>> > >
>> > > The pull request is ready for a full code review:
>> > > https://github.com/apache/knox/pull/2
>> > >
>> > > I'll write the documentation after the pac4j releases (I hope next
>> week).
>> > >
>> > > Thanks.
>> > > Best regards,
>> > > Jérôme
>> > >
>> > >
>> > > 2015-12-02 19:18 GMT+01:00 larry mccay <la...@gmail.com>:
>> > >
>> > > > Fixed in https://issues.apache.org/jira/browse/KNOX-636.
>> > > >
>> > > > On Wed, Dec 2, 2015 at 12:42 PM, larry mccay <larry.mccay@gmail.com
>> >
>> > > > wrote:
>> > > >
>> > > > > Sure - I can file a JIRA and commit a fix.
>> > > > >
>> > > > > The secret generation should be done in one instance and
>> replicated
>> > > > across
>> > > > > others.
>> > > > > This replication/management of the credential stores is outside of
>> > the
>> > > > > scope of Knox itself as of now.
>> > > > >
>> > > > > Documentation is done in markdown and is contributing details are
>> > > > > available at:
>> > > > >
>> > > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
>> > > > >
>> > > > > Which should give you a general idea.
>> > > > >
>> > > > > Find an example like: ./trunk/books/0.7.0/
>> > > config_preauth_sso_provider.md
>> > > > >
>> > > > > For an example of typical content and format.
>> > > > >
>> > > > > Here is how that example renders:
>> > > > >
>> > > >
>> > >
>> >
>> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
>> > > > >
>> > > > > You'll need to tie it into the rest of the book - just grep for
>> where
>> > > > that
>> > > > > filename is referenced.
>> > > > > To test how it renders build the site with: "ant" and note the
>> url to
>> > > the
>> > > > > 0.7.0 book.
>> > > > >
>> > > > >
>> > > > > On Wed, Dec 2, 2015 at 12:12 PM, Jérôme LELEU <le...@gmail.com>
>> > > wrote:
>> > > > >
>> > > > >> Hi,
>> > > > >>
>> > > > >> Why it doesn't work for pac4j while it works for others is a bit
>> > > strange
>> > > > >> to
>> > > > >> me, but if you have the patch in front of your eyes, I'd rather
>> > prefer
>> > > > you
>> > > > >> to commit it. In all cases, I'll sync with the master.
>> > > > >>
>> > > > >> There was one question you didn't answer previously: is the
>> password
>> > > > >> generated for the pac4j provider the same across all gateway
>> > > instances?
>> > > > >> Because I expect to have the same value as I use it to encrypt /
>> > > decrypt
>> > > > >> data.
>> > > > >>
>> > > > >> I will add the Javadoc. After that, you can review the pull
>> request
>> > > more
>> > > > >> completely.
>> > > > >>
>> > > > >> What do you expect for the documentation?
>> > > > >>
>> > > > >> Notice that pac4j dependencies are still snapshots, but they
>> will be
>> > > > >> released in a week or two.
>> > > > >>
>> > > > >> Thanks.
>> > > > >> Best regards,
>> > > > >> Jérôme
>> > > > >>
>> > > > >>
>> > > > >> 2015-12-02 17:51 GMT+01:00 larry mccay <la...@gmail.com>:
>> > > > >>
>> > > > >> > Jérôme -
>> > > > >> >
>> > > > >> > If you would like to add that change as part of your patch or
>> as a
>> > > > >> > separately filed JIRA to fix a bug that would certainly be
>> > welcomed.
>> > > > >> > Otherwise, I can do it.
>> > > > >> >
>> > > > >> > Let me know.
>> > > > >> >
>> > > > >> > thanks,
>> > > > >> >
>> > > > >> > --larry
>> > > > >> >
>> > > > >> > On Wed, Dec 2, 2015 at 11:44 AM, larry mccay <
>> > larry.mccay@gmail.com
>> > > >
>> > > > >> > wrote:
>> > > > >> >
>> > > > >> > > Okay - I had to add an override of getUserPrincipal() to the
>> > > > >> > > IdentityAsserterHttpServletRequestWrapper and return the
>> member
>> > > > >> variable
>> > > > >> > > username and it works like a charm.
>> > > > >> > >
>> > > > >> > > Why I haven't seen this same behavior with other providers
>> is a
>> > > bit
>> > > > >> of a
>> > > > >> > > mystery but they must be adding other wrappers that handle
>> it.
>> > > > >> > > This is quite cool, Jérôme!
>> > > > >> > >
>> > > > >> > > On Wed, Dec 2, 2015 at 10:41 AM, larry mccay <
>> > > larry.mccay@gmail.com
>> > > > >
>> > > > >> > > wrote:
>> > > > >> > >
>> > > > >> > >> That was it - thanks!
>> > > > >> > >>
>> > > > >> > >> On Wed, Dec 2, 2015 at 10:20 AM, Jérôme LELEU <
>> > leleuj@gmail.com>
>> > > > >> wrote:
>> > > > >> > >>
>> > > > >> > >>> This is my exact command line: mvn -Prelease clean install
>> > > > >> -DskipTests
>> > > > >> > >>>
>> > > > >> > >>> You use an internal Maven repository to fetch dependencies
>> > from
>> > > > >> > internet:
>> > > > >> > >>>
>> > > http://nexus-private.hortonworks.com/nexus/content/groups/public/
>> > > > >> > >>>
>> > > > >> > >>> Does this repository have access to the remote Snapshots
>> > > Sonatype
>> > > > >> repo?
>> > > > >> > >>>
>> > > > >> > >>>
>> > > > >> > >>>
>> > > > >> > >>> 2015-12-02 16:16 GMT+01:00 larry mccay <
>> larry.mccay@gmail.com
>> > >:
>> > > > >> > >>>
>> > > > >> > >>> > hmmm - I used:
>> > > > >> > >>> >
>> > > > >> > >>> > mvn clean install -DskipTests=true -Prelease
>> > > > >> > >>> >
>> > > > >> > >>> > The repository entry is in there already.
>> > > > >> > >>> > No worky.
>> > > > >> > >>> >
>> > > > >> > >>> > On Wed, Dec 2, 2015 at 10:12 AM, Jérôme LELEU <
>> > > leleuj@gmail.com
>> > > > >
>> > > > >> > >>> wrote:
>> > > > >> > >>> >
>> > > > >> > >>> > > Hi,
>> > > > >> > >>> > >
>> > > > >> > >>> > > You need the j2e-pac4j dependencies as well as the
>> pac4j-*
>> > > > >> > >>> dependencies,
>> > > > >> > >>> > > but you don't need to build them locally (hopefully).
>> > > > >> > >>> > >
>> > > > >> > >>> > > But you need a dependency on the Sonatype snapshots
>> > > repository
>> > > > >> > >>> (where the
>> > > > >> > >>> > > snapshot versions are hosted), which is added for
>> Maven in
>> > > the
>> > > > >> root
>> > > > >> > >>> > > pom.xml:
>> > > > >> > >>> > >
>> > > > >> > >>> > >
>> > > > >> > >>> >
>> > > > >> > >>>
>> > > > >> >
>> > > > >>
>> > > >
>> > >
>> >
>> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
>> > > > >> > >>> > >
>> > > > >> > >>> > > If you use Ant for the build, there is maybe a glitch
>> to
>> > > find
>> > > > >> the
>> > > > >> > >>> > Sonatype
>> > > > >> > >>> > > Maven repo.
>> > > > >> > >>> > >
>> > > > >> > >>> > > Thanks.
>> > > > >> > >>> > > Best regards,
>> > > > >> > >>> > > Jérôme
>> > > > >> > >>> > >
>> > > > >> > >>> > >
>> > > > >> > >>> > > 2015-12-02 16:06 GMT+01:00 larry mccay <
>> > > larry.mccay@gmail.com
>> > > > >:
>> > > > >> > >>> > >
>> > > > >> > >>> > > > 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.mccay@gmail.com>
>> > > > >> > >>> > > > wrote:
>> > > > >> > >>> > > >
>> > > > >> > >>> > > > > gateway-provider-security-pac4j doesn't build - do
>> you
>> > > > have
>> > > > >> a
>> > > > >> > >>> pending
>> > > > >> > >>> > > > > change for your pom.xml or something?
>> > > > >> > >>> > > > >
>> > > > >> > >>> >
>> > > > >> > >>>
>> > > > >> > >>
>> > > > >> > >>
>> > > > >> > >
>> > > > >> >
>> > > > >>
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
Excellent, Jérôme.
Thanks!
On Fri, Dec 4, 2015 at 2:40 AM, Jérôme LELEU <le...@gmail.com> wrote:
> Hi,
>
> I will write how to configure the pac4j provider in the documentation, but
> I can already give you some insights.
>
> My main goal is always to respect the key design principles of pac4j
> whatever the environment / framework in which it is implemented. For Knox,
> I'm pretty happy with the use of the j2e-pac4j library, which means that
> almost all the pac4j features are available, especially both direct and
> indirect clients. So it can do what Shiro already does but also, as we
> agreed together, supports remote authentications.
>
> It is only limited by what you can currently configure. And even
> configuration is a pac4j feature as the CAS server has the same need.
> Everything happens in this class:
>
> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java
> ,
> which allows you to configure Facebook, Twitter, a CAS server, a SAML IdP
> or an OpenID Connect provider. All the provided parameters to the pac4j
> provider are put into a Map and the ConfigPropertiesFactory is built with
> this Map to return the built client (= authentication mechanism).
>
> You have one more specific option for Knox as a basic authentication popup
> where the username must match the password, you can define that by:
>
> <param>
> <name>clientName</name>
> <value>testBasicAuth</value>
> </param>
>
>
> It's for testing only.
>
> For a CAS server:
>
> <param>
> <name>cas.loginUrl</name>
> <value>https://casserverpac4j.herokuapp.com/login</value>
> </param>
>
>
> Here are all the properties available for building clients (their meaning
> is obvious):
>
> facebook.id
> facebook.secret
> facebook.scope
> facebook.fields
> twitter.id
> twitter.secret
> saml.keystorePassword
> saml.privateKeyPassword
> saml.keystorePath
> saml.identityProviderMetadataPath
> saml.maximumAuthenticationLifetime
> saml.serviceProviderEntityId
> saml.serviceProviderMetadataPath
> cas.loginUrl
> cas.protocol
> oidc.id
> oidc.secret
> oidc.discoveryUri
> oidc.customParamKey1
> oidc.customParamValue1
>
>
> If you define multiple clients, the first one will be used for
> authentication, but you can explicitly choose the client you want to use
> via the clientName parameter, assuming you want to switch from client
> depending on environment for example.
>
> So if you want to add some new authentication mechanism, you must first
> check that it is available in pac4j (if it's not, it's another discussion,
> but generally, it is). Then, you'll need to upgrade the
> ConfigPropertiesFactory by submitting a new pull request to the pac4j
> project (I can do it myself, but I'm sure you could do that easily),
> finally wait for the new pac4j release and switch pac4j versions in Knox to
> benefit from the new feature.
> The good thing is that if someone related to the CAS server does the same
> thing for CAS (in pac4j), you will automatically get it when you'll upgrade
> pac4j.
>
> To go even further, replacing LDAP Shiro authentication is just a matter of
> making pac4j LDAP authentication available via configuration parameters.
>
> I hope it was clear enough.
>
> Thanks.
> Best regards,
> Jérôme
>
>
>
>
> 2015-12-03 20:45 GMT+01:00 larry mccay <la...@gmail.com>:
>
> > Excellent!
> >
> > I will carve out some time to do code review.
> > We will need to get some insights into how to go about testing:
> >
> > * is the CAS server going to be available for testing?
> > * what are the specific and generic/standard (if any) authentication
> > mechanisms available - for instance:
> > - Facebook, Google, LinkedIn and CAS are specifics
> > - OAuth 2, OpenID Connect, SAML are generic/standards - that may be
> > used for the above specifics...
> > * how do we test things other than CAS - in terms of getting credentials,
> > configuration, etc
> >
> > We could certainly do this is phases as well.
> >
> > If you can enumerate the things that should work and provide some testing
> > details for CAS or as many as possible and OpenID Connect then we can
> test
> > the specific implementations that you provide and enable the testing of
> > another OpenID Connect effort that is in the works in the community.
> >
> > I'm not sure whether we want to commit contributions that are dependent
> on
> > snapshots - we certainly can't release with any such dependencies.
> > I would hate to add a cleanup task to a release to make sure there are no
> > snapshots in there.
> > We will probably wait until after the pac4j releases to commit.
> >
> > I am really happy that this integration is happening and that it went
> > rather smoothly.
> > These sorts of authentication protocols are complex and I think we lined
> up
> > pretty well overall.
> >
> > Thanks for your work!
> >
> > On Thu, Dec 3, 2015 at 2:28 PM, Jérôme LELEU <le...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > I just sync'ed with master, cleaned dependencies and added missing
> > > Javadocs. Everything works correctly now. Many thanks.
> > >
> > > The pull request is ready for a full code review:
> > > https://github.com/apache/knox/pull/2
> > >
> > > I'll write the documentation after the pac4j releases (I hope next
> week).
> > >
> > > Thanks.
> > > Best regards,
> > > Jérôme
> > >
> > >
> > > 2015-12-02 19:18 GMT+01:00 larry mccay <la...@gmail.com>:
> > >
> > > > Fixed in https://issues.apache.org/jira/browse/KNOX-636.
> > > >
> > > > On Wed, Dec 2, 2015 at 12:42 PM, larry mccay <la...@gmail.com>
> > > > wrote:
> > > >
> > > > > Sure - I can file a JIRA and commit a fix.
> > > > >
> > > > > The secret generation should be done in one instance and replicated
> > > > across
> > > > > others.
> > > > > This replication/management of the credential stores is outside of
> > the
> > > > > scope of Knox itself as of now.
> > > > >
> > > > > Documentation is done in markdown and is contributing details are
> > > > > available at:
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
> > > > >
> > > > > Which should give you a general idea.
> > > > >
> > > > > Find an example like: ./trunk/books/0.7.0/
> > > config_preauth_sso_provider.md
> > > > >
> > > > > For an example of typical content and format.
> > > > >
> > > > > Here is how that example renders:
> > > > >
> > > >
> > >
> >
> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
> > > > >
> > > > > You'll need to tie it into the rest of the book - just grep for
> where
> > > > that
> > > > > filename is referenced.
> > > > > To test how it renders build the site with: "ant" and note the url
> to
> > > the
> > > > > 0.7.0 book.
> > > > >
> > > > >
> > > > > On Wed, Dec 2, 2015 at 12:12 PM, Jérôme LELEU <le...@gmail.com>
> > > wrote:
> > > > >
> > > > >> Hi,
> > > > >>
> > > > >> Why it doesn't work for pac4j while it works for others is a bit
> > > strange
> > > > >> to
> > > > >> me, but if you have the patch in front of your eyes, I'd rather
> > prefer
> > > > you
> > > > >> to commit it. In all cases, I'll sync with the master.
> > > > >>
> > > > >> There was one question you didn't answer previously: is the
> password
> > > > >> generated for the pac4j provider the same across all gateway
> > > instances?
> > > > >> Because I expect to have the same value as I use it to encrypt /
> > > decrypt
> > > > >> data.
> > > > >>
> > > > >> I will add the Javadoc. After that, you can review the pull
> request
> > > more
> > > > >> completely.
> > > > >>
> > > > >> What do you expect for the documentation?
> > > > >>
> > > > >> Notice that pac4j dependencies are still snapshots, but they will
> be
> > > > >> released in a week or two.
> > > > >>
> > > > >> Thanks.
> > > > >> Best regards,
> > > > >> Jérôme
> > > > >>
> > > > >>
> > > > >> 2015-12-02 17:51 GMT+01:00 larry mccay <la...@gmail.com>:
> > > > >>
> > > > >> > Jérôme -
> > > > >> >
> > > > >> > If you would like to add that change as part of your patch or
> as a
> > > > >> > separately filed JIRA to fix a bug that would certainly be
> > welcomed.
> > > > >> > Otherwise, I can do it.
> > > > >> >
> > > > >> > Let me know.
> > > > >> >
> > > > >> > thanks,
> > > > >> >
> > > > >> > --larry
> > > > >> >
> > > > >> > On Wed, Dec 2, 2015 at 11:44 AM, larry mccay <
> > larry.mccay@gmail.com
> > > >
> > > > >> > wrote:
> > > > >> >
> > > > >> > > Okay - I had to add an override of getUserPrincipal() to the
> > > > >> > > IdentityAsserterHttpServletRequestWrapper and return the
> member
> > > > >> variable
> > > > >> > > username and it works like a charm.
> > > > >> > >
> > > > >> > > Why I haven't seen this same behavior with other providers is
> a
> > > bit
> > > > >> of a
> > > > >> > > mystery but they must be adding other wrappers that handle it.
> > > > >> > > This is quite cool, Jérôme!
> > > > >> > >
> > > > >> > > On Wed, Dec 2, 2015 at 10:41 AM, larry mccay <
> > > larry.mccay@gmail.com
> > > > >
> > > > >> > > wrote:
> > > > >> > >
> > > > >> > >> That was it - thanks!
> > > > >> > >>
> > > > >> > >> On Wed, Dec 2, 2015 at 10:20 AM, Jérôme LELEU <
> > leleuj@gmail.com>
> > > > >> wrote:
> > > > >> > >>
> > > > >> > >>> This is my exact command line: mvn -Prelease clean install
> > > > >> -DskipTests
> > > > >> > >>>
> > > > >> > >>> You use an internal Maven repository to fetch dependencies
> > from
> > > > >> > internet:
> > > > >> > >>>
> > > http://nexus-private.hortonworks.com/nexus/content/groups/public/
> > > > >> > >>>
> > > > >> > >>> Does this repository have access to the remote Snapshots
> > > Sonatype
> > > > >> repo?
> > > > >> > >>>
> > > > >> > >>>
> > > > >> > >>>
> > > > >> > >>> 2015-12-02 16:16 GMT+01:00 larry mccay <
> larry.mccay@gmail.com
> > >:
> > > > >> > >>>
> > > > >> > >>> > hmmm - I used:
> > > > >> > >>> >
> > > > >> > >>> > mvn clean install -DskipTests=true -Prelease
> > > > >> > >>> >
> > > > >> > >>> > The repository entry is in there already.
> > > > >> > >>> > No worky.
> > > > >> > >>> >
> > > > >> > >>> > On Wed, Dec 2, 2015 at 10:12 AM, Jérôme LELEU <
> > > leleuj@gmail.com
> > > > >
> > > > >> > >>> wrote:
> > > > >> > >>> >
> > > > >> > >>> > > Hi,
> > > > >> > >>> > >
> > > > >> > >>> > > You need the j2e-pac4j dependencies as well as the
> pac4j-*
> > > > >> > >>> dependencies,
> > > > >> > >>> > > but you don't need to build them locally (hopefully).
> > > > >> > >>> > >
> > > > >> > >>> > > But you need a dependency on the Sonatype snapshots
> > > repository
> > > > >> > >>> (where the
> > > > >> > >>> > > snapshot versions are hosted), which is added for Maven
> in
> > > the
> > > > >> root
> > > > >> > >>> > > pom.xml:
> > > > >> > >>> > >
> > > > >> > >>> > >
> > > > >> > >>> >
> > > > >> > >>>
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> > > > >> > >>> > >
> > > > >> > >>> > > If you use Ant for the build, there is maybe a glitch to
> > > find
> > > > >> the
> > > > >> > >>> > Sonatype
> > > > >> > >>> > > Maven repo.
> > > > >> > >>> > >
> > > > >> > >>> > > Thanks.
> > > > >> > >>> > > Best regards,
> > > > >> > >>> > > Jérôme
> > > > >> > >>> > >
> > > > >> > >>> > >
> > > > >> > >>> > > 2015-12-02 16:06 GMT+01:00 larry mccay <
> > > larry.mccay@gmail.com
> > > > >:
> > > > >> > >>> > >
> > > > >> > >>> > > > 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.mccay@gmail.com>
> > > > >> > >>> > > > wrote:
> > > > >> > >>> > > >
> > > > >> > >>> > > > > gateway-provider-security-pac4j doesn't build - do
> you
> > > > have
> > > > >> a
> > > > >> > >>> pending
> > > > >> > >>> > > > > change for your pom.xml or something?
> > > > >> > >>> > > > >
> > > > >> > >>> >
> > > > >> > >>>
> > > > >> > >>
> > > > >> > >>
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Hi,
I will write how to configure the pac4j provider in the documentation, but
I can already give you some insights.
My main goal is always to respect the key design principles of pac4j
whatever the environment / framework in which it is implemented. For Knox,
I'm pretty happy with the use of the j2e-pac4j library, which means that
almost all the pac4j features are available, especially both direct and
indirect clients. So it can do what Shiro already does but also, as we
agreed together, supports remote authentications.
It is only limited by what you can currently configure. And even
configuration is a pac4j feature as the CAS server has the same need.
Everything happens in this class:
https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java,
which allows you to configure Facebook, Twitter, a CAS server, a SAML IdP
or an OpenID Connect provider. All the provided parameters to the pac4j
provider are put into a Map and the ConfigPropertiesFactory is built with
this Map to return the built client (= authentication mechanism).
You have one more specific option for Knox as a basic authentication popup
where the username must match the password, you can define that by:
<param>
<name>clientName</name>
<value>testBasicAuth</value>
</param>
It's for testing only.
For a CAS server:
<param>
<name>cas.loginUrl</name>
<value>https://casserverpac4j.herokuapp.com/login</value>
</param>
Here are all the properties available for building clients (their meaning
is obvious):
facebook.id
facebook.secret
facebook.scope
facebook.fields
twitter.id
twitter.secret
saml.keystorePassword
saml.privateKeyPassword
saml.keystorePath
saml.identityProviderMetadataPath
saml.maximumAuthenticationLifetime
saml.serviceProviderEntityId
saml.serviceProviderMetadataPath
cas.loginUrl
cas.protocol
oidc.id
oidc.secret
oidc.discoveryUri
oidc.customParamKey1
oidc.customParamValue1
If you define multiple clients, the first one will be used for
authentication, but you can explicitly choose the client you want to use
via the clientName parameter, assuming you want to switch from client
depending on environment for example.
So if you want to add some new authentication mechanism, you must first
check that it is available in pac4j (if it's not, it's another discussion,
but generally, it is). Then, you'll need to upgrade the
ConfigPropertiesFactory by submitting a new pull request to the pac4j
project (I can do it myself, but I'm sure you could do that easily),
finally wait for the new pac4j release and switch pac4j versions in Knox to
benefit from the new feature.
The good thing is that if someone related to the CAS server does the same
thing for CAS (in pac4j), you will automatically get it when you'll upgrade
pac4j.
To go even further, replacing LDAP Shiro authentication is just a matter of
making pac4j LDAP authentication available via configuration parameters.
I hope it was clear enough.
Thanks.
Best regards,
Jérôme
2015-12-03 20:45 GMT+01:00 larry mccay <la...@gmail.com>:
> Excellent!
>
> I will carve out some time to do code review.
> We will need to get some insights into how to go about testing:
>
> * is the CAS server going to be available for testing?
> * what are the specific and generic/standard (if any) authentication
> mechanisms available - for instance:
> - Facebook, Google, LinkedIn and CAS are specifics
> - OAuth 2, OpenID Connect, SAML are generic/standards - that may be
> used for the above specifics...
> * how do we test things other than CAS - in terms of getting credentials,
> configuration, etc
>
> We could certainly do this is phases as well.
>
> If you can enumerate the things that should work and provide some testing
> details for CAS or as many as possible and OpenID Connect then we can test
> the specific implementations that you provide and enable the testing of
> another OpenID Connect effort that is in the works in the community.
>
> I'm not sure whether we want to commit contributions that are dependent on
> snapshots - we certainly can't release with any such dependencies.
> I would hate to add a cleanup task to a release to make sure there are no
> snapshots in there.
> We will probably wait until after the pac4j releases to commit.
>
> I am really happy that this integration is happening and that it went
> rather smoothly.
> These sorts of authentication protocols are complex and I think we lined up
> pretty well overall.
>
> Thanks for your work!
>
> On Thu, Dec 3, 2015 at 2:28 PM, Jérôme LELEU <le...@gmail.com> wrote:
>
> > Hi,
> >
> > I just sync'ed with master, cleaned dependencies and added missing
> > Javadocs. Everything works correctly now. Many thanks.
> >
> > The pull request is ready for a full code review:
> > https://github.com/apache/knox/pull/2
> >
> > I'll write the documentation after the pac4j releases (I hope next week).
> >
> > Thanks.
> > Best regards,
> > Jérôme
> >
> >
> > 2015-12-02 19:18 GMT+01:00 larry mccay <la...@gmail.com>:
> >
> > > Fixed in https://issues.apache.org/jira/browse/KNOX-636.
> > >
> > > On Wed, Dec 2, 2015 at 12:42 PM, larry mccay <la...@gmail.com>
> > > wrote:
> > >
> > > > Sure - I can file a JIRA and commit a fix.
> > > >
> > > > The secret generation should be done in one instance and replicated
> > > across
> > > > others.
> > > > This replication/management of the credential stores is outside of
> the
> > > > scope of Knox itself as of now.
> > > >
> > > > Documentation is done in markdown and is contributing details are
> > > > available at:
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
> > > >
> > > > Which should give you a general idea.
> > > >
> > > > Find an example like: ./trunk/books/0.7.0/
> > config_preauth_sso_provider.md
> > > >
> > > > For an example of typical content and format.
> > > >
> > > > Here is how that example renders:
> > > >
> > >
> >
> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
> > > >
> > > > You'll need to tie it into the rest of the book - just grep for where
> > > that
> > > > filename is referenced.
> > > > To test how it renders build the site with: "ant" and note the url to
> > the
> > > > 0.7.0 book.
> > > >
> > > >
> > > > On Wed, Dec 2, 2015 at 12:12 PM, Jérôme LELEU <le...@gmail.com>
> > wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> Why it doesn't work for pac4j while it works for others is a bit
> > strange
> > > >> to
> > > >> me, but if you have the patch in front of your eyes, I'd rather
> prefer
> > > you
> > > >> to commit it. In all cases, I'll sync with the master.
> > > >>
> > > >> There was one question you didn't answer previously: is the password
> > > >> generated for the pac4j provider the same across all gateway
> > instances?
> > > >> Because I expect to have the same value as I use it to encrypt /
> > decrypt
> > > >> data.
> > > >>
> > > >> I will add the Javadoc. After that, you can review the pull request
> > more
> > > >> completely.
> > > >>
> > > >> What do you expect for the documentation?
> > > >>
> > > >> Notice that pac4j dependencies are still snapshots, but they will be
> > > >> released in a week or two.
> > > >>
> > > >> Thanks.
> > > >> Best regards,
> > > >> Jérôme
> > > >>
> > > >>
> > > >> 2015-12-02 17:51 GMT+01:00 larry mccay <la...@gmail.com>:
> > > >>
> > > >> > Jérôme -
> > > >> >
> > > >> > If you would like to add that change as part of your patch or as a
> > > >> > separately filed JIRA to fix a bug that would certainly be
> welcomed.
> > > >> > Otherwise, I can do it.
> > > >> >
> > > >> > Let me know.
> > > >> >
> > > >> > thanks,
> > > >> >
> > > >> > --larry
> > > >> >
> > > >> > On Wed, Dec 2, 2015 at 11:44 AM, larry mccay <
> larry.mccay@gmail.com
> > >
> > > >> > wrote:
> > > >> >
> > > >> > > Okay - I had to add an override of getUserPrincipal() to the
> > > >> > > IdentityAsserterHttpServletRequestWrapper and return the member
> > > >> variable
> > > >> > > username and it works like a charm.
> > > >> > >
> > > >> > > Why I haven't seen this same behavior with other providers is a
> > bit
> > > >> of a
> > > >> > > mystery but they must be adding other wrappers that handle it.
> > > >> > > This is quite cool, Jérôme!
> > > >> > >
> > > >> > > On Wed, Dec 2, 2015 at 10:41 AM, larry mccay <
> > larry.mccay@gmail.com
> > > >
> > > >> > > wrote:
> > > >> > >
> > > >> > >> That was it - thanks!
> > > >> > >>
> > > >> > >> On Wed, Dec 2, 2015 at 10:20 AM, Jérôme LELEU <
> leleuj@gmail.com>
> > > >> wrote:
> > > >> > >>
> > > >> > >>> This is my exact command line: mvn -Prelease clean install
> > > >> -DskipTests
> > > >> > >>>
> > > >> > >>> You use an internal Maven repository to fetch dependencies
> from
> > > >> > internet:
> > > >> > >>>
> > http://nexus-private.hortonworks.com/nexus/content/groups/public/
> > > >> > >>>
> > > >> > >>> Does this repository have access to the remote Snapshots
> > Sonatype
> > > >> repo?
> > > >> > >>>
> > > >> > >>>
> > > >> > >>>
> > > >> > >>> 2015-12-02 16:16 GMT+01:00 larry mccay <larry.mccay@gmail.com
> >:
> > > >> > >>>
> > > >> > >>> > hmmm - I used:
> > > >> > >>> >
> > > >> > >>> > mvn clean install -DskipTests=true -Prelease
> > > >> > >>> >
> > > >> > >>> > The repository entry is in there already.
> > > >> > >>> > No worky.
> > > >> > >>> >
> > > >> > >>> > On Wed, Dec 2, 2015 at 10:12 AM, Jérôme LELEU <
> > leleuj@gmail.com
> > > >
> > > >> > >>> wrote:
> > > >> > >>> >
> > > >> > >>> > > Hi,
> > > >> > >>> > >
> > > >> > >>> > > You need the j2e-pac4j dependencies as well as the pac4j-*
> > > >> > >>> dependencies,
> > > >> > >>> > > but you don't need to build them locally (hopefully).
> > > >> > >>> > >
> > > >> > >>> > > But you need a dependency on the Sonatype snapshots
> > repository
> > > >> > >>> (where the
> > > >> > >>> > > snapshot versions are hosted), which is added for Maven in
> > the
> > > >> root
> > > >> > >>> > > pom.xml:
> > > >> > >>> > >
> > > >> > >>> > >
> > > >> > >>> >
> > > >> > >>>
> > > >> >
> > > >>
> > >
> >
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> > > >> > >>> > >
> > > >> > >>> > > If you use Ant for the build, there is maybe a glitch to
> > find
> > > >> the
> > > >> > >>> > Sonatype
> > > >> > >>> > > Maven repo.
> > > >> > >>> > >
> > > >> > >>> > > Thanks.
> > > >> > >>> > > Best regards,
> > > >> > >>> > > Jérôme
> > > >> > >>> > >
> > > >> > >>> > >
> > > >> > >>> > > 2015-12-02 16:06 GMT+01:00 larry mccay <
> > larry.mccay@gmail.com
> > > >:
> > > >> > >>> > >
> > > >> > >>> > > > 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.mccay@gmail.com>
> > > >> > >>> > > > wrote:
> > > >> > >>> > > >
> > > >> > >>> > > > > gateway-provider-security-pac4j doesn't build - do you
> > > have
> > > >> a
> > > >> > >>> pending
> > > >> > >>> > > > > change for your pom.xml or something?
> > > >> > >>> > > > >
> > > >> > >>> >
> > > >> > >>>
> > > >> > >>
> > > >> > >>
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
Excellent!
I will carve out some time to do code review.
We will need to get some insights into how to go about testing:
* is the CAS server going to be available for testing?
* what are the specific and generic/standard (if any) authentication
mechanisms available - for instance:
- Facebook, Google, LinkedIn and CAS are specifics
- OAuth 2, OpenID Connect, SAML are generic/standards - that may be
used for the above specifics...
* how do we test things other than CAS - in terms of getting credentials,
configuration, etc
We could certainly do this is phases as well.
If you can enumerate the things that should work and provide some testing
details for CAS or as many as possible and OpenID Connect then we can test
the specific implementations that you provide and enable the testing of
another OpenID Connect effort that is in the works in the community.
I'm not sure whether we want to commit contributions that are dependent on
snapshots - we certainly can't release with any such dependencies.
I would hate to add a cleanup task to a release to make sure there are no
snapshots in there.
We will probably wait until after the pac4j releases to commit.
I am really happy that this integration is happening and that it went
rather smoothly.
These sorts of authentication protocols are complex and I think we lined up
pretty well overall.
Thanks for your work!
On Thu, Dec 3, 2015 at 2:28 PM, Jérôme LELEU <le...@gmail.com> wrote:
> Hi,
>
> I just sync'ed with master, cleaned dependencies and added missing
> Javadocs. Everything works correctly now. Many thanks.
>
> The pull request is ready for a full code review:
> https://github.com/apache/knox/pull/2
>
> I'll write the documentation after the pac4j releases (I hope next week).
>
> Thanks.
> Best regards,
> Jérôme
>
>
> 2015-12-02 19:18 GMT+01:00 larry mccay <la...@gmail.com>:
>
> > Fixed in https://issues.apache.org/jira/browse/KNOX-636.
> >
> > On Wed, Dec 2, 2015 at 12:42 PM, larry mccay <la...@gmail.com>
> > wrote:
> >
> > > Sure - I can file a JIRA and commit a fix.
> > >
> > > The secret generation should be done in one instance and replicated
> > across
> > > others.
> > > This replication/management of the credential stores is outside of the
> > > scope of Knox itself as of now.
> > >
> > > Documentation is done in markdown and is contributing details are
> > > available at:
> > >
> >
> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
> > >
> > > Which should give you a general idea.
> > >
> > > Find an example like: ./trunk/books/0.7.0/
> config_preauth_sso_provider.md
> > >
> > > For an example of typical content and format.
> > >
> > > Here is how that example renders:
> > >
> >
> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
> > >
> > > You'll need to tie it into the rest of the book - just grep for where
> > that
> > > filename is referenced.
> > > To test how it renders build the site with: "ant" and note the url to
> the
> > > 0.7.0 book.
> > >
> > >
> > > On Wed, Dec 2, 2015 at 12:12 PM, Jérôme LELEU <le...@gmail.com>
> wrote:
> > >
> > >> Hi,
> > >>
> > >> Why it doesn't work for pac4j while it works for others is a bit
> strange
> > >> to
> > >> me, but if you have the patch in front of your eyes, I'd rather prefer
> > you
> > >> to commit it. In all cases, I'll sync with the master.
> > >>
> > >> There was one question you didn't answer previously: is the password
> > >> generated for the pac4j provider the same across all gateway
> instances?
> > >> Because I expect to have the same value as I use it to encrypt /
> decrypt
> > >> data.
> > >>
> > >> I will add the Javadoc. After that, you can review the pull request
> more
> > >> completely.
> > >>
> > >> What do you expect for the documentation?
> > >>
> > >> Notice that pac4j dependencies are still snapshots, but they will be
> > >> released in a week or two.
> > >>
> > >> Thanks.
> > >> Best regards,
> > >> Jérôme
> > >>
> > >>
> > >> 2015-12-02 17:51 GMT+01:00 larry mccay <la...@gmail.com>:
> > >>
> > >> > Jérôme -
> > >> >
> > >> > If you would like to add that change as part of your patch or as a
> > >> > separately filed JIRA to fix a bug that would certainly be welcomed.
> > >> > Otherwise, I can do it.
> > >> >
> > >> > Let me know.
> > >> >
> > >> > thanks,
> > >> >
> > >> > --larry
> > >> >
> > >> > On Wed, Dec 2, 2015 at 11:44 AM, larry mccay <larry.mccay@gmail.com
> >
> > >> > wrote:
> > >> >
> > >> > > Okay - I had to add an override of getUserPrincipal() to the
> > >> > > IdentityAsserterHttpServletRequestWrapper and return the member
> > >> variable
> > >> > > username and it works like a charm.
> > >> > >
> > >> > > Why I haven't seen this same behavior with other providers is a
> bit
> > >> of a
> > >> > > mystery but they must be adding other wrappers that handle it.
> > >> > > This is quite cool, Jérôme!
> > >> > >
> > >> > > On Wed, Dec 2, 2015 at 10:41 AM, larry mccay <
> larry.mccay@gmail.com
> > >
> > >> > > wrote:
> > >> > >
> > >> > >> That was it - thanks!
> > >> > >>
> > >> > >> On Wed, Dec 2, 2015 at 10:20 AM, Jérôme LELEU <le...@gmail.com>
> > >> wrote:
> > >> > >>
> > >> > >>> This is my exact command line: mvn -Prelease clean install
> > >> -DskipTests
> > >> > >>>
> > >> > >>> You use an internal Maven repository to fetch dependencies from
> > >> > internet:
> > >> > >>>
> http://nexus-private.hortonworks.com/nexus/content/groups/public/
> > >> > >>>
> > >> > >>> Does this repository have access to the remote Snapshots
> Sonatype
> > >> repo?
> > >> > >>>
> > >> > >>>
> > >> > >>>
> > >> > >>> 2015-12-02 16:16 GMT+01:00 larry mccay <la...@gmail.com>:
> > >> > >>>
> > >> > >>> > hmmm - I used:
> > >> > >>> >
> > >> > >>> > mvn clean install -DskipTests=true -Prelease
> > >> > >>> >
> > >> > >>> > The repository entry is in there already.
> > >> > >>> > No worky.
> > >> > >>> >
> > >> > >>> > On Wed, Dec 2, 2015 at 10:12 AM, Jérôme LELEU <
> leleuj@gmail.com
> > >
> > >> > >>> wrote:
> > >> > >>> >
> > >> > >>> > > Hi,
> > >> > >>> > >
> > >> > >>> > > You need the j2e-pac4j dependencies as well as the pac4j-*
> > >> > >>> dependencies,
> > >> > >>> > > but you don't need to build them locally (hopefully).
> > >> > >>> > >
> > >> > >>> > > But you need a dependency on the Sonatype snapshots
> repository
> > >> > >>> (where the
> > >> > >>> > > snapshot versions are hosted), which is added for Maven in
> the
> > >> root
> > >> > >>> > > pom.xml:
> > >> > >>> > >
> > >> > >>> > >
> > >> > >>> >
> > >> > >>>
> > >> >
> > >>
> >
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> > >> > >>> > >
> > >> > >>> > > If you use Ant for the build, there is maybe a glitch to
> find
> > >> the
> > >> > >>> > Sonatype
> > >> > >>> > > Maven repo.
> > >> > >>> > >
> > >> > >>> > > Thanks.
> > >> > >>> > > Best regards,
> > >> > >>> > > Jérôme
> > >> > >>> > >
> > >> > >>> > >
> > >> > >>> > > 2015-12-02 16:06 GMT+01:00 larry mccay <
> larry.mccay@gmail.com
> > >:
> > >> > >>> > >
> > >> > >>> > > > 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.mccay@gmail.com>
> > >> > >>> > > > wrote:
> > >> > >>> > > >
> > >> > >>> > > > > gateway-provider-security-pac4j doesn't build - do you
> > have
> > >> a
> > >> > >>> pending
> > >> > >>> > > > > change for your pom.xml or something?
> > >> > >>> > > > >
> > >> > >>> >
> > >> > >>>
> > >> > >>
> > >> > >>
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Hi,
I just sync'ed with master, cleaned dependencies and added missing
Javadocs. Everything works correctly now. Many thanks.
The pull request is ready for a full code review:
https://github.com/apache/knox/pull/2
I'll write the documentation after the pac4j releases (I hope next week).
Thanks.
Best regards,
Jérôme
2015-12-02 19:18 GMT+01:00 larry mccay <la...@gmail.com>:
> Fixed in https://issues.apache.org/jira/browse/KNOX-636.
>
> On Wed, Dec 2, 2015 at 12:42 PM, larry mccay <la...@gmail.com>
> wrote:
>
> > Sure - I can file a JIRA and commit a fix.
> >
> > The secret generation should be done in one instance and replicated
> across
> > others.
> > This replication/management of the credential stores is outside of the
> > scope of Knox itself as of now.
> >
> > Documentation is done in markdown and is contributing details are
> > available at:
> >
> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
> >
> > Which should give you a general idea.
> >
> > Find an example like: ./trunk/books/0.7.0/config_preauth_sso_provider.md
> >
> > For an example of typical content and format.
> >
> > Here is how that example renders:
> >
> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
> >
> > You'll need to tie it into the rest of the book - just grep for where
> that
> > filename is referenced.
> > To test how it renders build the site with: "ant" and note the url to the
> > 0.7.0 book.
> >
> >
> > On Wed, Dec 2, 2015 at 12:12 PM, Jérôme LELEU <le...@gmail.com> wrote:
> >
> >> Hi,
> >>
> >> Why it doesn't work for pac4j while it works for others is a bit strange
> >> to
> >> me, but if you have the patch in front of your eyes, I'd rather prefer
> you
> >> to commit it. In all cases, I'll sync with the master.
> >>
> >> There was one question you didn't answer previously: is the password
> >> generated for the pac4j provider the same across all gateway instances?
> >> Because I expect to have the same value as I use it to encrypt / decrypt
> >> data.
> >>
> >> I will add the Javadoc. After that, you can review the pull request more
> >> completely.
> >>
> >> What do you expect for the documentation?
> >>
> >> Notice that pac4j dependencies are still snapshots, but they will be
> >> released in a week or two.
> >>
> >> Thanks.
> >> Best regards,
> >> Jérôme
> >>
> >>
> >> 2015-12-02 17:51 GMT+01:00 larry mccay <la...@gmail.com>:
> >>
> >> > Jérôme -
> >> >
> >> > If you would like to add that change as part of your patch or as a
> >> > separately filed JIRA to fix a bug that would certainly be welcomed.
> >> > Otherwise, I can do it.
> >> >
> >> > Let me know.
> >> >
> >> > thanks,
> >> >
> >> > --larry
> >> >
> >> > On Wed, Dec 2, 2015 at 11:44 AM, larry mccay <la...@gmail.com>
> >> > wrote:
> >> >
> >> > > Okay - I had to add an override of getUserPrincipal() to the
> >> > > IdentityAsserterHttpServletRequestWrapper and return the member
> >> variable
> >> > > username and it works like a charm.
> >> > >
> >> > > Why I haven't seen this same behavior with other providers is a bit
> >> of a
> >> > > mystery but they must be adding other wrappers that handle it.
> >> > > This is quite cool, Jérôme!
> >> > >
> >> > > On Wed, Dec 2, 2015 at 10:41 AM, larry mccay <larry.mccay@gmail.com
> >
> >> > > wrote:
> >> > >
> >> > >> That was it - thanks!
> >> > >>
> >> > >> On Wed, Dec 2, 2015 at 10:20 AM, Jérôme LELEU <le...@gmail.com>
> >> wrote:
> >> > >>
> >> > >>> This is my exact command line: mvn -Prelease clean install
> >> -DskipTests
> >> > >>>
> >> > >>> You use an internal Maven repository to fetch dependencies from
> >> > internet:
> >> > >>> http://nexus-private.hortonworks.com/nexus/content/groups/public/
> >> > >>>
> >> > >>> Does this repository have access to the remote Snapshots Sonatype
> >> repo?
> >> > >>>
> >> > >>>
> >> > >>>
> >> > >>> 2015-12-02 16:16 GMT+01:00 larry mccay <la...@gmail.com>:
> >> > >>>
> >> > >>> > hmmm - I used:
> >> > >>> >
> >> > >>> > mvn clean install -DskipTests=true -Prelease
> >> > >>> >
> >> > >>> > The repository entry is in there already.
> >> > >>> > No worky.
> >> > >>> >
> >> > >>> > On Wed, Dec 2, 2015 at 10:12 AM, Jérôme LELEU <leleuj@gmail.com
> >
> >> > >>> wrote:
> >> > >>> >
> >> > >>> > > Hi,
> >> > >>> > >
> >> > >>> > > You need the j2e-pac4j dependencies as well as the pac4j-*
> >> > >>> dependencies,
> >> > >>> > > but you don't need to build them locally (hopefully).
> >> > >>> > >
> >> > >>> > > But you need a dependency on the Sonatype snapshots repository
> >> > >>> (where the
> >> > >>> > > snapshot versions are hosted), which is added for Maven in the
> >> root
> >> > >>> > > pom.xml:
> >> > >>> > >
> >> > >>> > >
> >> > >>> >
> >> > >>>
> >> >
> >>
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> >> > >>> > >
> >> > >>> > > If you use Ant for the build, there is maybe a glitch to find
> >> the
> >> > >>> > Sonatype
> >> > >>> > > Maven repo.
> >> > >>> > >
> >> > >>> > > Thanks.
> >> > >>> > > Best regards,
> >> > >>> > > Jérôme
> >> > >>> > >
> >> > >>> > >
> >> > >>> > > 2015-12-02 16:06 GMT+01:00 larry mccay <larry.mccay@gmail.com
> >:
> >> > >>> > >
> >> > >>> > > > 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.mccay@gmail.com>
> >> > >>> > > > wrote:
> >> > >>> > > >
> >> > >>> > > > > gateway-provider-security-pac4j doesn't build - do you
> have
> >> a
> >> > >>> pending
> >> > >>> > > > > change for your pom.xml or something?
> >> > >>> > > > >
> >> > >>> >
> >> > >>>
> >> > >>
> >> > >>
> >> > >
> >> >
> >>
> >
> >
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
Fixed in https://issues.apache.org/jira/browse/KNOX-636.
On Wed, Dec 2, 2015 at 12:42 PM, larry mccay <la...@gmail.com> wrote:
> Sure - I can file a JIRA and commit a fix.
>
> The secret generation should be done in one instance and replicated across
> others.
> This replication/management of the credential stores is outside of the
> scope of Knox itself as of now.
>
> Documentation is done in markdown and is contributing details are
> available at:
> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
>
> Which should give you a general idea.
>
> Find an example like: ./trunk/books/0.7.0/config_preauth_sso_provider.md
>
> For an example of typical content and format.
>
> Here is how that example renders:
> http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
>
> You'll need to tie it into the rest of the book - just grep for where that
> filename is referenced.
> To test how it renders build the site with: "ant" and note the url to the
> 0.7.0 book.
>
>
> On Wed, Dec 2, 2015 at 12:12 PM, Jérôme LELEU <le...@gmail.com> wrote:
>
>> Hi,
>>
>> Why it doesn't work for pac4j while it works for others is a bit strange
>> to
>> me, but if you have the patch in front of your eyes, I'd rather prefer you
>> to commit it. In all cases, I'll sync with the master.
>>
>> There was one question you didn't answer previously: is the password
>> generated for the pac4j provider the same across all gateway instances?
>> Because I expect to have the same value as I use it to encrypt / decrypt
>> data.
>>
>> I will add the Javadoc. After that, you can review the pull request more
>> completely.
>>
>> What do you expect for the documentation?
>>
>> Notice that pac4j dependencies are still snapshots, but they will be
>> released in a week or two.
>>
>> Thanks.
>> Best regards,
>> Jérôme
>>
>>
>> 2015-12-02 17:51 GMT+01:00 larry mccay <la...@gmail.com>:
>>
>> > Jérôme -
>> >
>> > If you would like to add that change as part of your patch or as a
>> > separately filed JIRA to fix a bug that would certainly be welcomed.
>> > Otherwise, I can do it.
>> >
>> > Let me know.
>> >
>> > thanks,
>> >
>> > --larry
>> >
>> > On Wed, Dec 2, 2015 at 11:44 AM, larry mccay <la...@gmail.com>
>> > wrote:
>> >
>> > > Okay - I had to add an override of getUserPrincipal() to the
>> > > IdentityAsserterHttpServletRequestWrapper and return the member
>> variable
>> > > username and it works like a charm.
>> > >
>> > > Why I haven't seen this same behavior with other providers is a bit
>> of a
>> > > mystery but they must be adding other wrappers that handle it.
>> > > This is quite cool, Jérôme!
>> > >
>> > > On Wed, Dec 2, 2015 at 10:41 AM, larry mccay <la...@gmail.com>
>> > > wrote:
>> > >
>> > >> That was it - thanks!
>> > >>
>> > >> On Wed, Dec 2, 2015 at 10:20 AM, Jérôme LELEU <le...@gmail.com>
>> wrote:
>> > >>
>> > >>> This is my exact command line: mvn -Prelease clean install
>> -DskipTests
>> > >>>
>> > >>> You use an internal Maven repository to fetch dependencies from
>> > internet:
>> > >>> http://nexus-private.hortonworks.com/nexus/content/groups/public/
>> > >>>
>> > >>> Does this repository have access to the remote Snapshots Sonatype
>> repo?
>> > >>>
>> > >>>
>> > >>>
>> > >>> 2015-12-02 16:16 GMT+01:00 larry mccay <la...@gmail.com>:
>> > >>>
>> > >>> > hmmm - I used:
>> > >>> >
>> > >>> > mvn clean install -DskipTests=true -Prelease
>> > >>> >
>> > >>> > The repository entry is in there already.
>> > >>> > No worky.
>> > >>> >
>> > >>> > On Wed, Dec 2, 2015 at 10:12 AM, Jérôme LELEU <le...@gmail.com>
>> > >>> wrote:
>> > >>> >
>> > >>> > > Hi,
>> > >>> > >
>> > >>> > > You need the j2e-pac4j dependencies as well as the pac4j-*
>> > >>> dependencies,
>> > >>> > > but you don't need to build them locally (hopefully).
>> > >>> > >
>> > >>> > > But you need a dependency on the Sonatype snapshots repository
>> > >>> (where the
>> > >>> > > snapshot versions are hosted), which is added for Maven in the
>> root
>> > >>> > > pom.xml:
>> > >>> > >
>> > >>> > >
>> > >>> >
>> > >>>
>> >
>> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
>> > >>> > >
>> > >>> > > If you use Ant for the build, there is maybe a glitch to find
>> the
>> > >>> > Sonatype
>> > >>> > > Maven repo.
>> > >>> > >
>> > >>> > > Thanks.
>> > >>> > > Best regards,
>> > >>> > > Jérôme
>> > >>> > >
>> > >>> > >
>> > >>> > > 2015-12-02 16:06 GMT+01:00 larry mccay <la...@gmail.com>:
>> > >>> > >
>> > >>> > > > 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.mccay@gmail.com>
>> > >>> > > > wrote:
>> > >>> > > >
>> > >>> > > > > gateway-provider-security-pac4j doesn't build - do you have
>> a
>> > >>> pending
>> > >>> > > > > change for your pom.xml or something?
>> > >>> > > > >
>> > >>> >
>> > >>>
>> > >>
>> > >>
>> > >
>> >
>>
>
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
Sure - I can file a JIRA and commit a fix.
The secret generation should be done in one instance and replicated across
others.
This replication/management of the credential stores is outside of the
scope of Knox itself as of now.
Documentation is done in markdown and is contributing details are available
at:
https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-DocumentationContributorWorkflow
Which should give you a general idea.
Find an example like: ./trunk/books/0.7.0/config_preauth_sso_provider.md
For an example of typical content and format.
Here is how that example renders:
http://knox.apache.org/books/knox-0-7-0/user-guide.html#Preauthenticated+SSO+Provider
You'll need to tie it into the rest of the book - just grep for where that
filename is referenced.
To test how it renders build the site with: "ant" and note the url to the
0.7.0 book.
On Wed, Dec 2, 2015 at 12:12 PM, Jérôme LELEU <le...@gmail.com> wrote:
> Hi,
>
> Why it doesn't work for pac4j while it works for others is a bit strange to
> me, but if you have the patch in front of your eyes, I'd rather prefer you
> to commit it. In all cases, I'll sync with the master.
>
> There was one question you didn't answer previously: is the password
> generated for the pac4j provider the same across all gateway instances?
> Because I expect to have the same value as I use it to encrypt / decrypt
> data.
>
> I will add the Javadoc. After that, you can review the pull request more
> completely.
>
> What do you expect for the documentation?
>
> Notice that pac4j dependencies are still snapshots, but they will be
> released in a week or two.
>
> Thanks.
> Best regards,
> Jérôme
>
>
> 2015-12-02 17:51 GMT+01:00 larry mccay <la...@gmail.com>:
>
> > Jérôme -
> >
> > If you would like to add that change as part of your patch or as a
> > separately filed JIRA to fix a bug that would certainly be welcomed.
> > Otherwise, I can do it.
> >
> > Let me know.
> >
> > thanks,
> >
> > --larry
> >
> > On Wed, Dec 2, 2015 at 11:44 AM, larry mccay <la...@gmail.com>
> > wrote:
> >
> > > Okay - I had to add an override of getUserPrincipal() to the
> > > IdentityAsserterHttpServletRequestWrapper and return the member
> variable
> > > username and it works like a charm.
> > >
> > > Why I haven't seen this same behavior with other providers is a bit of
> a
> > > mystery but they must be adding other wrappers that handle it.
> > > This is quite cool, Jérôme!
> > >
> > > On Wed, Dec 2, 2015 at 10:41 AM, larry mccay <la...@gmail.com>
> > > wrote:
> > >
> > >> That was it - thanks!
> > >>
> > >> On Wed, Dec 2, 2015 at 10:20 AM, Jérôme LELEU <le...@gmail.com>
> wrote:
> > >>
> > >>> This is my exact command line: mvn -Prelease clean install
> -DskipTests
> > >>>
> > >>> You use an internal Maven repository to fetch dependencies from
> > internet:
> > >>> http://nexus-private.hortonworks.com/nexus/content/groups/public/
> > >>>
> > >>> Does this repository have access to the remote Snapshots Sonatype
> repo?
> > >>>
> > >>>
> > >>>
> > >>> 2015-12-02 16:16 GMT+01:00 larry mccay <la...@gmail.com>:
> > >>>
> > >>> > hmmm - I used:
> > >>> >
> > >>> > mvn clean install -DskipTests=true -Prelease
> > >>> >
> > >>> > The repository entry is in there already.
> > >>> > No worky.
> > >>> >
> > >>> > On Wed, Dec 2, 2015 at 10:12 AM, Jérôme LELEU <le...@gmail.com>
> > >>> wrote:
> > >>> >
> > >>> > > Hi,
> > >>> > >
> > >>> > > You need the j2e-pac4j dependencies as well as the pac4j-*
> > >>> dependencies,
> > >>> > > but you don't need to build them locally (hopefully).
> > >>> > >
> > >>> > > But you need a dependency on the Sonatype snapshots repository
> > >>> (where the
> > >>> > > snapshot versions are hosted), which is added for Maven in the
> root
> > >>> > > pom.xml:
> > >>> > >
> > >>> > >
> > >>> >
> > >>>
> >
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> > >>> > >
> > >>> > > If you use Ant for the build, there is maybe a glitch to find the
> > >>> > Sonatype
> > >>> > > Maven repo.
> > >>> > >
> > >>> > > Thanks.
> > >>> > > Best regards,
> > >>> > > Jérôme
> > >>> > >
> > >>> > >
> > >>> > > 2015-12-02 16:06 GMT+01:00 larry mccay <la...@gmail.com>:
> > >>> > >
> > >>> > > > 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.mccay@gmail.com>
> > >>> > > > wrote:
> > >>> > > >
> > >>> > > > > gateway-provider-security-pac4j doesn't build - do you have a
> > >>> pending
> > >>> > > > > change for your pom.xml or something?
> > >>> > > > >
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Hi,
Why it doesn't work for pac4j while it works for others is a bit strange to
me, but if you have the patch in front of your eyes, I'd rather prefer you
to commit it. In all cases, I'll sync with the master.
There was one question you didn't answer previously: is the password
generated for the pac4j provider the same across all gateway instances?
Because I expect to have the same value as I use it to encrypt / decrypt
data.
I will add the Javadoc. After that, you can review the pull request more
completely.
What do you expect for the documentation?
Notice that pac4j dependencies are still snapshots, but they will be
released in a week or two.
Thanks.
Best regards,
Jérôme
2015-12-02 17:51 GMT+01:00 larry mccay <la...@gmail.com>:
> Jérôme -
>
> If you would like to add that change as part of your patch or as a
> separately filed JIRA to fix a bug that would certainly be welcomed.
> Otherwise, I can do it.
>
> Let me know.
>
> thanks,
>
> --larry
>
> On Wed, Dec 2, 2015 at 11:44 AM, larry mccay <la...@gmail.com>
> wrote:
>
> > Okay - I had to add an override of getUserPrincipal() to the
> > IdentityAsserterHttpServletRequestWrapper and return the member variable
> > username and it works like a charm.
> >
> > Why I haven't seen this same behavior with other providers is a bit of a
> > mystery but they must be adding other wrappers that handle it.
> > This is quite cool, Jérôme!
> >
> > On Wed, Dec 2, 2015 at 10:41 AM, larry mccay <la...@gmail.com>
> > wrote:
> >
> >> That was it - thanks!
> >>
> >> On Wed, Dec 2, 2015 at 10:20 AM, Jérôme LELEU <le...@gmail.com> wrote:
> >>
> >>> This is my exact command line: mvn -Prelease clean install -DskipTests
> >>>
> >>> You use an internal Maven repository to fetch dependencies from
> internet:
> >>> http://nexus-private.hortonworks.com/nexus/content/groups/public/
> >>>
> >>> Does this repository have access to the remote Snapshots Sonatype repo?
> >>>
> >>>
> >>>
> >>> 2015-12-02 16:16 GMT+01:00 larry mccay <la...@gmail.com>:
> >>>
> >>> > hmmm - I used:
> >>> >
> >>> > mvn clean install -DskipTests=true -Prelease
> >>> >
> >>> > The repository entry is in there already.
> >>> > No worky.
> >>> >
> >>> > On Wed, Dec 2, 2015 at 10:12 AM, Jérôme LELEU <le...@gmail.com>
> >>> wrote:
> >>> >
> >>> > > Hi,
> >>> > >
> >>> > > You need the j2e-pac4j dependencies as well as the pac4j-*
> >>> dependencies,
> >>> > > but you don't need to build them locally (hopefully).
> >>> > >
> >>> > > But you need a dependency on the Sonatype snapshots repository
> >>> (where the
> >>> > > snapshot versions are hosted), which is added for Maven in the root
> >>> > > pom.xml:
> >>> > >
> >>> > >
> >>> >
> >>>
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> >>> > >
> >>> > > If you use Ant for the build, there is maybe a glitch to find the
> >>> > Sonatype
> >>> > > Maven repo.
> >>> > >
> >>> > > Thanks.
> >>> > > Best regards,
> >>> > > Jérôme
> >>> > >
> >>> > >
> >>> > > 2015-12-02 16:06 GMT+01:00 larry mccay <la...@gmail.com>:
> >>> > >
> >>> > > > 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.mccay@gmail.com>
> >>> > > > wrote:
> >>> > > >
> >>> > > > > gateway-provider-security-pac4j doesn't build - do you have a
> >>> pending
> >>> > > > > change for your pom.xml or something?
> >>> > > > >
> >>> >
> >>>
> >>
> >>
> >
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
Jérôme -
If you would like to add that change as part of your patch or as a
separately filed JIRA to fix a bug that would certainly be welcomed.
Otherwise, I can do it.
Let me know.
thanks,
--larry
On Wed, Dec 2, 2015 at 11:44 AM, larry mccay <la...@gmail.com> wrote:
> Okay - I had to add an override of getUserPrincipal() to the
> IdentityAsserterHttpServletRequestWrapper and return the member variable
> username and it works like a charm.
>
> Why I haven't seen this same behavior with other providers is a bit of a
> mystery but they must be adding other wrappers that handle it.
> This is quite cool, Jérôme!
>
> On Wed, Dec 2, 2015 at 10:41 AM, larry mccay <la...@gmail.com>
> wrote:
>
>> That was it - thanks!
>>
>> On Wed, Dec 2, 2015 at 10:20 AM, Jérôme LELEU <le...@gmail.com> wrote:
>>
>>> This is my exact command line: mvn -Prelease clean install -DskipTests
>>>
>>> You use an internal Maven repository to fetch dependencies from internet:
>>> http://nexus-private.hortonworks.com/nexus/content/groups/public/
>>>
>>> Does this repository have access to the remote Snapshots Sonatype repo?
>>>
>>>
>>>
>>> 2015-12-02 16:16 GMT+01:00 larry mccay <la...@gmail.com>:
>>>
>>> > hmmm - I used:
>>> >
>>> > mvn clean install -DskipTests=true -Prelease
>>> >
>>> > The repository entry is in there already.
>>> > No worky.
>>> >
>>> > On Wed, Dec 2, 2015 at 10:12 AM, Jérôme LELEU <le...@gmail.com>
>>> wrote:
>>> >
>>> > > Hi,
>>> > >
>>> > > You need the j2e-pac4j dependencies as well as the pac4j-*
>>> dependencies,
>>> > > but you don't need to build them locally (hopefully).
>>> > >
>>> > > But you need a dependency on the Sonatype snapshots repository
>>> (where the
>>> > > snapshot versions are hosted), which is added for Maven in the root
>>> > > pom.xml:
>>> > >
>>> > >
>>> >
>>> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
>>> > >
>>> > > If you use Ant for the build, there is maybe a glitch to find the
>>> > Sonatype
>>> > > Maven repo.
>>> > >
>>> > > Thanks.
>>> > > Best regards,
>>> > > Jérôme
>>> > >
>>> > >
>>> > > 2015-12-02 16:06 GMT+01:00 larry mccay <la...@gmail.com>:
>>> > >
>>> > > > 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.mccay@gmail.com>
>>> > > > wrote:
>>> > > >
>>> > > > > gateway-provider-security-pac4j doesn't build - do you have a
>>> pending
>>> > > > > change for your pom.xml or something?
>>> > > > >
>>> >
>>>
>>
>>
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
Okay - I had to add an override of getUserPrincipal() to the
IdentityAsserterHttpServletRequestWrapper and return the member variable
username and it works like a charm.
Why I haven't seen this same behavior with other providers is a bit of a
mystery but they must be adding other wrappers that handle it.
This is quite cool, Jérôme!
On Wed, Dec 2, 2015 at 10:41 AM, larry mccay <la...@gmail.com> wrote:
> That was it - thanks!
>
> On Wed, Dec 2, 2015 at 10:20 AM, Jérôme LELEU <le...@gmail.com> wrote:
>
>> This is my exact command line: mvn -Prelease clean install -DskipTests
>>
>> You use an internal Maven repository to fetch dependencies from internet:
>> http://nexus-private.hortonworks.com/nexus/content/groups/public/
>>
>> Does this repository have access to the remote Snapshots Sonatype repo?
>>
>>
>>
>> 2015-12-02 16:16 GMT+01:00 larry mccay <la...@gmail.com>:
>>
>> > hmmm - I used:
>> >
>> > mvn clean install -DskipTests=true -Prelease
>> >
>> > The repository entry is in there already.
>> > No worky.
>> >
>> > On Wed, Dec 2, 2015 at 10:12 AM, Jérôme LELEU <le...@gmail.com> wrote:
>> >
>> > > Hi,
>> > >
>> > > You need the j2e-pac4j dependencies as well as the pac4j-*
>> dependencies,
>> > > but you don't need to build them locally (hopefully).
>> > >
>> > > But you need a dependency on the Sonatype snapshots repository (where
>> the
>> > > snapshot versions are hosted), which is added for Maven in the root
>> > > pom.xml:
>> > >
>> > >
>> >
>> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
>> > >
>> > > If you use Ant for the build, there is maybe a glitch to find the
>> > Sonatype
>> > > Maven repo.
>> > >
>> > > Thanks.
>> > > Best regards,
>> > > Jérôme
>> > >
>> > >
>> > > 2015-12-02 16:06 GMT+01:00 larry mccay <la...@gmail.com>:
>> > >
>> > > > 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.mccay@gmail.com
>> >
>> > > > wrote:
>> > > >
>> > > > > gateway-provider-security-pac4j doesn't build - do you have a
>> pending
>> > > > > change for your pom.xml or something?
>> > > > >
>> >
>>
>
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
That was it - thanks!
On Wed, Dec 2, 2015 at 10:20 AM, Jérôme LELEU <le...@gmail.com> wrote:
> This is my exact command line: mvn -Prelease clean install -DskipTests
>
> You use an internal Maven repository to fetch dependencies from internet:
> http://nexus-private.hortonworks.com/nexus/content/groups/public/
>
> Does this repository have access to the remote Snapshots Sonatype repo?
>
>
>
> 2015-12-02 16:16 GMT+01:00 larry mccay <la...@gmail.com>:
>
> > hmmm - I used:
> >
> > mvn clean install -DskipTests=true -Prelease
> >
> > The repository entry is in there already.
> > No worky.
> >
> > On Wed, Dec 2, 2015 at 10:12 AM, Jérôme LELEU <le...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > You need the j2e-pac4j dependencies as well as the pac4j-*
> dependencies,
> > > but you don't need to build them locally (hopefully).
> > >
> > > But you need a dependency on the Sonatype snapshots repository (where
> the
> > > snapshot versions are hosted), which is added for Maven in the root
> > > pom.xml:
> > >
> > >
> >
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> > >
> > > If you use Ant for the build, there is maybe a glitch to find the
> > Sonatype
> > > Maven repo.
> > >
> > > Thanks.
> > > Best regards,
> > > Jérôme
> > >
> > >
> > > 2015-12-02 16:06 GMT+01:00 larry mccay <la...@gmail.com>:
> > >
> > > > 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 <la...@gmail.com>
> > > > wrote:
> > > >
> > > > > gateway-provider-security-pac4j doesn't build - do you have a
> pending
> > > > > change for your pom.xml or something?
> > > > >
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
This is my exact command line: mvn -Prelease clean install -DskipTests
You use an internal Maven repository to fetch dependencies from internet:
http://nexus-private.hortonworks.com/nexus/content/groups/public/
Does this repository have access to the remote Snapshots Sonatype repo?
2015-12-02 16:16 GMT+01:00 larry mccay <la...@gmail.com>:
> hmmm - I used:
>
> mvn clean install -DskipTests=true -Prelease
>
> The repository entry is in there already.
> No worky.
>
> On Wed, Dec 2, 2015 at 10:12 AM, Jérôme LELEU <le...@gmail.com> wrote:
>
> > Hi,
> >
> > You need the j2e-pac4j dependencies as well as the pac4j-* dependencies,
> > but you don't need to build them locally (hopefully).
> >
> > But you need a dependency on the Sonatype snapshots repository (where the
> > snapshot versions are hosted), which is added for Maven in the root
> > pom.xml:
> >
> >
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
> >
> > If you use Ant for the build, there is maybe a glitch to find the
> Sonatype
> > Maven repo.
> >
> > Thanks.
> > Best regards,
> > Jérôme
> >
> >
> > 2015-12-02 16:06 GMT+01:00 larry mccay <la...@gmail.com>:
> >
> > > 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 <la...@gmail.com>
> > > wrote:
> > >
> > > > gateway-provider-security-pac4j doesn't build - do you have a pending
> > > > change for your pom.xml or something?
> > > >
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
hmmm - I used:
mvn clean install -DskipTests=true -Prelease
The repository entry is in there already.
No worky.
On Wed, Dec 2, 2015 at 10:12 AM, Jérôme LELEU <le...@gmail.com> wrote:
> Hi,
>
> You need the j2e-pac4j dependencies as well as the pac4j-* dependencies,
> but you don't need to build them locally (hopefully).
>
> But you need a dependency on the Sonatype snapshots repository (where the
> snapshot versions are hosted), which is added for Maven in the root
> pom.xml:
>
> https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
>
> If you use Ant for the build, there is maybe a glitch to find the Sonatype
> Maven repo.
>
> Thanks.
> Best regards,
> Jérôme
>
>
> 2015-12-02 16:06 GMT+01:00 larry mccay <la...@gmail.com>:
>
> > 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 <la...@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 <la...@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 <le...@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 <la...@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 <le...@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 <la...@gmail.com>:
> > >>> > >
> > >>> > > > inline...
> > >>> > > >
> > >>> > > > On Wed, Nov 25, 2015 at 5:04 AM, Jérôme LELEU <
> leleuj@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
> > >>> > > >
> > >>> > >
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Hi,
You need the j2e-pac4j dependencies as well as the pac4j-* dependencies,
but you don't need to build them locally (hopefully).
But you need a dependency on the Sonatype snapshots repository (where the
snapshot versions are hosted), which is added for Maven in the root
pom.xml:
https://github.com/apache/knox/pull/2/files#diff-600376dffeb79835ede4a0b285078036R123
If you use Ant for the build, there is maybe a glitch to find the Sonatype
Maven repo.
Thanks.
Best regards,
Jérôme
2015-12-02 16:06 GMT+01:00 larry mccay <la...@gmail.com>:
> 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 <la...@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 <la...@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 <le...@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 <la...@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 <le...@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 <la...@gmail.com>:
> >>> > >
> >>> > > > inline...
> >>> > > >
> >>> > > > On Wed, Nov 25, 2015 at 5:04 AM, Jérôme LELEU <le...@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
> >>> > > >
> >>> > >
> >>> >
> >>>
> >>
> >>
> >
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
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 <la...@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 <la...@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 <le...@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 <la...@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 <le...@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 <la...@gmail.com>:
>>> > >
>>> > > > inline...
>>> > > >
>>> > > > On Wed, Nov 25, 2015 at 5:04 AM, Jérôme LELEU <le...@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
>>> > > >
>>> > >
>>> >
>>>
>>
>>
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
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 <la...@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 <le...@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 <la...@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 <le...@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 <la...@gmail.com>:
>> > >
>> > > > inline...
>> > > >
>> > > > On Wed, Nov 25, 2015 at 5:04 AM, Jérôme LELEU <le...@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
>> > > >
>> > >
>> >
>>
>
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
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 <le...@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 <la...@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 <le...@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 <la...@gmail.com>:
> > >
> > > > inline...
> > > >
> > > > On Wed, Nov 25, 2015 at 5:04 AM, Jérôme LELEU <le...@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
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
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 <la...@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 <le...@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 <la...@gmail.com>:
> >
> > > inline...
> > >
> > > On Wed, Nov 25, 2015 at 5:04 AM, Jérôme LELEU <le...@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
> > >
> >
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@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 <le...@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 <la...@gmail.com>:
>
> > inline...
> >
> > On Wed, Nov 25, 2015 at 5:04 AM, Jérôme LELEU <le...@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
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
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 <la...@gmail.com>:
> inline...
>
> On Wed, Nov 25, 2015 at 5:04 AM, Jérôme LELEU <le...@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
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
inline...
On Wed, Nov 25, 2015 at 5:04 AM, Jérôme LELEU <le...@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 <la...@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 <le...@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 <la...@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 <le...@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 <la...@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
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
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).
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".
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?
I updated the pull request with my latest source code:
https://github.com/apache/knox/pull/2
Thanks.
Best regards,
Jérôme
2015-11-24 21:25 GMT+01:00 larry mccay <la...@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 <le...@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 <la...@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 <le...@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 <la...@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
> > > > >
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Good catch. Mostly a copy/paste I did from Picketlink ;-)
2015-11-24 21:25 GMT+01:00 larry mccay <la...@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 <le...@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 <la...@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 <le...@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 <la...@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
> > > > >
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@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 <le...@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 <la...@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 <le...@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 <la...@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
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
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 <la...@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 <le...@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 <la...@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
> > >
> >
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@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 <le...@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 <la...@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
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
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 <la...@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
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@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
On Tue, Nov 24, 2015 at 9:03 AM, Jérôme LELEU <le...@gmail.com> wrote:
> Hi,
>
> As the j2e-pac4j library now supports the required features for Knox, I
> restarted working on pac4j - Knox integration.
>
> Though, I have a very strange error. The deployment of the WARs fails with
> the following error: *java.lang.IllegalArgumentException: Not supported:
> indent-number*
>
> I tried to comment out the line: *transformerFactory.setAttribute(
> "indent-number", 2 );* in the XmlGatewayDescriptorExporter class, but it
> leads me to another error
> (org.apache.hadoop.gateway.deploy.DeploymentException: Failed to finalize
> contribution)
>
> Any idea of what's wrong?
>
> Thanks.
> Best regards,
> Jérôme
>
>
>
>
> 2015-11-19 15:21 GMT+01:00 larry mccay <la...@gmail.com>:
>
> > Ahhh - in that case use:
> >
> > https://localhost:8443/gateway/idp/api/v1/websso
> >
> > The original resource path for the knoxsso service would have made it
> more
> > like:
> >
> > https://localhost:8443/gateway/idp/knoxsso/api/v1/websso
> >
> > Which seems redundant and arbitrary.
> > We need to evolve such services to be distinct from typical topologies
> > since they aren't really Hadoop cluster specific like typical topologies
> > are.
> >
> > Anyway, try the URL above for your current configuration - that should
> > resolve the 404.
> >
> >
> > On Thu, Nov 19, 2015 at 9:09 AM, Jérôme LELEU <le...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > I'm looking forward to read the new documentation you'll write on the
> > REST
> > > API support.
> > >
> > > About the 404, I'm not sure to understand why you want me to remove
> > "idp/"
> > > from the url as the KnoxSSO service is defined in the idp.xml topology:
> > > does its url not have a /idp?
> > >
> > > About the OpenID Connect support, I added it, it's now in pac4j:
> > >
> > >
> >
> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java#L60
> > >
> > > Thanks.
> > > Best regards,
> > > Jérôme
> > >
> > >
> > >
> > > 2015-11-18 14:35 GMT+01:00 larry mccay <la...@gmail.com>:
> > >
> > > > Hi Jérôme -
> > > >
> > > > Great progress!
> > > > You have the flow down perfectly.
> > > >
> > > > You should be also aware that the SSOCookieProvider is a mechanism
> for
> > > > consuming the SSO cookie for the REST APIs.
> > > > There are also integrations for the various Hadoop UIs - most
> > components
> > > > within the core Hadoop common project have a UI - ie. NameNode,
> > DataNode,
> > > > YARN ResourceManager, etc. Additionally, ecosystem components such as
> > > > Oozie, HBase, Hive, Falcon, Atlas, Ambari, Ranger, etc all have UIs
> and
> > > are
> > > > adding or already have support for the SSO cookie being created in
> > > KnoxSSO.
> > > > Many of these are able to leverage the support added to Hadoop common
> > and
> > > > get it largely for free.
> > > >
> > > > REST API support is interesting and immediately relevant to Knox but
> > may
> > > > actually be secondary to the WebSSO flow for the UIs.
> > > > When deployments do want to provide REST API support
> SSOCookieProvider
> > > > enables CORS for allowing javascript API calls from browsers in other
> > > > domains to access Hadoop resources. It is also great for development
> > > > scenarios like this where we need some consumer to test integrations.
> > > >
> > > > I am in the process of writing up more docs on these very aspects of
> > > > KnoxSSO and JWT cookie support across Hadoop.
> > > >
> > > > The 404 is related to the configured provider url on the
> > > SSOCookieProvider
> > > > - remove the "idp/" in the URL.
> > > >
> > > > That used to be the correct URL but we have since simplified it for
> the
> > > > time being to just be knoxsso.
> > > > There is a thread [1] on the dev list that describes that decision
> and
> > > what
> > > > we should consider moving forward.
> > > >
> > > > We will have generic OpenId Connect support as well? This is
> something
> > > that
> > > > would be of immediate value.
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/knox-dev/201511.mbox/%3CCACRbFygkWLJ-tFW612ha_Cr82u%2B41PwDqGx_TWbijbP0g34g%3DQ%40mail.gmail.com%3E
> > > >
> > > > Thanks!
> > > >
> > > > --larry
> > > >
> > > > On Wed, Nov 18, 2015 at 6:11 AM, Jérôme LELEU <le...@gmail.com>
> > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I've read the documentation and things seem fairly clear to me. Let
> > me
> > > > > share my understanding and progress:
> > > > >
> > > > > - the KnoxSSO service is mandatory and the
> > > > gateway-provider-security-pac4j
> > > > > won't work without it: the KnoxSSO service is responsible for
> > creating
> > > a
> > > > > hadoop-jwt cookie from the current authenticated user (J2E
> subject).
> > > > > - the SSOCookieProvider is also mandatory to protect services and
> > > request
> > > > > the hadoop-jwt cookie to exist by forwarding to the KnoxSSO
> endpoint.
> > > > >
> > > > > I have created two gateways: one for regular Hadoop services which
> is
> > > > > protected by the SSOCookieProvider ->
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/knox/pull/2/files#diff-128ca80baa2dfd6c2d25de7b8160b9d9R23
> > > > > the other one for the KnoxSSO service protected by pac4j ->
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/knox/pull/2/files#diff-4ea9a9a5ee5968f29982478512a63c54R23
> > > > >
> > > > > Here is my webflow :
> > > > >
> > > > > $ curl -ivk "
> > > > >
> https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS"
> > > > > 302 Found
> > > > > Location:
> > > > >
> > > > >
> > > >
> > >
> >
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
> > > > >
> > > > >
> > > > > Calling a regular Hadoop service through the gateway, it is
> > redirected
> > > to
> > > > > the KnoxSSO endpoint (as no hadoop-jwt cookie exists)
> > > > >
> > > > > $ curl -ivk "
> > > > >
> > > > >
> > > >
> > >
> >
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
> > > > > "
> > > > > 302 Found
> > > > > Set-Cookie: pac4j.session.pac4jRequestedUrl="
> > > > >
> > > > >
> > > >
> > >
> >
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
> > > > > "
> > > > > Location:
> > > > >
> > > > >
> > > >
> > >
> >
> https://casserverpac4j.herokuapp.com?service=https%3A%2F%2F127.0.0.1%3A8443%2Fgateway%2Fidp%2Fknoxsso%2Fapi%2Fv1%3Fclient_name%3DCasClient
> > > > >
> > > > >
> > > > > Calling the KnosSSO endpoint, the originally requested url is saved
> > > into
> > > > a
> > > > > cookie (the naive implementation I currently use) and it is
> > redirected
> > > > to a
> > > > > CAS server login for authentication (my internal configuration).
> > > > >
> > > > > After login at the CAS server, the user is redirected back to the
> > > > callback
> > > > > url, which is the KnoxSSO endpoint.
> > > > >
> > > > > $ curl -ivk --cookie "pac4j.session.pac4jRequestedUrl=
> > > > >
> > > > >
> > > >
> > >
> >
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhbhdfs/v1/tmp?op=LISTSTATUS
> > > > > "
> > > > > "
> > > > >
> > > > >
> > > >
> > >
> >
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?client_name=CasClient&ticket=ST-2-LQ2QLLEdAhBmrCPE1MZA-cas01.example.org
> > > > > "
> > > > > 302 Found
> > > > > Set-Cookie: pac4j.session.pac4jUserProfile=CasProfile#jleleu
> > > > > Location:
> > > > >
> > > > >
> > > >
> > >
> >
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
> > > > >
> > > > >
> > > > > The fact it's a callback (to finish the login process) is now based
> > on
> > > > the*
> > > > > client_name* parameter (instead of a /callback url). The
> > authentication
> > > > is
> > > > > finished by validating the CAS service ticket and a user profile is
> > > > created
> > > > > into session and saved in a cookie. It is redirected to the
> > originally
> > > > > requested url.
> > > > >
> > > > > $ curl -ivk --cookie
> > > "pac4j.session.pac4jUserProfile=CasProfile#jleleu" "
> > > > >
> > > > >
> > > >
> > >
> >
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
> > > > > "
> > > > > 404
> > > > >
> > > > >
> > > > > The call to the KnoxSSO endpoint triggers the pac4j filter, which
> > gets
> > > > the
> > > > > user profile from the cookie, calls the identity adapter and sets
> the
> > > J2E
> > > > > subject with the pac4j user profile. Here I get a 404 I don't
> > > understand
> > > > > and on which I'm currently investigating.
> > > > >
> > > > > So the callback url issue is solved: the KnoxSSO endpoint is the
> > static
> > > > url
> > > > > used for callback, for any identity provider and the *client_name*
> > > > > parameter is the way to know if it is a callback or not.
> > > > >
> > > > > To save the data in session, I used non-secure cookies for now,
> it's
> > my
> > > > > naive implementation. It currently doesn't work properly because as
> > we
> > > > rely
> > > > > on j2e-pac4j, response.sendRedirect occurs and after that, nothing
> > can
> > > be
> > > > > done on the response. So I need to change pac4j v1.8.1-SNAPSHOT and
> > > > > j2e-pac4j v1.2.1-SNAPSHOT to be able to plugin a specific session
> > > storage
> > > > > mechanism (the need has arisen for Play and Shiro as well) ->
> > > > > https://github.com/pac4j/pac4j/issues/359
> > > > >
> > > > > As for configuration, we said that the client configuration will be
> > > > defined
> > > > > based on properties. As the same mechanism is available for the CAS
> > > > server,
> > > > > this capability has been moved to pac4j ->
> > > > > https://github.com/pac4j/pac4j/issues/357
> > > > > It means that currently, Facebook, Twitter, a SAML IdP and a CAS
> > server
> > > > can
> > > > > be created via properties: if you need other identity providers,
> > please
> > > > > speak up so that I can integrate them.
> > > > >
> > > > > So I have some more work to do in pac4j and j2e-pac4j before being
> > able
> > > > to
> > > > > go further with Knox. I'll keep you posted.
> > > > >
> > > > > Thanks.
> > > > > Best regards,
> > > > > Jérôme
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 2015-11-14 19:03 GMT+01:00 larry mccay <lm...@apache.org>:
> > > > >
> > > > > > Here is a *very* early version of an integration guide for
> KnoxSSO:
> > > > > >
> > > > > > http://knox.apache.org/books/knox-0-7-0/knoxsso_integration.html
> > > > > >
> > > > > > It will walk you through setting up an environment to for using
> > > KnoxSSO
> > > > > to
> > > > > > secure the REST APIs using KnoxSSO cookies and a webflow.
> > > > > > The initial environment uses simple browser HTTP basic
> > authentication
> > > > to
> > > > > > protect the WebSSO service which hands out the cookies.
> > > > > > This allows us to ensure that KnoxSSO is setup properly without
> > > > > introducing
> > > > > > a 3rd party provider into the mix first.
> > > > > >
> > > > > > Once you have it working with Basic Auth then you can switch to
> > your
> > > > > pac4j
> > > > > > provider instead of Shiro to protect the websso service and we
> can
> > > > start
> > > > > to
> > > > > > work through the integration of your provider.
> > > > > >
> > > > > > Please understand that this is still a document that is very
> much a
> > > > work
> > > > > in
> > > > > > progress and has content, formatting and other issues.
> > > > > > It should serve as a general guide for you in the short term
> > though.
> > > > > >
> > > > > > Hope it is useful for you!
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, Nov 13, 2015 at 9:51 AM, Kevin Minder <
> > > > > > kevin.minder@hortonworks.com>
> > > > > > wrote:
> > > > > >
> > > > > > > I’ll add a bit to the logging answer. I created that for
> several
> > > > > > reasons.
> > > > > > > 1) Localization as Larry mentions.
> > > > > > > 2) It abstract from actual logging provider and you can see for
> > > > example
> > > > > > > gateway-i18n-logging-sl4j as an alternate integration.
> > > > > > > 3) Another important aspect is centralization. It centralizes
> > all
> > > > > > aspects
> > > > > > > of a given message. For example the level for a given message
> is
> > > > kept
> > > > > > with
> > > > > > > the message to hopefully prevent the message from being
> > duplicated
> > > > with
> > > > > > > potentially different levels. It is also intended to support
> the
> > > > > notion
> > > > > > of
> > > > > > > Ids and potentially cause/action annotations which are very
> > common
> > > as
> > > > > > > products mature.
> > > > > > > 4) Lastly and possibly the most interesting/important from a
> > > > developer
> > > > > > > perspective is traceability. Once you find the log method for
> a
> > > > given
> > > > > > > message you can use the IDE to find all of the palaces where a
> > > given
> > > > > > > message is used. You can also have the IDE tell you if the
> > message
> > > > > isn’t
> > > > > > > used anymore.
> > > > > > >
> > > > > > > All that being said the external components we integrate with
> > > > certainly
> > > > > > > don’t use it. So from that perspective, direct use of log4j if
> > > that
> > > > is
> > > > > > > your choice isn’t going to cause any major problems.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 11/13/15, 8:40 AM, "larry mccay" <lm...@apache.org> wrote:
> > > > > > >
> > > > > > > >Hi Jérôme -
> > > > > > > >
> > > > > > > >Great questions and I'm so glad that you are here to ask them.
> > > > > > > >
> > > > > > > >I think that the set of documentation that I am working on
> for a
> > > > > KnoxSSO
> > > > > > > >integration guide will probably answer most of your questions.
> > > > > > > >I need to spend a bit more time thinking about the some of it
> so
> > > > that
> > > > > I
> > > > > > > can
> > > > > > > >incorporate that information as well.
> > > > > > > >
> > > > > > > >The cookie approach is what we use in KnoxSSO. Cookies
> obviously
> > > > have
> > > > > > some
> > > > > > > >disadvantages but is probably the best alternative for
> KnoxSSO.
> > > > > > > >Something that we need to consider is that KnoxSSO is already
> > > > keeping
> > > > > > > track
> > > > > > > >of the original URL for redirecting back to the requested
> > > resource.
> > > > > > > >We have to reconcile whether that is separate from the
> callback
> > > > needs
> > > > > or
> > > > > > > >actually the same thing.
> > > > > > > >Having a little trouble wrapping my head around it right now -
> > > must
> > > > > have
> > > > > > > >more coffee. :)
> > > > > > > >
> > > > > > > >The Messages layer allows for the localization of the actual
> > > > messages
> > > > > by
> > > > > > > >decoupling the messages from the actual runtime code.
> > > > > > > >
> > > > > > > >I will try and get some docs published as quickly as possible
> > for
> > > > > > KnoxSSO
> > > > > > > >integration.
> > > > > > > >
> > > > > > > >thanks,
> > > > > > > >
> > > > > > > >--larry
> > > > > > > >
> > > > > > > >On Fri, Nov 13, 2015 at 3:27 AM, Jérôme LELEU <
> leleuj@gmail.com
> > >
> > > > > wrote:
> > > > > > > >
> > > > > > > >> Hi,
> > > > > > > >>
> > > > > > > >> 1) Webflow: I think I get the idea with the KnoxSSO service:
> > how
> > > > > can I
> > > > > > > test
> > > > > > > >> everything to ensure pac4j works correctly with it and will
> be
> > > > > usable
> > > > > > in
> > > > > > > >> Hadoop UIs?
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> 2) Callback url:
> > > > > > > >>
> > > > > > > >> For indirect clients, pac4j is designed to be called on any
> > url,
> > > > to
> > > > > > save
> > > > > > > >> it, to call the identity provider providing a static
> callback
> > > url,
> > > > > to
> > > > > > be
> > > > > > > >> called back on this static callback url and to restore the
> > > > > originally
> > > > > > > >> requested url.
> > > > > > > >>
> > > > > > > >> From point 1), I conclude that pac4j will always be used
> with
> > > the
> > > > > > > KnoxSSO
> > > > > > > >> service (for indirect clients): will KnoxSSO call the pac4j
> > > > provider
> > > > > > > always
> > > > > > > >> on the same url? Can you describe your first flow with urls?
> > > > > > > >>
> > > > > > > >> Because in that case, I could find a solution where I check
> > for
> > > > the
> > > > > > > >> client_name parameter to define if it's a callback or a
> first
> > > > call.
> > > > > > > >>
> > > > > > > >> Otherwise, I will need a specific pac4j service.
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> 3) Configuration: no problem here, I will use the
> > AliasService.
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> 4) Web session: I really need to put some information in
> > session
> > > > and
> > > > > > > check
> > > > > > > >> them on callback: I think I can take the data put in
> session,
> > > save
> > > > > > them
> > > > > > > in
> > > > > > > >> a cookie and restore them before the callback.
> > > > > > > >>
> > > > > > > >> Is it the recommended solution? Can I re-use the components
> > > > > available
> > > > > > > for
> > > > > > > >> JWT tokens and cookies? And how?
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> 5) Logs: I see in every descriptor the use of Messages and
> > > > > > > MessagesFactory:
> > > > > > > >> I can't use log4j directly, can I? What's the expected
> > benefits
> > > > > using
> > > > > > > this
> > > > > > > >> Messages layer?
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> Thanks.
> > > > > > > >> Best regards,
> > > > > > > >> Jérôme
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> 2015-11-12 18:14 GMT+01:00 larry mccay <lm...@apache.org>:
> > > > > > > >>
> > > > > > > >> > Terrific!
> > > > > > > >> >
> > > > > > > >> > Okay... original questions:
> > > > > > > >> >
> > > > > > > >> > 1) Webflow: is it normal to get a redirection to Facebook
> or
> > > > > another
> > > > > > > IdP
> > > > > > > >> > when I made the request (for such a configuration of
> > course)?
> > > Is
> > > > > > this
> > > > > > > >> > request meant to happen in a browser? (because it's the
> use
> > > case
> > > > > it
> > > > > > > was
> > > > > > > >> > made for)
> > > > > > > >> >
> > > > > > > >> > It is normal.
> > > > > > > >> > The usecases in which this mechanism would be used would
> > > involve
> > > > > the
> > > > > > > >> > KnoxSSO service/feature.
> > > > > > > >> > What we are doing with that is providing a normalization
> of
> > > > > > > >> authentication
> > > > > > > >> > mechanisms by federating each auth event through a JWT
> token
> > > > that
> > > > > > gets
> > > > > > > >> set
> > > > > > > >> > as a cookie.
> > > > > > > >> > These usecases allow us to provide WebSSO flows for Hadoop
> > UIs
> > > > and
> > > > > > > other
> > > > > > > >> > applications and those applications to only ever have to
> > know
> > > > > about
> > > > > > > >> KnoxSSO
> > > > > > > >> > tokens.
> > > > > > > >> >
> > > > > > > >> > What is slightly less normal is that the flow needs to
> have
> > > > > KnoxSSO
> > > > > > in
> > > > > > > >> the
> > > > > > > >> > middle.
> > > > > > > >> > For instance:
> > > > > > > >> > 1. a browser requests a resource from a KnoxSSO
> > participating
> > > > > > service
> > > > > > > >> > provider
> > > > > > > >> > 2. the service provider redirects the browser to KnoxSSO
> > since
> > > > > there
> > > > > > > is
> > > > > > > >> no
> > > > > > > >> > cookie
> > > > > > > >> > 3. KnoxSSO is protected with pac4j provider and redirects
> > the
> > > > > > browser
> > > > > > > to
> > > > > > > >> FB
> > > > > > > >> > 4. user authenticates to FB
> > > > > > > >> > 5. pac4j accepts the FB authentication and normalizes the
> > > > security
> > > > > > > >> context
> > > > > > > >> > to a J2E Subject
> > > > > > > >> > 6. WebSSO service then creates a signed JWT token, sets
> the
> > > > cookie
> > > > > > and
> > > > > > > >> > redirects to the originally requested resource
> > > > > > > >> > 7. originally requested resource finds the hadoop-jwt
> > cookie,
> > > > > > > validates
> > > > > > > >> the
> > > > > > > >> > token and verifies the signature and grants access to the
> > > > resource
> > > > > > > >> >
> > > > > > > >> > 2) Callback url:
> > > > https://localhost:8443/gateway/sandbox/callback
> > > > > > > >> currently
> > > > > > > >> > returns a 404, so I must declare this url somewhere to be
> > > taken
> > > > > into
> > > > > > > >> > account and pass to the pac4j filter. It would be even
> > better
> > > if
> > > > > it
> > > > > > > could
> > > > > > > >> > be done by the pac4j deployment contributor.
> > > > > > > >> >
> > > > > > > >> > How and where to do that?
> > > > > > > >> >
> > > > > > > >> > This is an interesting question and one that may have
> > multiple
> > > > > > > solutions:
> > > > > > > >> >
> > > > > > > >> > * we may be able to add the callback filter as part of the
> > > > > original
> > > > > > > >> > provider and just point them to the same URL. This would
> > > require
> > > > > the
> > > > > > > >> > ability to chain them where one knows to not handle a
> > request
> > > > that
> > > > > > is
> > > > > > > >> > really meant for the other.
> > > > > > > >> > * If we truly need a separate URL the way you depict it
> > there
> > > > then
> > > > > > we
> > > > > > > >> will
> > > > > > > >> > need to add a new service which would be unfortunate
> because
> > > it
> > > > > > > couples
> > > > > > > >> the
> > > > > > > >> > use of a certain provider to the use of a particular
> > service.
> > > > > > > >> >
> > > > > > > >> > 3) Configuration
> > > > > > > >> >
> > > > > > > >> > Currently, I hardcoded a FacebookClient for Facebook
> > > > > authentication,
> > > > > > > but
> > > > > > > >> we
> > > > > > > >> > should be able to pass the appropriate client like
> Facebook
> > or
> > > > > SAML.
> > > > > > > >> > Basically, we could do that using filter properties:
> > > > facebook.key
> > > > > +
> > > > > > > >> > facebook.secret means we use Facebook authentication with
> > the
> > > > > > > appropriate
> > > > > > > >> > key and secret for example. Any recommendation?
> > > > > > > >> >
> > > > > > > >> > This is fine. You will add your properties to the provider
> > > > > > properties
> > > > > > > in
> > > > > > > >> > the topology for the pac4j provider.
> > > > > > > >> > You can find example code in the article to blindly add
> all
> > > > > > > properties to
> > > > > > > >> > the filter init params.
> > > > > > > >> >
> > > > > > > >> > Incidentally, the storage of credentials directly in
> config
> > > > files
> > > > > > > should
> > > > > > > >> be
> > > > > > > >> > avoided.
> > > > > > > >> > See the use of the AliasService where such credentials can
> > be
> > > > > > > persisted
> > > > > > > >> in
> > > > > > > >> > a credential store and resolved at runtime.
> > > > > > > >> > I will find examples of this for you - we can go forward
> > with
> > > > > config
> > > > > > > >> based
> > > > > > > >> > values but will need to fix that later.
> > > > > > > >> >
> > > > > > > >> > 4) Web session: I seem to be able to use the web session
> to
> > > sore
> > > > > > data.
> > > > > > > >> > Can you confirm that point?
> > > > > > > >> >
> > > > > > > >> > This is probably not going to work.
> > > > > > > >> > Keep in mind that there may be a cluster of Knox instances
> > > > running
> > > > > > and
> > > > > > > >> the
> > > > > > > >> > session is not replicated across all instances.
> > > > > > > >> > Additionally, keep in mind that your provider will only be
> > > > engaged
> > > > > > on
> > > > > > > the
> > > > > > > >> > first request to KnoxSSO and then not until the
> token/cookie
> > > > > > expires.
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Hi,
As the j2e-pac4j library now supports the required features for Knox, I
restarted working on pac4j - Knox integration.
Though, I have a very strange error. The deployment of the WARs fails with
the following error: *java.lang.IllegalArgumentException: Not supported:
indent-number*
I tried to comment out the line: *transformerFactory.setAttribute(
"indent-number", 2 );* in the XmlGatewayDescriptorExporter class, but it
leads me to another error
(org.apache.hadoop.gateway.deploy.DeploymentException: Failed to finalize
contribution)
Any idea of what's wrong?
Thanks.
Best regards,
Jérôme
2015-11-19 15:21 GMT+01:00 larry mccay <la...@gmail.com>:
> Ahhh - in that case use:
>
> https://localhost:8443/gateway/idp/api/v1/websso
>
> The original resource path for the knoxsso service would have made it more
> like:
>
> https://localhost:8443/gateway/idp/knoxsso/api/v1/websso
>
> Which seems redundant and arbitrary.
> We need to evolve such services to be distinct from typical topologies
> since they aren't really Hadoop cluster specific like typical topologies
> are.
>
> Anyway, try the URL above for your current configuration - that should
> resolve the 404.
>
>
> On Thu, Nov 19, 2015 at 9:09 AM, Jérôme LELEU <le...@gmail.com> wrote:
>
> > Hi,
> >
> > I'm looking forward to read the new documentation you'll write on the
> REST
> > API support.
> >
> > About the 404, I'm not sure to understand why you want me to remove
> "idp/"
> > from the url as the KnoxSSO service is defined in the idp.xml topology:
> > does its url not have a /idp?
> >
> > About the OpenID Connect support, I added it, it's now in pac4j:
> >
> >
> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java#L60
> >
> > Thanks.
> > Best regards,
> > Jérôme
> >
> >
> >
> > 2015-11-18 14:35 GMT+01:00 larry mccay <la...@gmail.com>:
> >
> > > Hi Jérôme -
> > >
> > > Great progress!
> > > You have the flow down perfectly.
> > >
> > > You should be also aware that the SSOCookieProvider is a mechanism for
> > > consuming the SSO cookie for the REST APIs.
> > > There are also integrations for the various Hadoop UIs - most
> components
> > > within the core Hadoop common project have a UI - ie. NameNode,
> DataNode,
> > > YARN ResourceManager, etc. Additionally, ecosystem components such as
> > > Oozie, HBase, Hive, Falcon, Atlas, Ambari, Ranger, etc all have UIs and
> > are
> > > adding or already have support for the SSO cookie being created in
> > KnoxSSO.
> > > Many of these are able to leverage the support added to Hadoop common
> and
> > > get it largely for free.
> > >
> > > REST API support is interesting and immediately relevant to Knox but
> may
> > > actually be secondary to the WebSSO flow for the UIs.
> > > When deployments do want to provide REST API support SSOCookieProvider
> > > enables CORS for allowing javascript API calls from browsers in other
> > > domains to access Hadoop resources. It is also great for development
> > > scenarios like this where we need some consumer to test integrations.
> > >
> > > I am in the process of writing up more docs on these very aspects of
> > > KnoxSSO and JWT cookie support across Hadoop.
> > >
> > > The 404 is related to the configured provider url on the
> > SSOCookieProvider
> > > - remove the "idp/" in the URL.
> > >
> > > That used to be the correct URL but we have since simplified it for the
> > > time being to just be knoxsso.
> > > There is a thread [1] on the dev list that describes that decision and
> > what
> > > we should consider moving forward.
> > >
> > > We will have generic OpenId Connect support as well? This is something
> > that
> > > would be of immediate value.
> > >
> > > [1]
> > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/knox-dev/201511.mbox/%3CCACRbFygkWLJ-tFW612ha_Cr82u%2B41PwDqGx_TWbijbP0g34g%3DQ%40mail.gmail.com%3E
> > >
> > > Thanks!
> > >
> > > --larry
> > >
> > > On Wed, Nov 18, 2015 at 6:11 AM, Jérôme LELEU <le...@gmail.com>
> wrote:
> > >
> > > > Hi,
> > > >
> > > > I've read the documentation and things seem fairly clear to me. Let
> me
> > > > share my understanding and progress:
> > > >
> > > > - the KnoxSSO service is mandatory and the
> > > gateway-provider-security-pac4j
> > > > won't work without it: the KnoxSSO service is responsible for
> creating
> > a
> > > > hadoop-jwt cookie from the current authenticated user (J2E subject).
> > > > - the SSOCookieProvider is also mandatory to protect services and
> > request
> > > > the hadoop-jwt cookie to exist by forwarding to the KnoxSSO endpoint.
> > > >
> > > > I have created two gateways: one for regular Hadoop services which is
> > > > protected by the SSOCookieProvider ->
> > > >
> > > >
> > >
> >
> https://github.com/apache/knox/pull/2/files#diff-128ca80baa2dfd6c2d25de7b8160b9d9R23
> > > > the other one for the KnoxSSO service protected by pac4j ->
> > > >
> > > >
> > >
> >
> https://github.com/apache/knox/pull/2/files#diff-4ea9a9a5ee5968f29982478512a63c54R23
> > > >
> > > > Here is my webflow :
> > > >
> > > > $ curl -ivk "
> > > > https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS"
> > > > 302 Found
> > > > Location:
> > > >
> > > >
> > >
> >
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
> > > >
> > > >
> > > > Calling a regular Hadoop service through the gateway, it is
> redirected
> > to
> > > > the KnoxSSO endpoint (as no hadoop-jwt cookie exists)
> > > >
> > > > $ curl -ivk "
> > > >
> > > >
> > >
> >
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
> > > > "
> > > > 302 Found
> > > > Set-Cookie: pac4j.session.pac4jRequestedUrl="
> > > >
> > > >
> > >
> >
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
> > > > "
> > > > Location:
> > > >
> > > >
> > >
> >
> https://casserverpac4j.herokuapp.com?service=https%3A%2F%2F127.0.0.1%3A8443%2Fgateway%2Fidp%2Fknoxsso%2Fapi%2Fv1%3Fclient_name%3DCasClient
> > > >
> > > >
> > > > Calling the KnosSSO endpoint, the originally requested url is saved
> > into
> > > a
> > > > cookie (the naive implementation I currently use) and it is
> redirected
> > > to a
> > > > CAS server login for authentication (my internal configuration).
> > > >
> > > > After login at the CAS server, the user is redirected back to the
> > > callback
> > > > url, which is the KnoxSSO endpoint.
> > > >
> > > > $ curl -ivk --cookie "pac4j.session.pac4jRequestedUrl=
> > > >
> > > >
> > >
> >
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhbhdfs/v1/tmp?op=LISTSTATUS
> > > > "
> > > > "
> > > >
> > > >
> > >
> >
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?client_name=CasClient&ticket=ST-2-LQ2QLLEdAhBmrCPE1MZA-cas01.example.org
> > > > "
> > > > 302 Found
> > > > Set-Cookie: pac4j.session.pac4jUserProfile=CasProfile#jleleu
> > > > Location:
> > > >
> > > >
> > >
> >
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
> > > >
> > > >
> > > > The fact it's a callback (to finish the login process) is now based
> on
> > > the*
> > > > client_name* parameter (instead of a /callback url). The
> authentication
> > > is
> > > > finished by validating the CAS service ticket and a user profile is
> > > created
> > > > into session and saved in a cookie. It is redirected to the
> originally
> > > > requested url.
> > > >
> > > > $ curl -ivk --cookie
> > "pac4j.session.pac4jUserProfile=CasProfile#jleleu" "
> > > >
> > > >
> > >
> >
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
> > > > "
> > > > 404
> > > >
> > > >
> > > > The call to the KnoxSSO endpoint triggers the pac4j filter, which
> gets
> > > the
> > > > user profile from the cookie, calls the identity adapter and sets the
> > J2E
> > > > subject with the pac4j user profile. Here I get a 404 I don't
> > understand
> > > > and on which I'm currently investigating.
> > > >
> > > > So the callback url issue is solved: the KnoxSSO endpoint is the
> static
> > > url
> > > > used for callback, for any identity provider and the *client_name*
> > > > parameter is the way to know if it is a callback or not.
> > > >
> > > > To save the data in session, I used non-secure cookies for now, it's
> my
> > > > naive implementation. It currently doesn't work properly because as
> we
> > > rely
> > > > on j2e-pac4j, response.sendRedirect occurs and after that, nothing
> can
> > be
> > > > done on the response. So I need to change pac4j v1.8.1-SNAPSHOT and
> > > > j2e-pac4j v1.2.1-SNAPSHOT to be able to plugin a specific session
> > storage
> > > > mechanism (the need has arisen for Play and Shiro as well) ->
> > > > https://github.com/pac4j/pac4j/issues/359
> > > >
> > > > As for configuration, we said that the client configuration will be
> > > defined
> > > > based on properties. As the same mechanism is available for the CAS
> > > server,
> > > > this capability has been moved to pac4j ->
> > > > https://github.com/pac4j/pac4j/issues/357
> > > > It means that currently, Facebook, Twitter, a SAML IdP and a CAS
> server
> > > can
> > > > be created via properties: if you need other identity providers,
> please
> > > > speak up so that I can integrate them.
> > > >
> > > > So I have some more work to do in pac4j and j2e-pac4j before being
> able
> > > to
> > > > go further with Knox. I'll keep you posted.
> > > >
> > > > Thanks.
> > > > Best regards,
> > > > Jérôme
> > > >
> > > >
> > > >
> > > >
> > > > 2015-11-14 19:03 GMT+01:00 larry mccay <lm...@apache.org>:
> > > >
> > > > > Here is a *very* early version of an integration guide for KnoxSSO:
> > > > >
> > > > > http://knox.apache.org/books/knox-0-7-0/knoxsso_integration.html
> > > > >
> > > > > It will walk you through setting up an environment to for using
> > KnoxSSO
> > > > to
> > > > > secure the REST APIs using KnoxSSO cookies and a webflow.
> > > > > The initial environment uses simple browser HTTP basic
> authentication
> > > to
> > > > > protect the WebSSO service which hands out the cookies.
> > > > > This allows us to ensure that KnoxSSO is setup properly without
> > > > introducing
> > > > > a 3rd party provider into the mix first.
> > > > >
> > > > > Once you have it working with Basic Auth then you can switch to
> your
> > > > pac4j
> > > > > provider instead of Shiro to protect the websso service and we can
> > > start
> > > > to
> > > > > work through the integration of your provider.
> > > > >
> > > > > Please understand that this is still a document that is very much a
> > > work
> > > > in
> > > > > progress and has content, formatting and other issues.
> > > > > It should serve as a general guide for you in the short term
> though.
> > > > >
> > > > > Hope it is useful for you!
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Nov 13, 2015 at 9:51 AM, Kevin Minder <
> > > > > kevin.minder@hortonworks.com>
> > > > > wrote:
> > > > >
> > > > > > I’ll add a bit to the logging answer. I created that for several
> > > > > reasons.
> > > > > > 1) Localization as Larry mentions.
> > > > > > 2) It abstract from actual logging provider and you can see for
> > > example
> > > > > > gateway-i18n-logging-sl4j as an alternate integration.
> > > > > > 3) Another important aspect is centralization. It centralizes
> all
> > > > > aspects
> > > > > > of a given message. For example the level for a given message is
> > > kept
> > > > > with
> > > > > > the message to hopefully prevent the message from being
> duplicated
> > > with
> > > > > > potentially different levels. It is also intended to support the
> > > > notion
> > > > > of
> > > > > > Ids and potentially cause/action annotations which are very
> common
> > as
> > > > > > products mature.
> > > > > > 4) Lastly and possibly the most interesting/important from a
> > > developer
> > > > > > perspective is traceability. Once you find the log method for a
> > > given
> > > > > > message you can use the IDE to find all of the palaces where a
> > given
> > > > > > message is used. You can also have the IDE tell you if the
> message
> > > > isn’t
> > > > > > used anymore.
> > > > > >
> > > > > > All that being said the external components we integrate with
> > > certainly
> > > > > > don’t use it. So from that perspective, direct use of log4j if
> > that
> > > is
> > > > > > your choice isn’t going to cause any major problems.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 11/13/15, 8:40 AM, "larry mccay" <lm...@apache.org> wrote:
> > > > > >
> > > > > > >Hi Jérôme -
> > > > > > >
> > > > > > >Great questions and I'm so glad that you are here to ask them.
> > > > > > >
> > > > > > >I think that the set of documentation that I am working on for a
> > > > KnoxSSO
> > > > > > >integration guide will probably answer most of your questions.
> > > > > > >I need to spend a bit more time thinking about the some of it so
> > > that
> > > > I
> > > > > > can
> > > > > > >incorporate that information as well.
> > > > > > >
> > > > > > >The cookie approach is what we use in KnoxSSO. Cookies obviously
> > > have
> > > > > some
> > > > > > >disadvantages but is probably the best alternative for KnoxSSO.
> > > > > > >Something that we need to consider is that KnoxSSO is already
> > > keeping
> > > > > > track
> > > > > > >of the original URL for redirecting back to the requested
> > resource.
> > > > > > >We have to reconcile whether that is separate from the callback
> > > needs
> > > > or
> > > > > > >actually the same thing.
> > > > > > >Having a little trouble wrapping my head around it right now -
> > must
> > > > have
> > > > > > >more coffee. :)
> > > > > > >
> > > > > > >The Messages layer allows for the localization of the actual
> > > messages
> > > > by
> > > > > > >decoupling the messages from the actual runtime code.
> > > > > > >
> > > > > > >I will try and get some docs published as quickly as possible
> for
> > > > > KnoxSSO
> > > > > > >integration.
> > > > > > >
> > > > > > >thanks,
> > > > > > >
> > > > > > >--larry
> > > > > > >
> > > > > > >On Fri, Nov 13, 2015 at 3:27 AM, Jérôme LELEU <leleuj@gmail.com
> >
> > > > wrote:
> > > > > > >
> > > > > > >> Hi,
> > > > > > >>
> > > > > > >> 1) Webflow: I think I get the idea with the KnoxSSO service:
> how
> > > > can I
> > > > > > test
> > > > > > >> everything to ensure pac4j works correctly with it and will be
> > > > usable
> > > > > in
> > > > > > >> Hadoop UIs?
> > > > > > >>
> > > > > > >>
> > > > > > >> 2) Callback url:
> > > > > > >>
> > > > > > >> For indirect clients, pac4j is designed to be called on any
> url,
> > > to
> > > > > save
> > > > > > >> it, to call the identity provider providing a static callback
> > url,
> > > > to
> > > > > be
> > > > > > >> called back on this static callback url and to restore the
> > > > originally
> > > > > > >> requested url.
> > > > > > >>
> > > > > > >> From point 1), I conclude that pac4j will always be used with
> > the
> > > > > > KnoxSSO
> > > > > > >> service (for indirect clients): will KnoxSSO call the pac4j
> > > provider
> > > > > > always
> > > > > > >> on the same url? Can you describe your first flow with urls?
> > > > > > >>
> > > > > > >> Because in that case, I could find a solution where I check
> for
> > > the
> > > > > > >> client_name parameter to define if it's a callback or a first
> > > call.
> > > > > > >>
> > > > > > >> Otherwise, I will need a specific pac4j service.
> > > > > > >>
> > > > > > >>
> > > > > > >> 3) Configuration: no problem here, I will use the
> AliasService.
> > > > > > >>
> > > > > > >>
> > > > > > >> 4) Web session: I really need to put some information in
> session
> > > and
> > > > > > check
> > > > > > >> them on callback: I think I can take the data put in session,
> > save
> > > > > them
> > > > > > in
> > > > > > >> a cookie and restore them before the callback.
> > > > > > >>
> > > > > > >> Is it the recommended solution? Can I re-use the components
> > > > available
> > > > > > for
> > > > > > >> JWT tokens and cookies? And how?
> > > > > > >>
> > > > > > >>
> > > > > > >> 5) Logs: I see in every descriptor the use of Messages and
> > > > > > MessagesFactory:
> > > > > > >> I can't use log4j directly, can I? What's the expected
> benefits
> > > > using
> > > > > > this
> > > > > > >> Messages layer?
> > > > > > >>
> > > > > > >>
> > > > > > >> Thanks.
> > > > > > >> Best regards,
> > > > > > >> Jérôme
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> 2015-11-12 18:14 GMT+01:00 larry mccay <lm...@apache.org>:
> > > > > > >>
> > > > > > >> > Terrific!
> > > > > > >> >
> > > > > > >> > Okay... original questions:
> > > > > > >> >
> > > > > > >> > 1) Webflow: is it normal to get a redirection to Facebook or
> > > > another
> > > > > > IdP
> > > > > > >> > when I made the request (for such a configuration of
> course)?
> > Is
> > > > > this
> > > > > > >> > request meant to happen in a browser? (because it's the use
> > case
> > > > it
> > > > > > was
> > > > > > >> > made for)
> > > > > > >> >
> > > > > > >> > It is normal.
> > > > > > >> > The usecases in which this mechanism would be used would
> > involve
> > > > the
> > > > > > >> > KnoxSSO service/feature.
> > > > > > >> > What we are doing with that is providing a normalization of
> > > > > > >> authentication
> > > > > > >> > mechanisms by federating each auth event through a JWT token
> > > that
> > > > > gets
> > > > > > >> set
> > > > > > >> > as a cookie.
> > > > > > >> > These usecases allow us to provide WebSSO flows for Hadoop
> UIs
> > > and
> > > > > > other
> > > > > > >> > applications and those applications to only ever have to
> know
> > > > about
> > > > > > >> KnoxSSO
> > > > > > >> > tokens.
> > > > > > >> >
> > > > > > >> > What is slightly less normal is that the flow needs to have
> > > > KnoxSSO
> > > > > in
> > > > > > >> the
> > > > > > >> > middle.
> > > > > > >> > For instance:
> > > > > > >> > 1. a browser requests a resource from a KnoxSSO
> participating
> > > > > service
> > > > > > >> > provider
> > > > > > >> > 2. the service provider redirects the browser to KnoxSSO
> since
> > > > there
> > > > > > is
> > > > > > >> no
> > > > > > >> > cookie
> > > > > > >> > 3. KnoxSSO is protected with pac4j provider and redirects
> the
> > > > > browser
> > > > > > to
> > > > > > >> FB
> > > > > > >> > 4. user authenticates to FB
> > > > > > >> > 5. pac4j accepts the FB authentication and normalizes the
> > > security
> > > > > > >> context
> > > > > > >> > to a J2E Subject
> > > > > > >> > 6. WebSSO service then creates a signed JWT token, sets the
> > > cookie
> > > > > and
> > > > > > >> > redirects to the originally requested resource
> > > > > > >> > 7. originally requested resource finds the hadoop-jwt
> cookie,
> > > > > > validates
> > > > > > >> the
> > > > > > >> > token and verifies the signature and grants access to the
> > > resource
> > > > > > >> >
> > > > > > >> > 2) Callback url:
> > > https://localhost:8443/gateway/sandbox/callback
> > > > > > >> currently
> > > > > > >> > returns a 404, so I must declare this url somewhere to be
> > taken
> > > > into
> > > > > > >> > account and pass to the pac4j filter. It would be even
> better
> > if
> > > > it
> > > > > > could
> > > > > > >> > be done by the pac4j deployment contributor.
> > > > > > >> >
> > > > > > >> > How and where to do that?
> > > > > > >> >
> > > > > > >> > This is an interesting question and one that may have
> multiple
> > > > > > solutions:
> > > > > > >> >
> > > > > > >> > * we may be able to add the callback filter as part of the
> > > > original
> > > > > > >> > provider and just point them to the same URL. This would
> > require
> > > > the
> > > > > > >> > ability to chain them where one knows to not handle a
> request
> > > that
> > > > > is
> > > > > > >> > really meant for the other.
> > > > > > >> > * If we truly need a separate URL the way you depict it
> there
> > > then
> > > > > we
> > > > > > >> will
> > > > > > >> > need to add a new service which would be unfortunate because
> > it
> > > > > > couples
> > > > > > >> the
> > > > > > >> > use of a certain provider to the use of a particular
> service.
> > > > > > >> >
> > > > > > >> > 3) Configuration
> > > > > > >> >
> > > > > > >> > Currently, I hardcoded a FacebookClient for Facebook
> > > > authentication,
> > > > > > but
> > > > > > >> we
> > > > > > >> > should be able to pass the appropriate client like Facebook
> or
> > > > SAML.
> > > > > > >> > Basically, we could do that using filter properties:
> > > facebook.key
> > > > +
> > > > > > >> > facebook.secret means we use Facebook authentication with
> the
> > > > > > appropriate
> > > > > > >> > key and secret for example. Any recommendation?
> > > > > > >> >
> > > > > > >> > This is fine. You will add your properties to the provider
> > > > > properties
> > > > > > in
> > > > > > >> > the topology for the pac4j provider.
> > > > > > >> > You can find example code in the article to blindly add all
> > > > > > properties to
> > > > > > >> > the filter init params.
> > > > > > >> >
> > > > > > >> > Incidentally, the storage of credentials directly in config
> > > files
> > > > > > should
> > > > > > >> be
> > > > > > >> > avoided.
> > > > > > >> > See the use of the AliasService where such credentials can
> be
> > > > > > persisted
> > > > > > >> in
> > > > > > >> > a credential store and resolved at runtime.
> > > > > > >> > I will find examples of this for you - we can go forward
> with
> > > > config
> > > > > > >> based
> > > > > > >> > values but will need to fix that later.
> > > > > > >> >
> > > > > > >> > 4) Web session: I seem to be able to use the web session to
> > sore
> > > > > data.
> > > > > > >> > Can you confirm that point?
> > > > > > >> >
> > > > > > >> > This is probably not going to work.
> > > > > > >> > Keep in mind that there may be a cluster of Knox instances
> > > running
> > > > > and
> > > > > > >> the
> > > > > > >> > session is not replicated across all instances.
> > > > > > >> > Additionally, keep in mind that your provider will only be
> > > engaged
> > > > > on
> > > > > > the
> > > > > > >> > first request to KnoxSSO and then not until the token/cookie
> > > > > expires.
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
Ahhh - in that case use:
https://localhost:8443/gateway/idp/api/v1/websso
The original resource path for the knoxsso service would have made it more
like:
https://localhost:8443/gateway/idp/knoxsso/api/v1/websso
Which seems redundant and arbitrary.
We need to evolve such services to be distinct from typical topologies
since they aren't really Hadoop cluster specific like typical topologies
are.
Anyway, try the URL above for your current configuration - that should
resolve the 404.
On Thu, Nov 19, 2015 at 9:09 AM, Jérôme LELEU <le...@gmail.com> wrote:
> Hi,
>
> I'm looking forward to read the new documentation you'll write on the REST
> API support.
>
> About the 404, I'm not sure to understand why you want me to remove "idp/"
> from the url as the KnoxSSO service is defined in the idp.xml topology:
> does its url not have a /idp?
>
> About the OpenID Connect support, I added it, it's now in pac4j:
>
> https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java#L60
>
> Thanks.
> Best regards,
> Jérôme
>
>
>
> 2015-11-18 14:35 GMT+01:00 larry mccay <la...@gmail.com>:
>
> > Hi Jérôme -
> >
> > Great progress!
> > You have the flow down perfectly.
> >
> > You should be also aware that the SSOCookieProvider is a mechanism for
> > consuming the SSO cookie for the REST APIs.
> > There are also integrations for the various Hadoop UIs - most components
> > within the core Hadoop common project have a UI - ie. NameNode, DataNode,
> > YARN ResourceManager, etc. Additionally, ecosystem components such as
> > Oozie, HBase, Hive, Falcon, Atlas, Ambari, Ranger, etc all have UIs and
> are
> > adding or already have support for the SSO cookie being created in
> KnoxSSO.
> > Many of these are able to leverage the support added to Hadoop common and
> > get it largely for free.
> >
> > REST API support is interesting and immediately relevant to Knox but may
> > actually be secondary to the WebSSO flow for the UIs.
> > When deployments do want to provide REST API support SSOCookieProvider
> > enables CORS for allowing javascript API calls from browsers in other
> > domains to access Hadoop resources. It is also great for development
> > scenarios like this where we need some consumer to test integrations.
> >
> > I am in the process of writing up more docs on these very aspects of
> > KnoxSSO and JWT cookie support across Hadoop.
> >
> > The 404 is related to the configured provider url on the
> SSOCookieProvider
> > - remove the "idp/" in the URL.
> >
> > That used to be the correct URL but we have since simplified it for the
> > time being to just be knoxsso.
> > There is a thread [1] on the dev list that describes that decision and
> what
> > we should consider moving forward.
> >
> > We will have generic OpenId Connect support as well? This is something
> that
> > would be of immediate value.
> >
> > [1]
> >
> >
> http://mail-archives.apache.org/mod_mbox/knox-dev/201511.mbox/%3CCACRbFygkWLJ-tFW612ha_Cr82u%2B41PwDqGx_TWbijbP0g34g%3DQ%40mail.gmail.com%3E
> >
> > Thanks!
> >
> > --larry
> >
> > On Wed, Nov 18, 2015 at 6:11 AM, Jérôme LELEU <le...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > I've read the documentation and things seem fairly clear to me. Let me
> > > share my understanding and progress:
> > >
> > > - the KnoxSSO service is mandatory and the
> > gateway-provider-security-pac4j
> > > won't work without it: the KnoxSSO service is responsible for creating
> a
> > > hadoop-jwt cookie from the current authenticated user (J2E subject).
> > > - the SSOCookieProvider is also mandatory to protect services and
> request
> > > the hadoop-jwt cookie to exist by forwarding to the KnoxSSO endpoint.
> > >
> > > I have created two gateways: one for regular Hadoop services which is
> > > protected by the SSOCookieProvider ->
> > >
> > >
> >
> https://github.com/apache/knox/pull/2/files#diff-128ca80baa2dfd6c2d25de7b8160b9d9R23
> > > the other one for the KnoxSSO service protected by pac4j ->
> > >
> > >
> >
> https://github.com/apache/knox/pull/2/files#diff-4ea9a9a5ee5968f29982478512a63c54R23
> > >
> > > Here is my webflow :
> > >
> > > $ curl -ivk "
> > > https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS"
> > > 302 Found
> > > Location:
> > >
> > >
> >
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
> > >
> > >
> > > Calling a regular Hadoop service through the gateway, it is redirected
> to
> > > the KnoxSSO endpoint (as no hadoop-jwt cookie exists)
> > >
> > > $ curl -ivk "
> > >
> > >
> >
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
> > > "
> > > 302 Found
> > > Set-Cookie: pac4j.session.pac4jRequestedUrl="
> > >
> > >
> >
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
> > > "
> > > Location:
> > >
> > >
> >
> https://casserverpac4j.herokuapp.com?service=https%3A%2F%2F127.0.0.1%3A8443%2Fgateway%2Fidp%2Fknoxsso%2Fapi%2Fv1%3Fclient_name%3DCasClient
> > >
> > >
> > > Calling the KnosSSO endpoint, the originally requested url is saved
> into
> > a
> > > cookie (the naive implementation I currently use) and it is redirected
> > to a
> > > CAS server login for authentication (my internal configuration).
> > >
> > > After login at the CAS server, the user is redirected back to the
> > callback
> > > url, which is the KnoxSSO endpoint.
> > >
> > > $ curl -ivk --cookie "pac4j.session.pac4jRequestedUrl=
> > >
> > >
> >
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhbhdfs/v1/tmp?op=LISTSTATUS
> > > "
> > > "
> > >
> > >
> >
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?client_name=CasClient&ticket=ST-2-LQ2QLLEdAhBmrCPE1MZA-cas01.example.org
> > > "
> > > 302 Found
> > > Set-Cookie: pac4j.session.pac4jUserProfile=CasProfile#jleleu
> > > Location:
> > >
> > >
> >
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
> > >
> > >
> > > The fact it's a callback (to finish the login process) is now based on
> > the*
> > > client_name* parameter (instead of a /callback url). The authentication
> > is
> > > finished by validating the CAS service ticket and a user profile is
> > created
> > > into session and saved in a cookie. It is redirected to the originally
> > > requested url.
> > >
> > > $ curl -ivk --cookie
> "pac4j.session.pac4jUserProfile=CasProfile#jleleu" "
> > >
> > >
> >
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
> > > "
> > > 404
> > >
> > >
> > > The call to the KnoxSSO endpoint triggers the pac4j filter, which gets
> > the
> > > user profile from the cookie, calls the identity adapter and sets the
> J2E
> > > subject with the pac4j user profile. Here I get a 404 I don't
> understand
> > > and on which I'm currently investigating.
> > >
> > > So the callback url issue is solved: the KnoxSSO endpoint is the static
> > url
> > > used for callback, for any identity provider and the *client_name*
> > > parameter is the way to know if it is a callback or not.
> > >
> > > To save the data in session, I used non-secure cookies for now, it's my
> > > naive implementation. It currently doesn't work properly because as we
> > rely
> > > on j2e-pac4j, response.sendRedirect occurs and after that, nothing can
> be
> > > done on the response. So I need to change pac4j v1.8.1-SNAPSHOT and
> > > j2e-pac4j v1.2.1-SNAPSHOT to be able to plugin a specific session
> storage
> > > mechanism (the need has arisen for Play and Shiro as well) ->
> > > https://github.com/pac4j/pac4j/issues/359
> > >
> > > As for configuration, we said that the client configuration will be
> > defined
> > > based on properties. As the same mechanism is available for the CAS
> > server,
> > > this capability has been moved to pac4j ->
> > > https://github.com/pac4j/pac4j/issues/357
> > > It means that currently, Facebook, Twitter, a SAML IdP and a CAS server
> > can
> > > be created via properties: if you need other identity providers, please
> > > speak up so that I can integrate them.
> > >
> > > So I have some more work to do in pac4j and j2e-pac4j before being able
> > to
> > > go further with Knox. I'll keep you posted.
> > >
> > > Thanks.
> > > Best regards,
> > > Jérôme
> > >
> > >
> > >
> > >
> > > 2015-11-14 19:03 GMT+01:00 larry mccay <lm...@apache.org>:
> > >
> > > > Here is a *very* early version of an integration guide for KnoxSSO:
> > > >
> > > > http://knox.apache.org/books/knox-0-7-0/knoxsso_integration.html
> > > >
> > > > It will walk you through setting up an environment to for using
> KnoxSSO
> > > to
> > > > secure the REST APIs using KnoxSSO cookies and a webflow.
> > > > The initial environment uses simple browser HTTP basic authentication
> > to
> > > > protect the WebSSO service which hands out the cookies.
> > > > This allows us to ensure that KnoxSSO is setup properly without
> > > introducing
> > > > a 3rd party provider into the mix first.
> > > >
> > > > Once you have it working with Basic Auth then you can switch to your
> > > pac4j
> > > > provider instead of Shiro to protect the websso service and we can
> > start
> > > to
> > > > work through the integration of your provider.
> > > >
> > > > Please understand that this is still a document that is very much a
> > work
> > > in
> > > > progress and has content, formatting and other issues.
> > > > It should serve as a general guide for you in the short term though.
> > > >
> > > > Hope it is useful for you!
> > > >
> > > >
> > > >
> > > > On Fri, Nov 13, 2015 at 9:51 AM, Kevin Minder <
> > > > kevin.minder@hortonworks.com>
> > > > wrote:
> > > >
> > > > > I’ll add a bit to the logging answer. I created that for several
> > > > reasons.
> > > > > 1) Localization as Larry mentions.
> > > > > 2) It abstract from actual logging provider and you can see for
> > example
> > > > > gateway-i18n-logging-sl4j as an alternate integration.
> > > > > 3) Another important aspect is centralization. It centralizes all
> > > > aspects
> > > > > of a given message. For example the level for a given message is
> > kept
> > > > with
> > > > > the message to hopefully prevent the message from being duplicated
> > with
> > > > > potentially different levels. It is also intended to support the
> > > notion
> > > > of
> > > > > Ids and potentially cause/action annotations which are very common
> as
> > > > > products mature.
> > > > > 4) Lastly and possibly the most interesting/important from a
> > developer
> > > > > perspective is traceability. Once you find the log method for a
> > given
> > > > > message you can use the IDE to find all of the palaces where a
> given
> > > > > message is used. You can also have the IDE tell you if the message
> > > isn’t
> > > > > used anymore.
> > > > >
> > > > > All that being said the external components we integrate with
> > certainly
> > > > > don’t use it. So from that perspective, direct use of log4j if
> that
> > is
> > > > > your choice isn’t going to cause any major problems.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 11/13/15, 8:40 AM, "larry mccay" <lm...@apache.org> wrote:
> > > > >
> > > > > >Hi Jérôme -
> > > > > >
> > > > > >Great questions and I'm so glad that you are here to ask them.
> > > > > >
> > > > > >I think that the set of documentation that I am working on for a
> > > KnoxSSO
> > > > > >integration guide will probably answer most of your questions.
> > > > > >I need to spend a bit more time thinking about the some of it so
> > that
> > > I
> > > > > can
> > > > > >incorporate that information as well.
> > > > > >
> > > > > >The cookie approach is what we use in KnoxSSO. Cookies obviously
> > have
> > > > some
> > > > > >disadvantages but is probably the best alternative for KnoxSSO.
> > > > > >Something that we need to consider is that KnoxSSO is already
> > keeping
> > > > > track
> > > > > >of the original URL for redirecting back to the requested
> resource.
> > > > > >We have to reconcile whether that is separate from the callback
> > needs
> > > or
> > > > > >actually the same thing.
> > > > > >Having a little trouble wrapping my head around it right now -
> must
> > > have
> > > > > >more coffee. :)
> > > > > >
> > > > > >The Messages layer allows for the localization of the actual
> > messages
> > > by
> > > > > >decoupling the messages from the actual runtime code.
> > > > > >
> > > > > >I will try and get some docs published as quickly as possible for
> > > > KnoxSSO
> > > > > >integration.
> > > > > >
> > > > > >thanks,
> > > > > >
> > > > > >--larry
> > > > > >
> > > > > >On Fri, Nov 13, 2015 at 3:27 AM, Jérôme LELEU <le...@gmail.com>
> > > wrote:
> > > > > >
> > > > > >> Hi,
> > > > > >>
> > > > > >> 1) Webflow: I think I get the idea with the KnoxSSO service: how
> > > can I
> > > > > test
> > > > > >> everything to ensure pac4j works correctly with it and will be
> > > usable
> > > > in
> > > > > >> Hadoop UIs?
> > > > > >>
> > > > > >>
> > > > > >> 2) Callback url:
> > > > > >>
> > > > > >> For indirect clients, pac4j is designed to be called on any url,
> > to
> > > > save
> > > > > >> it, to call the identity provider providing a static callback
> url,
> > > to
> > > > be
> > > > > >> called back on this static callback url and to restore the
> > > originally
> > > > > >> requested url.
> > > > > >>
> > > > > >> From point 1), I conclude that pac4j will always be used with
> the
> > > > > KnoxSSO
> > > > > >> service (for indirect clients): will KnoxSSO call the pac4j
> > provider
> > > > > always
> > > > > >> on the same url? Can you describe your first flow with urls?
> > > > > >>
> > > > > >> Because in that case, I could find a solution where I check for
> > the
> > > > > >> client_name parameter to define if it's a callback or a first
> > call.
> > > > > >>
> > > > > >> Otherwise, I will need a specific pac4j service.
> > > > > >>
> > > > > >>
> > > > > >> 3) Configuration: no problem here, I will use the AliasService.
> > > > > >>
> > > > > >>
> > > > > >> 4) Web session: I really need to put some information in session
> > and
> > > > > check
> > > > > >> them on callback: I think I can take the data put in session,
> save
> > > > them
> > > > > in
> > > > > >> a cookie and restore them before the callback.
> > > > > >>
> > > > > >> Is it the recommended solution? Can I re-use the components
> > > available
> > > > > for
> > > > > >> JWT tokens and cookies? And how?
> > > > > >>
> > > > > >>
> > > > > >> 5) Logs: I see in every descriptor the use of Messages and
> > > > > MessagesFactory:
> > > > > >> I can't use log4j directly, can I? What's the expected benefits
> > > using
> > > > > this
> > > > > >> Messages layer?
> > > > > >>
> > > > > >>
> > > > > >> Thanks.
> > > > > >> Best regards,
> > > > > >> Jérôme
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> 2015-11-12 18:14 GMT+01:00 larry mccay <lm...@apache.org>:
> > > > > >>
> > > > > >> > Terrific!
> > > > > >> >
> > > > > >> > Okay... original questions:
> > > > > >> >
> > > > > >> > 1) Webflow: is it normal to get a redirection to Facebook or
> > > another
> > > > > IdP
> > > > > >> > when I made the request (for such a configuration of course)?
> Is
> > > > this
> > > > > >> > request meant to happen in a browser? (because it's the use
> case
> > > it
> > > > > was
> > > > > >> > made for)
> > > > > >> >
> > > > > >> > It is normal.
> > > > > >> > The usecases in which this mechanism would be used would
> involve
> > > the
> > > > > >> > KnoxSSO service/feature.
> > > > > >> > What we are doing with that is providing a normalization of
> > > > > >> authentication
> > > > > >> > mechanisms by federating each auth event through a JWT token
> > that
> > > > gets
> > > > > >> set
> > > > > >> > as a cookie.
> > > > > >> > These usecases allow us to provide WebSSO flows for Hadoop UIs
> > and
> > > > > other
> > > > > >> > applications and those applications to only ever have to know
> > > about
> > > > > >> KnoxSSO
> > > > > >> > tokens.
> > > > > >> >
> > > > > >> > What is slightly less normal is that the flow needs to have
> > > KnoxSSO
> > > > in
> > > > > >> the
> > > > > >> > middle.
> > > > > >> > For instance:
> > > > > >> > 1. a browser requests a resource from a KnoxSSO participating
> > > > service
> > > > > >> > provider
> > > > > >> > 2. the service provider redirects the browser to KnoxSSO since
> > > there
> > > > > is
> > > > > >> no
> > > > > >> > cookie
> > > > > >> > 3. KnoxSSO is protected with pac4j provider and redirects the
> > > > browser
> > > > > to
> > > > > >> FB
> > > > > >> > 4. user authenticates to FB
> > > > > >> > 5. pac4j accepts the FB authentication and normalizes the
> > security
> > > > > >> context
> > > > > >> > to a J2E Subject
> > > > > >> > 6. WebSSO service then creates a signed JWT token, sets the
> > cookie
> > > > and
> > > > > >> > redirects to the originally requested resource
> > > > > >> > 7. originally requested resource finds the hadoop-jwt cookie,
> > > > > validates
> > > > > >> the
> > > > > >> > token and verifies the signature and grants access to the
> > resource
> > > > > >> >
> > > > > >> > 2) Callback url:
> > https://localhost:8443/gateway/sandbox/callback
> > > > > >> currently
> > > > > >> > returns a 404, so I must declare this url somewhere to be
> taken
> > > into
> > > > > >> > account and pass to the pac4j filter. It would be even better
> if
> > > it
> > > > > could
> > > > > >> > be done by the pac4j deployment contributor.
> > > > > >> >
> > > > > >> > How and where to do that?
> > > > > >> >
> > > > > >> > This is an interesting question and one that may have multiple
> > > > > solutions:
> > > > > >> >
> > > > > >> > * we may be able to add the callback filter as part of the
> > > original
> > > > > >> > provider and just point them to the same URL. This would
> require
> > > the
> > > > > >> > ability to chain them where one knows to not handle a request
> > that
> > > > is
> > > > > >> > really meant for the other.
> > > > > >> > * If we truly need a separate URL the way you depict it there
> > then
> > > > we
> > > > > >> will
> > > > > >> > need to add a new service which would be unfortunate because
> it
> > > > > couples
> > > > > >> the
> > > > > >> > use of a certain provider to the use of a particular service.
> > > > > >> >
> > > > > >> > 3) Configuration
> > > > > >> >
> > > > > >> > Currently, I hardcoded a FacebookClient for Facebook
> > > authentication,
> > > > > but
> > > > > >> we
> > > > > >> > should be able to pass the appropriate client like Facebook or
> > > SAML.
> > > > > >> > Basically, we could do that using filter properties:
> > facebook.key
> > > +
> > > > > >> > facebook.secret means we use Facebook authentication with the
> > > > > appropriate
> > > > > >> > key and secret for example. Any recommendation?
> > > > > >> >
> > > > > >> > This is fine. You will add your properties to the provider
> > > > properties
> > > > > in
> > > > > >> > the topology for the pac4j provider.
> > > > > >> > You can find example code in the article to blindly add all
> > > > > properties to
> > > > > >> > the filter init params.
> > > > > >> >
> > > > > >> > Incidentally, the storage of credentials directly in config
> > files
> > > > > should
> > > > > >> be
> > > > > >> > avoided.
> > > > > >> > See the use of the AliasService where such credentials can be
> > > > > persisted
> > > > > >> in
> > > > > >> > a credential store and resolved at runtime.
> > > > > >> > I will find examples of this for you - we can go forward with
> > > config
> > > > > >> based
> > > > > >> > values but will need to fix that later.
> > > > > >> >
> > > > > >> > 4) Web session: I seem to be able to use the web session to
> sore
> > > > data.
> > > > > >> > Can you confirm that point?
> > > > > >> >
> > > > > >> > This is probably not going to work.
> > > > > >> > Keep in mind that there may be a cluster of Knox instances
> > running
> > > > and
> > > > > >> the
> > > > > >> > session is not replicated across all instances.
> > > > > >> > Additionally, keep in mind that your provider will only be
> > engaged
> > > > on
> > > > > the
> > > > > >> > first request to KnoxSSO and then not until the token/cookie
> > > > expires.
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Hi,
I'm looking forward to read the new documentation you'll write on the REST
API support.
About the 404, I'm not sure to understand why you want me to remove "idp/"
from the url as the KnoxSSO service is defined in the idp.xml topology:
does its url not have a /idp?
About the OpenID Connect support, I added it, it's now in pac4j:
https://github.com/pac4j/pac4j/blob/master/pac4j-config/src/main/java/org/pac4j/config/client/ConfigPropertiesFactory.java#L60
Thanks.
Best regards,
Jérôme
2015-11-18 14:35 GMT+01:00 larry mccay <la...@gmail.com>:
> Hi Jérôme -
>
> Great progress!
> You have the flow down perfectly.
>
> You should be also aware that the SSOCookieProvider is a mechanism for
> consuming the SSO cookie for the REST APIs.
> There are also integrations for the various Hadoop UIs - most components
> within the core Hadoop common project have a UI - ie. NameNode, DataNode,
> YARN ResourceManager, etc. Additionally, ecosystem components such as
> Oozie, HBase, Hive, Falcon, Atlas, Ambari, Ranger, etc all have UIs and are
> adding or already have support for the SSO cookie being created in KnoxSSO.
> Many of these are able to leverage the support added to Hadoop common and
> get it largely for free.
>
> REST API support is interesting and immediately relevant to Knox but may
> actually be secondary to the WebSSO flow for the UIs.
> When deployments do want to provide REST API support SSOCookieProvider
> enables CORS for allowing javascript API calls from browsers in other
> domains to access Hadoop resources. It is also great for development
> scenarios like this where we need some consumer to test integrations.
>
> I am in the process of writing up more docs on these very aspects of
> KnoxSSO and JWT cookie support across Hadoop.
>
> The 404 is related to the configured provider url on the SSOCookieProvider
> - remove the "idp/" in the URL.
>
> That used to be the correct URL but we have since simplified it for the
> time being to just be knoxsso.
> There is a thread [1] on the dev list that describes that decision and what
> we should consider moving forward.
>
> We will have generic OpenId Connect support as well? This is something that
> would be of immediate value.
>
> [1]
>
> http://mail-archives.apache.org/mod_mbox/knox-dev/201511.mbox/%3CCACRbFygkWLJ-tFW612ha_Cr82u%2B41PwDqGx_TWbijbP0g34g%3DQ%40mail.gmail.com%3E
>
> Thanks!
>
> --larry
>
> On Wed, Nov 18, 2015 at 6:11 AM, Jérôme LELEU <le...@gmail.com> wrote:
>
> > Hi,
> >
> > I've read the documentation and things seem fairly clear to me. Let me
> > share my understanding and progress:
> >
> > - the KnoxSSO service is mandatory and the
> gateway-provider-security-pac4j
> > won't work without it: the KnoxSSO service is responsible for creating a
> > hadoop-jwt cookie from the current authenticated user (J2E subject).
> > - the SSOCookieProvider is also mandatory to protect services and request
> > the hadoop-jwt cookie to exist by forwarding to the KnoxSSO endpoint.
> >
> > I have created two gateways: one for regular Hadoop services which is
> > protected by the SSOCookieProvider ->
> >
> >
> https://github.com/apache/knox/pull/2/files#diff-128ca80baa2dfd6c2d25de7b8160b9d9R23
> > the other one for the KnoxSSO service protected by pac4j ->
> >
> >
> https://github.com/apache/knox/pull/2/files#diff-4ea9a9a5ee5968f29982478512a63c54R23
> >
> > Here is my webflow :
> >
> > $ curl -ivk "
> > https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS"
> > 302 Found
> > Location:
> >
> >
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
> >
> >
> > Calling a regular Hadoop service through the gateway, it is redirected to
> > the KnoxSSO endpoint (as no hadoop-jwt cookie exists)
> >
> > $ curl -ivk "
> >
> >
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
> > "
> > 302 Found
> > Set-Cookie: pac4j.session.pac4jRequestedUrl="
> >
> >
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
> > "
> > Location:
> >
> >
> https://casserverpac4j.herokuapp.com?service=https%3A%2F%2F127.0.0.1%3A8443%2Fgateway%2Fidp%2Fknoxsso%2Fapi%2Fv1%3Fclient_name%3DCasClient
> >
> >
> > Calling the KnosSSO endpoint, the originally requested url is saved into
> a
> > cookie (the naive implementation I currently use) and it is redirected
> to a
> > CAS server login for authentication (my internal configuration).
> >
> > After login at the CAS server, the user is redirected back to the
> callback
> > url, which is the KnoxSSO endpoint.
> >
> > $ curl -ivk --cookie "pac4j.session.pac4jRequestedUrl=
> >
> >
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhbhdfs/v1/tmp?op=LISTSTATUS
> > "
> > "
> >
> >
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?client_name=CasClient&ticket=ST-2-LQ2QLLEdAhBmrCPE1MZA-cas01.example.org
> > "
> > 302 Found
> > Set-Cookie: pac4j.session.pac4jUserProfile=CasProfile#jleleu
> > Location:
> >
> >
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
> >
> >
> > The fact it's a callback (to finish the login process) is now based on
> the*
> > client_name* parameter (instead of a /callback url). The authentication
> is
> > finished by validating the CAS service ticket and a user profile is
> created
> > into session and saved in a cookie. It is redirected to the originally
> > requested url.
> >
> > $ curl -ivk --cookie "pac4j.session.pac4jUserProfile=CasProfile#jleleu" "
> >
> >
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
> > "
> > 404
> >
> >
> > The call to the KnoxSSO endpoint triggers the pac4j filter, which gets
> the
> > user profile from the cookie, calls the identity adapter and sets the J2E
> > subject with the pac4j user profile. Here I get a 404 I don't understand
> > and on which I'm currently investigating.
> >
> > So the callback url issue is solved: the KnoxSSO endpoint is the static
> url
> > used for callback, for any identity provider and the *client_name*
> > parameter is the way to know if it is a callback or not.
> >
> > To save the data in session, I used non-secure cookies for now, it's my
> > naive implementation. It currently doesn't work properly because as we
> rely
> > on j2e-pac4j, response.sendRedirect occurs and after that, nothing can be
> > done on the response. So I need to change pac4j v1.8.1-SNAPSHOT and
> > j2e-pac4j v1.2.1-SNAPSHOT to be able to plugin a specific session storage
> > mechanism (the need has arisen for Play and Shiro as well) ->
> > https://github.com/pac4j/pac4j/issues/359
> >
> > As for configuration, we said that the client configuration will be
> defined
> > based on properties. As the same mechanism is available for the CAS
> server,
> > this capability has been moved to pac4j ->
> > https://github.com/pac4j/pac4j/issues/357
> > It means that currently, Facebook, Twitter, a SAML IdP and a CAS server
> can
> > be created via properties: if you need other identity providers, please
> > speak up so that I can integrate them.
> >
> > So I have some more work to do in pac4j and j2e-pac4j before being able
> to
> > go further with Knox. I'll keep you posted.
> >
> > Thanks.
> > Best regards,
> > Jérôme
> >
> >
> >
> >
> > 2015-11-14 19:03 GMT+01:00 larry mccay <lm...@apache.org>:
> >
> > > Here is a *very* early version of an integration guide for KnoxSSO:
> > >
> > > http://knox.apache.org/books/knox-0-7-0/knoxsso_integration.html
> > >
> > > It will walk you through setting up an environment to for using KnoxSSO
> > to
> > > secure the REST APIs using KnoxSSO cookies and a webflow.
> > > The initial environment uses simple browser HTTP basic authentication
> to
> > > protect the WebSSO service which hands out the cookies.
> > > This allows us to ensure that KnoxSSO is setup properly without
> > introducing
> > > a 3rd party provider into the mix first.
> > >
> > > Once you have it working with Basic Auth then you can switch to your
> > pac4j
> > > provider instead of Shiro to protect the websso service and we can
> start
> > to
> > > work through the integration of your provider.
> > >
> > > Please understand that this is still a document that is very much a
> work
> > in
> > > progress and has content, formatting and other issues.
> > > It should serve as a general guide for you in the short term though.
> > >
> > > Hope it is useful for you!
> > >
> > >
> > >
> > > On Fri, Nov 13, 2015 at 9:51 AM, Kevin Minder <
> > > kevin.minder@hortonworks.com>
> > > wrote:
> > >
> > > > I’ll add a bit to the logging answer. I created that for several
> > > reasons.
> > > > 1) Localization as Larry mentions.
> > > > 2) It abstract from actual logging provider and you can see for
> example
> > > > gateway-i18n-logging-sl4j as an alternate integration.
> > > > 3) Another important aspect is centralization. It centralizes all
> > > aspects
> > > > of a given message. For example the level for a given message is
> kept
> > > with
> > > > the message to hopefully prevent the message from being duplicated
> with
> > > > potentially different levels. It is also intended to support the
> > notion
> > > of
> > > > Ids and potentially cause/action annotations which are very common as
> > > > products mature.
> > > > 4) Lastly and possibly the most interesting/important from a
> developer
> > > > perspective is traceability. Once you find the log method for a
> given
> > > > message you can use the IDE to find all of the palaces where a given
> > > > message is used. You can also have the IDE tell you if the message
> > isn’t
> > > > used anymore.
> > > >
> > > > All that being said the external components we integrate with
> certainly
> > > > don’t use it. So from that perspective, direct use of log4j if that
> is
> > > > your choice isn’t going to cause any major problems.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 11/13/15, 8:40 AM, "larry mccay" <lm...@apache.org> wrote:
> > > >
> > > > >Hi Jérôme -
> > > > >
> > > > >Great questions and I'm so glad that you are here to ask them.
> > > > >
> > > > >I think that the set of documentation that I am working on for a
> > KnoxSSO
> > > > >integration guide will probably answer most of your questions.
> > > > >I need to spend a bit more time thinking about the some of it so
> that
> > I
> > > > can
> > > > >incorporate that information as well.
> > > > >
> > > > >The cookie approach is what we use in KnoxSSO. Cookies obviously
> have
> > > some
> > > > >disadvantages but is probably the best alternative for KnoxSSO.
> > > > >Something that we need to consider is that KnoxSSO is already
> keeping
> > > > track
> > > > >of the original URL for redirecting back to the requested resource.
> > > > >We have to reconcile whether that is separate from the callback
> needs
> > or
> > > > >actually the same thing.
> > > > >Having a little trouble wrapping my head around it right now - must
> > have
> > > > >more coffee. :)
> > > > >
> > > > >The Messages layer allows for the localization of the actual
> messages
> > by
> > > > >decoupling the messages from the actual runtime code.
> > > > >
> > > > >I will try and get some docs published as quickly as possible for
> > > KnoxSSO
> > > > >integration.
> > > > >
> > > > >thanks,
> > > > >
> > > > >--larry
> > > > >
> > > > >On Fri, Nov 13, 2015 at 3:27 AM, Jérôme LELEU <le...@gmail.com>
> > wrote:
> > > > >
> > > > >> Hi,
> > > > >>
> > > > >> 1) Webflow: I think I get the idea with the KnoxSSO service: how
> > can I
> > > > test
> > > > >> everything to ensure pac4j works correctly with it and will be
> > usable
> > > in
> > > > >> Hadoop UIs?
> > > > >>
> > > > >>
> > > > >> 2) Callback url:
> > > > >>
> > > > >> For indirect clients, pac4j is designed to be called on any url,
> to
> > > save
> > > > >> it, to call the identity provider providing a static callback url,
> > to
> > > be
> > > > >> called back on this static callback url and to restore the
> > originally
> > > > >> requested url.
> > > > >>
> > > > >> From point 1), I conclude that pac4j will always be used with the
> > > > KnoxSSO
> > > > >> service (for indirect clients): will KnoxSSO call the pac4j
> provider
> > > > always
> > > > >> on the same url? Can you describe your first flow with urls?
> > > > >>
> > > > >> Because in that case, I could find a solution where I check for
> the
> > > > >> client_name parameter to define if it's a callback or a first
> call.
> > > > >>
> > > > >> Otherwise, I will need a specific pac4j service.
> > > > >>
> > > > >>
> > > > >> 3) Configuration: no problem here, I will use the AliasService.
> > > > >>
> > > > >>
> > > > >> 4) Web session: I really need to put some information in session
> and
> > > > check
> > > > >> them on callback: I think I can take the data put in session, save
> > > them
> > > > in
> > > > >> a cookie and restore them before the callback.
> > > > >>
> > > > >> Is it the recommended solution? Can I re-use the components
> > available
> > > > for
> > > > >> JWT tokens and cookies? And how?
> > > > >>
> > > > >>
> > > > >> 5) Logs: I see in every descriptor the use of Messages and
> > > > MessagesFactory:
> > > > >> I can't use log4j directly, can I? What's the expected benefits
> > using
> > > > this
> > > > >> Messages layer?
> > > > >>
> > > > >>
> > > > >> Thanks.
> > > > >> Best regards,
> > > > >> Jérôme
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> 2015-11-12 18:14 GMT+01:00 larry mccay <lm...@apache.org>:
> > > > >>
> > > > >> > Terrific!
> > > > >> >
> > > > >> > Okay... original questions:
> > > > >> >
> > > > >> > 1) Webflow: is it normal to get a redirection to Facebook or
> > another
> > > > IdP
> > > > >> > when I made the request (for such a configuration of course)? Is
> > > this
> > > > >> > request meant to happen in a browser? (because it's the use case
> > it
> > > > was
> > > > >> > made for)
> > > > >> >
> > > > >> > It is normal.
> > > > >> > The usecases in which this mechanism would be used would involve
> > the
> > > > >> > KnoxSSO service/feature.
> > > > >> > What we are doing with that is providing a normalization of
> > > > >> authentication
> > > > >> > mechanisms by federating each auth event through a JWT token
> that
> > > gets
> > > > >> set
> > > > >> > as a cookie.
> > > > >> > These usecases allow us to provide WebSSO flows for Hadoop UIs
> and
> > > > other
> > > > >> > applications and those applications to only ever have to know
> > about
> > > > >> KnoxSSO
> > > > >> > tokens.
> > > > >> >
> > > > >> > What is slightly less normal is that the flow needs to have
> > KnoxSSO
> > > in
> > > > >> the
> > > > >> > middle.
> > > > >> > For instance:
> > > > >> > 1. a browser requests a resource from a KnoxSSO participating
> > > service
> > > > >> > provider
> > > > >> > 2. the service provider redirects the browser to KnoxSSO since
> > there
> > > > is
> > > > >> no
> > > > >> > cookie
> > > > >> > 3. KnoxSSO is protected with pac4j provider and redirects the
> > > browser
> > > > to
> > > > >> FB
> > > > >> > 4. user authenticates to FB
> > > > >> > 5. pac4j accepts the FB authentication and normalizes the
> security
> > > > >> context
> > > > >> > to a J2E Subject
> > > > >> > 6. WebSSO service then creates a signed JWT token, sets the
> cookie
> > > and
> > > > >> > redirects to the originally requested resource
> > > > >> > 7. originally requested resource finds the hadoop-jwt cookie,
> > > > validates
> > > > >> the
> > > > >> > token and verifies the signature and grants access to the
> resource
> > > > >> >
> > > > >> > 2) Callback url:
> https://localhost:8443/gateway/sandbox/callback
> > > > >> currently
> > > > >> > returns a 404, so I must declare this url somewhere to be taken
> > into
> > > > >> > account and pass to the pac4j filter. It would be even better if
> > it
> > > > could
> > > > >> > be done by the pac4j deployment contributor.
> > > > >> >
> > > > >> > How and where to do that?
> > > > >> >
> > > > >> > This is an interesting question and one that may have multiple
> > > > solutions:
> > > > >> >
> > > > >> > * we may be able to add the callback filter as part of the
> > original
> > > > >> > provider and just point them to the same URL. This would require
> > the
> > > > >> > ability to chain them where one knows to not handle a request
> that
> > > is
> > > > >> > really meant for the other.
> > > > >> > * If we truly need a separate URL the way you depict it there
> then
> > > we
> > > > >> will
> > > > >> > need to add a new service which would be unfortunate because it
> > > > couples
> > > > >> the
> > > > >> > use of a certain provider to the use of a particular service.
> > > > >> >
> > > > >> > 3) Configuration
> > > > >> >
> > > > >> > Currently, I hardcoded a FacebookClient for Facebook
> > authentication,
> > > > but
> > > > >> we
> > > > >> > should be able to pass the appropriate client like Facebook or
> > SAML.
> > > > >> > Basically, we could do that using filter properties:
> facebook.key
> > +
> > > > >> > facebook.secret means we use Facebook authentication with the
> > > > appropriate
> > > > >> > key and secret for example. Any recommendation?
> > > > >> >
> > > > >> > This is fine. You will add your properties to the provider
> > > properties
> > > > in
> > > > >> > the topology for the pac4j provider.
> > > > >> > You can find example code in the article to blindly add all
> > > > properties to
> > > > >> > the filter init params.
> > > > >> >
> > > > >> > Incidentally, the storage of credentials directly in config
> files
> > > > should
> > > > >> be
> > > > >> > avoided.
> > > > >> > See the use of the AliasService where such credentials can be
> > > > persisted
> > > > >> in
> > > > >> > a credential store and resolved at runtime.
> > > > >> > I will find examples of this for you - we can go forward with
> > config
> > > > >> based
> > > > >> > values but will need to fix that later.
> > > > >> >
> > > > >> > 4) Web session: I seem to be able to use the web session to sore
> > > data.
> > > > >> > Can you confirm that point?
> > > > >> >
> > > > >> > This is probably not going to work.
> > > > >> > Keep in mind that there may be a cluster of Knox instances
> running
> > > and
> > > > >> the
> > > > >> > session is not replicated across all instances.
> > > > >> > Additionally, keep in mind that your provider will only be
> engaged
> > > on
> > > > the
> > > > >> > first request to KnoxSSO and then not until the token/cookie
> > > expires.
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >>
> > > >
> > >
> >
>
Re: pac4j and Apache Knox
Posted by larry mccay <la...@gmail.com>.
Hi Jérôme -
Great progress!
You have the flow down perfectly.
You should be also aware that the SSOCookieProvider is a mechanism for
consuming the SSO cookie for the REST APIs.
There are also integrations for the various Hadoop UIs - most components
within the core Hadoop common project have a UI - ie. NameNode, DataNode,
YARN ResourceManager, etc. Additionally, ecosystem components such as
Oozie, HBase, Hive, Falcon, Atlas, Ambari, Ranger, etc all have UIs and are
adding or already have support for the SSO cookie being created in KnoxSSO.
Many of these are able to leverage the support added to Hadoop common and
get it largely for free.
REST API support is interesting and immediately relevant to Knox but may
actually be secondary to the WebSSO flow for the UIs.
When deployments do want to provide REST API support SSOCookieProvider
enables CORS for allowing javascript API calls from browsers in other
domains to access Hadoop resources. It is also great for development
scenarios like this where we need some consumer to test integrations.
I am in the process of writing up more docs on these very aspects of
KnoxSSO and JWT cookie support across Hadoop.
The 404 is related to the configured provider url on the SSOCookieProvider
- remove the "idp/" in the URL.
That used to be the correct URL but we have since simplified it for the
time being to just be knoxsso.
There is a thread [1] on the dev list that describes that decision and what
we should consider moving forward.
We will have generic OpenId Connect support as well? This is something that
would be of immediate value.
[1]
http://mail-archives.apache.org/mod_mbox/knox-dev/201511.mbox/%3CCACRbFygkWLJ-tFW612ha_Cr82u%2B41PwDqGx_TWbijbP0g34g%3DQ%40mail.gmail.com%3E
Thanks!
--larry
On Wed, Nov 18, 2015 at 6:11 AM, Jérôme LELEU <le...@gmail.com> wrote:
> Hi,
>
> I've read the documentation and things seem fairly clear to me. Let me
> share my understanding and progress:
>
> - the KnoxSSO service is mandatory and the gateway-provider-security-pac4j
> won't work without it: the KnoxSSO service is responsible for creating a
> hadoop-jwt cookie from the current authenticated user (J2E subject).
> - the SSOCookieProvider is also mandatory to protect services and request
> the hadoop-jwt cookie to exist by forwarding to the KnoxSSO endpoint.
>
> I have created two gateways: one for regular Hadoop services which is
> protected by the SSOCookieProvider ->
>
> https://github.com/apache/knox/pull/2/files#diff-128ca80baa2dfd6c2d25de7b8160b9d9R23
> the other one for the KnoxSSO service protected by pac4j ->
>
> https://github.com/apache/knox/pull/2/files#diff-4ea9a9a5ee5968f29982478512a63c54R23
>
> Here is my webflow :
>
> $ curl -ivk "
> https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS"
> 302 Found
> Location:
>
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
>
>
> Calling a regular Hadoop service through the gateway, it is redirected to
> the KnoxSSO endpoint (as no hadoop-jwt cookie exists)
>
> $ curl -ivk "
>
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
> "
> 302 Found
> Set-Cookie: pac4j.session.pac4jRequestedUrl="
>
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
> "
> Location:
>
> https://casserverpac4j.herokuapp.com?service=https%3A%2F%2F127.0.0.1%3A8443%2Fgateway%2Fidp%2Fknoxsso%2Fapi%2Fv1%3Fclient_name%3DCasClient
>
>
> Calling the KnosSSO endpoint, the originally requested url is saved into a
> cookie (the naive implementation I currently use) and it is redirected to a
> CAS server login for authentication (my internal configuration).
>
> After login at the CAS server, the user is redirected back to the callback
> url, which is the KnoxSSO endpoint.
>
> $ curl -ivk --cookie "pac4j.session.pac4jRequestedUrl=
>
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhbhdfs/v1/tmp?op=LISTSTATUS
> "
> "
>
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?client_name=CasClient&ticket=ST-2-LQ2QLLEdAhBmrCPE1MZA-cas01.example.org
> "
> 302 Found
> Set-Cookie: pac4j.session.pac4jUserProfile=CasProfile#jleleu
> Location:
>
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
>
>
> The fact it's a callback (to finish the login process) is now based on the*
> client_name* parameter (instead of a /callback url). The authentication is
> finished by validating the CAS service ticket and a user profile is created
> into session and saved in a cookie. It is redirected to the originally
> requested url.
>
> $ curl -ivk --cookie "pac4j.session.pac4jUserProfile=CasProfile#jleleu" "
>
> https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
> "
> 404
>
>
> The call to the KnoxSSO endpoint triggers the pac4j filter, which gets the
> user profile from the cookie, calls the identity adapter and sets the J2E
> subject with the pac4j user profile. Here I get a 404 I don't understand
> and on which I'm currently investigating.
>
> So the callback url issue is solved: the KnoxSSO endpoint is the static url
> used for callback, for any identity provider and the *client_name*
> parameter is the way to know if it is a callback or not.
>
> To save the data in session, I used non-secure cookies for now, it's my
> naive implementation. It currently doesn't work properly because as we rely
> on j2e-pac4j, response.sendRedirect occurs and after that, nothing can be
> done on the response. So I need to change pac4j v1.8.1-SNAPSHOT and
> j2e-pac4j v1.2.1-SNAPSHOT to be able to plugin a specific session storage
> mechanism (the need has arisen for Play and Shiro as well) ->
> https://github.com/pac4j/pac4j/issues/359
>
> As for configuration, we said that the client configuration will be defined
> based on properties. As the same mechanism is available for the CAS server,
> this capability has been moved to pac4j ->
> https://github.com/pac4j/pac4j/issues/357
> It means that currently, Facebook, Twitter, a SAML IdP and a CAS server can
> be created via properties: if you need other identity providers, please
> speak up so that I can integrate them.
>
> So I have some more work to do in pac4j and j2e-pac4j before being able to
> go further with Knox. I'll keep you posted.
>
> Thanks.
> Best regards,
> Jérôme
>
>
>
>
> 2015-11-14 19:03 GMT+01:00 larry mccay <lm...@apache.org>:
>
> > Here is a *very* early version of an integration guide for KnoxSSO:
> >
> > http://knox.apache.org/books/knox-0-7-0/knoxsso_integration.html
> >
> > It will walk you through setting up an environment to for using KnoxSSO
> to
> > secure the REST APIs using KnoxSSO cookies and a webflow.
> > The initial environment uses simple browser HTTP basic authentication to
> > protect the WebSSO service which hands out the cookies.
> > This allows us to ensure that KnoxSSO is setup properly without
> introducing
> > a 3rd party provider into the mix first.
> >
> > Once you have it working with Basic Auth then you can switch to your
> pac4j
> > provider instead of Shiro to protect the websso service and we can start
> to
> > work through the integration of your provider.
> >
> > Please understand that this is still a document that is very much a work
> in
> > progress and has content, formatting and other issues.
> > It should serve as a general guide for you in the short term though.
> >
> > Hope it is useful for you!
> >
> >
> >
> > On Fri, Nov 13, 2015 at 9:51 AM, Kevin Minder <
> > kevin.minder@hortonworks.com>
> > wrote:
> >
> > > I’ll add a bit to the logging answer. I created that for several
> > reasons.
> > > 1) Localization as Larry mentions.
> > > 2) It abstract from actual logging provider and you can see for example
> > > gateway-i18n-logging-sl4j as an alternate integration.
> > > 3) Another important aspect is centralization. It centralizes all
> > aspects
> > > of a given message. For example the level for a given message is kept
> > with
> > > the message to hopefully prevent the message from being duplicated with
> > > potentially different levels. It is also intended to support the
> notion
> > of
> > > Ids and potentially cause/action annotations which are very common as
> > > products mature.
> > > 4) Lastly and possibly the most interesting/important from a developer
> > > perspective is traceability. Once you find the log method for a given
> > > message you can use the IDE to find all of the palaces where a given
> > > message is used. You can also have the IDE tell you if the message
> isn’t
> > > used anymore.
> > >
> > > All that being said the external components we integrate with certainly
> > > don’t use it. So from that perspective, direct use of log4j if that is
> > > your choice isn’t going to cause any major problems.
> > >
> > >
> > >
> > >
> > >
> > > On 11/13/15, 8:40 AM, "larry mccay" <lm...@apache.org> wrote:
> > >
> > > >Hi Jérôme -
> > > >
> > > >Great questions and I'm so glad that you are here to ask them.
> > > >
> > > >I think that the set of documentation that I am working on for a
> KnoxSSO
> > > >integration guide will probably answer most of your questions.
> > > >I need to spend a bit more time thinking about the some of it so that
> I
> > > can
> > > >incorporate that information as well.
> > > >
> > > >The cookie approach is what we use in KnoxSSO. Cookies obviously have
> > some
> > > >disadvantages but is probably the best alternative for KnoxSSO.
> > > >Something that we need to consider is that KnoxSSO is already keeping
> > > track
> > > >of the original URL for redirecting back to the requested resource.
> > > >We have to reconcile whether that is separate from the callback needs
> or
> > > >actually the same thing.
> > > >Having a little trouble wrapping my head around it right now - must
> have
> > > >more coffee. :)
> > > >
> > > >The Messages layer allows for the localization of the actual messages
> by
> > > >decoupling the messages from the actual runtime code.
> > > >
> > > >I will try and get some docs published as quickly as possible for
> > KnoxSSO
> > > >integration.
> > > >
> > > >thanks,
> > > >
> > > >--larry
> > > >
> > > >On Fri, Nov 13, 2015 at 3:27 AM, Jérôme LELEU <le...@gmail.com>
> wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> 1) Webflow: I think I get the idea with the KnoxSSO service: how
> can I
> > > test
> > > >> everything to ensure pac4j works correctly with it and will be
> usable
> > in
> > > >> Hadoop UIs?
> > > >>
> > > >>
> > > >> 2) Callback url:
> > > >>
> > > >> For indirect clients, pac4j is designed to be called on any url, to
> > save
> > > >> it, to call the identity provider providing a static callback url,
> to
> > be
> > > >> called back on this static callback url and to restore the
> originally
> > > >> requested url.
> > > >>
> > > >> From point 1), I conclude that pac4j will always be used with the
> > > KnoxSSO
> > > >> service (for indirect clients): will KnoxSSO call the pac4j provider
> > > always
> > > >> on the same url? Can you describe your first flow with urls?
> > > >>
> > > >> Because in that case, I could find a solution where I check for the
> > > >> client_name parameter to define if it's a callback or a first call.
> > > >>
> > > >> Otherwise, I will need a specific pac4j service.
> > > >>
> > > >>
> > > >> 3) Configuration: no problem here, I will use the AliasService.
> > > >>
> > > >>
> > > >> 4) Web session: I really need to put some information in session and
> > > check
> > > >> them on callback: I think I can take the data put in session, save
> > them
> > > in
> > > >> a cookie and restore them before the callback.
> > > >>
> > > >> Is it the recommended solution? Can I re-use the components
> available
> > > for
> > > >> JWT tokens and cookies? And how?
> > > >>
> > > >>
> > > >> 5) Logs: I see in every descriptor the use of Messages and
> > > MessagesFactory:
> > > >> I can't use log4j directly, can I? What's the expected benefits
> using
> > > this
> > > >> Messages layer?
> > > >>
> > > >>
> > > >> Thanks.
> > > >> Best regards,
> > > >> Jérôme
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> 2015-11-12 18:14 GMT+01:00 larry mccay <lm...@apache.org>:
> > > >>
> > > >> > Terrific!
> > > >> >
> > > >> > Okay... original questions:
> > > >> >
> > > >> > 1) Webflow: is it normal to get a redirection to Facebook or
> another
> > > IdP
> > > >> > when I made the request (for such a configuration of course)? Is
> > this
> > > >> > request meant to happen in a browser? (because it's the use case
> it
> > > was
> > > >> > made for)
> > > >> >
> > > >> > It is normal.
> > > >> > The usecases in which this mechanism would be used would involve
> the
> > > >> > KnoxSSO service/feature.
> > > >> > What we are doing with that is providing a normalization of
> > > >> authentication
> > > >> > mechanisms by federating each auth event through a JWT token that
> > gets
> > > >> set
> > > >> > as a cookie.
> > > >> > These usecases allow us to provide WebSSO flows for Hadoop UIs and
> > > other
> > > >> > applications and those applications to only ever have to know
> about
> > > >> KnoxSSO
> > > >> > tokens.
> > > >> >
> > > >> > What is slightly less normal is that the flow needs to have
> KnoxSSO
> > in
> > > >> the
> > > >> > middle.
> > > >> > For instance:
> > > >> > 1. a browser requests a resource from a KnoxSSO participating
> > service
> > > >> > provider
> > > >> > 2. the service provider redirects the browser to KnoxSSO since
> there
> > > is
> > > >> no
> > > >> > cookie
> > > >> > 3. KnoxSSO is protected with pac4j provider and redirects the
> > browser
> > > to
> > > >> FB
> > > >> > 4. user authenticates to FB
> > > >> > 5. pac4j accepts the FB authentication and normalizes the security
> > > >> context
> > > >> > to a J2E Subject
> > > >> > 6. WebSSO service then creates a signed JWT token, sets the cookie
> > and
> > > >> > redirects to the originally requested resource
> > > >> > 7. originally requested resource finds the hadoop-jwt cookie,
> > > validates
> > > >> the
> > > >> > token and verifies the signature and grants access to the resource
> > > >> >
> > > >> > 2) Callback url: https://localhost:8443/gateway/sandbox/callback
> > > >> currently
> > > >> > returns a 404, so I must declare this url somewhere to be taken
> into
> > > >> > account and pass to the pac4j filter. It would be even better if
> it
> > > could
> > > >> > be done by the pac4j deployment contributor.
> > > >> >
> > > >> > How and where to do that?
> > > >> >
> > > >> > This is an interesting question and one that may have multiple
> > > solutions:
> > > >> >
> > > >> > * we may be able to add the callback filter as part of the
> original
> > > >> > provider and just point them to the same URL. This would require
> the
> > > >> > ability to chain them where one knows to not handle a request that
> > is
> > > >> > really meant for the other.
> > > >> > * If we truly need a separate URL the way you depict it there then
> > we
> > > >> will
> > > >> > need to add a new service which would be unfortunate because it
> > > couples
> > > >> the
> > > >> > use of a certain provider to the use of a particular service.
> > > >> >
> > > >> > 3) Configuration
> > > >> >
> > > >> > Currently, I hardcoded a FacebookClient for Facebook
> authentication,
> > > but
> > > >> we
> > > >> > should be able to pass the appropriate client like Facebook or
> SAML.
> > > >> > Basically, we could do that using filter properties: facebook.key
> +
> > > >> > facebook.secret means we use Facebook authentication with the
> > > appropriate
> > > >> > key and secret for example. Any recommendation?
> > > >> >
> > > >> > This is fine. You will add your properties to the provider
> > properties
> > > in
> > > >> > the topology for the pac4j provider.
> > > >> > You can find example code in the article to blindly add all
> > > properties to
> > > >> > the filter init params.
> > > >> >
> > > >> > Incidentally, the storage of credentials directly in config files
> > > should
> > > >> be
> > > >> > avoided.
> > > >> > See the use of the AliasService where such credentials can be
> > > persisted
> > > >> in
> > > >> > a credential store and resolved at runtime.
> > > >> > I will find examples of this for you - we can go forward with
> config
> > > >> based
> > > >> > values but will need to fix that later.
> > > >> >
> > > >> > 4) Web session: I seem to be able to use the web session to sore
> > data.
> > > >> > Can you confirm that point?
> > > >> >
> > > >> > This is probably not going to work.
> > > >> > Keep in mind that there may be a cluster of Knox instances running
> > and
> > > >> the
> > > >> > session is not replicated across all instances.
> > > >> > Additionally, keep in mind that your provider will only be engaged
> > on
> > > the
> > > >> > first request to KnoxSSO and then not until the token/cookie
> > expires.
> > > >> >
> > > >> >
> > > >> >
> > > >>
> > >
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Hi,
I've read the documentation and things seem fairly clear to me. Let me
share my understanding and progress:
- the KnoxSSO service is mandatory and the gateway-provider-security-pac4j
won't work without it: the KnoxSSO service is responsible for creating a
hadoop-jwt cookie from the current authenticated user (J2E subject).
- the SSOCookieProvider is also mandatory to protect services and request
the hadoop-jwt cookie to exist by forwarding to the KnoxSSO endpoint.
I have created two gateways: one for regular Hadoop services which is
protected by the SSOCookieProvider ->
https://github.com/apache/knox/pull/2/files#diff-128ca80baa2dfd6c2d25de7b8160b9d9R23
the other one for the KnoxSSO service protected by pac4j ->
https://github.com/apache/knox/pull/2/files#diff-4ea9a9a5ee5968f29982478512a63c54R23
Here is my webflow :
$ curl -ivk "
https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS"
302 Found
Location:
https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
Calling a regular Hadoop service through the gateway, it is redirected to
the KnoxSSO endpoint (as no hadoop-jwt cookie exists)
$ curl -ivk "
https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
"
302 Found
Set-Cookie: pac4j.session.pac4jRequestedUrl="
https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
"
Location:
https://casserverpac4j.herokuapp.com?service=https%3A%2F%2F127.0.0.1%3A8443%2Fgateway%2Fidp%2Fknoxsso%2Fapi%2Fv1%3Fclient_name%3DCasClient
Calling the KnosSSO endpoint, the originally requested url is saved into a
cookie (the naive implementation I currently use) and it is redirected to a
CAS server login for authentication (my internal configuration).
After login at the CAS server, the user is redirected back to the callback
url, which is the KnoxSSO endpoint.
$ curl -ivk --cookie "pac4j.session.pac4jRequestedUrl=
https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhbhdfs/v1/tmp?op=LISTSTATUS"
"
https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?client_name=CasClient&ticket=ST-2-LQ2QLLEdAhBmrCPE1MZA-cas01.example.org
"
302 Found
Set-Cookie: pac4j.session.pac4jUserProfile=CasProfile#jleleu
Location:
https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
The fact it's a callback (to finish the login process) is now based on the*
client_name* parameter (instead of a /callback url). The authentication is
finished by validating the CAS service ticket and a user profile is created
into session and saved in a cookie. It is redirected to the originally
requested url.
$ curl -ivk --cookie "pac4j.session.pac4jUserProfile=CasProfile#jleleu" "
https://127.0.0.1:8443/gateway/idp/knoxsso/api/v1?originalUrl=https://127.0.0.1:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
"
404
The call to the KnoxSSO endpoint triggers the pac4j filter, which gets the
user profile from the cookie, calls the identity adapter and sets the J2E
subject with the pac4j user profile. Here I get a 404 I don't understand
and on which I'm currently investigating.
So the callback url issue is solved: the KnoxSSO endpoint is the static url
used for callback, for any identity provider and the *client_name*
parameter is the way to know if it is a callback or not.
To save the data in session, I used non-secure cookies for now, it's my
naive implementation. It currently doesn't work properly because as we rely
on j2e-pac4j, response.sendRedirect occurs and after that, nothing can be
done on the response. So I need to change pac4j v1.8.1-SNAPSHOT and
j2e-pac4j v1.2.1-SNAPSHOT to be able to plugin a specific session storage
mechanism (the need has arisen for Play and Shiro as well) ->
https://github.com/pac4j/pac4j/issues/359
As for configuration, we said that the client configuration will be defined
based on properties. As the same mechanism is available for the CAS server,
this capability has been moved to pac4j ->
https://github.com/pac4j/pac4j/issues/357
It means that currently, Facebook, Twitter, a SAML IdP and a CAS server can
be created via properties: if you need other identity providers, please
speak up so that I can integrate them.
So I have some more work to do in pac4j and j2e-pac4j before being able to
go further with Knox. I'll keep you posted.
Thanks.
Best regards,
Jérôme
2015-11-14 19:03 GMT+01:00 larry mccay <lm...@apache.org>:
> Here is a *very* early version of an integration guide for KnoxSSO:
>
> http://knox.apache.org/books/knox-0-7-0/knoxsso_integration.html
>
> It will walk you through setting up an environment to for using KnoxSSO to
> secure the REST APIs using KnoxSSO cookies and a webflow.
> The initial environment uses simple browser HTTP basic authentication to
> protect the WebSSO service which hands out the cookies.
> This allows us to ensure that KnoxSSO is setup properly without introducing
> a 3rd party provider into the mix first.
>
> Once you have it working with Basic Auth then you can switch to your pac4j
> provider instead of Shiro to protect the websso service and we can start to
> work through the integration of your provider.
>
> Please understand that this is still a document that is very much a work in
> progress and has content, formatting and other issues.
> It should serve as a general guide for you in the short term though.
>
> Hope it is useful for you!
>
>
>
> On Fri, Nov 13, 2015 at 9:51 AM, Kevin Minder <
> kevin.minder@hortonworks.com>
> wrote:
>
> > I’ll add a bit to the logging answer. I created that for several
> reasons.
> > 1) Localization as Larry mentions.
> > 2) It abstract from actual logging provider and you can see for example
> > gateway-i18n-logging-sl4j as an alternate integration.
> > 3) Another important aspect is centralization. It centralizes all
> aspects
> > of a given message. For example the level for a given message is kept
> with
> > the message to hopefully prevent the message from being duplicated with
> > potentially different levels. It is also intended to support the notion
> of
> > Ids and potentially cause/action annotations which are very common as
> > products mature.
> > 4) Lastly and possibly the most interesting/important from a developer
> > perspective is traceability. Once you find the log method for a given
> > message you can use the IDE to find all of the palaces where a given
> > message is used. You can also have the IDE tell you if the message isn’t
> > used anymore.
> >
> > All that being said the external components we integrate with certainly
> > don’t use it. So from that perspective, direct use of log4j if that is
> > your choice isn’t going to cause any major problems.
> >
> >
> >
> >
> >
> > On 11/13/15, 8:40 AM, "larry mccay" <lm...@apache.org> wrote:
> >
> > >Hi Jérôme -
> > >
> > >Great questions and I'm so glad that you are here to ask them.
> > >
> > >I think that the set of documentation that I am working on for a KnoxSSO
> > >integration guide will probably answer most of your questions.
> > >I need to spend a bit more time thinking about the some of it so that I
> > can
> > >incorporate that information as well.
> > >
> > >The cookie approach is what we use in KnoxSSO. Cookies obviously have
> some
> > >disadvantages but is probably the best alternative for KnoxSSO.
> > >Something that we need to consider is that KnoxSSO is already keeping
> > track
> > >of the original URL for redirecting back to the requested resource.
> > >We have to reconcile whether that is separate from the callback needs or
> > >actually the same thing.
> > >Having a little trouble wrapping my head around it right now - must have
> > >more coffee. :)
> > >
> > >The Messages layer allows for the localization of the actual messages by
> > >decoupling the messages from the actual runtime code.
> > >
> > >I will try and get some docs published as quickly as possible for
> KnoxSSO
> > >integration.
> > >
> > >thanks,
> > >
> > >--larry
> > >
> > >On Fri, Nov 13, 2015 at 3:27 AM, Jérôme LELEU <le...@gmail.com> wrote:
> > >
> > >> Hi,
> > >>
> > >> 1) Webflow: I think I get the idea with the KnoxSSO service: how can I
> > test
> > >> everything to ensure pac4j works correctly with it and will be usable
> in
> > >> Hadoop UIs?
> > >>
> > >>
> > >> 2) Callback url:
> > >>
> > >> For indirect clients, pac4j is designed to be called on any url, to
> save
> > >> it, to call the identity provider providing a static callback url, to
> be
> > >> called back on this static callback url and to restore the originally
> > >> requested url.
> > >>
> > >> From point 1), I conclude that pac4j will always be used with the
> > KnoxSSO
> > >> service (for indirect clients): will KnoxSSO call the pac4j provider
> > always
> > >> on the same url? Can you describe your first flow with urls?
> > >>
> > >> Because in that case, I could find a solution where I check for the
> > >> client_name parameter to define if it's a callback or a first call.
> > >>
> > >> Otherwise, I will need a specific pac4j service.
> > >>
> > >>
> > >> 3) Configuration: no problem here, I will use the AliasService.
> > >>
> > >>
> > >> 4) Web session: I really need to put some information in session and
> > check
> > >> them on callback: I think I can take the data put in session, save
> them
> > in
> > >> a cookie and restore them before the callback.
> > >>
> > >> Is it the recommended solution? Can I re-use the components available
> > for
> > >> JWT tokens and cookies? And how?
> > >>
> > >>
> > >> 5) Logs: I see in every descriptor the use of Messages and
> > MessagesFactory:
> > >> I can't use log4j directly, can I? What's the expected benefits using
> > this
> > >> Messages layer?
> > >>
> > >>
> > >> Thanks.
> > >> Best regards,
> > >> Jérôme
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> 2015-11-12 18:14 GMT+01:00 larry mccay <lm...@apache.org>:
> > >>
> > >> > Terrific!
> > >> >
> > >> > Okay... original questions:
> > >> >
> > >> > 1) Webflow: is it normal to get a redirection to Facebook or another
> > IdP
> > >> > when I made the request (for such a configuration of course)? Is
> this
> > >> > request meant to happen in a browser? (because it's the use case it
> > was
> > >> > made for)
> > >> >
> > >> > It is normal.
> > >> > The usecases in which this mechanism would be used would involve the
> > >> > KnoxSSO service/feature.
> > >> > What we are doing with that is providing a normalization of
> > >> authentication
> > >> > mechanisms by federating each auth event through a JWT token that
> gets
> > >> set
> > >> > as a cookie.
> > >> > These usecases allow us to provide WebSSO flows for Hadoop UIs and
> > other
> > >> > applications and those applications to only ever have to know about
> > >> KnoxSSO
> > >> > tokens.
> > >> >
> > >> > What is slightly less normal is that the flow needs to have KnoxSSO
> in
> > >> the
> > >> > middle.
> > >> > For instance:
> > >> > 1. a browser requests a resource from a KnoxSSO participating
> service
> > >> > provider
> > >> > 2. the service provider redirects the browser to KnoxSSO since there
> > is
> > >> no
> > >> > cookie
> > >> > 3. KnoxSSO is protected with pac4j provider and redirects the
> browser
> > to
> > >> FB
> > >> > 4. user authenticates to FB
> > >> > 5. pac4j accepts the FB authentication and normalizes the security
> > >> context
> > >> > to a J2E Subject
> > >> > 6. WebSSO service then creates a signed JWT token, sets the cookie
> and
> > >> > redirects to the originally requested resource
> > >> > 7. originally requested resource finds the hadoop-jwt cookie,
> > validates
> > >> the
> > >> > token and verifies the signature and grants access to the resource
> > >> >
> > >> > 2) Callback url: https://localhost:8443/gateway/sandbox/callback
> > >> currently
> > >> > returns a 404, so I must declare this url somewhere to be taken into
> > >> > account and pass to the pac4j filter. It would be even better if it
> > could
> > >> > be done by the pac4j deployment contributor.
> > >> >
> > >> > How and where to do that?
> > >> >
> > >> > This is an interesting question and one that may have multiple
> > solutions:
> > >> >
> > >> > * we may be able to add the callback filter as part of the original
> > >> > provider and just point them to the same URL. This would require the
> > >> > ability to chain them where one knows to not handle a request that
> is
> > >> > really meant for the other.
> > >> > * If we truly need a separate URL the way you depict it there then
> we
> > >> will
> > >> > need to add a new service which would be unfortunate because it
> > couples
> > >> the
> > >> > use of a certain provider to the use of a particular service.
> > >> >
> > >> > 3) Configuration
> > >> >
> > >> > Currently, I hardcoded a FacebookClient for Facebook authentication,
> > but
> > >> we
> > >> > should be able to pass the appropriate client like Facebook or SAML.
> > >> > Basically, we could do that using filter properties: facebook.key +
> > >> > facebook.secret means we use Facebook authentication with the
> > appropriate
> > >> > key and secret for example. Any recommendation?
> > >> >
> > >> > This is fine. You will add your properties to the provider
> properties
> > in
> > >> > the topology for the pac4j provider.
> > >> > You can find example code in the article to blindly add all
> > properties to
> > >> > the filter init params.
> > >> >
> > >> > Incidentally, the storage of credentials directly in config files
> > should
> > >> be
> > >> > avoided.
> > >> > See the use of the AliasService where such credentials can be
> > persisted
> > >> in
> > >> > a credential store and resolved at runtime.
> > >> > I will find examples of this for you - we can go forward with config
> > >> based
> > >> > values but will need to fix that later.
> > >> >
> > >> > 4) Web session: I seem to be able to use the web session to sore
> data.
> > >> > Can you confirm that point?
> > >> >
> > >> > This is probably not going to work.
> > >> > Keep in mind that there may be a cluster of Knox instances running
> and
> > >> the
> > >> > session is not replicated across all instances.
> > >> > Additionally, keep in mind that your provider will only be engaged
> on
> > the
> > >> > first request to KnoxSSO and then not until the token/cookie
> expires.
> > >> >
> > >> >
> > >> >
> > >>
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Hi,
Thanks for providing this early documentation. I will study it carefully.
Best regards,
Jérôme
2015-11-14 19:03 GMT+01:00 larry mccay <lm...@apache.org>:
> Here is a *very* early version of an integration guide for KnoxSSO:
>
> http://knox.apache.org/books/knox-0-7-0/knoxsso_integration.html
>
> It will walk you through setting up an environment to for using KnoxSSO to
> secure the REST APIs using KnoxSSO cookies and a webflow.
> The initial environment uses simple browser HTTP basic authentication to
> protect the WebSSO service which hands out the cookies.
> This allows us to ensure that KnoxSSO is setup properly without introducing
> a 3rd party provider into the mix first.
>
> Once you have it working with Basic Auth then you can switch to your pac4j
> provider instead of Shiro to protect the websso service and we can start to
> work through the integration of your provider.
>
> Please understand that this is still a document that is very much a work in
> progress and has content, formatting and other issues.
> It should serve as a general guide for you in the short term though.
>
> Hope it is useful for you!
>
>
>
> On Fri, Nov 13, 2015 at 9:51 AM, Kevin Minder <
> kevin.minder@hortonworks.com>
> wrote:
>
> > I’ll add a bit to the logging answer. I created that for several
> reasons.
> > 1) Localization as Larry mentions.
> > 2) It abstract from actual logging provider and you can see for example
> > gateway-i18n-logging-sl4j as an alternate integration.
> > 3) Another important aspect is centralization. It centralizes all
> aspects
> > of a given message. For example the level for a given message is kept
> with
> > the message to hopefully prevent the message from being duplicated with
> > potentially different levels. It is also intended to support the notion
> of
> > Ids and potentially cause/action annotations which are very common as
> > products mature.
> > 4) Lastly and possibly the most interesting/important from a developer
> > perspective is traceability. Once you find the log method for a given
> > message you can use the IDE to find all of the palaces where a given
> > message is used. You can also have the IDE tell you if the message isn’t
> > used anymore.
> >
> > All that being said the external components we integrate with certainly
> > don’t use it. So from that perspective, direct use of log4j if that is
> > your choice isn’t going to cause any major problems.
> >
> >
> >
> >
> >
> > On 11/13/15, 8:40 AM, "larry mccay" <lm...@apache.org> wrote:
> >
> > >Hi Jérôme -
> > >
> > >Great questions and I'm so glad that you are here to ask them.
> > >
> > >I think that the set of documentation that I am working on for a KnoxSSO
> > >integration guide will probably answer most of your questions.
> > >I need to spend a bit more time thinking about the some of it so that I
> > can
> > >incorporate that information as well.
> > >
> > >The cookie approach is what we use in KnoxSSO. Cookies obviously have
> some
> > >disadvantages but is probably the best alternative for KnoxSSO.
> > >Something that we need to consider is that KnoxSSO is already keeping
> > track
> > >of the original URL for redirecting back to the requested resource.
> > >We have to reconcile whether that is separate from the callback needs or
> > >actually the same thing.
> > >Having a little trouble wrapping my head around it right now - must have
> > >more coffee. :)
> > >
> > >The Messages layer allows for the localization of the actual messages by
> > >decoupling the messages from the actual runtime code.
> > >
> > >I will try and get some docs published as quickly as possible for
> KnoxSSO
> > >integration.
> > >
> > >thanks,
> > >
> > >--larry
> > >
> > >On Fri, Nov 13, 2015 at 3:27 AM, Jérôme LELEU <le...@gmail.com> wrote:
> > >
> > >> Hi,
> > >>
> > >> 1) Webflow: I think I get the idea with the KnoxSSO service: how can I
> > test
> > >> everything to ensure pac4j works correctly with it and will be usable
> in
> > >> Hadoop UIs?
> > >>
> > >>
> > >> 2) Callback url:
> > >>
> > >> For indirect clients, pac4j is designed to be called on any url, to
> save
> > >> it, to call the identity provider providing a static callback url, to
> be
> > >> called back on this static callback url and to restore the originally
> > >> requested url.
> > >>
> > >> From point 1), I conclude that pac4j will always be used with the
> > KnoxSSO
> > >> service (for indirect clients): will KnoxSSO call the pac4j provider
> > always
> > >> on the same url? Can you describe your first flow with urls?
> > >>
> > >> Because in that case, I could find a solution where I check for the
> > >> client_name parameter to define if it's a callback or a first call.
> > >>
> > >> Otherwise, I will need a specific pac4j service.
> > >>
> > >>
> > >> 3) Configuration: no problem here, I will use the AliasService.
> > >>
> > >>
> > >> 4) Web session: I really need to put some information in session and
> > check
> > >> them on callback: I think I can take the data put in session, save
> them
> > in
> > >> a cookie and restore them before the callback.
> > >>
> > >> Is it the recommended solution? Can I re-use the components available
> > for
> > >> JWT tokens and cookies? And how?
> > >>
> > >>
> > >> 5) Logs: I see in every descriptor the use of Messages and
> > MessagesFactory:
> > >> I can't use log4j directly, can I? What's the expected benefits using
> > this
> > >> Messages layer?
> > >>
> > >>
> > >> Thanks.
> > >> Best regards,
> > >> Jérôme
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> 2015-11-12 18:14 GMT+01:00 larry mccay <lm...@apache.org>:
> > >>
> > >> > Terrific!
> > >> >
> > >> > Okay... original questions:
> > >> >
> > >> > 1) Webflow: is it normal to get a redirection to Facebook or another
> > IdP
> > >> > when I made the request (for such a configuration of course)? Is
> this
> > >> > request meant to happen in a browser? (because it's the use case it
> > was
> > >> > made for)
> > >> >
> > >> > It is normal.
> > >> > The usecases in which this mechanism would be used would involve the
> > >> > KnoxSSO service/feature.
> > >> > What we are doing with that is providing a normalization of
> > >> authentication
> > >> > mechanisms by federating each auth event through a JWT token that
> gets
> > >> set
> > >> > as a cookie.
> > >> > These usecases allow us to provide WebSSO flows for Hadoop UIs and
> > other
> > >> > applications and those applications to only ever have to know about
> > >> KnoxSSO
> > >> > tokens.
> > >> >
> > >> > What is slightly less normal is that the flow needs to have KnoxSSO
> in
> > >> the
> > >> > middle.
> > >> > For instance:
> > >> > 1. a browser requests a resource from a KnoxSSO participating
> service
> > >> > provider
> > >> > 2. the service provider redirects the browser to KnoxSSO since there
> > is
> > >> no
> > >> > cookie
> > >> > 3. KnoxSSO is protected with pac4j provider and redirects the
> browser
> > to
> > >> FB
> > >> > 4. user authenticates to FB
> > >> > 5. pac4j accepts the FB authentication and normalizes the security
> > >> context
> > >> > to a J2E Subject
> > >> > 6. WebSSO service then creates a signed JWT token, sets the cookie
> and
> > >> > redirects to the originally requested resource
> > >> > 7. originally requested resource finds the hadoop-jwt cookie,
> > validates
> > >> the
> > >> > token and verifies the signature and grants access to the resource
> > >> >
> > >> > 2) Callback url: https://localhost:8443/gateway/sandbox/callback
> > >> currently
> > >> > returns a 404, so I must declare this url somewhere to be taken into
> > >> > account and pass to the pac4j filter. It would be even better if it
> > could
> > >> > be done by the pac4j deployment contributor.
> > >> >
> > >> > How and where to do that?
> > >> >
> > >> > This is an interesting question and one that may have multiple
> > solutions:
> > >> >
> > >> > * we may be able to add the callback filter as part of the original
> > >> > provider and just point them to the same URL. This would require the
> > >> > ability to chain them where one knows to not handle a request that
> is
> > >> > really meant for the other.
> > >> > * If we truly need a separate URL the way you depict it there then
> we
> > >> will
> > >> > need to add a new service which would be unfortunate because it
> > couples
> > >> the
> > >> > use of a certain provider to the use of a particular service.
> > >> >
> > >> > 3) Configuration
> > >> >
> > >> > Currently, I hardcoded a FacebookClient for Facebook authentication,
> > but
> > >> we
> > >> > should be able to pass the appropriate client like Facebook or SAML.
> > >> > Basically, we could do that using filter properties: facebook.key +
> > >> > facebook.secret means we use Facebook authentication with the
> > appropriate
> > >> > key and secret for example. Any recommendation?
> > >> >
> > >> > This is fine. You will add your properties to the provider
> properties
> > in
> > >> > the topology for the pac4j provider.
> > >> > You can find example code in the article to blindly add all
> > properties to
> > >> > the filter init params.
> > >> >
> > >> > Incidentally, the storage of credentials directly in config files
> > should
> > >> be
> > >> > avoided.
> > >> > See the use of the AliasService where such credentials can be
> > persisted
> > >> in
> > >> > a credential store and resolved at runtime.
> > >> > I will find examples of this for you - we can go forward with config
> > >> based
> > >> > values but will need to fix that later.
> > >> >
> > >> > 4) Web session: I seem to be able to use the web session to sore
> data.
> > >> > Can you confirm that point?
> > >> >
> > >> > This is probably not going to work.
> > >> > Keep in mind that there may be a cluster of Knox instances running
> and
> > >> the
> > >> > session is not replicated across all instances.
> > >> > Additionally, keep in mind that your provider will only be engaged
> on
> > the
> > >> > first request to KnoxSSO and then not until the token/cookie
> expires.
> > >> >
> > >> >
> > >> >
> > >>
> >
>
Re: pac4j and Apache Knox
Posted by larry mccay <lm...@apache.org>.
Here is a *very* early version of an integration guide for KnoxSSO:
http://knox.apache.org/books/knox-0-7-0/knoxsso_integration.html
It will walk you through setting up an environment to for using KnoxSSO to
secure the REST APIs using KnoxSSO cookies and a webflow.
The initial environment uses simple browser HTTP basic authentication to
protect the WebSSO service which hands out the cookies.
This allows us to ensure that KnoxSSO is setup properly without introducing
a 3rd party provider into the mix first.
Once you have it working with Basic Auth then you can switch to your pac4j
provider instead of Shiro to protect the websso service and we can start to
work through the integration of your provider.
Please understand that this is still a document that is very much a work in
progress and has content, formatting and other issues.
It should serve as a general guide for you in the short term though.
Hope it is useful for you!
On Fri, Nov 13, 2015 at 9:51 AM, Kevin Minder <ke...@hortonworks.com>
wrote:
> I’ll add a bit to the logging answer. I created that for several reasons.
> 1) Localization as Larry mentions.
> 2) It abstract from actual logging provider and you can see for example
> gateway-i18n-logging-sl4j as an alternate integration.
> 3) Another important aspect is centralization. It centralizes all aspects
> of a given message. For example the level for a given message is kept with
> the message to hopefully prevent the message from being duplicated with
> potentially different levels. It is also intended to support the notion of
> Ids and potentially cause/action annotations which are very common as
> products mature.
> 4) Lastly and possibly the most interesting/important from a developer
> perspective is traceability. Once you find the log method for a given
> message you can use the IDE to find all of the palaces where a given
> message is used. You can also have the IDE tell you if the message isn’t
> used anymore.
>
> All that being said the external components we integrate with certainly
> don’t use it. So from that perspective, direct use of log4j if that is
> your choice isn’t going to cause any major problems.
>
>
>
>
>
> On 11/13/15, 8:40 AM, "larry mccay" <lm...@apache.org> wrote:
>
> >Hi Jérôme -
> >
> >Great questions and I'm so glad that you are here to ask them.
> >
> >I think that the set of documentation that I am working on for a KnoxSSO
> >integration guide will probably answer most of your questions.
> >I need to spend a bit more time thinking about the some of it so that I
> can
> >incorporate that information as well.
> >
> >The cookie approach is what we use in KnoxSSO. Cookies obviously have some
> >disadvantages but is probably the best alternative for KnoxSSO.
> >Something that we need to consider is that KnoxSSO is already keeping
> track
> >of the original URL for redirecting back to the requested resource.
> >We have to reconcile whether that is separate from the callback needs or
> >actually the same thing.
> >Having a little trouble wrapping my head around it right now - must have
> >more coffee. :)
> >
> >The Messages layer allows for the localization of the actual messages by
> >decoupling the messages from the actual runtime code.
> >
> >I will try and get some docs published as quickly as possible for KnoxSSO
> >integration.
> >
> >thanks,
> >
> >--larry
> >
> >On Fri, Nov 13, 2015 at 3:27 AM, Jérôme LELEU <le...@gmail.com> wrote:
> >
> >> Hi,
> >>
> >> 1) Webflow: I think I get the idea with the KnoxSSO service: how can I
> test
> >> everything to ensure pac4j works correctly with it and will be usable in
> >> Hadoop UIs?
> >>
> >>
> >> 2) Callback url:
> >>
> >> For indirect clients, pac4j is designed to be called on any url, to save
> >> it, to call the identity provider providing a static callback url, to be
> >> called back on this static callback url and to restore the originally
> >> requested url.
> >>
> >> From point 1), I conclude that pac4j will always be used with the
> KnoxSSO
> >> service (for indirect clients): will KnoxSSO call the pac4j provider
> always
> >> on the same url? Can you describe your first flow with urls?
> >>
> >> Because in that case, I could find a solution where I check for the
> >> client_name parameter to define if it's a callback or a first call.
> >>
> >> Otherwise, I will need a specific pac4j service.
> >>
> >>
> >> 3) Configuration: no problem here, I will use the AliasService.
> >>
> >>
> >> 4) Web session: I really need to put some information in session and
> check
> >> them on callback: I think I can take the data put in session, save them
> in
> >> a cookie and restore them before the callback.
> >>
> >> Is it the recommended solution? Can I re-use the components available
> for
> >> JWT tokens and cookies? And how?
> >>
> >>
> >> 5) Logs: I see in every descriptor the use of Messages and
> MessagesFactory:
> >> I can't use log4j directly, can I? What's the expected benefits using
> this
> >> Messages layer?
> >>
> >>
> >> Thanks.
> >> Best regards,
> >> Jérôme
> >>
> >>
> >>
> >>
> >>
> >> 2015-11-12 18:14 GMT+01:00 larry mccay <lm...@apache.org>:
> >>
> >> > Terrific!
> >> >
> >> > Okay... original questions:
> >> >
> >> > 1) Webflow: is it normal to get a redirection to Facebook or another
> IdP
> >> > when I made the request (for such a configuration of course)? Is this
> >> > request meant to happen in a browser? (because it's the use case it
> was
> >> > made for)
> >> >
> >> > It is normal.
> >> > The usecases in which this mechanism would be used would involve the
> >> > KnoxSSO service/feature.
> >> > What we are doing with that is providing a normalization of
> >> authentication
> >> > mechanisms by federating each auth event through a JWT token that gets
> >> set
> >> > as a cookie.
> >> > These usecases allow us to provide WebSSO flows for Hadoop UIs and
> other
> >> > applications and those applications to only ever have to know about
> >> KnoxSSO
> >> > tokens.
> >> >
> >> > What is slightly less normal is that the flow needs to have KnoxSSO in
> >> the
> >> > middle.
> >> > For instance:
> >> > 1. a browser requests a resource from a KnoxSSO participating service
> >> > provider
> >> > 2. the service provider redirects the browser to KnoxSSO since there
> is
> >> no
> >> > cookie
> >> > 3. KnoxSSO is protected with pac4j provider and redirects the browser
> to
> >> FB
> >> > 4. user authenticates to FB
> >> > 5. pac4j accepts the FB authentication and normalizes the security
> >> context
> >> > to a J2E Subject
> >> > 6. WebSSO service then creates a signed JWT token, sets the cookie and
> >> > redirects to the originally requested resource
> >> > 7. originally requested resource finds the hadoop-jwt cookie,
> validates
> >> the
> >> > token and verifies the signature and grants access to the resource
> >> >
> >> > 2) Callback url: https://localhost:8443/gateway/sandbox/callback
> >> currently
> >> > returns a 404, so I must declare this url somewhere to be taken into
> >> > account and pass to the pac4j filter. It would be even better if it
> could
> >> > be done by the pac4j deployment contributor.
> >> >
> >> > How and where to do that?
> >> >
> >> > This is an interesting question and one that may have multiple
> solutions:
> >> >
> >> > * we may be able to add the callback filter as part of the original
> >> > provider and just point them to the same URL. This would require the
> >> > ability to chain them where one knows to not handle a request that is
> >> > really meant for the other.
> >> > * If we truly need a separate URL the way you depict it there then we
> >> will
> >> > need to add a new service which would be unfortunate because it
> couples
> >> the
> >> > use of a certain provider to the use of a particular service.
> >> >
> >> > 3) Configuration
> >> >
> >> > Currently, I hardcoded a FacebookClient for Facebook authentication,
> but
> >> we
> >> > should be able to pass the appropriate client like Facebook or SAML.
> >> > Basically, we could do that using filter properties: facebook.key +
> >> > facebook.secret means we use Facebook authentication with the
> appropriate
> >> > key and secret for example. Any recommendation?
> >> >
> >> > This is fine. You will add your properties to the provider properties
> in
> >> > the topology for the pac4j provider.
> >> > You can find example code in the article to blindly add all
> properties to
> >> > the filter init params.
> >> >
> >> > Incidentally, the storage of credentials directly in config files
> should
> >> be
> >> > avoided.
> >> > See the use of the AliasService where such credentials can be
> persisted
> >> in
> >> > a credential store and resolved at runtime.
> >> > I will find examples of this for you - we can go forward with config
> >> based
> >> > values but will need to fix that later.
> >> >
> >> > 4) Web session: I seem to be able to use the web session to sore data.
> >> > Can you confirm that point?
> >> >
> >> > This is probably not going to work.
> >> > Keep in mind that there may be a cluster of Knox instances running and
> >> the
> >> > session is not replicated across all instances.
> >> > Additionally, keep in mind that your provider will only be engaged on
> the
> >> > first request to KnoxSSO and then not until the token/cookie expires.
> >> >
> >> >
> >> >
> >>
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Hi,
Thanks for the explanations.
I'll use the MessageFactory in the gateway-provider-security-pac4j and
log4j for all pac4j components.
Best regards,
Jérôme
2015-11-13 15:51 GMT+01:00 Kevin Minder <ke...@hortonworks.com>:
> I’ll add a bit to the logging answer. I created that for several reasons.
> 1) Localization as Larry mentions.
> 2) It abstract from actual logging provider and you can see for example
> gateway-i18n-logging-sl4j as an alternate integration.
> 3) Another important aspect is centralization. It centralizes all aspects
> of a given message. For example the level for a given message is kept with
> the message to hopefully prevent the message from being duplicated with
> potentially different levels. It is also intended to support the notion of
> Ids and potentially cause/action annotations which are very common as
> products mature.
> 4) Lastly and possibly the most interesting/important from a developer
> perspective is traceability. Once you find the log method for a given
> message you can use the IDE to find all of the palaces where a given
> message is used. You can also have the IDE tell you if the message isn’t
> used anymore.
>
> All that being said the external components we integrate with certainly
> don’t use it. So from that perspective, direct use of log4j if that is
> your choice isn’t going to cause any major problems.
>
>
>
>
>
> On 11/13/15, 8:40 AM, "larry mccay" <lm...@apache.org> wrote:
>
> >Hi Jérôme -
> >
> >Great questions and I'm so glad that you are here to ask them.
> >
> >I think that the set of documentation that I am working on for a KnoxSSO
> >integration guide will probably answer most of your questions.
> >I need to spend a bit more time thinking about the some of it so that I
> can
> >incorporate that information as well.
> >
> >The cookie approach is what we use in KnoxSSO. Cookies obviously have some
> >disadvantages but is probably the best alternative for KnoxSSO.
> >Something that we need to consider is that KnoxSSO is already keeping
> track
> >of the original URL for redirecting back to the requested resource.
> >We have to reconcile whether that is separate from the callback needs or
> >actually the same thing.
> >Having a little trouble wrapping my head around it right now - must have
> >more coffee. :)
> >
> >The Messages layer allows for the localization of the actual messages by
> >decoupling the messages from the actual runtime code.
> >
> >I will try and get some docs published as quickly as possible for KnoxSSO
> >integration.
> >
> >thanks,
> >
> >--larry
> >
> >On Fri, Nov 13, 2015 at 3:27 AM, Jérôme LELEU <le...@gmail.com> wrote:
> >
> >> Hi,
> >>
> >> 1) Webflow: I think I get the idea with the KnoxSSO service: how can I
> test
> >> everything to ensure pac4j works correctly with it and will be usable in
> >> Hadoop UIs?
> >>
> >>
> >> 2) Callback url:
> >>
> >> For indirect clients, pac4j is designed to be called on any url, to save
> >> it, to call the identity provider providing a static callback url, to be
> >> called back on this static callback url and to restore the originally
> >> requested url.
> >>
> >> From point 1), I conclude that pac4j will always be used with the
> KnoxSSO
> >> service (for indirect clients): will KnoxSSO call the pac4j provider
> always
> >> on the same url? Can you describe your first flow with urls?
> >>
> >> Because in that case, I could find a solution where I check for the
> >> client_name parameter to define if it's a callback or a first call.
> >>
> >> Otherwise, I will need a specific pac4j service.
> >>
> >>
> >> 3) Configuration: no problem here, I will use the AliasService.
> >>
> >>
> >> 4) Web session: I really need to put some information in session and
> check
> >> them on callback: I think I can take the data put in session, save them
> in
> >> a cookie and restore them before the callback.
> >>
> >> Is it the recommended solution? Can I re-use the components available
> for
> >> JWT tokens and cookies? And how?
> >>
> >>
> >> 5) Logs: I see in every descriptor the use of Messages and
> MessagesFactory:
> >> I can't use log4j directly, can I? What's the expected benefits using
> this
> >> Messages layer?
> >>
> >>
> >> Thanks.
> >> Best regards,
> >> Jérôme
> >>
> >>
> >>
> >>
> >>
> >> 2015-11-12 18:14 GMT+01:00 larry mccay <lm...@apache.org>:
> >>
> >> > Terrific!
> >> >
> >> > Okay... original questions:
> >> >
> >> > 1) Webflow: is it normal to get a redirection to Facebook or another
> IdP
> >> > when I made the request (for such a configuration of course)? Is this
> >> > request meant to happen in a browser? (because it's the use case it
> was
> >> > made for)
> >> >
> >> > It is normal.
> >> > The usecases in which this mechanism would be used would involve the
> >> > KnoxSSO service/feature.
> >> > What we are doing with that is providing a normalization of
> >> authentication
> >> > mechanisms by federating each auth event through a JWT token that gets
> >> set
> >> > as a cookie.
> >> > These usecases allow us to provide WebSSO flows for Hadoop UIs and
> other
> >> > applications and those applications to only ever have to know about
> >> KnoxSSO
> >> > tokens.
> >> >
> >> > What is slightly less normal is that the flow needs to have KnoxSSO in
> >> the
> >> > middle.
> >> > For instance:
> >> > 1. a browser requests a resource from a KnoxSSO participating service
> >> > provider
> >> > 2. the service provider redirects the browser to KnoxSSO since there
> is
> >> no
> >> > cookie
> >> > 3. KnoxSSO is protected with pac4j provider and redirects the browser
> to
> >> FB
> >> > 4. user authenticates to FB
> >> > 5. pac4j accepts the FB authentication and normalizes the security
> >> context
> >> > to a J2E Subject
> >> > 6. WebSSO service then creates a signed JWT token, sets the cookie and
> >> > redirects to the originally requested resource
> >> > 7. originally requested resource finds the hadoop-jwt cookie,
> validates
> >> the
> >> > token and verifies the signature and grants access to the resource
> >> >
> >> > 2) Callback url: https://localhost:8443/gateway/sandbox/callback
> >> currently
> >> > returns a 404, so I must declare this url somewhere to be taken into
> >> > account and pass to the pac4j filter. It would be even better if it
> could
> >> > be done by the pac4j deployment contributor.
> >> >
> >> > How and where to do that?
> >> >
> >> > This is an interesting question and one that may have multiple
> solutions:
> >> >
> >> > * we may be able to add the callback filter as part of the original
> >> > provider and just point them to the same URL. This would require the
> >> > ability to chain them where one knows to not handle a request that is
> >> > really meant for the other.
> >> > * If we truly need a separate URL the way you depict it there then we
> >> will
> >> > need to add a new service which would be unfortunate because it
> couples
> >> the
> >> > use of a certain provider to the use of a particular service.
> >> >
> >> > 3) Configuration
> >> >
> >> > Currently, I hardcoded a FacebookClient for Facebook authentication,
> but
> >> we
> >> > should be able to pass the appropriate client like Facebook or SAML.
> >> > Basically, we could do that using filter properties: facebook.key +
> >> > facebook.secret means we use Facebook authentication with the
> appropriate
> >> > key and secret for example. Any recommendation?
> >> >
> >> > This is fine. You will add your properties to the provider properties
> in
> >> > the topology for the pac4j provider.
> >> > You can find example code in the article to blindly add all
> properties to
> >> > the filter init params.
> >> >
> >> > Incidentally, the storage of credentials directly in config files
> should
> >> be
> >> > avoided.
> >> > See the use of the AliasService where such credentials can be
> persisted
> >> in
> >> > a credential store and resolved at runtime.
> >> > I will find examples of this for you - we can go forward with config
> >> based
> >> > values but will need to fix that later.
> >> >
> >> > 4) Web session: I seem to be able to use the web session to sore data.
> >> > Can you confirm that point?
> >> >
> >> > This is probably not going to work.
> >> > Keep in mind that there may be a cluster of Knox instances running and
> >> the
> >> > session is not replicated across all instances.
> >> > Additionally, keep in mind that your provider will only be engaged on
> the
> >> > first request to KnoxSSO and then not until the token/cookie expires.
> >> >
> >> >
> >> >
> >>
>
Re: pac4j and Apache Knox
Posted by Kevin Minder <ke...@hortonworks.com>.
I’ll add a bit to the logging answer. I created that for several reasons.
1) Localization as Larry mentions.
2) It abstract from actual logging provider and you can see for example gateway-i18n-logging-sl4j as an alternate integration.
3) Another important aspect is centralization. It centralizes all aspects of a given message. For example the level for a given message is kept with the message to hopefully prevent the message from being duplicated with potentially different levels. It is also intended to support the notion of Ids and potentially cause/action annotations which are very common as products mature.
4) Lastly and possibly the most interesting/important from a developer perspective is traceability. Once you find the log method for a given message you can use the IDE to find all of the palaces where a given message is used. You can also have the IDE tell you if the message isn’t used anymore.
All that being said the external components we integrate with certainly don’t use it. So from that perspective, direct use of log4j if that is your choice isn’t going to cause any major problems.
On 11/13/15, 8:40 AM, "larry mccay" <lm...@apache.org> wrote:
>Hi Jérôme -
>
>Great questions and I'm so glad that you are here to ask them.
>
>I think that the set of documentation that I am working on for a KnoxSSO
>integration guide will probably answer most of your questions.
>I need to spend a bit more time thinking about the some of it so that I can
>incorporate that information as well.
>
>The cookie approach is what we use in KnoxSSO. Cookies obviously have some
>disadvantages but is probably the best alternative for KnoxSSO.
>Something that we need to consider is that KnoxSSO is already keeping track
>of the original URL for redirecting back to the requested resource.
>We have to reconcile whether that is separate from the callback needs or
>actually the same thing.
>Having a little trouble wrapping my head around it right now - must have
>more coffee. :)
>
>The Messages layer allows for the localization of the actual messages by
>decoupling the messages from the actual runtime code.
>
>I will try and get some docs published as quickly as possible for KnoxSSO
>integration.
>
>thanks,
>
>--larry
>
>On Fri, Nov 13, 2015 at 3:27 AM, Jérôme LELEU <le...@gmail.com> wrote:
>
>> Hi,
>>
>> 1) Webflow: I think I get the idea with the KnoxSSO service: how can I test
>> everything to ensure pac4j works correctly with it and will be usable in
>> Hadoop UIs?
>>
>>
>> 2) Callback url:
>>
>> For indirect clients, pac4j is designed to be called on any url, to save
>> it, to call the identity provider providing a static callback url, to be
>> called back on this static callback url and to restore the originally
>> requested url.
>>
>> From point 1), I conclude that pac4j will always be used with the KnoxSSO
>> service (for indirect clients): will KnoxSSO call the pac4j provider always
>> on the same url? Can you describe your first flow with urls?
>>
>> Because in that case, I could find a solution where I check for the
>> client_name parameter to define if it's a callback or a first call.
>>
>> Otherwise, I will need a specific pac4j service.
>>
>>
>> 3) Configuration: no problem here, I will use the AliasService.
>>
>>
>> 4) Web session: I really need to put some information in session and check
>> them on callback: I think I can take the data put in session, save them in
>> a cookie and restore them before the callback.
>>
>> Is it the recommended solution? Can I re-use the components available for
>> JWT tokens and cookies? And how?
>>
>>
>> 5) Logs: I see in every descriptor the use of Messages and MessagesFactory:
>> I can't use log4j directly, can I? What's the expected benefits using this
>> Messages layer?
>>
>>
>> Thanks.
>> Best regards,
>> Jérôme
>>
>>
>>
>>
>>
>> 2015-11-12 18:14 GMT+01:00 larry mccay <lm...@apache.org>:
>>
>> > Terrific!
>> >
>> > Okay... original questions:
>> >
>> > 1) Webflow: is it normal to get a redirection to Facebook or another IdP
>> > when I made the request (for such a configuration of course)? Is this
>> > request meant to happen in a browser? (because it's the use case it was
>> > made for)
>> >
>> > It is normal.
>> > The usecases in which this mechanism would be used would involve the
>> > KnoxSSO service/feature.
>> > What we are doing with that is providing a normalization of
>> authentication
>> > mechanisms by federating each auth event through a JWT token that gets
>> set
>> > as a cookie.
>> > These usecases allow us to provide WebSSO flows for Hadoop UIs and other
>> > applications and those applications to only ever have to know about
>> KnoxSSO
>> > tokens.
>> >
>> > What is slightly less normal is that the flow needs to have KnoxSSO in
>> the
>> > middle.
>> > For instance:
>> > 1. a browser requests a resource from a KnoxSSO participating service
>> > provider
>> > 2. the service provider redirects the browser to KnoxSSO since there is
>> no
>> > cookie
>> > 3. KnoxSSO is protected with pac4j provider and redirects the browser to
>> FB
>> > 4. user authenticates to FB
>> > 5. pac4j accepts the FB authentication and normalizes the security
>> context
>> > to a J2E Subject
>> > 6. WebSSO service then creates a signed JWT token, sets the cookie and
>> > redirects to the originally requested resource
>> > 7. originally requested resource finds the hadoop-jwt cookie, validates
>> the
>> > token and verifies the signature and grants access to the resource
>> >
>> > 2) Callback url: https://localhost:8443/gateway/sandbox/callback
>> currently
>> > returns a 404, so I must declare this url somewhere to be taken into
>> > account and pass to the pac4j filter. It would be even better if it could
>> > be done by the pac4j deployment contributor.
>> >
>> > How and where to do that?
>> >
>> > This is an interesting question and one that may have multiple solutions:
>> >
>> > * we may be able to add the callback filter as part of the original
>> > provider and just point them to the same URL. This would require the
>> > ability to chain them where one knows to not handle a request that is
>> > really meant for the other.
>> > * If we truly need a separate URL the way you depict it there then we
>> will
>> > need to add a new service which would be unfortunate because it couples
>> the
>> > use of a certain provider to the use of a particular service.
>> >
>> > 3) Configuration
>> >
>> > Currently, I hardcoded a FacebookClient for Facebook authentication, but
>> we
>> > should be able to pass the appropriate client like Facebook or SAML.
>> > Basically, we could do that using filter properties: facebook.key +
>> > facebook.secret means we use Facebook authentication with the appropriate
>> > key and secret for example. Any recommendation?
>> >
>> > This is fine. You will add your properties to the provider properties in
>> > the topology for the pac4j provider.
>> > You can find example code in the article to blindly add all properties to
>> > the filter init params.
>> >
>> > Incidentally, the storage of credentials directly in config files should
>> be
>> > avoided.
>> > See the use of the AliasService where such credentials can be persisted
>> in
>> > a credential store and resolved at runtime.
>> > I will find examples of this for you - we can go forward with config
>> based
>> > values but will need to fix that later.
>> >
>> > 4) Web session: I seem to be able to use the web session to sore data.
>> > Can you confirm that point?
>> >
>> > This is probably not going to work.
>> > Keep in mind that there may be a cluster of Knox instances running and
>> the
>> > session is not replicated across all instances.
>> > Additionally, keep in mind that your provider will only be engaged on the
>> > first request to KnoxSSO and then not until the token/cookie expires.
>> >
>> >
>> >
>>
Re: pac4j and Apache Knox
Posted by larry mccay <lm...@apache.org>.
Hi Jérôme -
Great questions and I'm so glad that you are here to ask them.
I think that the set of documentation that I am working on for a KnoxSSO
integration guide will probably answer most of your questions.
I need to spend a bit more time thinking about the some of it so that I can
incorporate that information as well.
The cookie approach is what we use in KnoxSSO. Cookies obviously have some
disadvantages but is probably the best alternative for KnoxSSO.
Something that we need to consider is that KnoxSSO is already keeping track
of the original URL for redirecting back to the requested resource.
We have to reconcile whether that is separate from the callback needs or
actually the same thing.
Having a little trouble wrapping my head around it right now - must have
more coffee. :)
The Messages layer allows for the localization of the actual messages by
decoupling the messages from the actual runtime code.
I will try and get some docs published as quickly as possible for KnoxSSO
integration.
thanks,
--larry
On Fri, Nov 13, 2015 at 3:27 AM, Jérôme LELEU <le...@gmail.com> wrote:
> Hi,
>
> 1) Webflow: I think I get the idea with the KnoxSSO service: how can I test
> everything to ensure pac4j works correctly with it and will be usable in
> Hadoop UIs?
>
>
> 2) Callback url:
>
> For indirect clients, pac4j is designed to be called on any url, to save
> it, to call the identity provider providing a static callback url, to be
> called back on this static callback url and to restore the originally
> requested url.
>
> From point 1), I conclude that pac4j will always be used with the KnoxSSO
> service (for indirect clients): will KnoxSSO call the pac4j provider always
> on the same url? Can you describe your first flow with urls?
>
> Because in that case, I could find a solution where I check for the
> client_name parameter to define if it's a callback or a first call.
>
> Otherwise, I will need a specific pac4j service.
>
>
> 3) Configuration: no problem here, I will use the AliasService.
>
>
> 4) Web session: I really need to put some information in session and check
> them on callback: I think I can take the data put in session, save them in
> a cookie and restore them before the callback.
>
> Is it the recommended solution? Can I re-use the components available for
> JWT tokens and cookies? And how?
>
>
> 5) Logs: I see in every descriptor the use of Messages and MessagesFactory:
> I can't use log4j directly, can I? What's the expected benefits using this
> Messages layer?
>
>
> Thanks.
> Best regards,
> Jérôme
>
>
>
>
>
> 2015-11-12 18:14 GMT+01:00 larry mccay <lm...@apache.org>:
>
> > Terrific!
> >
> > Okay... original questions:
> >
> > 1) Webflow: is it normal to get a redirection to Facebook or another IdP
> > when I made the request (for such a configuration of course)? Is this
> > request meant to happen in a browser? (because it's the use case it was
> > made for)
> >
> > It is normal.
> > The usecases in which this mechanism would be used would involve the
> > KnoxSSO service/feature.
> > What we are doing with that is providing a normalization of
> authentication
> > mechanisms by federating each auth event through a JWT token that gets
> set
> > as a cookie.
> > These usecases allow us to provide WebSSO flows for Hadoop UIs and other
> > applications and those applications to only ever have to know about
> KnoxSSO
> > tokens.
> >
> > What is slightly less normal is that the flow needs to have KnoxSSO in
> the
> > middle.
> > For instance:
> > 1. a browser requests a resource from a KnoxSSO participating service
> > provider
> > 2. the service provider redirects the browser to KnoxSSO since there is
> no
> > cookie
> > 3. KnoxSSO is protected with pac4j provider and redirects the browser to
> FB
> > 4. user authenticates to FB
> > 5. pac4j accepts the FB authentication and normalizes the security
> context
> > to a J2E Subject
> > 6. WebSSO service then creates a signed JWT token, sets the cookie and
> > redirects to the originally requested resource
> > 7. originally requested resource finds the hadoop-jwt cookie, validates
> the
> > token and verifies the signature and grants access to the resource
> >
> > 2) Callback url: https://localhost:8443/gateway/sandbox/callback
> currently
> > returns a 404, so I must declare this url somewhere to be taken into
> > account and pass to the pac4j filter. It would be even better if it could
> > be done by the pac4j deployment contributor.
> >
> > How and where to do that?
> >
> > This is an interesting question and one that may have multiple solutions:
> >
> > * we may be able to add the callback filter as part of the original
> > provider and just point them to the same URL. This would require the
> > ability to chain them where one knows to not handle a request that is
> > really meant for the other.
> > * If we truly need a separate URL the way you depict it there then we
> will
> > need to add a new service which would be unfortunate because it couples
> the
> > use of a certain provider to the use of a particular service.
> >
> > 3) Configuration
> >
> > Currently, I hardcoded a FacebookClient for Facebook authentication, but
> we
> > should be able to pass the appropriate client like Facebook or SAML.
> > Basically, we could do that using filter properties: facebook.key +
> > facebook.secret means we use Facebook authentication with the appropriate
> > key and secret for example. Any recommendation?
> >
> > This is fine. You will add your properties to the provider properties in
> > the topology for the pac4j provider.
> > You can find example code in the article to blindly add all properties to
> > the filter init params.
> >
> > Incidentally, the storage of credentials directly in config files should
> be
> > avoided.
> > See the use of the AliasService where such credentials can be persisted
> in
> > a credential store and resolved at runtime.
> > I will find examples of this for you - we can go forward with config
> based
> > values but will need to fix that later.
> >
> > 4) Web session: I seem to be able to use the web session to sore data.
> > Can you confirm that point?
> >
> > This is probably not going to work.
> > Keep in mind that there may be a cluster of Knox instances running and
> the
> > session is not replicated across all instances.
> > Additionally, keep in mind that your provider will only be engaged on the
> > first request to KnoxSSO and then not until the token/cookie expires.
> >
> >
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Hi,
1) Webflow: I think I get the idea with the KnoxSSO service: how can I test
everything to ensure pac4j works correctly with it and will be usable in
Hadoop UIs?
2) Callback url:
For indirect clients, pac4j is designed to be called on any url, to save
it, to call the identity provider providing a static callback url, to be
called back on this static callback url and to restore the originally
requested url.
>From point 1), I conclude that pac4j will always be used with the KnoxSSO
service (for indirect clients): will KnoxSSO call the pac4j provider always
on the same url? Can you describe your first flow with urls?
Because in that case, I could find a solution where I check for the
client_name parameter to define if it's a callback or a first call.
Otherwise, I will need a specific pac4j service.
3) Configuration: no problem here, I will use the AliasService.
4) Web session: I really need to put some information in session and check
them on callback: I think I can take the data put in session, save them in
a cookie and restore them before the callback.
Is it the recommended solution? Can I re-use the components available for
JWT tokens and cookies? And how?
5) Logs: I see in every descriptor the use of Messages and MessagesFactory:
I can't use log4j directly, can I? What's the expected benefits using this
Messages layer?
Thanks.
Best regards,
Jérôme
2015-11-12 18:14 GMT+01:00 larry mccay <lm...@apache.org>:
> Terrific!
>
> Okay... original questions:
>
> 1) Webflow: is it normal to get a redirection to Facebook or another IdP
> when I made the request (for such a configuration of course)? Is this
> request meant to happen in a browser? (because it's the use case it was
> made for)
>
> It is normal.
> The usecases in which this mechanism would be used would involve the
> KnoxSSO service/feature.
> What we are doing with that is providing a normalization of authentication
> mechanisms by federating each auth event through a JWT token that gets set
> as a cookie.
> These usecases allow us to provide WebSSO flows for Hadoop UIs and other
> applications and those applications to only ever have to know about KnoxSSO
> tokens.
>
> What is slightly less normal is that the flow needs to have KnoxSSO in the
> middle.
> For instance:
> 1. a browser requests a resource from a KnoxSSO participating service
> provider
> 2. the service provider redirects the browser to KnoxSSO since there is no
> cookie
> 3. KnoxSSO is protected with pac4j provider and redirects the browser to FB
> 4. user authenticates to FB
> 5. pac4j accepts the FB authentication and normalizes the security context
> to a J2E Subject
> 6. WebSSO service then creates a signed JWT token, sets the cookie and
> redirects to the originally requested resource
> 7. originally requested resource finds the hadoop-jwt cookie, validates the
> token and verifies the signature and grants access to the resource
>
> 2) Callback url: https://localhost:8443/gateway/sandbox/callback currently
> returns a 404, so I must declare this url somewhere to be taken into
> account and pass to the pac4j filter. It would be even better if it could
> be done by the pac4j deployment contributor.
>
> How and where to do that?
>
> This is an interesting question and one that may have multiple solutions:
>
> * we may be able to add the callback filter as part of the original
> provider and just point them to the same URL. This would require the
> ability to chain them where one knows to not handle a request that is
> really meant for the other.
> * If we truly need a separate URL the way you depict it there then we will
> need to add a new service which would be unfortunate because it couples the
> use of a certain provider to the use of a particular service.
>
> 3) Configuration
>
> Currently, I hardcoded a FacebookClient for Facebook authentication, but we
> should be able to pass the appropriate client like Facebook or SAML.
> Basically, we could do that using filter properties: facebook.key +
> facebook.secret means we use Facebook authentication with the appropriate
> key and secret for example. Any recommendation?
>
> This is fine. You will add your properties to the provider properties in
> the topology for the pac4j provider.
> You can find example code in the article to blindly add all properties to
> the filter init params.
>
> Incidentally, the storage of credentials directly in config files should be
> avoided.
> See the use of the AliasService where such credentials can be persisted in
> a credential store and resolved at runtime.
> I will find examples of this for you - we can go forward with config based
> values but will need to fix that later.
>
> 4) Web session: I seem to be able to use the web session to sore data.
> Can you confirm that point?
>
> This is probably not going to work.
> Keep in mind that there may be a cluster of Knox instances running and the
> session is not replicated across all instances.
> Additionally, keep in mind that your provider will only be engaged on the
> first request to KnoxSSO and then not until the token/cookie expires.
>
>
>
Re: pac4j and Apache Knox
Posted by larry mccay <lm...@apache.org>.
Terrific!
Okay... original questions:
1) Webflow: is it normal to get a redirection to Facebook or another IdP
when I made the request (for such a configuration of course)? Is this
request meant to happen in a browser? (because it's the use case it was
made for)
It is normal.
The usecases in which this mechanism would be used would involve the
KnoxSSO service/feature.
What we are doing with that is providing a normalization of authentication
mechanisms by federating each auth event through a JWT token that gets set
as a cookie.
These usecases allow us to provide WebSSO flows for Hadoop UIs and other
applications and those applications to only ever have to know about KnoxSSO
tokens.
What is slightly less normal is that the flow needs to have KnoxSSO in the
middle.
For instance:
1. a browser requests a resource from a KnoxSSO participating service
provider
2. the service provider redirects the browser to KnoxSSO since there is no
cookie
3. KnoxSSO is protected with pac4j provider and redirects the browser to FB
4. user authenticates to FB
5. pac4j accepts the FB authentication and normalizes the security context
to a J2E Subject
6. WebSSO service then creates a signed JWT token, sets the cookie and
redirects to the originally requested resource
7. originally requested resource finds the hadoop-jwt cookie, validates the
token and verifies the signature and grants access to the resource
2) Callback url: https://localhost:8443/gateway/sandbox/callback currently
returns a 404, so I must declare this url somewhere to be taken into
account and pass to the pac4j filter. It would be even better if it could
be done by the pac4j deployment contributor.
How and where to do that?
This is an interesting question and one that may have multiple solutions:
* we may be able to add the callback filter as part of the original
provider and just point them to the same URL. This would require the
ability to chain them where one knows to not handle a request that is
really meant for the other.
* If we truly need a separate URL the way you depict it there then we will
need to add a new service which would be unfortunate because it couples the
use of a certain provider to the use of a particular service.
3) Configuration
Currently, I hardcoded a FacebookClient for Facebook authentication, but we
should be able to pass the appropriate client like Facebook or SAML.
Basically, we could do that using filter properties: facebook.key +
facebook.secret means we use Facebook authentication with the appropriate
key and secret for example. Any recommendation?
This is fine. You will add your properties to the provider properties in
the topology for the pac4j provider.
You can find example code in the article to blindly add all properties to
the filter init params.
Incidentally, the storage of credentials directly in config files should be
avoided.
See the use of the AliasService where such credentials can be persisted in
a credential store and resolved at runtime.
I will find examples of this for you - we can go forward with config based
values but will need to fix that later.
4) Web session: I seem to be able to use the web session to sore data.
Can you confirm that point?
This is probably not going to work.
Keep in mind that there may be a cluster of Knox instances running and the
session is not replicated across all instances.
Additionally, keep in mind that your provider will only be engaged on the
first request to KnoxSSO and then not until the token/cookie expires.
On Thu, Nov 12, 2015 at 11:25 AM, Jérôme LELEU <le...@gmail.com> wrote:
> Hi,
>
> Thanks for your feedback. I didn't understand why the dependency was
> required so I didn't add it.
>
> Now, it starts working:
>
> *$ curl -ivk
> "https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
> <https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS>"*
> ** Trying ::1...*
> ** Connected to localhost (::1) port 8443 (#0)*
> ** TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384*
> ** Server certificate: localhost*
> *> GET /gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS HTTP/1.1*
> *> Host: localhost:8443*
> *> User-Agent: curl/7.43.0*
> *> Accept: */**
> *>*
> *< HTTP/1.1 302 Found*
> *HTTP/1.1 302 Found*
> *< Set-Cookie:
> JSESSIONID=jsk1e89neg3l10xg39ar3a5mt;Path=/gateway/sandbox;Secure*
> *Set-Cookie:
> JSESSIONID=jsk1e89neg3l10xg39ar3a5mt;Path=/gateway/sandbox;Secure*
> *< Expires: Thu, 01 Jan 1970 00:00:00 GMT*
> *Expires: Thu, 01 Jan 1970 00:00:00 GMT*
> *< Location:
>
> https://www.facebook.com/v2.2/dialog/oauth?client_id=x&redirect_uri=https%3A%2F%2Flocalhost%3A8443%2Fgateway%2Fsandbox%2Fcallback%3Fclient_name%3DFacebookClient&state=QCS9Vz83i9&scope=user_likes%2Cuser_about_me%2Cuser_birthday%2Cuser_education_history%2Cemail%2Cuser_hometown%2Cuser_relationship_details%2Cuser_location%2Cuser_religion_politics%2Cuser_relationships%2Cuser_website%2Cuser_work_history
> <
> https://www.facebook.com/v2.2/dialog/oauth?client_id=x&redirect_uri=https%3A%2F%2Flocalhost%3A8443%2Fgateway%2Fsandbox%2Fcallback%3Fclient_name%3DFacebookClient&state=QCS9Vz83i9&scope=user_likes%2Cuser_about_me%2Cuser_birthday%2Cuser_education_history%2Cemail%2Cuser_hometown%2Cuser_relationship_details%2Cuser_location%2Cuser_religion_politics%2Cuser_relationships%2Cuser_website%2Cuser_work_history
> >*
> *Location:
>
> https://www.facebook.com/v2.2/dialog/oauth?client_id=x&redirect_uri=https%3A%2F%2Flocalhost%3A8443%2Fgateway%2Fsandbox%2Fcallback%3Fclient_name%3DFacebookClient&state=QCS9Vz83i9&scope=user_likes%2Cuser_about_me%2Cuser_birthday%2Cuser_education_history%2Cemail%2Cuser_hometown%2Cuser_relationship_details%2Cuser_location%2Cuser_religion_politics%2Cuser_relationships%2Cuser_website%2Cuser_work_history
> <
> https://www.facebook.com/v2.2/dialog/oauth?client_id=x&redirect_uri=https%3A%2F%2Flocalhost%3A8443%2Fgateway%2Fsandbox%2Fcallback%3Fclient_name%3DFacebookClient&state=QCS9Vz83i9&scope=user_likes%2Cuser_about_me%2Cuser_birthday%2Cuser_education_history%2Cemail%2Cuser_hometown%2Cuser_relationship_details%2Cuser_location%2Cuser_religion_politics%2Cuser_relationships%2Cuser_website%2Cuser_work_history
> >*
> *< Content-Length: 0*
>
>
> The response is clearly a redirection to Facebook for authentication (using
> a configuration with Facebook).
>
>
>
> *Even better*: as the pac4j gateway relies on the j2e-pac4j library, all
> authentication mechanisms are supported. So I tried with a direct client
> like the basic auth (where login must be equals to password):
>
> requiresAuthenticationFilter.setClientName("DirectBasicAuthClient");
> requiresAuthenticationFilter.setConfig(new Config(new
> DirectBasicAuthClient(new
> SimpleTestUsernamePasswordAuthenticator())));
>
> And it seems to works: the authentication is successful in the
> Pac4jDispatcherFilter, the adapter filter is called and the pac4j user
> profile is retrieved and passed to the *Subject.doAs*. I finally have a 500
> response, but it's not a surprise as I don't have any running Hadoop:
>
> 2015-11-12 17:07:12,748 WARN hadoop.gateway
> (DefaultDispatch.java:executeOutboundRequest(115)) - Connection exception
> dispatching request:
> http://localhost:50070/webhdfs/v1/tmp?op=LISTSTATUS&user.name=jleleu
> org.apache.http.conn.HttpHostConnectException: Connect to localhost:50070
> [localhost/127.0.0.1, localhost/0:0:0:0:0:0:0:1] failed: Connection
> refused
>
> Reading this stacktrace, I assume that I have been authenticated and
> authorized to call the Hadoop service behind and the identity (user.name)
> is exactly the one I used to make the request:
>
> *curl -ivk --user jleleu:jleleu
> "https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
> <https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS>"*
>
>
>
> *So I'm finally back to my original questions to go further:*
>
> 1) Webflow: is it normal to get a redirection to Facebook or another IdP
> when I made the request (for such a configuration of course)? Is this
> request meant to happen in a browser? (because it's the use case it was
> made for)
>
> 2) Callback url: https://localhost:8443/gateway/sandbox/callback currently
> returns a 404, so I must declare this url somewhere to be taken into
> account and pass to the pac4j filter. It would be even better if it could
> be done by the pac4j deployment contributor.
>
> How and where to do that?
>
> 3) Configuration
>
> Currently, I hardcoded a FacebookClient for Facebook authentication, but we
> should be able to pass the appropriate client like Facebook or SAML.
> Basically, we could do that using filter properties: facebook.key +
> facebook.secret means we use Facebook authentication with the appropriate
> key and secret for example. Any recommendation?
>
> 4) Web session: I seem to be able to use the web session to sore data.
> Can you confirm that point?
>
>
> Thanks.
>
> Best regards,
> Jérôme
>
>
>
>
>
>
>
>
> 2015-11-12 14:55 GMT+01:00 larry mccay <lm...@apache.org>:
>
> > Yes, Kevin, that seems to be missing from the pull request.
> > Also, the parent pom doesn't have all of the changes needed to add a new
> > module.
> >
> > See the section in the article called "Root Level Pom.xml" and the
> section
> > below that for the "Gateway Release Module Pom.xml"
> >
> >
> https://github.com/lmccay/gateway-provider-security-pseudo/blob/master/AddingFederationProvider.md#root-level-pomxml
> >
> > On Thu, Nov 12, 2015 at 8:04 AM, Kevin Minder <
> > kevin.minder@hortonworks.com>
> > wrote:
> >
> > > I think I know what it probably is. The gateway-release module pom.xml
> > is
> > > what actually defines the classpath of the final packaged server. If
> you
> > > take a look at that you will see it references all of the providers
> that
> > > are intended to be included by default. Try adding yours to the
> > > dependencies.
> > >
> > >
> > >
> > >
> > > On 11/12/15, 7:49 AM, "larry mccay" <lm...@apache.org> wrote:
> > >
> > > >We really need to fix this behavior...
> > > >
> > > >It seems you traded in your random authentication provider for a
> random
> > > >federation provider. :/
> > > >
> > > >This is most likely due to not having your new provider on the
> classpath
> > > >for the serviceLoader to find.
> > > >
> > > >Just to try and articulate how it works...
> > > >
> > > >The deployment machinery loads all of the federation (whichever role)
> > > >providers contributors that is finds on the classpath - via the
> > >
> > >
> >
> >src/main/resources/META-INF/services/org.apache.hadoop.gateway.deploy.ProviderDeploymentContributor
> > > >- and interrogates each for its name to match to the name in the
> > topology.
> > > >Once it finds a match it allows the contributor to "contribute" to the
> > > >creation of the topology specific webapp. Part of which includes
> adding
> > > >filters to the gateway.xml.
> > > >
> > > >We currently have an issue wherein, given a name that doesn't match
> any
> > > >found on the classpath, a random provider is returned. This needs to
> be
> > > >fixed to fail deployment with appropriate error messages.
> > > >
> > > >Now, this usually comes down to one of 2 things:
> > > >
> > > >1. there is no
> > >
> >
> src/main/resources/META-INF/services/org.apache.hadoop.gateway.deploy.ProviderDeploymentContributor
> > > >file in the provider or it contains the classname of some other
> > > contributor
> > > >2. the provider itself isn't on the gateway classpath. I see that your
> > > >service file seems to be defined properly - so it is probably not on
> the
> > > >classpath. Did you add the new provider to the parent pom? The article
> > > >should provide all you need to do so.
> > > >
> > > >I will file a JIRA to fix the random provider issue.
> > > >
> > > >On Thu, Nov 12, 2015 at 7:18 AM, Jérôme LELEU <le...@gmail.com>
> wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> By changing the role to the appropriate value, the error is gone,
> but
> > I
> > > >> have a new problem:
> > > >>
> > > >> *Caused by: javax.servlet.ServletException: Required authentication
> > > >> provider URL is missing.*
> > > >> * at
> > > >>
> > > >>
> > >
> >
> org.apache.hadoop.gateway.provider.federation.jwt.filter.SSOCookieFederationFilter.init(SSOCookieFederationFilter.java:90)*
> > > >>
> > > >> My sandbox.xml file only references the pac4j provider as well as
> the
> > > >> Default (role: identity-assertion) and static (role: hostmap) ones.
> > > >>
> > > >> Though, the SSOCookieFederationFilter is defined in the gateway.xml
> > > file of
> > > >> my sandbox deployment. Why do I need it? What's the expected
> > > authentication
> > > >> provider url? How this gatweay.xml is generated?
> > > >>
> > > >> Thanks.
> > > >> Best regards,
> > > >> Jérôme
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> 2015-11-10 17:36 GMT+01:00 Kevin Minder <
> kevin.minder@hortonworks.com
> > >:
> > > >>
> > > >> > To be a bit more explicit your Pac4jFederationProviderContributor
> > > >> declares
> > > >> > itself to be of role “federation” but when you used it in the
> > > sandbox.xml
> > > >> > topology file you were attempting to configure it as an provider
> > with
> > > >> role
> > > >> > authentication.
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > On 11/10/15, 11:32 AM, "larry mccay" <lm...@apache.org> wrote:
> > > >> >
> > > >> > >Let's get you past the error that you are getting...
> > > >> > >
> > > >> > >It seems as though you have change the topology for pac4j but
> > didn't
> > > >> > change
> > > >> > >the role to "federation".
> > > >> > >It looks like it is grabbing a random authentication provider and
> > > seems
> > > >> to
> > > >> > >be the hadoop-auth provider.
> > > >> > >
> > > >> > >Change that to federation and see if that helps.
> > > >> > >
> > > >> > >On Tue, Nov 10, 2015 at 11:21 AM, larry mccay <lmccay@apache.org
> >
> > > >> wrote:
> > > >> > >
> > > >> > >> Hi Jérôme -
> > > >> > >>
> > > >> > >> Happy to see you here!
> > > >> > >> I apologize for having missed your note on the list a few days
> > ago.
> > > >> > >>
> > > >> > >> Glad to see that the article was helpful and it seems like you
> > are
> > > >> > making
> > > >> > >> great progress.
> > > >> > >>
> > > >> > >> Let me dig into your note a bit deeper and answer your
> questions.
> > > >> > >>
> > > >> > >> Welcome!
> > > >> > >>
> > > >> > >> --larry
> > > >> > >>
> > > >> > >> On Tue, Nov 10, 2015 at 11:14 AM, Jérôme LELEU <
> leleuj@gmail.com
> > >
> > > >> > wrote:
> > > >> > >>
> > > >> > >>> Hi,
> > > >> > >>>
> > > >> > >>> Perfect timing ;-) I have started implemented the pac4j
> support
> > in
> > > >> > Knox,
> > > >> > >>> it's a very basic attempt:
> > > >> https://github.com/apache/knox/pull/2/files
> > > >> > >>>
> > > >> > >>> This implementation reuses the pac4j implementation for J2E. I
> > > have a
> > > >> > >>> ProviderDeploymentContributorBase which registers two filters:
> > > >> > >>> - the first one is a dispatcher filter which uses the
> j2e-pac4j
> > > >> > >>> CallbackFilter on the /callabck url (it finishes the
> > > authentication
> > > >> > process
> > > >> > >>> after a successful authentication at some identity provider)
> and
> > > uses
> > > >> > the
> > > >> > >>> j2e-pac4j RequiresAuthenticationFilter otherwise (redirection
> to
> > > the
> > > >> > >>> identity provider to start the authentication when the user is
> > not
> > > >> > >>> authenticated)
> > > >> > >>> - the second one is an identity adapter which gets the current
> > > >> > >>> authenticated user from the pac4j point of view and populates
> > the
> > > J2E
> > > >> > >>> security context.
> > > >> > >>>
> > > >> > >>>
> > > >> > >>> * I have the following error:
> > > >> > >>>
> > > >> > >>> 2015-11-10 16:30:22,347 ERROR hadoop.gateway
> > > >> > >>> (GatewayFilter.java:doFilter(135)) - Gateway processing
> failed:
> > > >> > >>> javax.servlet.ServletException:
> javax.servlet.ServletException:
> > > >> > >>> Authentication type must be specified: simple|kerberos|<class>
> > > >> > >>> javax.servlet.ServletException:
> javax.servlet.ServletException:
> > > >> > >>> Authentication type must be specified: simple|kerberos|<class>
> > > >> > >>> at
> > > >> > >>>
> > > >> >
> > > >>
> > >
> >
> org.apache.hadoop.gateway.GatewayFilter$Holder.getInstance(GatewayFilter.java:354)
> > > >> > >>>
> > > >> > >>> Notice I have changed the sandbox.xml file to use pac4j
> instead
> > of
> > > >> > Shiro,
> > > >> > >>> maybe it's not the right way:
> > > >> > >>>
> > > >> >
> > > >>
> > >
> >
> https://github.com/apache/knox/pull/2/files#diff-128ca80baa2dfd6c2d25de7b8160b9d9R24
> > > >> > >>>
> > > >> > >>> Any idea of the problem?
> > > >> > >>>
> > > >> > >>>
> > > >> > >>> * Am I understanding webflows correctly?
> > > >> > >>>
> > > >> > >>> I use the default request to: curl -ivk "
> > > >> > >>>
> > > https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS"
> > > >> > >>>
> > > >> > >>> It looks like a REST request, though I'm expecting the
> following
> > > >> > webflow:
> > > >> > >>> redirection of the user to the identity provider, successful
> > > login,
> > > >> > >>> redirection back to the /callback url of the gateway: do I get
> > it
> > > >> > right?
> > > >> > >>>
> > > >> > >>>
> > > >> > >>> * The callback url
> > > >> > >>>
> > > >> > >>> I currently do a check expecting the last part of the url to
> end
> > > with
> > > >> > >>> /callback, but does the gateway will receive requests on this
> > url?
> > > >> Do I
> > > >> > >>> have to do something special?
> > > >> > >>>
> > > >> > >>> It's highly recommended to only have one callback url as this
> > url
> > > is
> > > >> > >>> defined on the identity provider side.
> > > >> > >>>
> > > >> > >>>
> > > >> > >>> * How to pass configuration?
> > > >> > >>>
> > > >> > >>> Currently, I hardcoded a FacebookClient for Facebook
> > > authentication,
> > > >> > but
> > > >> > >>> we should be able to pass the appropriate client like Facebook
> > or
> > > >> SAML.
> > > >> > >>> Basically, we could do that using filter properties:
> > facebook.key
> > > +
> > > >> > >>> facebook.secret means we use Facebook authentication with the
> > > >> > appropriate
> > > >> > >>> key and secret for example. Any recommendation?
> > > >> > >>>
> > > >> > >>>
> > > >> > >>> * Can I use the J2E session to store the requested protected
> url
> > > and
> > > >> > >>> other information?
> > > >> > >>>
> > > >> > >>> Or do I need to do something special?
> > > >> > >>>
> > > >> > >>>
> > > >> > >>> Thanks.
> > > >> > >>> Best regards,
> > > >> > >>> Jérôme
> > > >> > >>>
> > > >> > >>> 2015-11-10 17:03 GMT+01:00 Kevin Minder <
> > > >> kevin.minder@hortonworks.com
> > > >> > >:
> > > >> > >>>
> > > >> > >>>> Hi Jerome,
> > > >> > >>>> This sounds very exciting and is just the sort of thing the
> > open
> > > >> > >>>> architecture of Knox is intended to allow. Larry and I have
> > > looked
> > > >> at
> > > >> > >>>> pac4j a number of times thinking that it would be a good fit
> > and
> > > >> would
> > > >> > >>>> provide a great feature set to the Hadoop community.
> > > >> > >>>> Kevin.
> > > >> > >>>>
> > > >> > >>>>
> > > >> > >>>>
> > > >> > >>>> On 11/6/15, 3:31 AM, "Jérôme LELEU" <le...@gmail.com>
> wrote:
> > > >> > >>>>
> > > >> > >>>> >Hi,
> > > >> > >>>> >
> > > >> > >>>> >Let's open this private discussion on the Knox dev mailing
> > list.
> > > >> > >>>> >
> > > >> > >>>> >I'm Jerome Leleu and the creator of pac4j (
> > > >> > >>>> https://github.com/pac4j/pac4j),
> > > >> > >>>> >a security engine for Java with many implementations for
> J2E,
> > > Play,
> > > >> > >>>> Spring,
> > > >> > >>>> >Vertx, Ratpack... The idea is to offer something as powerful
> > as
> > > >> > Spring
> > > >> > >>>> >Security, but a lot easier and for all Java frameworks /
> tools
> > > and
> > > >> > all
> > > >> > >>>> >authentication mechanisms.
> > > >> > >>>> >
> > > >> > >>>> >Two years ago, we had a discussion with Larry on how pac4j
> > > could be
> > > >> > >>>> used in
> > > >> > >>>> >Knox.
> > > >> > >>>> >
> > > >> > >>>> >Meanwhile, both projects have grown up and I'm back to try
> to
> > > see
> > > >> if
> > > >> > >>>> pac4j
> > > >> > >>>> >can help Knox in terms of security.
> > > >> > >>>> >
> > > >> > >>>> >-----
> > > >> > >>>> >
> > > >> > >>>> >In its latest version, pac4j can be used to build a full
> > > security
> > > >> > >>>> library,
> > > >> > >>>> >not only focused on delegated authentication (Facebook,
> SAML).
> > > So
> > > >> we
> > > >> > >>>> have
> > > >> > >>>> >the concepts of direct clients (a client is an
> authentication
> > > >> > >>>> mechanism):
> > > >> > >>>> >basic auth, header, token... and indirect clients: SAML,
> > > Facebook,
> > > >> > >>>> OpenID,
> > > >> > >>>> >CAS...
> > > >> > >>>> >It seems to be very close to the Authentication and
> Federation
> > > >> > Providers
> > > >> > >>>> >concepts from Knox.
> > > >> > >>>> >
> > > >> > >>>> >The provided article is great and as it's focused on
> > > authentication
> > > >> > >>>> with a
> > > >> > >>>> >real example, it's easier to start with it.
> > > >> > >>>> >
> > > >> > >>>> >Thanks for your answers.
> > > >> > >>>> >
> > > >> > >>>> >Like Shiro, pac4j has LDAP support and caching can be done.
> > The
> > > >> only
> > > >> > >>>> >difference is that pac4j relies on ldaptive (
> > > >> > http://www.ldaptive.org/).
> > > >> > >>>> But
> > > >> > >>>> >I think you're right: it would be better to start by
> > > implementing
> > > >> the
> > > >> > >>>> >Federation part which might be the most expected feature for
> > > Knox
> > > >> > users
> > > >> > >>>> (a
> > > >> > >>>> >bit like buji-pac4j: https://github.com/bujiio/buji-pac4j
> is
> > > for
> > > >> > >>>> Shiro) and
> > > >> > >>>> >see if it's worth the work to have an authentication
> provider
> > > with
> > > >> > >>>> pac4j in
> > > >> > >>>> >addition to the one of Shiro.
> > > >> > >>>> >
> > > >> > >>>> >I plan to start working on that next week. Do you accept
> pull
> > > >> > requests
> > > >> > >>>> on
> > > >> > >>>> >Github (it would make discussion easier on source code)?
> > > >> > >>>> >
> > > >> > >>>> >Any feedback will be appreciated.
> > > >> > >>>> >
> > > >> > >>>> >Thanks.
> > > >> > >>>> >Best regards,
> > > >> > >>>> >Jérôme
> > > >> > >>>> >
> > > >> > >>>> >
> > > >> > >>>> >
> > > >> > >>>> >
> > > >> > >>>> >
> > > >> > >>>> >
> > > >> > >>>> >2015-11-05 17:13 GMT+01:00 larry mccay:
> > > >> > >>>> >
> > > >> > >>>> >> Hi Jérôme -
> > > >> > >>>> >>
> > > >> > >>>> >> Contributions coming from the community are owned and
> > > maintained
> > > >> by
> > > >> > >>>> the
> > > >> > >>>> >> entire community.
> > > >> > >>>> >> You would certainly not be expected to do all work on it
> and
> > > at
> > > >> the
> > > >> > >>>> same
> > > >> > >>>> >> time any assistance and upgrade messages that you provided
> > > would
> > > >> be
> > > >> > >>>> awesome.
> > > >> > >>>> >>
> > > >> > >>>> >> As for an empty module for pac4j, maybe the following
> > example
> > > >> > project
> > > >> > >>>> >> would be helpful to you:
> > > >> > >>>> >>
> > > >> > >>>> >>
> https://github.com/lmccay/gateway-provider-security-pseudo
> > > >> > >>>> >>
> > > >> > >>>> >> It is in support of an article to illustrate how to go
> about
> > > >> > adding a
> > > >> > >>>> >> authentication or federation provider - as you would be
> > doing:
> > > >> > >>>> >>
> > > >> > >>>> >>
> > > >> > >>>>
> > > >> >
> > > >>
> > >
> >
> https://github.com/lmccay/gateway-provider-security-pseudo/blob/master/AddingFederationProvider.md
> > > >> > >>>> >>
> > > >> > >>>> >> That may be easier to consume than the entire developers
> > > guide.
> > > >> > >>>> >> That said, it would be great if you could describe what
> > makes
> > > the
> > > >> > dev
> > > >> > >>>> >> guide too much - if that is the case.
> > > >> > >>>> >>
> > > >> > >>>> >> I'll take a stab at your questions here but we should move
> > > more
> > > >> > >>>> detailed
> > > >> > >>>> >> discussions on the topic to the dev@ list in order to
> keep
> > > this
> > > >> in
> > > >> > >>>> the
> > > >> > >>>> >> open and provide insights to others:
> > > >> > >>>> >>
> > > >> > >>>> >> 1) What do I do with the authenticated user: where / how
> do
> > I
> > > >> fill
> > > >> > >>>> this
> > > >> > >>>> >> identity in Knox?
> > > >> > >>>> >>
> > > >> > >>>> >> We normalize the authentication event into a Java subject
> to
> > > >> > >>>> represent the
> > > >> > >>>> >> user, groups and impersonated user as appropriate.
> > > >> > >>>> >> In cases - like shiro - where we don't have access to the
> > > actual
> > > >> > >>>> >> authenticating code and we need to normalize the provider
> > > >> specific
> > > >> > >>>> security
> > > >> > >>>> >> context, we add another filter. You can look at the shiro
> > > >> provider
> > > >> > >>>> for an
> > > >> > >>>> >> example. The code inside the simple example provider in
> the
> > > >> article
> > > >> > >>>> also
> > > >> > >>>> >> shows what is expected at least in terms of the
> > > PrimaryPrincipal.
> > > >> > >>>> >>
> > > >> > >>>> >> 2) How to handle errors: not authenticated, not
> authorized?
> > > >> > >>>> >>
> > > >> > >>>> >> We aren't intrusive on what should be done by a provider
> > here.
> > > >> > >>>> >> Generally, authentication failures result in a 401 and
> > > >> > authorizations
> > > >> > >>>> in a
> > > >> > >>>> >> 403 and they are usually sent by the provider.
> > > >> > >>>> >>
> > > >> > >>>> >> 3) How to handle redirections to an external provider?
> > > >> > >>>> >>
> > > >> > >>>> >> Redirects are sent by the providers themselves with a 307
> or
> > > 302.
> > > >> > >>>> >> You can look at the SSOCookieFederationFilter in the jwt
> > > module
> > > >> as
> > > >> > an
> > > >> > >>>> >> example if you like.
> > > >> > >>>> >>
> > > >> > >>>> >> 4) Should the pac4j filter also handle authorizations
> (pac4j
> > > can
> > > >> do
> > > >> > >>>> that)?
> > > >> > >>>> >>
> > > >> > >>>> >> This is an interesting question.
> > > >> > >>>> >> Knox provides a separate slot in the provider chain for
> > > >> > authorization.
> > > >> > >>>> >> It is there because of the ability for identity assertion
> > > >> providers
> > > >> > >>>> to map
> > > >> > >>>> >> principals in order to impersonate another user or map
> > > external
> > > >> > >>>> usernames
> > > >> > >>>> >> to those used inside of hadoop clusters. So, the
> > authorization
> > > >> > >>>> decisions
> > > >> > >>>> >> are made based on those identities.
> > > >> > >>>> >>
> > > >> > >>>> >> If we can add the authorization filter as an authorization
> > > >> provider
> > > >> > >>>> rather
> > > >> > >>>> >> than part of the authentication provider than that might
> > make
> > > >> > sense.
> > > >> > >>>> >> Although, the security context is normalized as Knox
> expects
> > > not
> > > >> as
> > > >> > >>>> pac4j
> > > >> > >>>> >> authorization probably does. Now, if there is real value
> in
> > > doing
> > > >> > so,
> > > >> > >>>> the
> > > >> > >>>> >> pac4j Subject adaptor could stuff additional context into
> > the
> > > >> > Subject
> > > >> > >>>> or
> > > >> > >>>> >> the request that can be accessed later by the pac4j
> > > authorization
> > > >> > >>>> provider.
> > > >> > >>>> >>
> > > >> > >>>> >> So, it can be done - the question is whether there is
> > > compelling
> > > >> > >>>> reason to
> > > >> > >>>> >> do so.
> > > >> > >>>> >>
> > > >> > >>>> >> 5) How to test?
> > > >> > >>>> >>
> > > >> > >>>> >> This can be challenging especially for external
> > > authentications
> > > >> and
> > > >> > >>>> web
> > > >> > >>>> >> app flows.
> > > >> > >>>> >> Generally, unit testing as much as possible is required.
> > > >> > >>>> >> We would want to make sure that the security context
> > > >> normalization
> > > >> > >>>> happens
> > > >> > >>>> >> as expected, etc.
> > > >> > >>>> >>
> > > >> > >>>> >> Additional considerations:
> > > >> > >>>> >>
> > > >> > >>>> >> 1. Our Shiro provider does group lookup and caching of the
> > > >> > >>>> authentication
> > > >> > >>>> >> event for optimizing interactions with authentication
> > servers,
> > > >> > LDAP,
> > > >> > >>>> AD,
> > > >> > >>>> >> etc. We wouldn't want to lose these. Doing so would be a
> > > >> > non-starter
> > > >> > >>>> for
> > > >> > >>>> >> most folks replacing what Shiro is used for today.
> > > >> > >>>> >> 2. It is probably best to concentrate on the gaps that
> pac4j
> > > can
> > > >> > fill
> > > >> > >>>> for
> > > >> > >>>> >> openid, oauth, etc for the initial contribution and if the
> > > >> usecases
> > > >> > >>>> handled
> > > >> > >>>> >> by Shiro can be done better, easier, simpler then we can
> > > >> consider a
> > > >> > >>>> >> migration path.
> > > >> > >>>> >>
> > > >> > >>>> >> BTW - we have a couple very interesting possibilities for
> > > strong
> > > >> > and
> > > >> > >>>> >> multi-factor authentication that would be enabled by
> OpenID
> > > >> > >>>> immediately.
> > > >> > >>>> >>
> > > >> > >>>> >> Hope this isn't too long a response and that it is helpful
> > for
> > > >> you.
> > > >> > >>>> >>
> > > >> > >>>> >> Let's determine what an initial contribution would be for
> > and
> > > >> > bring a
> > > >> > >>>> >> proposal to the dev@ list and/or file a jira for the
> > > >> integration.
> > > >> > >>>> >> This would be great for adding features and growing the
> > > >> community -
> > > >> > >>>> so we
> > > >> > >>>> >> are all for it!
> > > >> > >>>> >>
> > > >> > >>>> >> thanks,
> > > >> > >>>> >>
> > > >> > >>>> >> --larry
> > > >> > >>>> >>
> > > >> > >>>> >>
> > > >> > >>>> >> On Thu, Nov 5, 2015 at 9:43 AM, Jérôme LELEU <
> > > leleuj@gmail.com>
> > > >> > >>>> wrote:
> > > >> > >>>> >>
> > > >> > >>>> >>> Hi,
> > > >> > >>>> >>>
> > > >> > >>>> >>> I see that Shiro is already used for basic auth and LDAP
> > > >> > >>>> authentication
> > > >> > >>>> >>> and Picketlink for SAML. pac4j v1.8 can now handle both
> > cases
> > > >> and
> > > >> > >>>> even
> > > >> > >>>> >>> more. So I think we could create a
> > > >> gateway-provider-security-pac4j
> > > >> > >>>> >>> supporting all authentication mechanisms and not only
> > OpenID.
> > > >> > >>>> >>>
> > > >> > >>>> >>> pac4j implementations generally work with two filters:
> one
> > to
> > > >> > >>>> protect a
> > > >> > >>>> >>> resource and play direct authentication like basic auth
> > (and
> > > >> check
> > > >> > >>>> >>> authorizations) and a callback filter to finish remote
> > > >> > >>>> authentication like
> > > >> > >>>> >>> Facebook, SAML, OpenID. The easiest one is the j2e-pac4j
> > > with:
> > > >> > >>>> >>>
> > > >> > >>>>
> > > >> >
> > > >>
> > >
> >
> https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/RequiresAuthenticationFilter.java#L96
> > > >> > >>>> >>> and
> > > >> > >>>> >>>
> > > >> > >>>>
> > > >> >
> > > >>
> > >
> >
> https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/CallbackFilter.java#L65
> > > >> > >>>> >>>
> > > >> > >>>> >>> That said, I have already many pac4j implementations to
> > > handle
> > > >> so
> > > >> > I'm
> > > >> > >>>> >>> pushing communities to maintain on their own their pac4j
> > > >> > >>>> implementations:
> > > >> > >>>> >>> can we imagine having an official:
> > > >> gateway-provider-security-pac4j
> > > >> > >>>> module
> > > >> > >>>> >>> maintained by the Knox community with my help of course?
> > > This is
> > > >> > the
> > > >> > >>>> kind
> > > >> > >>>> >>> of message I deliver to communities when a new version of
> > > pac4j
> > > >> is
> > > >> > >>>> >>> available so that they can upgrade:
> > > >> > >>>> >>> https://github.com/ratpack/ratpack/issues/819
> > > >> > >>>> >>>
> > > >> > >>>> >>> I read:
> > > >> > >>>>
> > > https://knox.apache.org/books/knox-0-6-0/dev-guide.html#Providers,
> > > >> > >>>> >>> it might be easy for Knox contributors, but it's a bit
> hard
> > > for
> > > >> me
> > > >> > >>>> to get
> > > >> > >>>> >>> in everything: can you or someone in the Knox community
> > > provides
> > > >> > me
> > > >> > >>>> an
> > > >> > >>>> >>> empty gateway-provider-security-pac4j module and the
> > default
> > > >> > >>>> expectations
> > > >> > >>>> >>> from a Knox point of view?
> > > >> > >>>> >>> My main questions:
> > > >> > >>>> >>> 1) What do I do with the authenticated user: where / how
> > do I
> > > >> fill
> > > >> > >>>> this
> > > >> > >>>> >>> identity in Knox?
> > > >> > >>>> >>> 2) How to handle errors: not authenticated, not
> authorized?
> > > >> > >>>> >>> 3) How to handle redirections to an external provider?
> > > >> > >>>> >>> 4) Should the pac4j filter also handle authorizations
> > (pac4j
> > > can
> > > >> > do
> > > >> > >>>> that)?
> > > >> > >>>> >>> 5) How to test?
> > > >> > >>>> >>>
> > > >> > >>>> >>> Thanks.
> > > >> > >>>> >>> Best regards,
> > > >> > >>>> >>> Jérôme
> > > >> > >>>> >>>
> > > >> > >>>> >>>
> > > >> > >>>> >>>
> > > >> > >>>> >>>
> > > >> > >>>> >>> 2015-11-03 16:58 GMT+01:00 larry mccay:
> > > >> > >>>> >>>
> > > >> > >>>> >>>> Hi Jérôme -
> > > >> > >>>> >>>>
> > > >> > >>>> >>>> We were evaluating buji-pac4j for SSO with SAML and
> ended
> > up
> > > >> > going
> > > >> > >>>> with
> > > >> > >>>> >>>> Picketlink at the time.
> > > >> > >>>> >>>> That said, we do have a pluggable architecture that
> would
> > > allow
> > > >> > for
> > > >> > >>>> a
> > > >> > >>>> >>>> pac4j provider as well.
> > > >> > >>>> >>>>
> > > >> > >>>> >>>> If you are interested in contributing such a provider
> that
> > > >> would
> > > >> > >>>> >>>> certainly be welcome.
> > > >> > >>>> >>>> There is someone in the community working on an openid
> > > provider
> > > >> > but
> > > >> > >>>> >>>> perhaps pac4j would be the way to go there?
> > > >> > >>>> >>>>
> > > >> > >>>> >>>> thanks,
> > > >> > >>>> >>>>
> > > >> > >>>> >>>> --larry
> > > >> > >>>> >>>>
> > > >> > >>>> >>>>
> > > >> > >>>>
> > > >> > >>>
> > > >> > >>>
> > > >> > >>
> > > >> >
> > > >>
> > >
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Hi,
Thanks for your feedback. I didn't understand why the dependency was
required so I didn't add it.
Now, it starts working:
*$ curl -ivk
"https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
<https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS>"*
** Trying ::1...*
** Connected to localhost (::1) port 8443 (#0)*
** TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384*
** Server certificate: localhost*
*> GET /gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS HTTP/1.1*
*> Host: localhost:8443*
*> User-Agent: curl/7.43.0*
*> Accept: */**
*>*
*< HTTP/1.1 302 Found*
*HTTP/1.1 302 Found*
*< Set-Cookie:
JSESSIONID=jsk1e89neg3l10xg39ar3a5mt;Path=/gateway/sandbox;Secure*
*Set-Cookie:
JSESSIONID=jsk1e89neg3l10xg39ar3a5mt;Path=/gateway/sandbox;Secure*
*< Expires: Thu, 01 Jan 1970 00:00:00 GMT*
*Expires: Thu, 01 Jan 1970 00:00:00 GMT*
*< Location:
https://www.facebook.com/v2.2/dialog/oauth?client_id=x&redirect_uri=https%3A%2F%2Flocalhost%3A8443%2Fgateway%2Fsandbox%2Fcallback%3Fclient_name%3DFacebookClient&state=QCS9Vz83i9&scope=user_likes%2Cuser_about_me%2Cuser_birthday%2Cuser_education_history%2Cemail%2Cuser_hometown%2Cuser_relationship_details%2Cuser_location%2Cuser_religion_politics%2Cuser_relationships%2Cuser_website%2Cuser_work_history
<https://www.facebook.com/v2.2/dialog/oauth?client_id=x&redirect_uri=https%3A%2F%2Flocalhost%3A8443%2Fgateway%2Fsandbox%2Fcallback%3Fclient_name%3DFacebookClient&state=QCS9Vz83i9&scope=user_likes%2Cuser_about_me%2Cuser_birthday%2Cuser_education_history%2Cemail%2Cuser_hometown%2Cuser_relationship_details%2Cuser_location%2Cuser_religion_politics%2Cuser_relationships%2Cuser_website%2Cuser_work_history>*
*Location:
https://www.facebook.com/v2.2/dialog/oauth?client_id=x&redirect_uri=https%3A%2F%2Flocalhost%3A8443%2Fgateway%2Fsandbox%2Fcallback%3Fclient_name%3DFacebookClient&state=QCS9Vz83i9&scope=user_likes%2Cuser_about_me%2Cuser_birthday%2Cuser_education_history%2Cemail%2Cuser_hometown%2Cuser_relationship_details%2Cuser_location%2Cuser_religion_politics%2Cuser_relationships%2Cuser_website%2Cuser_work_history
<https://www.facebook.com/v2.2/dialog/oauth?client_id=x&redirect_uri=https%3A%2F%2Flocalhost%3A8443%2Fgateway%2Fsandbox%2Fcallback%3Fclient_name%3DFacebookClient&state=QCS9Vz83i9&scope=user_likes%2Cuser_about_me%2Cuser_birthday%2Cuser_education_history%2Cemail%2Cuser_hometown%2Cuser_relationship_details%2Cuser_location%2Cuser_religion_politics%2Cuser_relationships%2Cuser_website%2Cuser_work_history>*
*< Content-Length: 0*
The response is clearly a redirection to Facebook for authentication (using
a configuration with Facebook).
*Even better*: as the pac4j gateway relies on the j2e-pac4j library, all
authentication mechanisms are supported. So I tried with a direct client
like the basic auth (where login must be equals to password):
requiresAuthenticationFilter.setClientName("DirectBasicAuthClient");
requiresAuthenticationFilter.setConfig(new Config(new
DirectBasicAuthClient(new
SimpleTestUsernamePasswordAuthenticator())));
And it seems to works: the authentication is successful in the
Pac4jDispatcherFilter, the adapter filter is called and the pac4j user
profile is retrieved and passed to the *Subject.doAs*. I finally have a 500
response, but it's not a surprise as I don't have any running Hadoop:
2015-11-12 17:07:12,748 WARN hadoop.gateway
(DefaultDispatch.java:executeOutboundRequest(115)) - Connection exception
dispatching request:
http://localhost:50070/webhdfs/v1/tmp?op=LISTSTATUS&user.name=jleleu
org.apache.http.conn.HttpHostConnectException: Connect to localhost:50070
[localhost/127.0.0.1, localhost/0:0:0:0:0:0:0:1] failed: Connection refused
Reading this stacktrace, I assume that I have been authenticated and
authorized to call the Hadoop service behind and the identity (user.name)
is exactly the one I used to make the request:
*curl -ivk --user jleleu:jleleu
"https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS
<https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS>"*
*So I'm finally back to my original questions to go further:*
1) Webflow: is it normal to get a redirection to Facebook or another IdP
when I made the request (for such a configuration of course)? Is this
request meant to happen in a browser? (because it's the use case it was
made for)
2) Callback url: https://localhost:8443/gateway/sandbox/callback currently
returns a 404, so I must declare this url somewhere to be taken into
account and pass to the pac4j filter. It would be even better if it could
be done by the pac4j deployment contributor.
How and where to do that?
3) Configuration
Currently, I hardcoded a FacebookClient for Facebook authentication, but we
should be able to pass the appropriate client like Facebook or SAML.
Basically, we could do that using filter properties: facebook.key +
facebook.secret means we use Facebook authentication with the appropriate
key and secret for example. Any recommendation?
4) Web session: I seem to be able to use the web session to sore data.
Can you confirm that point?
Thanks.
Best regards,
Jérôme
2015-11-12 14:55 GMT+01:00 larry mccay <lm...@apache.org>:
> Yes, Kevin, that seems to be missing from the pull request.
> Also, the parent pom doesn't have all of the changes needed to add a new
> module.
>
> See the section in the article called "Root Level Pom.xml" and the section
> below that for the "Gateway Release Module Pom.xml"
>
> https://github.com/lmccay/gateway-provider-security-pseudo/blob/master/AddingFederationProvider.md#root-level-pomxml
>
> On Thu, Nov 12, 2015 at 8:04 AM, Kevin Minder <
> kevin.minder@hortonworks.com>
> wrote:
>
> > I think I know what it probably is. The gateway-release module pom.xml
> is
> > what actually defines the classpath of the final packaged server. If you
> > take a look at that you will see it references all of the providers that
> > are intended to be included by default. Try adding yours to the
> > dependencies.
> >
> >
> >
> >
> > On 11/12/15, 7:49 AM, "larry mccay" <lm...@apache.org> wrote:
> >
> > >We really need to fix this behavior...
> > >
> > >It seems you traded in your random authentication provider for a random
> > >federation provider. :/
> > >
> > >This is most likely due to not having your new provider on the classpath
> > >for the serviceLoader to find.
> > >
> > >Just to try and articulate how it works...
> > >
> > >The deployment machinery loads all of the federation (whichever role)
> > >providers contributors that is finds on the classpath - via the
> >
> >
> >src/main/resources/META-INF/services/org.apache.hadoop.gateway.deploy.ProviderDeploymentContributor
> > >- and interrogates each for its name to match to the name in the
> topology.
> > >Once it finds a match it allows the contributor to "contribute" to the
> > >creation of the topology specific webapp. Part of which includes adding
> > >filters to the gateway.xml.
> > >
> > >We currently have an issue wherein, given a name that doesn't match any
> > >found on the classpath, a random provider is returned. This needs to be
> > >fixed to fail deployment with appropriate error messages.
> > >
> > >Now, this usually comes down to one of 2 things:
> > >
> > >1. there is no
> >
> src/main/resources/META-INF/services/org.apache.hadoop.gateway.deploy.ProviderDeploymentContributor
> > >file in the provider or it contains the classname of some other
> > contributor
> > >2. the provider itself isn't on the gateway classpath. I see that your
> > >service file seems to be defined properly - so it is probably not on the
> > >classpath. Did you add the new provider to the parent pom? The article
> > >should provide all you need to do so.
> > >
> > >I will file a JIRA to fix the random provider issue.
> > >
> > >On Thu, Nov 12, 2015 at 7:18 AM, Jérôme LELEU <le...@gmail.com> wrote:
> > >
> > >> Hi,
> > >>
> > >> By changing the role to the appropriate value, the error is gone, but
> I
> > >> have a new problem:
> > >>
> > >> *Caused by: javax.servlet.ServletException: Required authentication
> > >> provider URL is missing.*
> > >> * at
> > >>
> > >>
> >
> org.apache.hadoop.gateway.provider.federation.jwt.filter.SSOCookieFederationFilter.init(SSOCookieFederationFilter.java:90)*
> > >>
> > >> My sandbox.xml file only references the pac4j provider as well as the
> > >> Default (role: identity-assertion) and static (role: hostmap) ones.
> > >>
> > >> Though, the SSOCookieFederationFilter is defined in the gateway.xml
> > file of
> > >> my sandbox deployment. Why do I need it? What's the expected
> > authentication
> > >> provider url? How this gatweay.xml is generated?
> > >>
> > >> Thanks.
> > >> Best regards,
> > >> Jérôme
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> 2015-11-10 17:36 GMT+01:00 Kevin Minder <kevin.minder@hortonworks.com
> >:
> > >>
> > >> > To be a bit more explicit your Pac4jFederationProviderContributor
> > >> declares
> > >> > itself to be of role “federation” but when you used it in the
> > sandbox.xml
> > >> > topology file you were attempting to configure it as an provider
> with
> > >> role
> > >> > authentication.
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On 11/10/15, 11:32 AM, "larry mccay" <lm...@apache.org> wrote:
> > >> >
> > >> > >Let's get you past the error that you are getting...
> > >> > >
> > >> > >It seems as though you have change the topology for pac4j but
> didn't
> > >> > change
> > >> > >the role to "federation".
> > >> > >It looks like it is grabbing a random authentication provider and
> > seems
> > >> to
> > >> > >be the hadoop-auth provider.
> > >> > >
> > >> > >Change that to federation and see if that helps.
> > >> > >
> > >> > >On Tue, Nov 10, 2015 at 11:21 AM, larry mccay <lm...@apache.org>
> > >> wrote:
> > >> > >
> > >> > >> Hi Jérôme -
> > >> > >>
> > >> > >> Happy to see you here!
> > >> > >> I apologize for having missed your note on the list a few days
> ago.
> > >> > >>
> > >> > >> Glad to see that the article was helpful and it seems like you
> are
> > >> > making
> > >> > >> great progress.
> > >> > >>
> > >> > >> Let me dig into your note a bit deeper and answer your questions.
> > >> > >>
> > >> > >> Welcome!
> > >> > >>
> > >> > >> --larry
> > >> > >>
> > >> > >> On Tue, Nov 10, 2015 at 11:14 AM, Jérôme LELEU <leleuj@gmail.com
> >
> > >> > wrote:
> > >> > >>
> > >> > >>> Hi,
> > >> > >>>
> > >> > >>> Perfect timing ;-) I have started implemented the pac4j support
> in
> > >> > Knox,
> > >> > >>> it's a very basic attempt:
> > >> https://github.com/apache/knox/pull/2/files
> > >> > >>>
> > >> > >>> This implementation reuses the pac4j implementation for J2E. I
> > have a
> > >> > >>> ProviderDeploymentContributorBase which registers two filters:
> > >> > >>> - the first one is a dispatcher filter which uses the j2e-pac4j
> > >> > >>> CallbackFilter on the /callabck url (it finishes the
> > authentication
> > >> > process
> > >> > >>> after a successful authentication at some identity provider) and
> > uses
> > >> > the
> > >> > >>> j2e-pac4j RequiresAuthenticationFilter otherwise (redirection to
> > the
> > >> > >>> identity provider to start the authentication when the user is
> not
> > >> > >>> authenticated)
> > >> > >>> - the second one is an identity adapter which gets the current
> > >> > >>> authenticated user from the pac4j point of view and populates
> the
> > J2E
> > >> > >>> security context.
> > >> > >>>
> > >> > >>>
> > >> > >>> * I have the following error:
> > >> > >>>
> > >> > >>> 2015-11-10 16:30:22,347 ERROR hadoop.gateway
> > >> > >>> (GatewayFilter.java:doFilter(135)) - Gateway processing failed:
> > >> > >>> javax.servlet.ServletException: javax.servlet.ServletException:
> > >> > >>> Authentication type must be specified: simple|kerberos|<class>
> > >> > >>> javax.servlet.ServletException: javax.servlet.ServletException:
> > >> > >>> Authentication type must be specified: simple|kerberos|<class>
> > >> > >>> at
> > >> > >>>
> > >> >
> > >>
> >
> org.apache.hadoop.gateway.GatewayFilter$Holder.getInstance(GatewayFilter.java:354)
> > >> > >>>
> > >> > >>> Notice I have changed the sandbox.xml file to use pac4j instead
> of
> > >> > Shiro,
> > >> > >>> maybe it's not the right way:
> > >> > >>>
> > >> >
> > >>
> >
> https://github.com/apache/knox/pull/2/files#diff-128ca80baa2dfd6c2d25de7b8160b9d9R24
> > >> > >>>
> > >> > >>> Any idea of the problem?
> > >> > >>>
> > >> > >>>
> > >> > >>> * Am I understanding webflows correctly?
> > >> > >>>
> > >> > >>> I use the default request to: curl -ivk "
> > >> > >>>
> > https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS"
> > >> > >>>
> > >> > >>> It looks like a REST request, though I'm expecting the following
> > >> > webflow:
> > >> > >>> redirection of the user to the identity provider, successful
> > login,
> > >> > >>> redirection back to the /callback url of the gateway: do I get
> it
> > >> > right?
> > >> > >>>
> > >> > >>>
> > >> > >>> * The callback url
> > >> > >>>
> > >> > >>> I currently do a check expecting the last part of the url to end
> > with
> > >> > >>> /callback, but does the gateway will receive requests on this
> url?
> > >> Do I
> > >> > >>> have to do something special?
> > >> > >>>
> > >> > >>> It's highly recommended to only have one callback url as this
> url
> > is
> > >> > >>> defined on the identity provider side.
> > >> > >>>
> > >> > >>>
> > >> > >>> * How to pass configuration?
> > >> > >>>
> > >> > >>> Currently, I hardcoded a FacebookClient for Facebook
> > authentication,
> > >> > but
> > >> > >>> we should be able to pass the appropriate client like Facebook
> or
> > >> SAML.
> > >> > >>> Basically, we could do that using filter properties:
> facebook.key
> > +
> > >> > >>> facebook.secret means we use Facebook authentication with the
> > >> > appropriate
> > >> > >>> key and secret for example. Any recommendation?
> > >> > >>>
> > >> > >>>
> > >> > >>> * Can I use the J2E session to store the requested protected url
> > and
> > >> > >>> other information?
> > >> > >>>
> > >> > >>> Or do I need to do something special?
> > >> > >>>
> > >> > >>>
> > >> > >>> Thanks.
> > >> > >>> Best regards,
> > >> > >>> Jérôme
> > >> > >>>
> > >> > >>> 2015-11-10 17:03 GMT+01:00 Kevin Minder <
> > >> kevin.minder@hortonworks.com
> > >> > >:
> > >> > >>>
> > >> > >>>> Hi Jerome,
> > >> > >>>> This sounds very exciting and is just the sort of thing the
> open
> > >> > >>>> architecture of Knox is intended to allow. Larry and I have
> > looked
> > >> at
> > >> > >>>> pac4j a number of times thinking that it would be a good fit
> and
> > >> would
> > >> > >>>> provide a great feature set to the Hadoop community.
> > >> > >>>> Kevin.
> > >> > >>>>
> > >> > >>>>
> > >> > >>>>
> > >> > >>>> On 11/6/15, 3:31 AM, "Jérôme LELEU" <le...@gmail.com> wrote:
> > >> > >>>>
> > >> > >>>> >Hi,
> > >> > >>>> >
> > >> > >>>> >Let's open this private discussion on the Knox dev mailing
> list.
> > >> > >>>> >
> > >> > >>>> >I'm Jerome Leleu and the creator of pac4j (
> > >> > >>>> https://github.com/pac4j/pac4j),
> > >> > >>>> >a security engine for Java with many implementations for J2E,
> > Play,
> > >> > >>>> Spring,
> > >> > >>>> >Vertx, Ratpack... The idea is to offer something as powerful
> as
> > >> > Spring
> > >> > >>>> >Security, but a lot easier and for all Java frameworks / tools
> > and
> > >> > all
> > >> > >>>> >authentication mechanisms.
> > >> > >>>> >
> > >> > >>>> >Two years ago, we had a discussion with Larry on how pac4j
> > could be
> > >> > >>>> used in
> > >> > >>>> >Knox.
> > >> > >>>> >
> > >> > >>>> >Meanwhile, both projects have grown up and I'm back to try to
> > see
> > >> if
> > >> > >>>> pac4j
> > >> > >>>> >can help Knox in terms of security.
> > >> > >>>> >
> > >> > >>>> >-----
> > >> > >>>> >
> > >> > >>>> >In its latest version, pac4j can be used to build a full
> > security
> > >> > >>>> library,
> > >> > >>>> >not only focused on delegated authentication (Facebook, SAML).
> > So
> > >> we
> > >> > >>>> have
> > >> > >>>> >the concepts of direct clients (a client is an authentication
> > >> > >>>> mechanism):
> > >> > >>>> >basic auth, header, token... and indirect clients: SAML,
> > Facebook,
> > >> > >>>> OpenID,
> > >> > >>>> >CAS...
> > >> > >>>> >It seems to be very close to the Authentication and Federation
> > >> > Providers
> > >> > >>>> >concepts from Knox.
> > >> > >>>> >
> > >> > >>>> >The provided article is great and as it's focused on
> > authentication
> > >> > >>>> with a
> > >> > >>>> >real example, it's easier to start with it.
> > >> > >>>> >
> > >> > >>>> >Thanks for your answers.
> > >> > >>>> >
> > >> > >>>> >Like Shiro, pac4j has LDAP support and caching can be done.
> The
> > >> only
> > >> > >>>> >difference is that pac4j relies on ldaptive (
> > >> > http://www.ldaptive.org/).
> > >> > >>>> But
> > >> > >>>> >I think you're right: it would be better to start by
> > implementing
> > >> the
> > >> > >>>> >Federation part which might be the most expected feature for
> > Knox
> > >> > users
> > >> > >>>> (a
> > >> > >>>> >bit like buji-pac4j: https://github.com/bujiio/buji-pac4j is
> > for
> > >> > >>>> Shiro) and
> > >> > >>>> >see if it's worth the work to have an authentication provider
> > with
> > >> > >>>> pac4j in
> > >> > >>>> >addition to the one of Shiro.
> > >> > >>>> >
> > >> > >>>> >I plan to start working on that next week. Do you accept pull
> > >> > requests
> > >> > >>>> on
> > >> > >>>> >Github (it would make discussion easier on source code)?
> > >> > >>>> >
> > >> > >>>> >Any feedback will be appreciated.
> > >> > >>>> >
> > >> > >>>> >Thanks.
> > >> > >>>> >Best regards,
> > >> > >>>> >Jérôme
> > >> > >>>> >
> > >> > >>>> >
> > >> > >>>> >
> > >> > >>>> >
> > >> > >>>> >
> > >> > >>>> >
> > >> > >>>> >2015-11-05 17:13 GMT+01:00 larry mccay:
> > >> > >>>> >
> > >> > >>>> >> Hi Jérôme -
> > >> > >>>> >>
> > >> > >>>> >> Contributions coming from the community are owned and
> > maintained
> > >> by
> > >> > >>>> the
> > >> > >>>> >> entire community.
> > >> > >>>> >> You would certainly not be expected to do all work on it and
> > at
> > >> the
> > >> > >>>> same
> > >> > >>>> >> time any assistance and upgrade messages that you provided
> > would
> > >> be
> > >> > >>>> awesome.
> > >> > >>>> >>
> > >> > >>>> >> As for an empty module for pac4j, maybe the following
> example
> > >> > project
> > >> > >>>> >> would be helpful to you:
> > >> > >>>> >>
> > >> > >>>> >> https://github.com/lmccay/gateway-provider-security-pseudo
> > >> > >>>> >>
> > >> > >>>> >> It is in support of an article to illustrate how to go about
> > >> > adding a
> > >> > >>>> >> authentication or federation provider - as you would be
> doing:
> > >> > >>>> >>
> > >> > >>>> >>
> > >> > >>>>
> > >> >
> > >>
> >
> https://github.com/lmccay/gateway-provider-security-pseudo/blob/master/AddingFederationProvider.md
> > >> > >>>> >>
> > >> > >>>> >> That may be easier to consume than the entire developers
> > guide.
> > >> > >>>> >> That said, it would be great if you could describe what
> makes
> > the
> > >> > dev
> > >> > >>>> >> guide too much - if that is the case.
> > >> > >>>> >>
> > >> > >>>> >> I'll take a stab at your questions here but we should move
> > more
> > >> > >>>> detailed
> > >> > >>>> >> discussions on the topic to the dev@ list in order to keep
> > this
> > >> in
> > >> > >>>> the
> > >> > >>>> >> open and provide insights to others:
> > >> > >>>> >>
> > >> > >>>> >> 1) What do I do with the authenticated user: where / how do
> I
> > >> fill
> > >> > >>>> this
> > >> > >>>> >> identity in Knox?
> > >> > >>>> >>
> > >> > >>>> >> We normalize the authentication event into a Java subject to
> > >> > >>>> represent the
> > >> > >>>> >> user, groups and impersonated user as appropriate.
> > >> > >>>> >> In cases - like shiro - where we don't have access to the
> > actual
> > >> > >>>> >> authenticating code and we need to normalize the provider
> > >> specific
> > >> > >>>> security
> > >> > >>>> >> context, we add another filter. You can look at the shiro
> > >> provider
> > >> > >>>> for an
> > >> > >>>> >> example. The code inside the simple example provider in the
> > >> article
> > >> > >>>> also
> > >> > >>>> >> shows what is expected at least in terms of the
> > PrimaryPrincipal.
> > >> > >>>> >>
> > >> > >>>> >> 2) How to handle errors: not authenticated, not authorized?
> > >> > >>>> >>
> > >> > >>>> >> We aren't intrusive on what should be done by a provider
> here.
> > >> > >>>> >> Generally, authentication failures result in a 401 and
> > >> > authorizations
> > >> > >>>> in a
> > >> > >>>> >> 403 and they are usually sent by the provider.
> > >> > >>>> >>
> > >> > >>>> >> 3) How to handle redirections to an external provider?
> > >> > >>>> >>
> > >> > >>>> >> Redirects are sent by the providers themselves with a 307 or
> > 302.
> > >> > >>>> >> You can look at the SSOCookieFederationFilter in the jwt
> > module
> > >> as
> > >> > an
> > >> > >>>> >> example if you like.
> > >> > >>>> >>
> > >> > >>>> >> 4) Should the pac4j filter also handle authorizations (pac4j
> > can
> > >> do
> > >> > >>>> that)?
> > >> > >>>> >>
> > >> > >>>> >> This is an interesting question.
> > >> > >>>> >> Knox provides a separate slot in the provider chain for
> > >> > authorization.
> > >> > >>>> >> It is there because of the ability for identity assertion
> > >> providers
> > >> > >>>> to map
> > >> > >>>> >> principals in order to impersonate another user or map
> > external
> > >> > >>>> usernames
> > >> > >>>> >> to those used inside of hadoop clusters. So, the
> authorization
> > >> > >>>> decisions
> > >> > >>>> >> are made based on those identities.
> > >> > >>>> >>
> > >> > >>>> >> If we can add the authorization filter as an authorization
> > >> provider
> > >> > >>>> rather
> > >> > >>>> >> than part of the authentication provider than that might
> make
> > >> > sense.
> > >> > >>>> >> Although, the security context is normalized as Knox expects
> > not
> > >> as
> > >> > >>>> pac4j
> > >> > >>>> >> authorization probably does. Now, if there is real value in
> > doing
> > >> > so,
> > >> > >>>> the
> > >> > >>>> >> pac4j Subject adaptor could stuff additional context into
> the
> > >> > Subject
> > >> > >>>> or
> > >> > >>>> >> the request that can be accessed later by the pac4j
> > authorization
> > >> > >>>> provider.
> > >> > >>>> >>
> > >> > >>>> >> So, it can be done - the question is whether there is
> > compelling
> > >> > >>>> reason to
> > >> > >>>> >> do so.
> > >> > >>>> >>
> > >> > >>>> >> 5) How to test?
> > >> > >>>> >>
> > >> > >>>> >> This can be challenging especially for external
> > authentications
> > >> and
> > >> > >>>> web
> > >> > >>>> >> app flows.
> > >> > >>>> >> Generally, unit testing as much as possible is required.
> > >> > >>>> >> We would want to make sure that the security context
> > >> normalization
> > >> > >>>> happens
> > >> > >>>> >> as expected, etc.
> > >> > >>>> >>
> > >> > >>>> >> Additional considerations:
> > >> > >>>> >>
> > >> > >>>> >> 1. Our Shiro provider does group lookup and caching of the
> > >> > >>>> authentication
> > >> > >>>> >> event for optimizing interactions with authentication
> servers,
> > >> > LDAP,
> > >> > >>>> AD,
> > >> > >>>> >> etc. We wouldn't want to lose these. Doing so would be a
> > >> > non-starter
> > >> > >>>> for
> > >> > >>>> >> most folks replacing what Shiro is used for today.
> > >> > >>>> >> 2. It is probably best to concentrate on the gaps that pac4j
> > can
> > >> > fill
> > >> > >>>> for
> > >> > >>>> >> openid, oauth, etc for the initial contribution and if the
> > >> usecases
> > >> > >>>> handled
> > >> > >>>> >> by Shiro can be done better, easier, simpler then we can
> > >> consider a
> > >> > >>>> >> migration path.
> > >> > >>>> >>
> > >> > >>>> >> BTW - we have a couple very interesting possibilities for
> > strong
> > >> > and
> > >> > >>>> >> multi-factor authentication that would be enabled by OpenID
> > >> > >>>> immediately.
> > >> > >>>> >>
> > >> > >>>> >> Hope this isn't too long a response and that it is helpful
> for
> > >> you.
> > >> > >>>> >>
> > >> > >>>> >> Let's determine what an initial contribution would be for
> and
> > >> > bring a
> > >> > >>>> >> proposal to the dev@ list and/or file a jira for the
> > >> integration.
> > >> > >>>> >> This would be great for adding features and growing the
> > >> community -
> > >> > >>>> so we
> > >> > >>>> >> are all for it!
> > >> > >>>> >>
> > >> > >>>> >> thanks,
> > >> > >>>> >>
> > >> > >>>> >> --larry
> > >> > >>>> >>
> > >> > >>>> >>
> > >> > >>>> >> On Thu, Nov 5, 2015 at 9:43 AM, Jérôme LELEU <
> > leleuj@gmail.com>
> > >> > >>>> wrote:
> > >> > >>>> >>
> > >> > >>>> >>> Hi,
> > >> > >>>> >>>
> > >> > >>>> >>> I see that Shiro is already used for basic auth and LDAP
> > >> > >>>> authentication
> > >> > >>>> >>> and Picketlink for SAML. pac4j v1.8 can now handle both
> cases
> > >> and
> > >> > >>>> even
> > >> > >>>> >>> more. So I think we could create a
> > >> gateway-provider-security-pac4j
> > >> > >>>> >>> supporting all authentication mechanisms and not only
> OpenID.
> > >> > >>>> >>>
> > >> > >>>> >>> pac4j implementations generally work with two filters: one
> to
> > >> > >>>> protect a
> > >> > >>>> >>> resource and play direct authentication like basic auth
> (and
> > >> check
> > >> > >>>> >>> authorizations) and a callback filter to finish remote
> > >> > >>>> authentication like
> > >> > >>>> >>> Facebook, SAML, OpenID. The easiest one is the j2e-pac4j
> > with:
> > >> > >>>> >>>
> > >> > >>>>
> > >> >
> > >>
> >
> https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/RequiresAuthenticationFilter.java#L96
> > >> > >>>> >>> and
> > >> > >>>> >>>
> > >> > >>>>
> > >> >
> > >>
> >
> https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/CallbackFilter.java#L65
> > >> > >>>> >>>
> > >> > >>>> >>> That said, I have already many pac4j implementations to
> > handle
> > >> so
> > >> > I'm
> > >> > >>>> >>> pushing communities to maintain on their own their pac4j
> > >> > >>>> implementations:
> > >> > >>>> >>> can we imagine having an official:
> > >> gateway-provider-security-pac4j
> > >> > >>>> module
> > >> > >>>> >>> maintained by the Knox community with my help of course?
> > This is
> > >> > the
> > >> > >>>> kind
> > >> > >>>> >>> of message I deliver to communities when a new version of
> > pac4j
> > >> is
> > >> > >>>> >>> available so that they can upgrade:
> > >> > >>>> >>> https://github.com/ratpack/ratpack/issues/819
> > >> > >>>> >>>
> > >> > >>>> >>> I read:
> > >> > >>>>
> > https://knox.apache.org/books/knox-0-6-0/dev-guide.html#Providers,
> > >> > >>>> >>> it might be easy for Knox contributors, but it's a bit hard
> > for
> > >> me
> > >> > >>>> to get
> > >> > >>>> >>> in everything: can you or someone in the Knox community
> > provides
> > >> > me
> > >> > >>>> an
> > >> > >>>> >>> empty gateway-provider-security-pac4j module and the
> default
> > >> > >>>> expectations
> > >> > >>>> >>> from a Knox point of view?
> > >> > >>>> >>> My main questions:
> > >> > >>>> >>> 1) What do I do with the authenticated user: where / how
> do I
> > >> fill
> > >> > >>>> this
> > >> > >>>> >>> identity in Knox?
> > >> > >>>> >>> 2) How to handle errors: not authenticated, not authorized?
> > >> > >>>> >>> 3) How to handle redirections to an external provider?
> > >> > >>>> >>> 4) Should the pac4j filter also handle authorizations
> (pac4j
> > can
> > >> > do
> > >> > >>>> that)?
> > >> > >>>> >>> 5) How to test?
> > >> > >>>> >>>
> > >> > >>>> >>> Thanks.
> > >> > >>>> >>> Best regards,
> > >> > >>>> >>> Jérôme
> > >> > >>>> >>>
> > >> > >>>> >>>
> > >> > >>>> >>>
> > >> > >>>> >>>
> > >> > >>>> >>> 2015-11-03 16:58 GMT+01:00 larry mccay:
> > >> > >>>> >>>
> > >> > >>>> >>>> Hi Jérôme -
> > >> > >>>> >>>>
> > >> > >>>> >>>> We were evaluating buji-pac4j for SSO with SAML and ended
> up
> > >> > going
> > >> > >>>> with
> > >> > >>>> >>>> Picketlink at the time.
> > >> > >>>> >>>> That said, we do have a pluggable architecture that would
> > allow
> > >> > for
> > >> > >>>> a
> > >> > >>>> >>>> pac4j provider as well.
> > >> > >>>> >>>>
> > >> > >>>> >>>> If you are interested in contributing such a provider that
> > >> would
> > >> > >>>> >>>> certainly be welcome.
> > >> > >>>> >>>> There is someone in the community working on an openid
> > provider
> > >> > but
> > >> > >>>> >>>> perhaps pac4j would be the way to go there?
> > >> > >>>> >>>>
> > >> > >>>> >>>> thanks,
> > >> > >>>> >>>>
> > >> > >>>> >>>> --larry
> > >> > >>>> >>>>
> > >> > >>>> >>>>
> > >> > >>>>
> > >> > >>>
> > >> > >>>
> > >> > >>
> > >> >
> > >>
> >
>
Re: pac4j and Apache Knox
Posted by larry mccay <lm...@apache.org>.
Yes, Kevin, that seems to be missing from the pull request.
Also, the parent pom doesn't have all of the changes needed to add a new
module.
See the section in the article called "Root Level Pom.xml" and the section
below that for the "Gateway Release Module Pom.xml"
https://github.com/lmccay/gateway-provider-security-pseudo/blob/master/AddingFederationProvider.md#root-level-pomxml
On Thu, Nov 12, 2015 at 8:04 AM, Kevin Minder <ke...@hortonworks.com>
wrote:
> I think I know what it probably is. The gateway-release module pom.xml is
> what actually defines the classpath of the final packaged server. If you
> take a look at that you will see it references all of the providers that
> are intended to be included by default. Try adding yours to the
> dependencies.
>
>
>
>
> On 11/12/15, 7:49 AM, "larry mccay" <lm...@apache.org> wrote:
>
> >We really need to fix this behavior...
> >
> >It seems you traded in your random authentication provider for a random
> >federation provider. :/
> >
> >This is most likely due to not having your new provider on the classpath
> >for the serviceLoader to find.
> >
> >Just to try and articulate how it works...
> >
> >The deployment machinery loads all of the federation (whichever role)
> >providers contributors that is finds on the classpath - via the
>
> >src/main/resources/META-INF/services/org.apache.hadoop.gateway.deploy.ProviderDeploymentContributor
> >- and interrogates each for its name to match to the name in the topology.
> >Once it finds a match it allows the contributor to "contribute" to the
> >creation of the topology specific webapp. Part of which includes adding
> >filters to the gateway.xml.
> >
> >We currently have an issue wherein, given a name that doesn't match any
> >found on the classpath, a random provider is returned. This needs to be
> >fixed to fail deployment with appropriate error messages.
> >
> >Now, this usually comes down to one of 2 things:
> >
> >1. there is no
> src/main/resources/META-INF/services/org.apache.hadoop.gateway.deploy.ProviderDeploymentContributor
> >file in the provider or it contains the classname of some other
> contributor
> >2. the provider itself isn't on the gateway classpath. I see that your
> >service file seems to be defined properly - so it is probably not on the
> >classpath. Did you add the new provider to the parent pom? The article
> >should provide all you need to do so.
> >
> >I will file a JIRA to fix the random provider issue.
> >
> >On Thu, Nov 12, 2015 at 7:18 AM, Jérôme LELEU <le...@gmail.com> wrote:
> >
> >> Hi,
> >>
> >> By changing the role to the appropriate value, the error is gone, but I
> >> have a new problem:
> >>
> >> *Caused by: javax.servlet.ServletException: Required authentication
> >> provider URL is missing.*
> >> * at
> >>
> >>
> org.apache.hadoop.gateway.provider.federation.jwt.filter.SSOCookieFederationFilter.init(SSOCookieFederationFilter.java:90)*
> >>
> >> My sandbox.xml file only references the pac4j provider as well as the
> >> Default (role: identity-assertion) and static (role: hostmap) ones.
> >>
> >> Though, the SSOCookieFederationFilter is defined in the gateway.xml
> file of
> >> my sandbox deployment. Why do I need it? What's the expected
> authentication
> >> provider url? How this gatweay.xml is generated?
> >>
> >> Thanks.
> >> Best regards,
> >> Jérôme
> >>
> >>
> >>
> >>
> >>
> >> 2015-11-10 17:36 GMT+01:00 Kevin Minder <ke...@hortonworks.com>:
> >>
> >> > To be a bit more explicit your Pac4jFederationProviderContributor
> >> declares
> >> > itself to be of role “federation” but when you used it in the
> sandbox.xml
> >> > topology file you were attempting to configure it as an provider with
> >> role
> >> > authentication.
> >> >
> >> >
> >> >
> >> >
> >> > On 11/10/15, 11:32 AM, "larry mccay" <lm...@apache.org> wrote:
> >> >
> >> > >Let's get you past the error that you are getting...
> >> > >
> >> > >It seems as though you have change the topology for pac4j but didn't
> >> > change
> >> > >the role to "federation".
> >> > >It looks like it is grabbing a random authentication provider and
> seems
> >> to
> >> > >be the hadoop-auth provider.
> >> > >
> >> > >Change that to federation and see if that helps.
> >> > >
> >> > >On Tue, Nov 10, 2015 at 11:21 AM, larry mccay <lm...@apache.org>
> >> wrote:
> >> > >
> >> > >> Hi Jérôme -
> >> > >>
> >> > >> Happy to see you here!
> >> > >> I apologize for having missed your note on the list a few days ago.
> >> > >>
> >> > >> Glad to see that the article was helpful and it seems like you are
> >> > making
> >> > >> great progress.
> >> > >>
> >> > >> Let me dig into your note a bit deeper and answer your questions.
> >> > >>
> >> > >> Welcome!
> >> > >>
> >> > >> --larry
> >> > >>
> >> > >> On Tue, Nov 10, 2015 at 11:14 AM, Jérôme LELEU <le...@gmail.com>
> >> > wrote:
> >> > >>
> >> > >>> Hi,
> >> > >>>
> >> > >>> Perfect timing ;-) I have started implemented the pac4j support in
> >> > Knox,
> >> > >>> it's a very basic attempt:
> >> https://github.com/apache/knox/pull/2/files
> >> > >>>
> >> > >>> This implementation reuses the pac4j implementation for J2E. I
> have a
> >> > >>> ProviderDeploymentContributorBase which registers two filters:
> >> > >>> - the first one is a dispatcher filter which uses the j2e-pac4j
> >> > >>> CallbackFilter on the /callabck url (it finishes the
> authentication
> >> > process
> >> > >>> after a successful authentication at some identity provider) and
> uses
> >> > the
> >> > >>> j2e-pac4j RequiresAuthenticationFilter otherwise (redirection to
> the
> >> > >>> identity provider to start the authentication when the user is not
> >> > >>> authenticated)
> >> > >>> - the second one is an identity adapter which gets the current
> >> > >>> authenticated user from the pac4j point of view and populates the
> J2E
> >> > >>> security context.
> >> > >>>
> >> > >>>
> >> > >>> * I have the following error:
> >> > >>>
> >> > >>> 2015-11-10 16:30:22,347 ERROR hadoop.gateway
> >> > >>> (GatewayFilter.java:doFilter(135)) - Gateway processing failed:
> >> > >>> javax.servlet.ServletException: javax.servlet.ServletException:
> >> > >>> Authentication type must be specified: simple|kerberos|<class>
> >> > >>> javax.servlet.ServletException: javax.servlet.ServletException:
> >> > >>> Authentication type must be specified: simple|kerberos|<class>
> >> > >>> at
> >> > >>>
> >> >
> >>
> org.apache.hadoop.gateway.GatewayFilter$Holder.getInstance(GatewayFilter.java:354)
> >> > >>>
> >> > >>> Notice I have changed the sandbox.xml file to use pac4j instead of
> >> > Shiro,
> >> > >>> maybe it's not the right way:
> >> > >>>
> >> >
> >>
> https://github.com/apache/knox/pull/2/files#diff-128ca80baa2dfd6c2d25de7b8160b9d9R24
> >> > >>>
> >> > >>> Any idea of the problem?
> >> > >>>
> >> > >>>
> >> > >>> * Am I understanding webflows correctly?
> >> > >>>
> >> > >>> I use the default request to: curl -ivk "
> >> > >>>
> https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS"
> >> > >>>
> >> > >>> It looks like a REST request, though I'm expecting the following
> >> > webflow:
> >> > >>> redirection of the user to the identity provider, successful
> login,
> >> > >>> redirection back to the /callback url of the gateway: do I get it
> >> > right?
> >> > >>>
> >> > >>>
> >> > >>> * The callback url
> >> > >>>
> >> > >>> I currently do a check expecting the last part of the url to end
> with
> >> > >>> /callback, but does the gateway will receive requests on this url?
> >> Do I
> >> > >>> have to do something special?
> >> > >>>
> >> > >>> It's highly recommended to only have one callback url as this url
> is
> >> > >>> defined on the identity provider side.
> >> > >>>
> >> > >>>
> >> > >>> * How to pass configuration?
> >> > >>>
> >> > >>> Currently, I hardcoded a FacebookClient for Facebook
> authentication,
> >> > but
> >> > >>> we should be able to pass the appropriate client like Facebook or
> >> SAML.
> >> > >>> Basically, we could do that using filter properties: facebook.key
> +
> >> > >>> facebook.secret means we use Facebook authentication with the
> >> > appropriate
> >> > >>> key and secret for example. Any recommendation?
> >> > >>>
> >> > >>>
> >> > >>> * Can I use the J2E session to store the requested protected url
> and
> >> > >>> other information?
> >> > >>>
> >> > >>> Or do I need to do something special?
> >> > >>>
> >> > >>>
> >> > >>> Thanks.
> >> > >>> Best regards,
> >> > >>> Jérôme
> >> > >>>
> >> > >>> 2015-11-10 17:03 GMT+01:00 Kevin Minder <
> >> kevin.minder@hortonworks.com
> >> > >:
> >> > >>>
> >> > >>>> Hi Jerome,
> >> > >>>> This sounds very exciting and is just the sort of thing the open
> >> > >>>> architecture of Knox is intended to allow. Larry and I have
> looked
> >> at
> >> > >>>> pac4j a number of times thinking that it would be a good fit and
> >> would
> >> > >>>> provide a great feature set to the Hadoop community.
> >> > >>>> Kevin.
> >> > >>>>
> >> > >>>>
> >> > >>>>
> >> > >>>> On 11/6/15, 3:31 AM, "Jérôme LELEU" <le...@gmail.com> wrote:
> >> > >>>>
> >> > >>>> >Hi,
> >> > >>>> >
> >> > >>>> >Let's open this private discussion on the Knox dev mailing list.
> >> > >>>> >
> >> > >>>> >I'm Jerome Leleu and the creator of pac4j (
> >> > >>>> https://github.com/pac4j/pac4j),
> >> > >>>> >a security engine for Java with many implementations for J2E,
> Play,
> >> > >>>> Spring,
> >> > >>>> >Vertx, Ratpack... The idea is to offer something as powerful as
> >> > Spring
> >> > >>>> >Security, but a lot easier and for all Java frameworks / tools
> and
> >> > all
> >> > >>>> >authentication mechanisms.
> >> > >>>> >
> >> > >>>> >Two years ago, we had a discussion with Larry on how pac4j
> could be
> >> > >>>> used in
> >> > >>>> >Knox.
> >> > >>>> >
> >> > >>>> >Meanwhile, both projects have grown up and I'm back to try to
> see
> >> if
> >> > >>>> pac4j
> >> > >>>> >can help Knox in terms of security.
> >> > >>>> >
> >> > >>>> >-----
> >> > >>>> >
> >> > >>>> >In its latest version, pac4j can be used to build a full
> security
> >> > >>>> library,
> >> > >>>> >not only focused on delegated authentication (Facebook, SAML).
> So
> >> we
> >> > >>>> have
> >> > >>>> >the concepts of direct clients (a client is an authentication
> >> > >>>> mechanism):
> >> > >>>> >basic auth, header, token... and indirect clients: SAML,
> Facebook,
> >> > >>>> OpenID,
> >> > >>>> >CAS...
> >> > >>>> >It seems to be very close to the Authentication and Federation
> >> > Providers
> >> > >>>> >concepts from Knox.
> >> > >>>> >
> >> > >>>> >The provided article is great and as it's focused on
> authentication
> >> > >>>> with a
> >> > >>>> >real example, it's easier to start with it.
> >> > >>>> >
> >> > >>>> >Thanks for your answers.
> >> > >>>> >
> >> > >>>> >Like Shiro, pac4j has LDAP support and caching can be done. The
> >> only
> >> > >>>> >difference is that pac4j relies on ldaptive (
> >> > http://www.ldaptive.org/).
> >> > >>>> But
> >> > >>>> >I think you're right: it would be better to start by
> implementing
> >> the
> >> > >>>> >Federation part which might be the most expected feature for
> Knox
> >> > users
> >> > >>>> (a
> >> > >>>> >bit like buji-pac4j: https://github.com/bujiio/buji-pac4j is
> for
> >> > >>>> Shiro) and
> >> > >>>> >see if it's worth the work to have an authentication provider
> with
> >> > >>>> pac4j in
> >> > >>>> >addition to the one of Shiro.
> >> > >>>> >
> >> > >>>> >I plan to start working on that next week. Do you accept pull
> >> > requests
> >> > >>>> on
> >> > >>>> >Github (it would make discussion easier on source code)?
> >> > >>>> >
> >> > >>>> >Any feedback will be appreciated.
> >> > >>>> >
> >> > >>>> >Thanks.
> >> > >>>> >Best regards,
> >> > >>>> >Jérôme
> >> > >>>> >
> >> > >>>> >
> >> > >>>> >
> >> > >>>> >
> >> > >>>> >
> >> > >>>> >
> >> > >>>> >2015-11-05 17:13 GMT+01:00 larry mccay:
> >> > >>>> >
> >> > >>>> >> Hi Jérôme -
> >> > >>>> >>
> >> > >>>> >> Contributions coming from the community are owned and
> maintained
> >> by
> >> > >>>> the
> >> > >>>> >> entire community.
> >> > >>>> >> You would certainly not be expected to do all work on it and
> at
> >> the
> >> > >>>> same
> >> > >>>> >> time any assistance and upgrade messages that you provided
> would
> >> be
> >> > >>>> awesome.
> >> > >>>> >>
> >> > >>>> >> As for an empty module for pac4j, maybe the following example
> >> > project
> >> > >>>> >> would be helpful to you:
> >> > >>>> >>
> >> > >>>> >> https://github.com/lmccay/gateway-provider-security-pseudo
> >> > >>>> >>
> >> > >>>> >> It is in support of an article to illustrate how to go about
> >> > adding a
> >> > >>>> >> authentication or federation provider - as you would be doing:
> >> > >>>> >>
> >> > >>>> >>
> >> > >>>>
> >> >
> >>
> https://github.com/lmccay/gateway-provider-security-pseudo/blob/master/AddingFederationProvider.md
> >> > >>>> >>
> >> > >>>> >> That may be easier to consume than the entire developers
> guide.
> >> > >>>> >> That said, it would be great if you could describe what makes
> the
> >> > dev
> >> > >>>> >> guide too much - if that is the case.
> >> > >>>> >>
> >> > >>>> >> I'll take a stab at your questions here but we should move
> more
> >> > >>>> detailed
> >> > >>>> >> discussions on the topic to the dev@ list in order to keep
> this
> >> in
> >> > >>>> the
> >> > >>>> >> open and provide insights to others:
> >> > >>>> >>
> >> > >>>> >> 1) What do I do with the authenticated user: where / how do I
> >> fill
> >> > >>>> this
> >> > >>>> >> identity in Knox?
> >> > >>>> >>
> >> > >>>> >> We normalize the authentication event into a Java subject to
> >> > >>>> represent the
> >> > >>>> >> user, groups and impersonated user as appropriate.
> >> > >>>> >> In cases - like shiro - where we don't have access to the
> actual
> >> > >>>> >> authenticating code and we need to normalize the provider
> >> specific
> >> > >>>> security
> >> > >>>> >> context, we add another filter. You can look at the shiro
> >> provider
> >> > >>>> for an
> >> > >>>> >> example. The code inside the simple example provider in the
> >> article
> >> > >>>> also
> >> > >>>> >> shows what is expected at least in terms of the
> PrimaryPrincipal.
> >> > >>>> >>
> >> > >>>> >> 2) How to handle errors: not authenticated, not authorized?
> >> > >>>> >>
> >> > >>>> >> We aren't intrusive on what should be done by a provider here.
> >> > >>>> >> Generally, authentication failures result in a 401 and
> >> > authorizations
> >> > >>>> in a
> >> > >>>> >> 403 and they are usually sent by the provider.
> >> > >>>> >>
> >> > >>>> >> 3) How to handle redirections to an external provider?
> >> > >>>> >>
> >> > >>>> >> Redirects are sent by the providers themselves with a 307 or
> 302.
> >> > >>>> >> You can look at the SSOCookieFederationFilter in the jwt
> module
> >> as
> >> > an
> >> > >>>> >> example if you like.
> >> > >>>> >>
> >> > >>>> >> 4) Should the pac4j filter also handle authorizations (pac4j
> can
> >> do
> >> > >>>> that)?
> >> > >>>> >>
> >> > >>>> >> This is an interesting question.
> >> > >>>> >> Knox provides a separate slot in the provider chain for
> >> > authorization.
> >> > >>>> >> It is there because of the ability for identity assertion
> >> providers
> >> > >>>> to map
> >> > >>>> >> principals in order to impersonate another user or map
> external
> >> > >>>> usernames
> >> > >>>> >> to those used inside of hadoop clusters. So, the authorization
> >> > >>>> decisions
> >> > >>>> >> are made based on those identities.
> >> > >>>> >>
> >> > >>>> >> If we can add the authorization filter as an authorization
> >> provider
> >> > >>>> rather
> >> > >>>> >> than part of the authentication provider than that might make
> >> > sense.
> >> > >>>> >> Although, the security context is normalized as Knox expects
> not
> >> as
> >> > >>>> pac4j
> >> > >>>> >> authorization probably does. Now, if there is real value in
> doing
> >> > so,
> >> > >>>> the
> >> > >>>> >> pac4j Subject adaptor could stuff additional context into the
> >> > Subject
> >> > >>>> or
> >> > >>>> >> the request that can be accessed later by the pac4j
> authorization
> >> > >>>> provider.
> >> > >>>> >>
> >> > >>>> >> So, it can be done - the question is whether there is
> compelling
> >> > >>>> reason to
> >> > >>>> >> do so.
> >> > >>>> >>
> >> > >>>> >> 5) How to test?
> >> > >>>> >>
> >> > >>>> >> This can be challenging especially for external
> authentications
> >> and
> >> > >>>> web
> >> > >>>> >> app flows.
> >> > >>>> >> Generally, unit testing as much as possible is required.
> >> > >>>> >> We would want to make sure that the security context
> >> normalization
> >> > >>>> happens
> >> > >>>> >> as expected, etc.
> >> > >>>> >>
> >> > >>>> >> Additional considerations:
> >> > >>>> >>
> >> > >>>> >> 1. Our Shiro provider does group lookup and caching of the
> >> > >>>> authentication
> >> > >>>> >> event for optimizing interactions with authentication servers,
> >> > LDAP,
> >> > >>>> AD,
> >> > >>>> >> etc. We wouldn't want to lose these. Doing so would be a
> >> > non-starter
> >> > >>>> for
> >> > >>>> >> most folks replacing what Shiro is used for today.
> >> > >>>> >> 2. It is probably best to concentrate on the gaps that pac4j
> can
> >> > fill
> >> > >>>> for
> >> > >>>> >> openid, oauth, etc for the initial contribution and if the
> >> usecases
> >> > >>>> handled
> >> > >>>> >> by Shiro can be done better, easier, simpler then we can
> >> consider a
> >> > >>>> >> migration path.
> >> > >>>> >>
> >> > >>>> >> BTW - we have a couple very interesting possibilities for
> strong
> >> > and
> >> > >>>> >> multi-factor authentication that would be enabled by OpenID
> >> > >>>> immediately.
> >> > >>>> >>
> >> > >>>> >> Hope this isn't too long a response and that it is helpful for
> >> you.
> >> > >>>> >>
> >> > >>>> >> Let's determine what an initial contribution would be for and
> >> > bring a
> >> > >>>> >> proposal to the dev@ list and/or file a jira for the
> >> integration.
> >> > >>>> >> This would be great for adding features and growing the
> >> community -
> >> > >>>> so we
> >> > >>>> >> are all for it!
> >> > >>>> >>
> >> > >>>> >> thanks,
> >> > >>>> >>
> >> > >>>> >> --larry
> >> > >>>> >>
> >> > >>>> >>
> >> > >>>> >> On Thu, Nov 5, 2015 at 9:43 AM, Jérôme LELEU <
> leleuj@gmail.com>
> >> > >>>> wrote:
> >> > >>>> >>
> >> > >>>> >>> Hi,
> >> > >>>> >>>
> >> > >>>> >>> I see that Shiro is already used for basic auth and LDAP
> >> > >>>> authentication
> >> > >>>> >>> and Picketlink for SAML. pac4j v1.8 can now handle both cases
> >> and
> >> > >>>> even
> >> > >>>> >>> more. So I think we could create a
> >> gateway-provider-security-pac4j
> >> > >>>> >>> supporting all authentication mechanisms and not only OpenID.
> >> > >>>> >>>
> >> > >>>> >>> pac4j implementations generally work with two filters: one to
> >> > >>>> protect a
> >> > >>>> >>> resource and play direct authentication like basic auth (and
> >> check
> >> > >>>> >>> authorizations) and a callback filter to finish remote
> >> > >>>> authentication like
> >> > >>>> >>> Facebook, SAML, OpenID. The easiest one is the j2e-pac4j
> with:
> >> > >>>> >>>
> >> > >>>>
> >> >
> >>
> https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/RequiresAuthenticationFilter.java#L96
> >> > >>>> >>> and
> >> > >>>> >>>
> >> > >>>>
> >> >
> >>
> https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/CallbackFilter.java#L65
> >> > >>>> >>>
> >> > >>>> >>> That said, I have already many pac4j implementations to
> handle
> >> so
> >> > I'm
> >> > >>>> >>> pushing communities to maintain on their own their pac4j
> >> > >>>> implementations:
> >> > >>>> >>> can we imagine having an official:
> >> gateway-provider-security-pac4j
> >> > >>>> module
> >> > >>>> >>> maintained by the Knox community with my help of course?
> This is
> >> > the
> >> > >>>> kind
> >> > >>>> >>> of message I deliver to communities when a new version of
> pac4j
> >> is
> >> > >>>> >>> available so that they can upgrade:
> >> > >>>> >>> https://github.com/ratpack/ratpack/issues/819
> >> > >>>> >>>
> >> > >>>> >>> I read:
> >> > >>>>
> https://knox.apache.org/books/knox-0-6-0/dev-guide.html#Providers,
> >> > >>>> >>> it might be easy for Knox contributors, but it's a bit hard
> for
> >> me
> >> > >>>> to get
> >> > >>>> >>> in everything: can you or someone in the Knox community
> provides
> >> > me
> >> > >>>> an
> >> > >>>> >>> empty gateway-provider-security-pac4j module and the default
> >> > >>>> expectations
> >> > >>>> >>> from a Knox point of view?
> >> > >>>> >>> My main questions:
> >> > >>>> >>> 1) What do I do with the authenticated user: where / how do I
> >> fill
> >> > >>>> this
> >> > >>>> >>> identity in Knox?
> >> > >>>> >>> 2) How to handle errors: not authenticated, not authorized?
> >> > >>>> >>> 3) How to handle redirections to an external provider?
> >> > >>>> >>> 4) Should the pac4j filter also handle authorizations (pac4j
> can
> >> > do
> >> > >>>> that)?
> >> > >>>> >>> 5) How to test?
> >> > >>>> >>>
> >> > >>>> >>> Thanks.
> >> > >>>> >>> Best regards,
> >> > >>>> >>> Jérôme
> >> > >>>> >>>
> >> > >>>> >>>
> >> > >>>> >>>
> >> > >>>> >>>
> >> > >>>> >>> 2015-11-03 16:58 GMT+01:00 larry mccay:
> >> > >>>> >>>
> >> > >>>> >>>> Hi Jérôme -
> >> > >>>> >>>>
> >> > >>>> >>>> We were evaluating buji-pac4j for SSO with SAML and ended up
> >> > going
> >> > >>>> with
> >> > >>>> >>>> Picketlink at the time.
> >> > >>>> >>>> That said, we do have a pluggable architecture that would
> allow
> >> > for
> >> > >>>> a
> >> > >>>> >>>> pac4j provider as well.
> >> > >>>> >>>>
> >> > >>>> >>>> If you are interested in contributing such a provider that
> >> would
> >> > >>>> >>>> certainly be welcome.
> >> > >>>> >>>> There is someone in the community working on an openid
> provider
> >> > but
> >> > >>>> >>>> perhaps pac4j would be the way to go there?
> >> > >>>> >>>>
> >> > >>>> >>>> thanks,
> >> > >>>> >>>>
> >> > >>>> >>>> --larry
> >> > >>>> >>>>
> >> > >>>> >>>>
> >> > >>>>
> >> > >>>
> >> > >>>
> >> > >>
> >> >
> >>
>
Re: pac4j and Apache Knox
Posted by Kevin Minder <ke...@hortonworks.com>.
I think I know what it probably is. The gateway-release module pom.xml is what actually defines the classpath of the final packaged server. If you take a look at that you will see it references all of the providers that are intended to be included by default. Try adding yours to the dependencies.
On 11/12/15, 7:49 AM, "larry mccay" <lm...@apache.org> wrote:
>We really need to fix this behavior...
>
>It seems you traded in your random authentication provider for a random
>federation provider. :/
>
>This is most likely due to not having your new provider on the classpath
>for the serviceLoader to find.
>
>Just to try and articulate how it works...
>
>The deployment machinery loads all of the federation (whichever role)
>providers contributors that is finds on the classpath - via the
>src/main/resources/META-INF/services/org.apache.hadoop.gateway.deploy.ProviderDeploymentContributor
>- and interrogates each for its name to match to the name in the topology.
>Once it finds a match it allows the contributor to "contribute" to the
>creation of the topology specific webapp. Part of which includes adding
>filters to the gateway.xml.
>
>We currently have an issue wherein, given a name that doesn't match any
>found on the classpath, a random provider is returned. This needs to be
>fixed to fail deployment with appropriate error messages.
>
>Now, this usually comes down to one of 2 things:
>
>1. there is no src/main/resources/META-INF/services/org.apache.hadoop.gateway.deploy.ProviderDeploymentContributor
>file in the provider or it contains the classname of some other contributor
>2. the provider itself isn't on the gateway classpath. I see that your
>service file seems to be defined properly - so it is probably not on the
>classpath. Did you add the new provider to the parent pom? The article
>should provide all you need to do so.
>
>I will file a JIRA to fix the random provider issue.
>
>On Thu, Nov 12, 2015 at 7:18 AM, Jérôme LELEU <le...@gmail.com> wrote:
>
>> Hi,
>>
>> By changing the role to the appropriate value, the error is gone, but I
>> have a new problem:
>>
>> *Caused by: javax.servlet.ServletException: Required authentication
>> provider URL is missing.*
>> * at
>>
>> org.apache.hadoop.gateway.provider.federation.jwt.filter.SSOCookieFederationFilter.init(SSOCookieFederationFilter.java:90)*
>>
>> My sandbox.xml file only references the pac4j provider as well as the
>> Default (role: identity-assertion) and static (role: hostmap) ones.
>>
>> Though, the SSOCookieFederationFilter is defined in the gateway.xml file of
>> my sandbox deployment. Why do I need it? What's the expected authentication
>> provider url? How this gatweay.xml is generated?
>>
>> Thanks.
>> Best regards,
>> Jérôme
>>
>>
>>
>>
>>
>> 2015-11-10 17:36 GMT+01:00 Kevin Minder <ke...@hortonworks.com>:
>>
>> > To be a bit more explicit your Pac4jFederationProviderContributor
>> declares
>> > itself to be of role “federation” but when you used it in the sandbox.xml
>> > topology file you were attempting to configure it as an provider with
>> role
>> > authentication.
>> >
>> >
>> >
>> >
>> > On 11/10/15, 11:32 AM, "larry mccay" <lm...@apache.org> wrote:
>> >
>> > >Let's get you past the error that you are getting...
>> > >
>> > >It seems as though you have change the topology for pac4j but didn't
>> > change
>> > >the role to "federation".
>> > >It looks like it is grabbing a random authentication provider and seems
>> to
>> > >be the hadoop-auth provider.
>> > >
>> > >Change that to federation and see if that helps.
>> > >
>> > >On Tue, Nov 10, 2015 at 11:21 AM, larry mccay <lm...@apache.org>
>> wrote:
>> > >
>> > >> Hi Jérôme -
>> > >>
>> > >> Happy to see you here!
>> > >> I apologize for having missed your note on the list a few days ago.
>> > >>
>> > >> Glad to see that the article was helpful and it seems like you are
>> > making
>> > >> great progress.
>> > >>
>> > >> Let me dig into your note a bit deeper and answer your questions.
>> > >>
>> > >> Welcome!
>> > >>
>> > >> --larry
>> > >>
>> > >> On Tue, Nov 10, 2015 at 11:14 AM, Jérôme LELEU <le...@gmail.com>
>> > wrote:
>> > >>
>> > >>> Hi,
>> > >>>
>> > >>> Perfect timing ;-) I have started implemented the pac4j support in
>> > Knox,
>> > >>> it's a very basic attempt:
>> https://github.com/apache/knox/pull/2/files
>> > >>>
>> > >>> This implementation reuses the pac4j implementation for J2E. I have a
>> > >>> ProviderDeploymentContributorBase which registers two filters:
>> > >>> - the first one is a dispatcher filter which uses the j2e-pac4j
>> > >>> CallbackFilter on the /callabck url (it finishes the authentication
>> > process
>> > >>> after a successful authentication at some identity provider) and uses
>> > the
>> > >>> j2e-pac4j RequiresAuthenticationFilter otherwise (redirection to the
>> > >>> identity provider to start the authentication when the user is not
>> > >>> authenticated)
>> > >>> - the second one is an identity adapter which gets the current
>> > >>> authenticated user from the pac4j point of view and populates the J2E
>> > >>> security context.
>> > >>>
>> > >>>
>> > >>> * I have the following error:
>> > >>>
>> > >>> 2015-11-10 16:30:22,347 ERROR hadoop.gateway
>> > >>> (GatewayFilter.java:doFilter(135)) - Gateway processing failed:
>> > >>> javax.servlet.ServletException: javax.servlet.ServletException:
>> > >>> Authentication type must be specified: simple|kerberos|<class>
>> > >>> javax.servlet.ServletException: javax.servlet.ServletException:
>> > >>> Authentication type must be specified: simple|kerberos|<class>
>> > >>> at
>> > >>>
>> >
>> org.apache.hadoop.gateway.GatewayFilter$Holder.getInstance(GatewayFilter.java:354)
>> > >>>
>> > >>> Notice I have changed the sandbox.xml file to use pac4j instead of
>> > Shiro,
>> > >>> maybe it's not the right way:
>> > >>>
>> >
>> https://github.com/apache/knox/pull/2/files#diff-128ca80baa2dfd6c2d25de7b8160b9d9R24
>> > >>>
>> > >>> Any idea of the problem?
>> > >>>
>> > >>>
>> > >>> * Am I understanding webflows correctly?
>> > >>>
>> > >>> I use the default request to: curl -ivk "
>> > >>> https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS"
>> > >>>
>> > >>> It looks like a REST request, though I'm expecting the following
>> > webflow:
>> > >>> redirection of the user to the identity provider, successful login,
>> > >>> redirection back to the /callback url of the gateway: do I get it
>> > right?
>> > >>>
>> > >>>
>> > >>> * The callback url
>> > >>>
>> > >>> I currently do a check expecting the last part of the url to end with
>> > >>> /callback, but does the gateway will receive requests on this url?
>> Do I
>> > >>> have to do something special?
>> > >>>
>> > >>> It's highly recommended to only have one callback url as this url is
>> > >>> defined on the identity provider side.
>> > >>>
>> > >>>
>> > >>> * How to pass configuration?
>> > >>>
>> > >>> Currently, I hardcoded a FacebookClient for Facebook authentication,
>> > but
>> > >>> we should be able to pass the appropriate client like Facebook or
>> SAML.
>> > >>> Basically, we could do that using filter properties: facebook.key +
>> > >>> facebook.secret means we use Facebook authentication with the
>> > appropriate
>> > >>> key and secret for example. Any recommendation?
>> > >>>
>> > >>>
>> > >>> * Can I use the J2E session to store the requested protected url and
>> > >>> other information?
>> > >>>
>> > >>> Or do I need to do something special?
>> > >>>
>> > >>>
>> > >>> Thanks.
>> > >>> Best regards,
>> > >>> Jérôme
>> > >>>
>> > >>> 2015-11-10 17:03 GMT+01:00 Kevin Minder <
>> kevin.minder@hortonworks.com
>> > >:
>> > >>>
>> > >>>> Hi Jerome,
>> > >>>> This sounds very exciting and is just the sort of thing the open
>> > >>>> architecture of Knox is intended to allow. Larry and I have looked
>> at
>> > >>>> pac4j a number of times thinking that it would be a good fit and
>> would
>> > >>>> provide a great feature set to the Hadoop community.
>> > >>>> Kevin.
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>> On 11/6/15, 3:31 AM, "Jérôme LELEU" <le...@gmail.com> wrote:
>> > >>>>
>> > >>>> >Hi,
>> > >>>> >
>> > >>>> >Let's open this private discussion on the Knox dev mailing list.
>> > >>>> >
>> > >>>> >I'm Jerome Leleu and the creator of pac4j (
>> > >>>> https://github.com/pac4j/pac4j),
>> > >>>> >a security engine for Java with many implementations for J2E, Play,
>> > >>>> Spring,
>> > >>>> >Vertx, Ratpack... The idea is to offer something as powerful as
>> > Spring
>> > >>>> >Security, but a lot easier and for all Java frameworks / tools and
>> > all
>> > >>>> >authentication mechanisms.
>> > >>>> >
>> > >>>> >Two years ago, we had a discussion with Larry on how pac4j could be
>> > >>>> used in
>> > >>>> >Knox.
>> > >>>> >
>> > >>>> >Meanwhile, both projects have grown up and I'm back to try to see
>> if
>> > >>>> pac4j
>> > >>>> >can help Knox in terms of security.
>> > >>>> >
>> > >>>> >-----
>> > >>>> >
>> > >>>> >In its latest version, pac4j can be used to build a full security
>> > >>>> library,
>> > >>>> >not only focused on delegated authentication (Facebook, SAML). So
>> we
>> > >>>> have
>> > >>>> >the concepts of direct clients (a client is an authentication
>> > >>>> mechanism):
>> > >>>> >basic auth, header, token... and indirect clients: SAML, Facebook,
>> > >>>> OpenID,
>> > >>>> >CAS...
>> > >>>> >It seems to be very close to the Authentication and Federation
>> > Providers
>> > >>>> >concepts from Knox.
>> > >>>> >
>> > >>>> >The provided article is great and as it's focused on authentication
>> > >>>> with a
>> > >>>> >real example, it's easier to start with it.
>> > >>>> >
>> > >>>> >Thanks for your answers.
>> > >>>> >
>> > >>>> >Like Shiro, pac4j has LDAP support and caching can be done. The
>> only
>> > >>>> >difference is that pac4j relies on ldaptive (
>> > http://www.ldaptive.org/).
>> > >>>> But
>> > >>>> >I think you're right: it would be better to start by implementing
>> the
>> > >>>> >Federation part which might be the most expected feature for Knox
>> > users
>> > >>>> (a
>> > >>>> >bit like buji-pac4j: https://github.com/bujiio/buji-pac4j is for
>> > >>>> Shiro) and
>> > >>>> >see if it's worth the work to have an authentication provider with
>> > >>>> pac4j in
>> > >>>> >addition to the one of Shiro.
>> > >>>> >
>> > >>>> >I plan to start working on that next week. Do you accept pull
>> > requests
>> > >>>> on
>> > >>>> >Github (it would make discussion easier on source code)?
>> > >>>> >
>> > >>>> >Any feedback will be appreciated.
>> > >>>> >
>> > >>>> >Thanks.
>> > >>>> >Best regards,
>> > >>>> >Jérôme
>> > >>>> >
>> > >>>> >
>> > >>>> >
>> > >>>> >
>> > >>>> >
>> > >>>> >
>> > >>>> >2015-11-05 17:13 GMT+01:00 larry mccay:
>> > >>>> >
>> > >>>> >> Hi Jérôme -
>> > >>>> >>
>> > >>>> >> Contributions coming from the community are owned and maintained
>> by
>> > >>>> the
>> > >>>> >> entire community.
>> > >>>> >> You would certainly not be expected to do all work on it and at
>> the
>> > >>>> same
>> > >>>> >> time any assistance and upgrade messages that you provided would
>> be
>> > >>>> awesome.
>> > >>>> >>
>> > >>>> >> As for an empty module for pac4j, maybe the following example
>> > project
>> > >>>> >> would be helpful to you:
>> > >>>> >>
>> > >>>> >> https://github.com/lmccay/gateway-provider-security-pseudo
>> > >>>> >>
>> > >>>> >> It is in support of an article to illustrate how to go about
>> > adding a
>> > >>>> >> authentication or federation provider - as you would be doing:
>> > >>>> >>
>> > >>>> >>
>> > >>>>
>> >
>> https://github.com/lmccay/gateway-provider-security-pseudo/blob/master/AddingFederationProvider.md
>> > >>>> >>
>> > >>>> >> That may be easier to consume than the entire developers guide.
>> > >>>> >> That said, it would be great if you could describe what makes the
>> > dev
>> > >>>> >> guide too much - if that is the case.
>> > >>>> >>
>> > >>>> >> I'll take a stab at your questions here but we should move more
>> > >>>> detailed
>> > >>>> >> discussions on the topic to the dev@ list in order to keep this
>> in
>> > >>>> the
>> > >>>> >> open and provide insights to others:
>> > >>>> >>
>> > >>>> >> 1) What do I do with the authenticated user: where / how do I
>> fill
>> > >>>> this
>> > >>>> >> identity in Knox?
>> > >>>> >>
>> > >>>> >> We normalize the authentication event into a Java subject to
>> > >>>> represent the
>> > >>>> >> user, groups and impersonated user as appropriate.
>> > >>>> >> In cases - like shiro - where we don't have access to the actual
>> > >>>> >> authenticating code and we need to normalize the provider
>> specific
>> > >>>> security
>> > >>>> >> context, we add another filter. You can look at the shiro
>> provider
>> > >>>> for an
>> > >>>> >> example. The code inside the simple example provider in the
>> article
>> > >>>> also
>> > >>>> >> shows what is expected at least in terms of the PrimaryPrincipal.
>> > >>>> >>
>> > >>>> >> 2) How to handle errors: not authenticated, not authorized?
>> > >>>> >>
>> > >>>> >> We aren't intrusive on what should be done by a provider here.
>> > >>>> >> Generally, authentication failures result in a 401 and
>> > authorizations
>> > >>>> in a
>> > >>>> >> 403 and they are usually sent by the provider.
>> > >>>> >>
>> > >>>> >> 3) How to handle redirections to an external provider?
>> > >>>> >>
>> > >>>> >> Redirects are sent by the providers themselves with a 307 or 302.
>> > >>>> >> You can look at the SSOCookieFederationFilter in the jwt module
>> as
>> > an
>> > >>>> >> example if you like.
>> > >>>> >>
>> > >>>> >> 4) Should the pac4j filter also handle authorizations (pac4j can
>> do
>> > >>>> that)?
>> > >>>> >>
>> > >>>> >> This is an interesting question.
>> > >>>> >> Knox provides a separate slot in the provider chain for
>> > authorization.
>> > >>>> >> It is there because of the ability for identity assertion
>> providers
>> > >>>> to map
>> > >>>> >> principals in order to impersonate another user or map external
>> > >>>> usernames
>> > >>>> >> to those used inside of hadoop clusters. So, the authorization
>> > >>>> decisions
>> > >>>> >> are made based on those identities.
>> > >>>> >>
>> > >>>> >> If we can add the authorization filter as an authorization
>> provider
>> > >>>> rather
>> > >>>> >> than part of the authentication provider than that might make
>> > sense.
>> > >>>> >> Although, the security context is normalized as Knox expects not
>> as
>> > >>>> pac4j
>> > >>>> >> authorization probably does. Now, if there is real value in doing
>> > so,
>> > >>>> the
>> > >>>> >> pac4j Subject adaptor could stuff additional context into the
>> > Subject
>> > >>>> or
>> > >>>> >> the request that can be accessed later by the pac4j authorization
>> > >>>> provider.
>> > >>>> >>
>> > >>>> >> So, it can be done - the question is whether there is compelling
>> > >>>> reason to
>> > >>>> >> do so.
>> > >>>> >>
>> > >>>> >> 5) How to test?
>> > >>>> >>
>> > >>>> >> This can be challenging especially for external authentications
>> and
>> > >>>> web
>> > >>>> >> app flows.
>> > >>>> >> Generally, unit testing as much as possible is required.
>> > >>>> >> We would want to make sure that the security context
>> normalization
>> > >>>> happens
>> > >>>> >> as expected, etc.
>> > >>>> >>
>> > >>>> >> Additional considerations:
>> > >>>> >>
>> > >>>> >> 1. Our Shiro provider does group lookup and caching of the
>> > >>>> authentication
>> > >>>> >> event for optimizing interactions with authentication servers,
>> > LDAP,
>> > >>>> AD,
>> > >>>> >> etc. We wouldn't want to lose these. Doing so would be a
>> > non-starter
>> > >>>> for
>> > >>>> >> most folks replacing what Shiro is used for today.
>> > >>>> >> 2. It is probably best to concentrate on the gaps that pac4j can
>> > fill
>> > >>>> for
>> > >>>> >> openid, oauth, etc for the initial contribution and if the
>> usecases
>> > >>>> handled
>> > >>>> >> by Shiro can be done better, easier, simpler then we can
>> consider a
>> > >>>> >> migration path.
>> > >>>> >>
>> > >>>> >> BTW - we have a couple very interesting possibilities for strong
>> > and
>> > >>>> >> multi-factor authentication that would be enabled by OpenID
>> > >>>> immediately.
>> > >>>> >>
>> > >>>> >> Hope this isn't too long a response and that it is helpful for
>> you.
>> > >>>> >>
>> > >>>> >> Let's determine what an initial contribution would be for and
>> > bring a
>> > >>>> >> proposal to the dev@ list and/or file a jira for the
>> integration.
>> > >>>> >> This would be great for adding features and growing the
>> community -
>> > >>>> so we
>> > >>>> >> are all for it!
>> > >>>> >>
>> > >>>> >> thanks,
>> > >>>> >>
>> > >>>> >> --larry
>> > >>>> >>
>> > >>>> >>
>> > >>>> >> On Thu, Nov 5, 2015 at 9:43 AM, Jérôme LELEU <le...@gmail.com>
>> > >>>> wrote:
>> > >>>> >>
>> > >>>> >>> Hi,
>> > >>>> >>>
>> > >>>> >>> I see that Shiro is already used for basic auth and LDAP
>> > >>>> authentication
>> > >>>> >>> and Picketlink for SAML. pac4j v1.8 can now handle both cases
>> and
>> > >>>> even
>> > >>>> >>> more. So I think we could create a
>> gateway-provider-security-pac4j
>> > >>>> >>> supporting all authentication mechanisms and not only OpenID.
>> > >>>> >>>
>> > >>>> >>> pac4j implementations generally work with two filters: one to
>> > >>>> protect a
>> > >>>> >>> resource and play direct authentication like basic auth (and
>> check
>> > >>>> >>> authorizations) and a callback filter to finish remote
>> > >>>> authentication like
>> > >>>> >>> Facebook, SAML, OpenID. The easiest one is the j2e-pac4j with:
>> > >>>> >>>
>> > >>>>
>> >
>> https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/RequiresAuthenticationFilter.java#L96
>> > >>>> >>> and
>> > >>>> >>>
>> > >>>>
>> >
>> https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/CallbackFilter.java#L65
>> > >>>> >>>
>> > >>>> >>> That said, I have already many pac4j implementations to handle
>> so
>> > I'm
>> > >>>> >>> pushing communities to maintain on their own their pac4j
>> > >>>> implementations:
>> > >>>> >>> can we imagine having an official:
>> gateway-provider-security-pac4j
>> > >>>> module
>> > >>>> >>> maintained by the Knox community with my help of course? This is
>> > the
>> > >>>> kind
>> > >>>> >>> of message I deliver to communities when a new version of pac4j
>> is
>> > >>>> >>> available so that they can upgrade:
>> > >>>> >>> https://github.com/ratpack/ratpack/issues/819
>> > >>>> >>>
>> > >>>> >>> I read:
>> > >>>> https://knox.apache.org/books/knox-0-6-0/dev-guide.html#Providers,
>> > >>>> >>> it might be easy for Knox contributors, but it's a bit hard for
>> me
>> > >>>> to get
>> > >>>> >>> in everything: can you or someone in the Knox community provides
>> > me
>> > >>>> an
>> > >>>> >>> empty gateway-provider-security-pac4j module and the default
>> > >>>> expectations
>> > >>>> >>> from a Knox point of view?
>> > >>>> >>> My main questions:
>> > >>>> >>> 1) What do I do with the authenticated user: where / how do I
>> fill
>> > >>>> this
>> > >>>> >>> identity in Knox?
>> > >>>> >>> 2) How to handle errors: not authenticated, not authorized?
>> > >>>> >>> 3) How to handle redirections to an external provider?
>> > >>>> >>> 4) Should the pac4j filter also handle authorizations (pac4j can
>> > do
>> > >>>> that)?
>> > >>>> >>> 5) How to test?
>> > >>>> >>>
>> > >>>> >>> Thanks.
>> > >>>> >>> Best regards,
>> > >>>> >>> Jérôme
>> > >>>> >>>
>> > >>>> >>>
>> > >>>> >>>
>> > >>>> >>>
>> > >>>> >>> 2015-11-03 16:58 GMT+01:00 larry mccay:
>> > >>>> >>>
>> > >>>> >>>> Hi Jérôme -
>> > >>>> >>>>
>> > >>>> >>>> We were evaluating buji-pac4j for SSO with SAML and ended up
>> > going
>> > >>>> with
>> > >>>> >>>> Picketlink at the time.
>> > >>>> >>>> That said, we do have a pluggable architecture that would allow
>> > for
>> > >>>> a
>> > >>>> >>>> pac4j provider as well.
>> > >>>> >>>>
>> > >>>> >>>> If you are interested in contributing such a provider that
>> would
>> > >>>> >>>> certainly be welcome.
>> > >>>> >>>> There is someone in the community working on an openid provider
>> > but
>> > >>>> >>>> perhaps pac4j would be the way to go there?
>> > >>>> >>>>
>> > >>>> >>>> thanks,
>> > >>>> >>>>
>> > >>>> >>>> --larry
>> > >>>> >>>>
>> > >>>> >>>>
>> > >>>>
>> > >>>
>> > >>>
>> > >>
>> >
>>
Re: pac4j and Apache Knox
Posted by larry mccay <lm...@apache.org>.
We really need to fix this behavior...
It seems you traded in your random authentication provider for a random
federation provider. :/
This is most likely due to not having your new provider on the classpath
for the serviceLoader to find.
Just to try and articulate how it works...
The deployment machinery loads all of the federation (whichever role)
providers contributors that is finds on the classpath - via the
src/main/resources/META-INF/services/org.apache.hadoop.gateway.deploy.ProviderDeploymentContributor
- and interrogates each for its name to match to the name in the topology.
Once it finds a match it allows the contributor to "contribute" to the
creation of the topology specific webapp. Part of which includes adding
filters to the gateway.xml.
We currently have an issue wherein, given a name that doesn't match any
found on the classpath, a random provider is returned. This needs to be
fixed to fail deployment with appropriate error messages.
Now, this usually comes down to one of 2 things:
1. there is no src/main/resources/META-INF/services/org.apache.hadoop.gateway.deploy.ProviderDeploymentContributor
file in the provider or it contains the classname of some other contributor
2. the provider itself isn't on the gateway classpath. I see that your
service file seems to be defined properly - so it is probably not on the
classpath. Did you add the new provider to the parent pom? The article
should provide all you need to do so.
I will file a JIRA to fix the random provider issue.
On Thu, Nov 12, 2015 at 7:18 AM, Jérôme LELEU <le...@gmail.com> wrote:
> Hi,
>
> By changing the role to the appropriate value, the error is gone, but I
> have a new problem:
>
> *Caused by: javax.servlet.ServletException: Required authentication
> provider URL is missing.*
> * at
>
> org.apache.hadoop.gateway.provider.federation.jwt.filter.SSOCookieFederationFilter.init(SSOCookieFederationFilter.java:90)*
>
> My sandbox.xml file only references the pac4j provider as well as the
> Default (role: identity-assertion) and static (role: hostmap) ones.
>
> Though, the SSOCookieFederationFilter is defined in the gateway.xml file of
> my sandbox deployment. Why do I need it? What's the expected authentication
> provider url? How this gatweay.xml is generated?
>
> Thanks.
> Best regards,
> Jérôme
>
>
>
>
>
> 2015-11-10 17:36 GMT+01:00 Kevin Minder <ke...@hortonworks.com>:
>
> > To be a bit more explicit your Pac4jFederationProviderContributor
> declares
> > itself to be of role “federation” but when you used it in the sandbox.xml
> > topology file you were attempting to configure it as an provider with
> role
> > authentication.
> >
> >
> >
> >
> > On 11/10/15, 11:32 AM, "larry mccay" <lm...@apache.org> wrote:
> >
> > >Let's get you past the error that you are getting...
> > >
> > >It seems as though you have change the topology for pac4j but didn't
> > change
> > >the role to "federation".
> > >It looks like it is grabbing a random authentication provider and seems
> to
> > >be the hadoop-auth provider.
> > >
> > >Change that to federation and see if that helps.
> > >
> > >On Tue, Nov 10, 2015 at 11:21 AM, larry mccay <lm...@apache.org>
> wrote:
> > >
> > >> Hi Jérôme -
> > >>
> > >> Happy to see you here!
> > >> I apologize for having missed your note on the list a few days ago.
> > >>
> > >> Glad to see that the article was helpful and it seems like you are
> > making
> > >> great progress.
> > >>
> > >> Let me dig into your note a bit deeper and answer your questions.
> > >>
> > >> Welcome!
> > >>
> > >> --larry
> > >>
> > >> On Tue, Nov 10, 2015 at 11:14 AM, Jérôme LELEU <le...@gmail.com>
> > wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> Perfect timing ;-) I have started implemented the pac4j support in
> > Knox,
> > >>> it's a very basic attempt:
> https://github.com/apache/knox/pull/2/files
> > >>>
> > >>> This implementation reuses the pac4j implementation for J2E. I have a
> > >>> ProviderDeploymentContributorBase which registers two filters:
> > >>> - the first one is a dispatcher filter which uses the j2e-pac4j
> > >>> CallbackFilter on the /callabck url (it finishes the authentication
> > process
> > >>> after a successful authentication at some identity provider) and uses
> > the
> > >>> j2e-pac4j RequiresAuthenticationFilter otherwise (redirection to the
> > >>> identity provider to start the authentication when the user is not
> > >>> authenticated)
> > >>> - the second one is an identity adapter which gets the current
> > >>> authenticated user from the pac4j point of view and populates the J2E
> > >>> security context.
> > >>>
> > >>>
> > >>> * I have the following error:
> > >>>
> > >>> 2015-11-10 16:30:22,347 ERROR hadoop.gateway
> > >>> (GatewayFilter.java:doFilter(135)) - Gateway processing failed:
> > >>> javax.servlet.ServletException: javax.servlet.ServletException:
> > >>> Authentication type must be specified: simple|kerberos|<class>
> > >>> javax.servlet.ServletException: javax.servlet.ServletException:
> > >>> Authentication type must be specified: simple|kerberos|<class>
> > >>> at
> > >>>
> >
> org.apache.hadoop.gateway.GatewayFilter$Holder.getInstance(GatewayFilter.java:354)
> > >>>
> > >>> Notice I have changed the sandbox.xml file to use pac4j instead of
> > Shiro,
> > >>> maybe it's not the right way:
> > >>>
> >
> https://github.com/apache/knox/pull/2/files#diff-128ca80baa2dfd6c2d25de7b8160b9d9R24
> > >>>
> > >>> Any idea of the problem?
> > >>>
> > >>>
> > >>> * Am I understanding webflows correctly?
> > >>>
> > >>> I use the default request to: curl -ivk "
> > >>> https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS"
> > >>>
> > >>> It looks like a REST request, though I'm expecting the following
> > webflow:
> > >>> redirection of the user to the identity provider, successful login,
> > >>> redirection back to the /callback url of the gateway: do I get it
> > right?
> > >>>
> > >>>
> > >>> * The callback url
> > >>>
> > >>> I currently do a check expecting the last part of the url to end with
> > >>> /callback, but does the gateway will receive requests on this url?
> Do I
> > >>> have to do something special?
> > >>>
> > >>> It's highly recommended to only have one callback url as this url is
> > >>> defined on the identity provider side.
> > >>>
> > >>>
> > >>> * How to pass configuration?
> > >>>
> > >>> Currently, I hardcoded a FacebookClient for Facebook authentication,
> > but
> > >>> we should be able to pass the appropriate client like Facebook or
> SAML.
> > >>> Basically, we could do that using filter properties: facebook.key +
> > >>> facebook.secret means we use Facebook authentication with the
> > appropriate
> > >>> key and secret for example. Any recommendation?
> > >>>
> > >>>
> > >>> * Can I use the J2E session to store the requested protected url and
> > >>> other information?
> > >>>
> > >>> Or do I need to do something special?
> > >>>
> > >>>
> > >>> Thanks.
> > >>> Best regards,
> > >>> Jérôme
> > >>>
> > >>> 2015-11-10 17:03 GMT+01:00 Kevin Minder <
> kevin.minder@hortonworks.com
> > >:
> > >>>
> > >>>> Hi Jerome,
> > >>>> This sounds very exciting and is just the sort of thing the open
> > >>>> architecture of Knox is intended to allow. Larry and I have looked
> at
> > >>>> pac4j a number of times thinking that it would be a good fit and
> would
> > >>>> provide a great feature set to the Hadoop community.
> > >>>> Kevin.
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 11/6/15, 3:31 AM, "Jérôme LELEU" <le...@gmail.com> wrote:
> > >>>>
> > >>>> >Hi,
> > >>>> >
> > >>>> >Let's open this private discussion on the Knox dev mailing list.
> > >>>> >
> > >>>> >I'm Jerome Leleu and the creator of pac4j (
> > >>>> https://github.com/pac4j/pac4j),
> > >>>> >a security engine for Java with many implementations for J2E, Play,
> > >>>> Spring,
> > >>>> >Vertx, Ratpack... The idea is to offer something as powerful as
> > Spring
> > >>>> >Security, but a lot easier and for all Java frameworks / tools and
> > all
> > >>>> >authentication mechanisms.
> > >>>> >
> > >>>> >Two years ago, we had a discussion with Larry on how pac4j could be
> > >>>> used in
> > >>>> >Knox.
> > >>>> >
> > >>>> >Meanwhile, both projects have grown up and I'm back to try to see
> if
> > >>>> pac4j
> > >>>> >can help Knox in terms of security.
> > >>>> >
> > >>>> >-----
> > >>>> >
> > >>>> >In its latest version, pac4j can be used to build a full security
> > >>>> library,
> > >>>> >not only focused on delegated authentication (Facebook, SAML). So
> we
> > >>>> have
> > >>>> >the concepts of direct clients (a client is an authentication
> > >>>> mechanism):
> > >>>> >basic auth, header, token... and indirect clients: SAML, Facebook,
> > >>>> OpenID,
> > >>>> >CAS...
> > >>>> >It seems to be very close to the Authentication and Federation
> > Providers
> > >>>> >concepts from Knox.
> > >>>> >
> > >>>> >The provided article is great and as it's focused on authentication
> > >>>> with a
> > >>>> >real example, it's easier to start with it.
> > >>>> >
> > >>>> >Thanks for your answers.
> > >>>> >
> > >>>> >Like Shiro, pac4j has LDAP support and caching can be done. The
> only
> > >>>> >difference is that pac4j relies on ldaptive (
> > http://www.ldaptive.org/).
> > >>>> But
> > >>>> >I think you're right: it would be better to start by implementing
> the
> > >>>> >Federation part which might be the most expected feature for Knox
> > users
> > >>>> (a
> > >>>> >bit like buji-pac4j: https://github.com/bujiio/buji-pac4j is for
> > >>>> Shiro) and
> > >>>> >see if it's worth the work to have an authentication provider with
> > >>>> pac4j in
> > >>>> >addition to the one of Shiro.
> > >>>> >
> > >>>> >I plan to start working on that next week. Do you accept pull
> > requests
> > >>>> on
> > >>>> >Github (it would make discussion easier on source code)?
> > >>>> >
> > >>>> >Any feedback will be appreciated.
> > >>>> >
> > >>>> >Thanks.
> > >>>> >Best regards,
> > >>>> >Jérôme
> > >>>> >
> > >>>> >
> > >>>> >
> > >>>> >
> > >>>> >
> > >>>> >
> > >>>> >2015-11-05 17:13 GMT+01:00 larry mccay:
> > >>>> >
> > >>>> >> Hi Jérôme -
> > >>>> >>
> > >>>> >> Contributions coming from the community are owned and maintained
> by
> > >>>> the
> > >>>> >> entire community.
> > >>>> >> You would certainly not be expected to do all work on it and at
> the
> > >>>> same
> > >>>> >> time any assistance and upgrade messages that you provided would
> be
> > >>>> awesome.
> > >>>> >>
> > >>>> >> As for an empty module for pac4j, maybe the following example
> > project
> > >>>> >> would be helpful to you:
> > >>>> >>
> > >>>> >> https://github.com/lmccay/gateway-provider-security-pseudo
> > >>>> >>
> > >>>> >> It is in support of an article to illustrate how to go about
> > adding a
> > >>>> >> authentication or federation provider - as you would be doing:
> > >>>> >>
> > >>>> >>
> > >>>>
> >
> https://github.com/lmccay/gateway-provider-security-pseudo/blob/master/AddingFederationProvider.md
> > >>>> >>
> > >>>> >> That may be easier to consume than the entire developers guide.
> > >>>> >> That said, it would be great if you could describe what makes the
> > dev
> > >>>> >> guide too much - if that is the case.
> > >>>> >>
> > >>>> >> I'll take a stab at your questions here but we should move more
> > >>>> detailed
> > >>>> >> discussions on the topic to the dev@ list in order to keep this
> in
> > >>>> the
> > >>>> >> open and provide insights to others:
> > >>>> >>
> > >>>> >> 1) What do I do with the authenticated user: where / how do I
> fill
> > >>>> this
> > >>>> >> identity in Knox?
> > >>>> >>
> > >>>> >> We normalize the authentication event into a Java subject to
> > >>>> represent the
> > >>>> >> user, groups and impersonated user as appropriate.
> > >>>> >> In cases - like shiro - where we don't have access to the actual
> > >>>> >> authenticating code and we need to normalize the provider
> specific
> > >>>> security
> > >>>> >> context, we add another filter. You can look at the shiro
> provider
> > >>>> for an
> > >>>> >> example. The code inside the simple example provider in the
> article
> > >>>> also
> > >>>> >> shows what is expected at least in terms of the PrimaryPrincipal.
> > >>>> >>
> > >>>> >> 2) How to handle errors: not authenticated, not authorized?
> > >>>> >>
> > >>>> >> We aren't intrusive on what should be done by a provider here.
> > >>>> >> Generally, authentication failures result in a 401 and
> > authorizations
> > >>>> in a
> > >>>> >> 403 and they are usually sent by the provider.
> > >>>> >>
> > >>>> >> 3) How to handle redirections to an external provider?
> > >>>> >>
> > >>>> >> Redirects are sent by the providers themselves with a 307 or 302.
> > >>>> >> You can look at the SSOCookieFederationFilter in the jwt module
> as
> > an
> > >>>> >> example if you like.
> > >>>> >>
> > >>>> >> 4) Should the pac4j filter also handle authorizations (pac4j can
> do
> > >>>> that)?
> > >>>> >>
> > >>>> >> This is an interesting question.
> > >>>> >> Knox provides a separate slot in the provider chain for
> > authorization.
> > >>>> >> It is there because of the ability for identity assertion
> providers
> > >>>> to map
> > >>>> >> principals in order to impersonate another user or map external
> > >>>> usernames
> > >>>> >> to those used inside of hadoop clusters. So, the authorization
> > >>>> decisions
> > >>>> >> are made based on those identities.
> > >>>> >>
> > >>>> >> If we can add the authorization filter as an authorization
> provider
> > >>>> rather
> > >>>> >> than part of the authentication provider than that might make
> > sense.
> > >>>> >> Although, the security context is normalized as Knox expects not
> as
> > >>>> pac4j
> > >>>> >> authorization probably does. Now, if there is real value in doing
> > so,
> > >>>> the
> > >>>> >> pac4j Subject adaptor could stuff additional context into the
> > Subject
> > >>>> or
> > >>>> >> the request that can be accessed later by the pac4j authorization
> > >>>> provider.
> > >>>> >>
> > >>>> >> So, it can be done - the question is whether there is compelling
> > >>>> reason to
> > >>>> >> do so.
> > >>>> >>
> > >>>> >> 5) How to test?
> > >>>> >>
> > >>>> >> This can be challenging especially for external authentications
> and
> > >>>> web
> > >>>> >> app flows.
> > >>>> >> Generally, unit testing as much as possible is required.
> > >>>> >> We would want to make sure that the security context
> normalization
> > >>>> happens
> > >>>> >> as expected, etc.
> > >>>> >>
> > >>>> >> Additional considerations:
> > >>>> >>
> > >>>> >> 1. Our Shiro provider does group lookup and caching of the
> > >>>> authentication
> > >>>> >> event for optimizing interactions with authentication servers,
> > LDAP,
> > >>>> AD,
> > >>>> >> etc. We wouldn't want to lose these. Doing so would be a
> > non-starter
> > >>>> for
> > >>>> >> most folks replacing what Shiro is used for today.
> > >>>> >> 2. It is probably best to concentrate on the gaps that pac4j can
> > fill
> > >>>> for
> > >>>> >> openid, oauth, etc for the initial contribution and if the
> usecases
> > >>>> handled
> > >>>> >> by Shiro can be done better, easier, simpler then we can
> consider a
> > >>>> >> migration path.
> > >>>> >>
> > >>>> >> BTW - we have a couple very interesting possibilities for strong
> > and
> > >>>> >> multi-factor authentication that would be enabled by OpenID
> > >>>> immediately.
> > >>>> >>
> > >>>> >> Hope this isn't too long a response and that it is helpful for
> you.
> > >>>> >>
> > >>>> >> Let's determine what an initial contribution would be for and
> > bring a
> > >>>> >> proposal to the dev@ list and/or file a jira for the
> integration.
> > >>>> >> This would be great for adding features and growing the
> community -
> > >>>> so we
> > >>>> >> are all for it!
> > >>>> >>
> > >>>> >> thanks,
> > >>>> >>
> > >>>> >> --larry
> > >>>> >>
> > >>>> >>
> > >>>> >> On Thu, Nov 5, 2015 at 9:43 AM, Jérôme LELEU <le...@gmail.com>
> > >>>> wrote:
> > >>>> >>
> > >>>> >>> Hi,
> > >>>> >>>
> > >>>> >>> I see that Shiro is already used for basic auth and LDAP
> > >>>> authentication
> > >>>> >>> and Picketlink for SAML. pac4j v1.8 can now handle both cases
> and
> > >>>> even
> > >>>> >>> more. So I think we could create a
> gateway-provider-security-pac4j
> > >>>> >>> supporting all authentication mechanisms and not only OpenID.
> > >>>> >>>
> > >>>> >>> pac4j implementations generally work with two filters: one to
> > >>>> protect a
> > >>>> >>> resource and play direct authentication like basic auth (and
> check
> > >>>> >>> authorizations) and a callback filter to finish remote
> > >>>> authentication like
> > >>>> >>> Facebook, SAML, OpenID. The easiest one is the j2e-pac4j with:
> > >>>> >>>
> > >>>>
> >
> https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/RequiresAuthenticationFilter.java#L96
> > >>>> >>> and
> > >>>> >>>
> > >>>>
> >
> https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/CallbackFilter.java#L65
> > >>>> >>>
> > >>>> >>> That said, I have already many pac4j implementations to handle
> so
> > I'm
> > >>>> >>> pushing communities to maintain on their own their pac4j
> > >>>> implementations:
> > >>>> >>> can we imagine having an official:
> gateway-provider-security-pac4j
> > >>>> module
> > >>>> >>> maintained by the Knox community with my help of course? This is
> > the
> > >>>> kind
> > >>>> >>> of message I deliver to communities when a new version of pac4j
> is
> > >>>> >>> available so that they can upgrade:
> > >>>> >>> https://github.com/ratpack/ratpack/issues/819
> > >>>> >>>
> > >>>> >>> I read:
> > >>>> https://knox.apache.org/books/knox-0-6-0/dev-guide.html#Providers,
> > >>>> >>> it might be easy for Knox contributors, but it's a bit hard for
> me
> > >>>> to get
> > >>>> >>> in everything: can you or someone in the Knox community provides
> > me
> > >>>> an
> > >>>> >>> empty gateway-provider-security-pac4j module and the default
> > >>>> expectations
> > >>>> >>> from a Knox point of view?
> > >>>> >>> My main questions:
> > >>>> >>> 1) What do I do with the authenticated user: where / how do I
> fill
> > >>>> this
> > >>>> >>> identity in Knox?
> > >>>> >>> 2) How to handle errors: not authenticated, not authorized?
> > >>>> >>> 3) How to handle redirections to an external provider?
> > >>>> >>> 4) Should the pac4j filter also handle authorizations (pac4j can
> > do
> > >>>> that)?
> > >>>> >>> 5) How to test?
> > >>>> >>>
> > >>>> >>> Thanks.
> > >>>> >>> Best regards,
> > >>>> >>> Jérôme
> > >>>> >>>
> > >>>> >>>
> > >>>> >>>
> > >>>> >>>
> > >>>> >>> 2015-11-03 16:58 GMT+01:00 larry mccay:
> > >>>> >>>
> > >>>> >>>> Hi Jérôme -
> > >>>> >>>>
> > >>>> >>>> We were evaluating buji-pac4j for SSO with SAML and ended up
> > going
> > >>>> with
> > >>>> >>>> Picketlink at the time.
> > >>>> >>>> That said, we do have a pluggable architecture that would allow
> > for
> > >>>> a
> > >>>> >>>> pac4j provider as well.
> > >>>> >>>>
> > >>>> >>>> If you are interested in contributing such a provider that
> would
> > >>>> >>>> certainly be welcome.
> > >>>> >>>> There is someone in the community working on an openid provider
> > but
> > >>>> >>>> perhaps pac4j would be the way to go there?
> > >>>> >>>>
> > >>>> >>>> thanks,
> > >>>> >>>>
> > >>>> >>>> --larry
> > >>>> >>>>
> > >>>> >>>>
> > >>>>
> > >>>
> > >>>
> > >>
> >
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Hi,
By changing the role to the appropriate value, the error is gone, but I
have a new problem:
*Caused by: javax.servlet.ServletException: Required authentication
provider URL is missing.*
* at
org.apache.hadoop.gateway.provider.federation.jwt.filter.SSOCookieFederationFilter.init(SSOCookieFederationFilter.java:90)*
My sandbox.xml file only references the pac4j provider as well as the
Default (role: identity-assertion) and static (role: hostmap) ones.
Though, the SSOCookieFederationFilter is defined in the gateway.xml file of
my sandbox deployment. Why do I need it? What's the expected authentication
provider url? How this gatweay.xml is generated?
Thanks.
Best regards,
Jérôme
2015-11-10 17:36 GMT+01:00 Kevin Minder <ke...@hortonworks.com>:
> To be a bit more explicit your Pac4jFederationProviderContributor declares
> itself to be of role “federation” but when you used it in the sandbox.xml
> topology file you were attempting to configure it as an provider with role
> authentication.
>
>
>
>
> On 11/10/15, 11:32 AM, "larry mccay" <lm...@apache.org> wrote:
>
> >Let's get you past the error that you are getting...
> >
> >It seems as though you have change the topology for pac4j but didn't
> change
> >the role to "federation".
> >It looks like it is grabbing a random authentication provider and seems to
> >be the hadoop-auth provider.
> >
> >Change that to federation and see if that helps.
> >
> >On Tue, Nov 10, 2015 at 11:21 AM, larry mccay <lm...@apache.org> wrote:
> >
> >> Hi Jérôme -
> >>
> >> Happy to see you here!
> >> I apologize for having missed your note on the list a few days ago.
> >>
> >> Glad to see that the article was helpful and it seems like you are
> making
> >> great progress.
> >>
> >> Let me dig into your note a bit deeper and answer your questions.
> >>
> >> Welcome!
> >>
> >> --larry
> >>
> >> On Tue, Nov 10, 2015 at 11:14 AM, Jérôme LELEU <le...@gmail.com>
> wrote:
> >>
> >>> Hi,
> >>>
> >>> Perfect timing ;-) I have started implemented the pac4j support in
> Knox,
> >>> it's a very basic attempt: https://github.com/apache/knox/pull/2/files
> >>>
> >>> This implementation reuses the pac4j implementation for J2E. I have a
> >>> ProviderDeploymentContributorBase which registers two filters:
> >>> - the first one is a dispatcher filter which uses the j2e-pac4j
> >>> CallbackFilter on the /callabck url (it finishes the authentication
> process
> >>> after a successful authentication at some identity provider) and uses
> the
> >>> j2e-pac4j RequiresAuthenticationFilter otherwise (redirection to the
> >>> identity provider to start the authentication when the user is not
> >>> authenticated)
> >>> - the second one is an identity adapter which gets the current
> >>> authenticated user from the pac4j point of view and populates the J2E
> >>> security context.
> >>>
> >>>
> >>> * I have the following error:
> >>>
> >>> 2015-11-10 16:30:22,347 ERROR hadoop.gateway
> >>> (GatewayFilter.java:doFilter(135)) - Gateway processing failed:
> >>> javax.servlet.ServletException: javax.servlet.ServletException:
> >>> Authentication type must be specified: simple|kerberos|<class>
> >>> javax.servlet.ServletException: javax.servlet.ServletException:
> >>> Authentication type must be specified: simple|kerberos|<class>
> >>> at
> >>>
> org.apache.hadoop.gateway.GatewayFilter$Holder.getInstance(GatewayFilter.java:354)
> >>>
> >>> Notice I have changed the sandbox.xml file to use pac4j instead of
> Shiro,
> >>> maybe it's not the right way:
> >>>
> https://github.com/apache/knox/pull/2/files#diff-128ca80baa2dfd6c2d25de7b8160b9d9R24
> >>>
> >>> Any idea of the problem?
> >>>
> >>>
> >>> * Am I understanding webflows correctly?
> >>>
> >>> I use the default request to: curl -ivk "
> >>> https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS"
> >>>
> >>> It looks like a REST request, though I'm expecting the following
> webflow:
> >>> redirection of the user to the identity provider, successful login,
> >>> redirection back to the /callback url of the gateway: do I get it
> right?
> >>>
> >>>
> >>> * The callback url
> >>>
> >>> I currently do a check expecting the last part of the url to end with
> >>> /callback, but does the gateway will receive requests on this url? Do I
> >>> have to do something special?
> >>>
> >>> It's highly recommended to only have one callback url as this url is
> >>> defined on the identity provider side.
> >>>
> >>>
> >>> * How to pass configuration?
> >>>
> >>> Currently, I hardcoded a FacebookClient for Facebook authentication,
> but
> >>> we should be able to pass the appropriate client like Facebook or SAML.
> >>> Basically, we could do that using filter properties: facebook.key +
> >>> facebook.secret means we use Facebook authentication with the
> appropriate
> >>> key and secret for example. Any recommendation?
> >>>
> >>>
> >>> * Can I use the J2E session to store the requested protected url and
> >>> other information?
> >>>
> >>> Or do I need to do something special?
> >>>
> >>>
> >>> Thanks.
> >>> Best regards,
> >>> Jérôme
> >>>
> >>> 2015-11-10 17:03 GMT+01:00 Kevin Minder <kevin.minder@hortonworks.com
> >:
> >>>
> >>>> Hi Jerome,
> >>>> This sounds very exciting and is just the sort of thing the open
> >>>> architecture of Knox is intended to allow. Larry and I have looked at
> >>>> pac4j a number of times thinking that it would be a good fit and would
> >>>> provide a great feature set to the Hadoop community.
> >>>> Kevin.
> >>>>
> >>>>
> >>>>
> >>>> On 11/6/15, 3:31 AM, "Jérôme LELEU" <le...@gmail.com> wrote:
> >>>>
> >>>> >Hi,
> >>>> >
> >>>> >Let's open this private discussion on the Knox dev mailing list.
> >>>> >
> >>>> >I'm Jerome Leleu and the creator of pac4j (
> >>>> https://github.com/pac4j/pac4j),
> >>>> >a security engine for Java with many implementations for J2E, Play,
> >>>> Spring,
> >>>> >Vertx, Ratpack... The idea is to offer something as powerful as
> Spring
> >>>> >Security, but a lot easier and for all Java frameworks / tools and
> all
> >>>> >authentication mechanisms.
> >>>> >
> >>>> >Two years ago, we had a discussion with Larry on how pac4j could be
> >>>> used in
> >>>> >Knox.
> >>>> >
> >>>> >Meanwhile, both projects have grown up and I'm back to try to see if
> >>>> pac4j
> >>>> >can help Knox in terms of security.
> >>>> >
> >>>> >-----
> >>>> >
> >>>> >In its latest version, pac4j can be used to build a full security
> >>>> library,
> >>>> >not only focused on delegated authentication (Facebook, SAML). So we
> >>>> have
> >>>> >the concepts of direct clients (a client is an authentication
> >>>> mechanism):
> >>>> >basic auth, header, token... and indirect clients: SAML, Facebook,
> >>>> OpenID,
> >>>> >CAS...
> >>>> >It seems to be very close to the Authentication and Federation
> Providers
> >>>> >concepts from Knox.
> >>>> >
> >>>> >The provided article is great and as it's focused on authentication
> >>>> with a
> >>>> >real example, it's easier to start with it.
> >>>> >
> >>>> >Thanks for your answers.
> >>>> >
> >>>> >Like Shiro, pac4j has LDAP support and caching can be done. The only
> >>>> >difference is that pac4j relies on ldaptive (
> http://www.ldaptive.org/).
> >>>> But
> >>>> >I think you're right: it would be better to start by implementing the
> >>>> >Federation part which might be the most expected feature for Knox
> users
> >>>> (a
> >>>> >bit like buji-pac4j: https://github.com/bujiio/buji-pac4j is for
> >>>> Shiro) and
> >>>> >see if it's worth the work to have an authentication provider with
> >>>> pac4j in
> >>>> >addition to the one of Shiro.
> >>>> >
> >>>> >I plan to start working on that next week. Do you accept pull
> requests
> >>>> on
> >>>> >Github (it would make discussion easier on source code)?
> >>>> >
> >>>> >Any feedback will be appreciated.
> >>>> >
> >>>> >Thanks.
> >>>> >Best regards,
> >>>> >Jérôme
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> >2015-11-05 17:13 GMT+01:00 larry mccay:
> >>>> >
> >>>> >> Hi Jérôme -
> >>>> >>
> >>>> >> Contributions coming from the community are owned and maintained by
> >>>> the
> >>>> >> entire community.
> >>>> >> You would certainly not be expected to do all work on it and at the
> >>>> same
> >>>> >> time any assistance and upgrade messages that you provided would be
> >>>> awesome.
> >>>> >>
> >>>> >> As for an empty module for pac4j, maybe the following example
> project
> >>>> >> would be helpful to you:
> >>>> >>
> >>>> >> https://github.com/lmccay/gateway-provider-security-pseudo
> >>>> >>
> >>>> >> It is in support of an article to illustrate how to go about
> adding a
> >>>> >> authentication or federation provider - as you would be doing:
> >>>> >>
> >>>> >>
> >>>>
> https://github.com/lmccay/gateway-provider-security-pseudo/blob/master/AddingFederationProvider.md
> >>>> >>
> >>>> >> That may be easier to consume than the entire developers guide.
> >>>> >> That said, it would be great if you could describe what makes the
> dev
> >>>> >> guide too much - if that is the case.
> >>>> >>
> >>>> >> I'll take a stab at your questions here but we should move more
> >>>> detailed
> >>>> >> discussions on the topic to the dev@ list in order to keep this in
> >>>> the
> >>>> >> open and provide insights to others:
> >>>> >>
> >>>> >> 1) What do I do with the authenticated user: where / how do I fill
> >>>> this
> >>>> >> identity in Knox?
> >>>> >>
> >>>> >> We normalize the authentication event into a Java subject to
> >>>> represent the
> >>>> >> user, groups and impersonated user as appropriate.
> >>>> >> In cases - like shiro - where we don't have access to the actual
> >>>> >> authenticating code and we need to normalize the provider specific
> >>>> security
> >>>> >> context, we add another filter. You can look at the shiro provider
> >>>> for an
> >>>> >> example. The code inside the simple example provider in the article
> >>>> also
> >>>> >> shows what is expected at least in terms of the PrimaryPrincipal.
> >>>> >>
> >>>> >> 2) How to handle errors: not authenticated, not authorized?
> >>>> >>
> >>>> >> We aren't intrusive on what should be done by a provider here.
> >>>> >> Generally, authentication failures result in a 401 and
> authorizations
> >>>> in a
> >>>> >> 403 and they are usually sent by the provider.
> >>>> >>
> >>>> >> 3) How to handle redirections to an external provider?
> >>>> >>
> >>>> >> Redirects are sent by the providers themselves with a 307 or 302.
> >>>> >> You can look at the SSOCookieFederationFilter in the jwt module as
> an
> >>>> >> example if you like.
> >>>> >>
> >>>> >> 4) Should the pac4j filter also handle authorizations (pac4j can do
> >>>> that)?
> >>>> >>
> >>>> >> This is an interesting question.
> >>>> >> Knox provides a separate slot in the provider chain for
> authorization.
> >>>> >> It is there because of the ability for identity assertion providers
> >>>> to map
> >>>> >> principals in order to impersonate another user or map external
> >>>> usernames
> >>>> >> to those used inside of hadoop clusters. So, the authorization
> >>>> decisions
> >>>> >> are made based on those identities.
> >>>> >>
> >>>> >> If we can add the authorization filter as an authorization provider
> >>>> rather
> >>>> >> than part of the authentication provider than that might make
> sense.
> >>>> >> Although, the security context is normalized as Knox expects not as
> >>>> pac4j
> >>>> >> authorization probably does. Now, if there is real value in doing
> so,
> >>>> the
> >>>> >> pac4j Subject adaptor could stuff additional context into the
> Subject
> >>>> or
> >>>> >> the request that can be accessed later by the pac4j authorization
> >>>> provider.
> >>>> >>
> >>>> >> So, it can be done - the question is whether there is compelling
> >>>> reason to
> >>>> >> do so.
> >>>> >>
> >>>> >> 5) How to test?
> >>>> >>
> >>>> >> This can be challenging especially for external authentications and
> >>>> web
> >>>> >> app flows.
> >>>> >> Generally, unit testing as much as possible is required.
> >>>> >> We would want to make sure that the security context normalization
> >>>> happens
> >>>> >> as expected, etc.
> >>>> >>
> >>>> >> Additional considerations:
> >>>> >>
> >>>> >> 1. Our Shiro provider does group lookup and caching of the
> >>>> authentication
> >>>> >> event for optimizing interactions with authentication servers,
> LDAP,
> >>>> AD,
> >>>> >> etc. We wouldn't want to lose these. Doing so would be a
> non-starter
> >>>> for
> >>>> >> most folks replacing what Shiro is used for today.
> >>>> >> 2. It is probably best to concentrate on the gaps that pac4j can
> fill
> >>>> for
> >>>> >> openid, oauth, etc for the initial contribution and if the usecases
> >>>> handled
> >>>> >> by Shiro can be done better, easier, simpler then we can consider a
> >>>> >> migration path.
> >>>> >>
> >>>> >> BTW - we have a couple very interesting possibilities for strong
> and
> >>>> >> multi-factor authentication that would be enabled by OpenID
> >>>> immediately.
> >>>> >>
> >>>> >> Hope this isn't too long a response and that it is helpful for you.
> >>>> >>
> >>>> >> Let's determine what an initial contribution would be for and
> bring a
> >>>> >> proposal to the dev@ list and/or file a jira for the integration.
> >>>> >> This would be great for adding features and growing the community -
> >>>> so we
> >>>> >> are all for it!
> >>>> >>
> >>>> >> thanks,
> >>>> >>
> >>>> >> --larry
> >>>> >>
> >>>> >>
> >>>> >> On Thu, Nov 5, 2015 at 9:43 AM, Jérôme LELEU <le...@gmail.com>
> >>>> wrote:
> >>>> >>
> >>>> >>> Hi,
> >>>> >>>
> >>>> >>> I see that Shiro is already used for basic auth and LDAP
> >>>> authentication
> >>>> >>> and Picketlink for SAML. pac4j v1.8 can now handle both cases and
> >>>> even
> >>>> >>> more. So I think we could create a gateway-provider-security-pac4j
> >>>> >>> supporting all authentication mechanisms and not only OpenID.
> >>>> >>>
> >>>> >>> pac4j implementations generally work with two filters: one to
> >>>> protect a
> >>>> >>> resource and play direct authentication like basic auth (and check
> >>>> >>> authorizations) and a callback filter to finish remote
> >>>> authentication like
> >>>> >>> Facebook, SAML, OpenID. The easiest one is the j2e-pac4j with:
> >>>> >>>
> >>>>
> https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/RequiresAuthenticationFilter.java#L96
> >>>> >>> and
> >>>> >>>
> >>>>
> https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/CallbackFilter.java#L65
> >>>> >>>
> >>>> >>> That said, I have already many pac4j implementations to handle so
> I'm
> >>>> >>> pushing communities to maintain on their own their pac4j
> >>>> implementations:
> >>>> >>> can we imagine having an official: gateway-provider-security-pac4j
> >>>> module
> >>>> >>> maintained by the Knox community with my help of course? This is
> the
> >>>> kind
> >>>> >>> of message I deliver to communities when a new version of pac4j is
> >>>> >>> available so that they can upgrade:
> >>>> >>> https://github.com/ratpack/ratpack/issues/819
> >>>> >>>
> >>>> >>> I read:
> >>>> https://knox.apache.org/books/knox-0-6-0/dev-guide.html#Providers,
> >>>> >>> it might be easy for Knox contributors, but it's a bit hard for me
> >>>> to get
> >>>> >>> in everything: can you or someone in the Knox community provides
> me
> >>>> an
> >>>> >>> empty gateway-provider-security-pac4j module and the default
> >>>> expectations
> >>>> >>> from a Knox point of view?
> >>>> >>> My main questions:
> >>>> >>> 1) What do I do with the authenticated user: where / how do I fill
> >>>> this
> >>>> >>> identity in Knox?
> >>>> >>> 2) How to handle errors: not authenticated, not authorized?
> >>>> >>> 3) How to handle redirections to an external provider?
> >>>> >>> 4) Should the pac4j filter also handle authorizations (pac4j can
> do
> >>>> that)?
> >>>> >>> 5) How to test?
> >>>> >>>
> >>>> >>> Thanks.
> >>>> >>> Best regards,
> >>>> >>> Jérôme
> >>>> >>>
> >>>> >>>
> >>>> >>>
> >>>> >>>
> >>>> >>> 2015-11-03 16:58 GMT+01:00 larry mccay:
> >>>> >>>
> >>>> >>>> Hi Jérôme -
> >>>> >>>>
> >>>> >>>> We were evaluating buji-pac4j for SSO with SAML and ended up
> going
> >>>> with
> >>>> >>>> Picketlink at the time.
> >>>> >>>> That said, we do have a pluggable architecture that would allow
> for
> >>>> a
> >>>> >>>> pac4j provider as well.
> >>>> >>>>
> >>>> >>>> If you are interested in contributing such a provider that would
> >>>> >>>> certainly be welcome.
> >>>> >>>> There is someone in the community working on an openid provider
> but
> >>>> >>>> perhaps pac4j would be the way to go there?
> >>>> >>>>
> >>>> >>>> thanks,
> >>>> >>>>
> >>>> >>>> --larry
> >>>> >>>>
> >>>> >>>>
> >>>>
> >>>
> >>>
> >>
>
Re: pac4j and Apache Knox
Posted by Kevin Minder <ke...@hortonworks.com>.
To be a bit more explicit your Pac4jFederationProviderContributor declares itself to be of role “federation” but when you used it in the sandbox.xml topology file you were attempting to configure it as an provider with role authentication.
On 11/10/15, 11:32 AM, "larry mccay" <lm...@apache.org> wrote:
>Let's get you past the error that you are getting...
>
>It seems as though you have change the topology for pac4j but didn't change
>the role to "federation".
>It looks like it is grabbing a random authentication provider and seems to
>be the hadoop-auth provider.
>
>Change that to federation and see if that helps.
>
>On Tue, Nov 10, 2015 at 11:21 AM, larry mccay <lm...@apache.org> wrote:
>
>> Hi Jérôme -
>>
>> Happy to see you here!
>> I apologize for having missed your note on the list a few days ago.
>>
>> Glad to see that the article was helpful and it seems like you are making
>> great progress.
>>
>> Let me dig into your note a bit deeper and answer your questions.
>>
>> Welcome!
>>
>> --larry
>>
>> On Tue, Nov 10, 2015 at 11:14 AM, Jérôme LELEU <le...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Perfect timing ;-) I have started implemented the pac4j support in Knox,
>>> it's a very basic attempt: https://github.com/apache/knox/pull/2/files
>>>
>>> This implementation reuses the pac4j implementation for J2E. I have a
>>> ProviderDeploymentContributorBase which registers two filters:
>>> - the first one is a dispatcher filter which uses the j2e-pac4j
>>> CallbackFilter on the /callabck url (it finishes the authentication process
>>> after a successful authentication at some identity provider) and uses the
>>> j2e-pac4j RequiresAuthenticationFilter otherwise (redirection to the
>>> identity provider to start the authentication when the user is not
>>> authenticated)
>>> - the second one is an identity adapter which gets the current
>>> authenticated user from the pac4j point of view and populates the J2E
>>> security context.
>>>
>>>
>>> * I have the following error:
>>>
>>> 2015-11-10 16:30:22,347 ERROR hadoop.gateway
>>> (GatewayFilter.java:doFilter(135)) - Gateway processing failed:
>>> javax.servlet.ServletException: javax.servlet.ServletException:
>>> Authentication type must be specified: simple|kerberos|<class>
>>> javax.servlet.ServletException: javax.servlet.ServletException:
>>> Authentication type must be specified: simple|kerberos|<class>
>>> at
>>> org.apache.hadoop.gateway.GatewayFilter$Holder.getInstance(GatewayFilter.java:354)
>>>
>>> Notice I have changed the sandbox.xml file to use pac4j instead of Shiro,
>>> maybe it's not the right way:
>>> https://github.com/apache/knox/pull/2/files#diff-128ca80baa2dfd6c2d25de7b8160b9d9R24
>>>
>>> Any idea of the problem?
>>>
>>>
>>> * Am I understanding webflows correctly?
>>>
>>> I use the default request to: curl -ivk "
>>> https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS"
>>>
>>> It looks like a REST request, though I'm expecting the following webflow:
>>> redirection of the user to the identity provider, successful login,
>>> redirection back to the /callback url of the gateway: do I get it right?
>>>
>>>
>>> * The callback url
>>>
>>> I currently do a check expecting the last part of the url to end with
>>> /callback, but does the gateway will receive requests on this url? Do I
>>> have to do something special?
>>>
>>> It's highly recommended to only have one callback url as this url is
>>> defined on the identity provider side.
>>>
>>>
>>> * How to pass configuration?
>>>
>>> Currently, I hardcoded a FacebookClient for Facebook authentication, but
>>> we should be able to pass the appropriate client like Facebook or SAML.
>>> Basically, we could do that using filter properties: facebook.key +
>>> facebook.secret means we use Facebook authentication with the appropriate
>>> key and secret for example. Any recommendation?
>>>
>>>
>>> * Can I use the J2E session to store the requested protected url and
>>> other information?
>>>
>>> Or do I need to do something special?
>>>
>>>
>>> Thanks.
>>> Best regards,
>>> Jérôme
>>>
>>> 2015-11-10 17:03 GMT+01:00 Kevin Minder <ke...@hortonworks.com>:
>>>
>>>> Hi Jerome,
>>>> This sounds very exciting and is just the sort of thing the open
>>>> architecture of Knox is intended to allow. Larry and I have looked at
>>>> pac4j a number of times thinking that it would be a good fit and would
>>>> provide a great feature set to the Hadoop community.
>>>> Kevin.
>>>>
>>>>
>>>>
>>>> On 11/6/15, 3:31 AM, "Jérôme LELEU" <le...@gmail.com> wrote:
>>>>
>>>> >Hi,
>>>> >
>>>> >Let's open this private discussion on the Knox dev mailing list.
>>>> >
>>>> >I'm Jerome Leleu and the creator of pac4j (
>>>> https://github.com/pac4j/pac4j),
>>>> >a security engine for Java with many implementations for J2E, Play,
>>>> Spring,
>>>> >Vertx, Ratpack... The idea is to offer something as powerful as Spring
>>>> >Security, but a lot easier and for all Java frameworks / tools and all
>>>> >authentication mechanisms.
>>>> >
>>>> >Two years ago, we had a discussion with Larry on how pac4j could be
>>>> used in
>>>> >Knox.
>>>> >
>>>> >Meanwhile, both projects have grown up and I'm back to try to see if
>>>> pac4j
>>>> >can help Knox in terms of security.
>>>> >
>>>> >-----
>>>> >
>>>> >In its latest version, pac4j can be used to build a full security
>>>> library,
>>>> >not only focused on delegated authentication (Facebook, SAML). So we
>>>> have
>>>> >the concepts of direct clients (a client is an authentication
>>>> mechanism):
>>>> >basic auth, header, token... and indirect clients: SAML, Facebook,
>>>> OpenID,
>>>> >CAS...
>>>> >It seems to be very close to the Authentication and Federation Providers
>>>> >concepts from Knox.
>>>> >
>>>> >The provided article is great and as it's focused on authentication
>>>> with a
>>>> >real example, it's easier to start with it.
>>>> >
>>>> >Thanks for your answers.
>>>> >
>>>> >Like Shiro, pac4j has LDAP support and caching can be done. The only
>>>> >difference is that pac4j relies on ldaptive (http://www.ldaptive.org/).
>>>> But
>>>> >I think you're right: it would be better to start by implementing the
>>>> >Federation part which might be the most expected feature for Knox users
>>>> (a
>>>> >bit like buji-pac4j: https://github.com/bujiio/buji-pac4j is for
>>>> Shiro) and
>>>> >see if it's worth the work to have an authentication provider with
>>>> pac4j in
>>>> >addition to the one of Shiro.
>>>> >
>>>> >I plan to start working on that next week. Do you accept pull requests
>>>> on
>>>> >Github (it would make discussion easier on source code)?
>>>> >
>>>> >Any feedback will be appreciated.
>>>> >
>>>> >Thanks.
>>>> >Best regards,
>>>> >Jérôme
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >2015-11-05 17:13 GMT+01:00 larry mccay:
>>>> >
>>>> >> Hi Jérôme -
>>>> >>
>>>> >> Contributions coming from the community are owned and maintained by
>>>> the
>>>> >> entire community.
>>>> >> You would certainly not be expected to do all work on it and at the
>>>> same
>>>> >> time any assistance and upgrade messages that you provided would be
>>>> awesome.
>>>> >>
>>>> >> As for an empty module for pac4j, maybe the following example project
>>>> >> would be helpful to you:
>>>> >>
>>>> >> https://github.com/lmccay/gateway-provider-security-pseudo
>>>> >>
>>>> >> It is in support of an article to illustrate how to go about adding a
>>>> >> authentication or federation provider - as you would be doing:
>>>> >>
>>>> >>
>>>> https://github.com/lmccay/gateway-provider-security-pseudo/blob/master/AddingFederationProvider.md
>>>> >>
>>>> >> That may be easier to consume than the entire developers guide.
>>>> >> That said, it would be great if you could describe what makes the dev
>>>> >> guide too much - if that is the case.
>>>> >>
>>>> >> I'll take a stab at your questions here but we should move more
>>>> detailed
>>>> >> discussions on the topic to the dev@ list in order to keep this in
>>>> the
>>>> >> open and provide insights to others:
>>>> >>
>>>> >> 1) What do I do with the authenticated user: where / how do I fill
>>>> this
>>>> >> identity in Knox?
>>>> >>
>>>> >> We normalize the authentication event into a Java subject to
>>>> represent the
>>>> >> user, groups and impersonated user as appropriate.
>>>> >> In cases - like shiro - where we don't have access to the actual
>>>> >> authenticating code and we need to normalize the provider specific
>>>> security
>>>> >> context, we add another filter. You can look at the shiro provider
>>>> for an
>>>> >> example. The code inside the simple example provider in the article
>>>> also
>>>> >> shows what is expected at least in terms of the PrimaryPrincipal.
>>>> >>
>>>> >> 2) How to handle errors: not authenticated, not authorized?
>>>> >>
>>>> >> We aren't intrusive on what should be done by a provider here.
>>>> >> Generally, authentication failures result in a 401 and authorizations
>>>> in a
>>>> >> 403 and they are usually sent by the provider.
>>>> >>
>>>> >> 3) How to handle redirections to an external provider?
>>>> >>
>>>> >> Redirects are sent by the providers themselves with a 307 or 302.
>>>> >> You can look at the SSOCookieFederationFilter in the jwt module as an
>>>> >> example if you like.
>>>> >>
>>>> >> 4) Should the pac4j filter also handle authorizations (pac4j can do
>>>> that)?
>>>> >>
>>>> >> This is an interesting question.
>>>> >> Knox provides a separate slot in the provider chain for authorization.
>>>> >> It is there because of the ability for identity assertion providers
>>>> to map
>>>> >> principals in order to impersonate another user or map external
>>>> usernames
>>>> >> to those used inside of hadoop clusters. So, the authorization
>>>> decisions
>>>> >> are made based on those identities.
>>>> >>
>>>> >> If we can add the authorization filter as an authorization provider
>>>> rather
>>>> >> than part of the authentication provider than that might make sense.
>>>> >> Although, the security context is normalized as Knox expects not as
>>>> pac4j
>>>> >> authorization probably does. Now, if there is real value in doing so,
>>>> the
>>>> >> pac4j Subject adaptor could stuff additional context into the Subject
>>>> or
>>>> >> the request that can be accessed later by the pac4j authorization
>>>> provider.
>>>> >>
>>>> >> So, it can be done - the question is whether there is compelling
>>>> reason to
>>>> >> do so.
>>>> >>
>>>> >> 5) How to test?
>>>> >>
>>>> >> This can be challenging especially for external authentications and
>>>> web
>>>> >> app flows.
>>>> >> Generally, unit testing as much as possible is required.
>>>> >> We would want to make sure that the security context normalization
>>>> happens
>>>> >> as expected, etc.
>>>> >>
>>>> >> Additional considerations:
>>>> >>
>>>> >> 1. Our Shiro provider does group lookup and caching of the
>>>> authentication
>>>> >> event for optimizing interactions with authentication servers, LDAP,
>>>> AD,
>>>> >> etc. We wouldn't want to lose these. Doing so would be a non-starter
>>>> for
>>>> >> most folks replacing what Shiro is used for today.
>>>> >> 2. It is probably best to concentrate on the gaps that pac4j can fill
>>>> for
>>>> >> openid, oauth, etc for the initial contribution and if the usecases
>>>> handled
>>>> >> by Shiro can be done better, easier, simpler then we can consider a
>>>> >> migration path.
>>>> >>
>>>> >> BTW - we have a couple very interesting possibilities for strong and
>>>> >> multi-factor authentication that would be enabled by OpenID
>>>> immediately.
>>>> >>
>>>> >> Hope this isn't too long a response and that it is helpful for you.
>>>> >>
>>>> >> Let's determine what an initial contribution would be for and bring a
>>>> >> proposal to the dev@ list and/or file a jira for the integration.
>>>> >> This would be great for adding features and growing the community -
>>>> so we
>>>> >> are all for it!
>>>> >>
>>>> >> thanks,
>>>> >>
>>>> >> --larry
>>>> >>
>>>> >>
>>>> >> On Thu, Nov 5, 2015 at 9:43 AM, Jérôme LELEU <le...@gmail.com>
>>>> wrote:
>>>> >>
>>>> >>> Hi,
>>>> >>>
>>>> >>> I see that Shiro is already used for basic auth and LDAP
>>>> authentication
>>>> >>> and Picketlink for SAML. pac4j v1.8 can now handle both cases and
>>>> even
>>>> >>> more. So I think we could create a gateway-provider-security-pac4j
>>>> >>> supporting all authentication mechanisms and not only OpenID.
>>>> >>>
>>>> >>> pac4j implementations generally work with two filters: one to
>>>> protect a
>>>> >>> resource and play direct authentication like basic auth (and check
>>>> >>> authorizations) and a callback filter to finish remote
>>>> authentication like
>>>> >>> Facebook, SAML, OpenID. The easiest one is the j2e-pac4j with:
>>>> >>>
>>>> https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/RequiresAuthenticationFilter.java#L96
>>>> >>> and
>>>> >>>
>>>> https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/CallbackFilter.java#L65
>>>> >>>
>>>> >>> That said, I have already many pac4j implementations to handle so I'm
>>>> >>> pushing communities to maintain on their own their pac4j
>>>> implementations:
>>>> >>> can we imagine having an official: gateway-provider-security-pac4j
>>>> module
>>>> >>> maintained by the Knox community with my help of course? This is the
>>>> kind
>>>> >>> of message I deliver to communities when a new version of pac4j is
>>>> >>> available so that they can upgrade:
>>>> >>> https://github.com/ratpack/ratpack/issues/819
>>>> >>>
>>>> >>> I read:
>>>> https://knox.apache.org/books/knox-0-6-0/dev-guide.html#Providers,
>>>> >>> it might be easy for Knox contributors, but it's a bit hard for me
>>>> to get
>>>> >>> in everything: can you or someone in the Knox community provides me
>>>> an
>>>> >>> empty gateway-provider-security-pac4j module and the default
>>>> expectations
>>>> >>> from a Knox point of view?
>>>> >>> My main questions:
>>>> >>> 1) What do I do with the authenticated user: where / how do I fill
>>>> this
>>>> >>> identity in Knox?
>>>> >>> 2) How to handle errors: not authenticated, not authorized?
>>>> >>> 3) How to handle redirections to an external provider?
>>>> >>> 4) Should the pac4j filter also handle authorizations (pac4j can do
>>>> that)?
>>>> >>> 5) How to test?
>>>> >>>
>>>> >>> Thanks.
>>>> >>> Best regards,
>>>> >>> Jérôme
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> 2015-11-03 16:58 GMT+01:00 larry mccay:
>>>> >>>
>>>> >>>> Hi Jérôme -
>>>> >>>>
>>>> >>>> We were evaluating buji-pac4j for SSO with SAML and ended up going
>>>> with
>>>> >>>> Picketlink at the time.
>>>> >>>> That said, we do have a pluggable architecture that would allow for
>>>> a
>>>> >>>> pac4j provider as well.
>>>> >>>>
>>>> >>>> If you are interested in contributing such a provider that would
>>>> >>>> certainly be welcome.
>>>> >>>> There is someone in the community working on an openid provider but
>>>> >>>> perhaps pac4j would be the way to go there?
>>>> >>>>
>>>> >>>> thanks,
>>>> >>>>
>>>> >>>> --larry
>>>> >>>>
>>>> >>>>
>>>>
>>>
>>>
>>
Re: pac4j and Apache Knox
Posted by larry mccay <lm...@apache.org>.
Let's get you past the error that you are getting...
It seems as though you have change the topology for pac4j but didn't change
the role to "federation".
It looks like it is grabbing a random authentication provider and seems to
be the hadoop-auth provider.
Change that to federation and see if that helps.
On Tue, Nov 10, 2015 at 11:21 AM, larry mccay <lm...@apache.org> wrote:
> Hi Jérôme -
>
> Happy to see you here!
> I apologize for having missed your note on the list a few days ago.
>
> Glad to see that the article was helpful and it seems like you are making
> great progress.
>
> Let me dig into your note a bit deeper and answer your questions.
>
> Welcome!
>
> --larry
>
> On Tue, Nov 10, 2015 at 11:14 AM, Jérôme LELEU <le...@gmail.com> wrote:
>
>> Hi,
>>
>> Perfect timing ;-) I have started implemented the pac4j support in Knox,
>> it's a very basic attempt: https://github.com/apache/knox/pull/2/files
>>
>> This implementation reuses the pac4j implementation for J2E. I have a
>> ProviderDeploymentContributorBase which registers two filters:
>> - the first one is a dispatcher filter which uses the j2e-pac4j
>> CallbackFilter on the /callabck url (it finishes the authentication process
>> after a successful authentication at some identity provider) and uses the
>> j2e-pac4j RequiresAuthenticationFilter otherwise (redirection to the
>> identity provider to start the authentication when the user is not
>> authenticated)
>> - the second one is an identity adapter which gets the current
>> authenticated user from the pac4j point of view and populates the J2E
>> security context.
>>
>>
>> * I have the following error:
>>
>> 2015-11-10 16:30:22,347 ERROR hadoop.gateway
>> (GatewayFilter.java:doFilter(135)) - Gateway processing failed:
>> javax.servlet.ServletException: javax.servlet.ServletException:
>> Authentication type must be specified: simple|kerberos|<class>
>> javax.servlet.ServletException: javax.servlet.ServletException:
>> Authentication type must be specified: simple|kerberos|<class>
>> at
>> org.apache.hadoop.gateway.GatewayFilter$Holder.getInstance(GatewayFilter.java:354)
>>
>> Notice I have changed the sandbox.xml file to use pac4j instead of Shiro,
>> maybe it's not the right way:
>> https://github.com/apache/knox/pull/2/files#diff-128ca80baa2dfd6c2d25de7b8160b9d9R24
>>
>> Any idea of the problem?
>>
>>
>> * Am I understanding webflows correctly?
>>
>> I use the default request to: curl -ivk "
>> https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS"
>>
>> It looks like a REST request, though I'm expecting the following webflow:
>> redirection of the user to the identity provider, successful login,
>> redirection back to the /callback url of the gateway: do I get it right?
>>
>>
>> * The callback url
>>
>> I currently do a check expecting the last part of the url to end with
>> /callback, but does the gateway will receive requests on this url? Do I
>> have to do something special?
>>
>> It's highly recommended to only have one callback url as this url is
>> defined on the identity provider side.
>>
>>
>> * How to pass configuration?
>>
>> Currently, I hardcoded a FacebookClient for Facebook authentication, but
>> we should be able to pass the appropriate client like Facebook or SAML.
>> Basically, we could do that using filter properties: facebook.key +
>> facebook.secret means we use Facebook authentication with the appropriate
>> key and secret for example. Any recommendation?
>>
>>
>> * Can I use the J2E session to store the requested protected url and
>> other information?
>>
>> Or do I need to do something special?
>>
>>
>> Thanks.
>> Best regards,
>> Jérôme
>>
>> 2015-11-10 17:03 GMT+01:00 Kevin Minder <ke...@hortonworks.com>:
>>
>>> Hi Jerome,
>>> This sounds very exciting and is just the sort of thing the open
>>> architecture of Knox is intended to allow. Larry and I have looked at
>>> pac4j a number of times thinking that it would be a good fit and would
>>> provide a great feature set to the Hadoop community.
>>> Kevin.
>>>
>>>
>>>
>>> On 11/6/15, 3:31 AM, "Jérôme LELEU" <le...@gmail.com> wrote:
>>>
>>> >Hi,
>>> >
>>> >Let's open this private discussion on the Knox dev mailing list.
>>> >
>>> >I'm Jerome Leleu and the creator of pac4j (
>>> https://github.com/pac4j/pac4j),
>>> >a security engine for Java with many implementations for J2E, Play,
>>> Spring,
>>> >Vertx, Ratpack... The idea is to offer something as powerful as Spring
>>> >Security, but a lot easier and for all Java frameworks / tools and all
>>> >authentication mechanisms.
>>> >
>>> >Two years ago, we had a discussion with Larry on how pac4j could be
>>> used in
>>> >Knox.
>>> >
>>> >Meanwhile, both projects have grown up and I'm back to try to see if
>>> pac4j
>>> >can help Knox in terms of security.
>>> >
>>> >-----
>>> >
>>> >In its latest version, pac4j can be used to build a full security
>>> library,
>>> >not only focused on delegated authentication (Facebook, SAML). So we
>>> have
>>> >the concepts of direct clients (a client is an authentication
>>> mechanism):
>>> >basic auth, header, token... and indirect clients: SAML, Facebook,
>>> OpenID,
>>> >CAS...
>>> >It seems to be very close to the Authentication and Federation Providers
>>> >concepts from Knox.
>>> >
>>> >The provided article is great and as it's focused on authentication
>>> with a
>>> >real example, it's easier to start with it.
>>> >
>>> >Thanks for your answers.
>>> >
>>> >Like Shiro, pac4j has LDAP support and caching can be done. The only
>>> >difference is that pac4j relies on ldaptive (http://www.ldaptive.org/).
>>> But
>>> >I think you're right: it would be better to start by implementing the
>>> >Federation part which might be the most expected feature for Knox users
>>> (a
>>> >bit like buji-pac4j: https://github.com/bujiio/buji-pac4j is for
>>> Shiro) and
>>> >see if it's worth the work to have an authentication provider with
>>> pac4j in
>>> >addition to the one of Shiro.
>>> >
>>> >I plan to start working on that next week. Do you accept pull requests
>>> on
>>> >Github (it would make discussion easier on source code)?
>>> >
>>> >Any feedback will be appreciated.
>>> >
>>> >Thanks.
>>> >Best regards,
>>> >Jérôme
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >2015-11-05 17:13 GMT+01:00 larry mccay:
>>> >
>>> >> Hi Jérôme -
>>> >>
>>> >> Contributions coming from the community are owned and maintained by
>>> the
>>> >> entire community.
>>> >> You would certainly not be expected to do all work on it and at the
>>> same
>>> >> time any assistance and upgrade messages that you provided would be
>>> awesome.
>>> >>
>>> >> As for an empty module for pac4j, maybe the following example project
>>> >> would be helpful to you:
>>> >>
>>> >> https://github.com/lmccay/gateway-provider-security-pseudo
>>> >>
>>> >> It is in support of an article to illustrate how to go about adding a
>>> >> authentication or federation provider - as you would be doing:
>>> >>
>>> >>
>>> https://github.com/lmccay/gateway-provider-security-pseudo/blob/master/AddingFederationProvider.md
>>> >>
>>> >> That may be easier to consume than the entire developers guide.
>>> >> That said, it would be great if you could describe what makes the dev
>>> >> guide too much - if that is the case.
>>> >>
>>> >> I'll take a stab at your questions here but we should move more
>>> detailed
>>> >> discussions on the topic to the dev@ list in order to keep this in
>>> the
>>> >> open and provide insights to others:
>>> >>
>>> >> 1) What do I do with the authenticated user: where / how do I fill
>>> this
>>> >> identity in Knox?
>>> >>
>>> >> We normalize the authentication event into a Java subject to
>>> represent the
>>> >> user, groups and impersonated user as appropriate.
>>> >> In cases - like shiro - where we don't have access to the actual
>>> >> authenticating code and we need to normalize the provider specific
>>> security
>>> >> context, we add another filter. You can look at the shiro provider
>>> for an
>>> >> example. The code inside the simple example provider in the article
>>> also
>>> >> shows what is expected at least in terms of the PrimaryPrincipal.
>>> >>
>>> >> 2) How to handle errors: not authenticated, not authorized?
>>> >>
>>> >> We aren't intrusive on what should be done by a provider here.
>>> >> Generally, authentication failures result in a 401 and authorizations
>>> in a
>>> >> 403 and they are usually sent by the provider.
>>> >>
>>> >> 3) How to handle redirections to an external provider?
>>> >>
>>> >> Redirects are sent by the providers themselves with a 307 or 302.
>>> >> You can look at the SSOCookieFederationFilter in the jwt module as an
>>> >> example if you like.
>>> >>
>>> >> 4) Should the pac4j filter also handle authorizations (pac4j can do
>>> that)?
>>> >>
>>> >> This is an interesting question.
>>> >> Knox provides a separate slot in the provider chain for authorization.
>>> >> It is there because of the ability for identity assertion providers
>>> to map
>>> >> principals in order to impersonate another user or map external
>>> usernames
>>> >> to those used inside of hadoop clusters. So, the authorization
>>> decisions
>>> >> are made based on those identities.
>>> >>
>>> >> If we can add the authorization filter as an authorization provider
>>> rather
>>> >> than part of the authentication provider than that might make sense.
>>> >> Although, the security context is normalized as Knox expects not as
>>> pac4j
>>> >> authorization probably does. Now, if there is real value in doing so,
>>> the
>>> >> pac4j Subject adaptor could stuff additional context into the Subject
>>> or
>>> >> the request that can be accessed later by the pac4j authorization
>>> provider.
>>> >>
>>> >> So, it can be done - the question is whether there is compelling
>>> reason to
>>> >> do so.
>>> >>
>>> >> 5) How to test?
>>> >>
>>> >> This can be challenging especially for external authentications and
>>> web
>>> >> app flows.
>>> >> Generally, unit testing as much as possible is required.
>>> >> We would want to make sure that the security context normalization
>>> happens
>>> >> as expected, etc.
>>> >>
>>> >> Additional considerations:
>>> >>
>>> >> 1. Our Shiro provider does group lookup and caching of the
>>> authentication
>>> >> event for optimizing interactions with authentication servers, LDAP,
>>> AD,
>>> >> etc. We wouldn't want to lose these. Doing so would be a non-starter
>>> for
>>> >> most folks replacing what Shiro is used for today.
>>> >> 2. It is probably best to concentrate on the gaps that pac4j can fill
>>> for
>>> >> openid, oauth, etc for the initial contribution and if the usecases
>>> handled
>>> >> by Shiro can be done better, easier, simpler then we can consider a
>>> >> migration path.
>>> >>
>>> >> BTW - we have a couple very interesting possibilities for strong and
>>> >> multi-factor authentication that would be enabled by OpenID
>>> immediately.
>>> >>
>>> >> Hope this isn't too long a response and that it is helpful for you.
>>> >>
>>> >> Let's determine what an initial contribution would be for and bring a
>>> >> proposal to the dev@ list and/or file a jira for the integration.
>>> >> This would be great for adding features and growing the community -
>>> so we
>>> >> are all for it!
>>> >>
>>> >> thanks,
>>> >>
>>> >> --larry
>>> >>
>>> >>
>>> >> On Thu, Nov 5, 2015 at 9:43 AM, Jérôme LELEU <le...@gmail.com>
>>> wrote:
>>> >>
>>> >>> Hi,
>>> >>>
>>> >>> I see that Shiro is already used for basic auth and LDAP
>>> authentication
>>> >>> and Picketlink for SAML. pac4j v1.8 can now handle both cases and
>>> even
>>> >>> more. So I think we could create a gateway-provider-security-pac4j
>>> >>> supporting all authentication mechanisms and not only OpenID.
>>> >>>
>>> >>> pac4j implementations generally work with two filters: one to
>>> protect a
>>> >>> resource and play direct authentication like basic auth (and check
>>> >>> authorizations) and a callback filter to finish remote
>>> authentication like
>>> >>> Facebook, SAML, OpenID. The easiest one is the j2e-pac4j with:
>>> >>>
>>> https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/RequiresAuthenticationFilter.java#L96
>>> >>> and
>>> >>>
>>> https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/CallbackFilter.java#L65
>>> >>>
>>> >>> That said, I have already many pac4j implementations to handle so I'm
>>> >>> pushing communities to maintain on their own their pac4j
>>> implementations:
>>> >>> can we imagine having an official: gateway-provider-security-pac4j
>>> module
>>> >>> maintained by the Knox community with my help of course? This is the
>>> kind
>>> >>> of message I deliver to communities when a new version of pac4j is
>>> >>> available so that they can upgrade:
>>> >>> https://github.com/ratpack/ratpack/issues/819
>>> >>>
>>> >>> I read:
>>> https://knox.apache.org/books/knox-0-6-0/dev-guide.html#Providers,
>>> >>> it might be easy for Knox contributors, but it's a bit hard for me
>>> to get
>>> >>> in everything: can you or someone in the Knox community provides me
>>> an
>>> >>> empty gateway-provider-security-pac4j module and the default
>>> expectations
>>> >>> from a Knox point of view?
>>> >>> My main questions:
>>> >>> 1) What do I do with the authenticated user: where / how do I fill
>>> this
>>> >>> identity in Knox?
>>> >>> 2) How to handle errors: not authenticated, not authorized?
>>> >>> 3) How to handle redirections to an external provider?
>>> >>> 4) Should the pac4j filter also handle authorizations (pac4j can do
>>> that)?
>>> >>> 5) How to test?
>>> >>>
>>> >>> Thanks.
>>> >>> Best regards,
>>> >>> Jérôme
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> 2015-11-03 16:58 GMT+01:00 larry mccay:
>>> >>>
>>> >>>> Hi Jérôme -
>>> >>>>
>>> >>>> We were evaluating buji-pac4j for SSO with SAML and ended up going
>>> with
>>> >>>> Picketlink at the time.
>>> >>>> That said, we do have a pluggable architecture that would allow for
>>> a
>>> >>>> pac4j provider as well.
>>> >>>>
>>> >>>> If you are interested in contributing such a provider that would
>>> >>>> certainly be welcome.
>>> >>>> There is someone in the community working on an openid provider but
>>> >>>> perhaps pac4j would be the way to go there?
>>> >>>>
>>> >>>> thanks,
>>> >>>>
>>> >>>> --larry
>>> >>>>
>>> >>>>
>>>
>>
>>
>
Re: pac4j and Apache Knox
Posted by larry mccay <lm...@apache.org>.
Hi Jérôme -
Happy to see you here!
I apologize for having missed your note on the list a few days ago.
Glad to see that the article was helpful and it seems like you are making
great progress.
Let me dig into your note a bit deeper and answer your questions.
Welcome!
--larry
On Tue, Nov 10, 2015 at 11:14 AM, Jérôme LELEU <le...@gmail.com> wrote:
> Hi,
>
> Perfect timing ;-) I have started implemented the pac4j support in Knox,
> it's a very basic attempt: https://github.com/apache/knox/pull/2/files
>
> This implementation reuses the pac4j implementation for J2E. I have a
> ProviderDeploymentContributorBase which registers two filters:
> - the first one is a dispatcher filter which uses the j2e-pac4j
> CallbackFilter on the /callabck url (it finishes the authentication process
> after a successful authentication at some identity provider) and uses the
> j2e-pac4j RequiresAuthenticationFilter otherwise (redirection to the
> identity provider to start the authentication when the user is not
> authenticated)
> - the second one is an identity adapter which gets the current
> authenticated user from the pac4j point of view and populates the J2E
> security context.
>
>
> * I have the following error:
>
> 2015-11-10 16:30:22,347 ERROR hadoop.gateway
> (GatewayFilter.java:doFilter(135)) - Gateway processing failed:
> javax.servlet.ServletException: javax.servlet.ServletException:
> Authentication type must be specified: simple|kerberos|<class>
> javax.servlet.ServletException: javax.servlet.ServletException:
> Authentication type must be specified: simple|kerberos|<class>
> at
> org.apache.hadoop.gateway.GatewayFilter$Holder.getInstance(GatewayFilter.java:354)
>
> Notice I have changed the sandbox.xml file to use pac4j instead of Shiro,
> maybe it's not the right way:
> https://github.com/apache/knox/pull/2/files#diff-128ca80baa2dfd6c2d25de7b8160b9d9R24
>
> Any idea of the problem?
>
>
> * Am I understanding webflows correctly?
>
> I use the default request to: curl -ivk "
> https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS"
>
> It looks like a REST request, though I'm expecting the following webflow:
> redirection of the user to the identity provider, successful login,
> redirection back to the /callback url of the gateway: do I get it right?
>
>
> * The callback url
>
> I currently do a check expecting the last part of the url to end with
> /callback, but does the gateway will receive requests on this url? Do I
> have to do something special?
>
> It's highly recommended to only have one callback url as this url is
> defined on the identity provider side.
>
>
> * How to pass configuration?
>
> Currently, I hardcoded a FacebookClient for Facebook authentication, but
> we should be able to pass the appropriate client like Facebook or SAML.
> Basically, we could do that using filter properties: facebook.key +
> facebook.secret means we use Facebook authentication with the appropriate
> key and secret for example. Any recommendation?
>
>
> * Can I use the J2E session to store the requested protected url and other
> information?
>
> Or do I need to do something special?
>
>
> Thanks.
> Best regards,
> Jérôme
>
> 2015-11-10 17:03 GMT+01:00 Kevin Minder <ke...@hortonworks.com>:
>
>> Hi Jerome,
>> This sounds very exciting and is just the sort of thing the open
>> architecture of Knox is intended to allow. Larry and I have looked at
>> pac4j a number of times thinking that it would be a good fit and would
>> provide a great feature set to the Hadoop community.
>> Kevin.
>>
>>
>>
>> On 11/6/15, 3:31 AM, "Jérôme LELEU" <le...@gmail.com> wrote:
>>
>> >Hi,
>> >
>> >Let's open this private discussion on the Knox dev mailing list.
>> >
>> >I'm Jerome Leleu and the creator of pac4j (
>> https://github.com/pac4j/pac4j),
>> >a security engine for Java with many implementations for J2E, Play,
>> Spring,
>> >Vertx, Ratpack... The idea is to offer something as powerful as Spring
>> >Security, but a lot easier and for all Java frameworks / tools and all
>> >authentication mechanisms.
>> >
>> >Two years ago, we had a discussion with Larry on how pac4j could be used
>> in
>> >Knox.
>> >
>> >Meanwhile, both projects have grown up and I'm back to try to see if
>> pac4j
>> >can help Knox in terms of security.
>> >
>> >-----
>> >
>> >In its latest version, pac4j can be used to build a full security
>> library,
>> >not only focused on delegated authentication (Facebook, SAML). So we have
>> >the concepts of direct clients (a client is an authentication mechanism):
>> >basic auth, header, token... and indirect clients: SAML, Facebook,
>> OpenID,
>> >CAS...
>> >It seems to be very close to the Authentication and Federation Providers
>> >concepts from Knox.
>> >
>> >The provided article is great and as it's focused on authentication with
>> a
>> >real example, it's easier to start with it.
>> >
>> >Thanks for your answers.
>> >
>> >Like Shiro, pac4j has LDAP support and caching can be done. The only
>> >difference is that pac4j relies on ldaptive (http://www.ldaptive.org/).
>> But
>> >I think you're right: it would be better to start by implementing the
>> >Federation part which might be the most expected feature for Knox users
>> (a
>> >bit like buji-pac4j: https://github.com/bujiio/buji-pac4j is for Shiro)
>> and
>> >see if it's worth the work to have an authentication provider with pac4j
>> in
>> >addition to the one of Shiro.
>> >
>> >I plan to start working on that next week. Do you accept pull requests on
>> >Github (it would make discussion easier on source code)?
>> >
>> >Any feedback will be appreciated.
>> >
>> >Thanks.
>> >Best regards,
>> >Jérôme
>> >
>> >
>> >
>> >
>> >
>> >
>> >2015-11-05 17:13 GMT+01:00 larry mccay:
>> >
>> >> Hi Jérôme -
>> >>
>> >> Contributions coming from the community are owned and maintained by the
>> >> entire community.
>> >> You would certainly not be expected to do all work on it and at the
>> same
>> >> time any assistance and upgrade messages that you provided would be
>> awesome.
>> >>
>> >> As for an empty module for pac4j, maybe the following example project
>> >> would be helpful to you:
>> >>
>> >> https://github.com/lmccay/gateway-provider-security-pseudo
>> >>
>> >> It is in support of an article to illustrate how to go about adding a
>> >> authentication or federation provider - as you would be doing:
>> >>
>> >>
>> https://github.com/lmccay/gateway-provider-security-pseudo/blob/master/AddingFederationProvider.md
>> >>
>> >> That may be easier to consume than the entire developers guide.
>> >> That said, it would be great if you could describe what makes the dev
>> >> guide too much - if that is the case.
>> >>
>> >> I'll take a stab at your questions here but we should move more
>> detailed
>> >> discussions on the topic to the dev@ list in order to keep this in the
>> >> open and provide insights to others:
>> >>
>> >> 1) What do I do with the authenticated user: where / how do I fill this
>> >> identity in Knox?
>> >>
>> >> We normalize the authentication event into a Java subject to represent
>> the
>> >> user, groups and impersonated user as appropriate.
>> >> In cases - like shiro - where we don't have access to the actual
>> >> authenticating code and we need to normalize the provider specific
>> security
>> >> context, we add another filter. You can look at the shiro provider for
>> an
>> >> example. The code inside the simple example provider in the article
>> also
>> >> shows what is expected at least in terms of the PrimaryPrincipal.
>> >>
>> >> 2) How to handle errors: not authenticated, not authorized?
>> >>
>> >> We aren't intrusive on what should be done by a provider here.
>> >> Generally, authentication failures result in a 401 and authorizations
>> in a
>> >> 403 and they are usually sent by the provider.
>> >>
>> >> 3) How to handle redirections to an external provider?
>> >>
>> >> Redirects are sent by the providers themselves with a 307 or 302.
>> >> You can look at the SSOCookieFederationFilter in the jwt module as an
>> >> example if you like.
>> >>
>> >> 4) Should the pac4j filter also handle authorizations (pac4j can do
>> that)?
>> >>
>> >> This is an interesting question.
>> >> Knox provides a separate slot in the provider chain for authorization.
>> >> It is there because of the ability for identity assertion providers to
>> map
>> >> principals in order to impersonate another user or map external
>> usernames
>> >> to those used inside of hadoop clusters. So, the authorization
>> decisions
>> >> are made based on those identities.
>> >>
>> >> If we can add the authorization filter as an authorization provider
>> rather
>> >> than part of the authentication provider than that might make sense.
>> >> Although, the security context is normalized as Knox expects not as
>> pac4j
>> >> authorization probably does. Now, if there is real value in doing so,
>> the
>> >> pac4j Subject adaptor could stuff additional context into the Subject
>> or
>> >> the request that can be accessed later by the pac4j authorization
>> provider.
>> >>
>> >> So, it can be done - the question is whether there is compelling
>> reason to
>> >> do so.
>> >>
>> >> 5) How to test?
>> >>
>> >> This can be challenging especially for external authentications and web
>> >> app flows.
>> >> Generally, unit testing as much as possible is required.
>> >> We would want to make sure that the security context normalization
>> happens
>> >> as expected, etc.
>> >>
>> >> Additional considerations:
>> >>
>> >> 1. Our Shiro provider does group lookup and caching of the
>> authentication
>> >> event for optimizing interactions with authentication servers, LDAP,
>> AD,
>> >> etc. We wouldn't want to lose these. Doing so would be a non-starter
>> for
>> >> most folks replacing what Shiro is used for today.
>> >> 2. It is probably best to concentrate on the gaps that pac4j can fill
>> for
>> >> openid, oauth, etc for the initial contribution and if the usecases
>> handled
>> >> by Shiro can be done better, easier, simpler then we can consider a
>> >> migration path.
>> >>
>> >> BTW - we have a couple very interesting possibilities for strong and
>> >> multi-factor authentication that would be enabled by OpenID
>> immediately.
>> >>
>> >> Hope this isn't too long a response and that it is helpful for you.
>> >>
>> >> Let's determine what an initial contribution would be for and bring a
>> >> proposal to the dev@ list and/or file a jira for the integration.
>> >> This would be great for adding features and growing the community - so
>> we
>> >> are all for it!
>> >>
>> >> thanks,
>> >>
>> >> --larry
>> >>
>> >>
>> >> On Thu, Nov 5, 2015 at 9:43 AM, Jérôme LELEU <le...@gmail.com> wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> I see that Shiro is already used for basic auth and LDAP
>> authentication
>> >>> and Picketlink for SAML. pac4j v1.8 can now handle both cases and even
>> >>> more. So I think we could create a gateway-provider-security-pac4j
>> >>> supporting all authentication mechanisms and not only OpenID.
>> >>>
>> >>> pac4j implementations generally work with two filters: one to protect
>> a
>> >>> resource and play direct authentication like basic auth (and check
>> >>> authorizations) and a callback filter to finish remote authentication
>> like
>> >>> Facebook, SAML, OpenID. The easiest one is the j2e-pac4j with:
>> >>>
>> https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/RequiresAuthenticationFilter.java#L96
>> >>> and
>> >>>
>> https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/CallbackFilter.java#L65
>> >>>
>> >>> That said, I have already many pac4j implementations to handle so I'm
>> >>> pushing communities to maintain on their own their pac4j
>> implementations:
>> >>> can we imagine having an official: gateway-provider-security-pac4j
>> module
>> >>> maintained by the Knox community with my help of course? This is the
>> kind
>> >>> of message I deliver to communities when a new version of pac4j is
>> >>> available so that they can upgrade:
>> >>> https://github.com/ratpack/ratpack/issues/819
>> >>>
>> >>> I read:
>> https://knox.apache.org/books/knox-0-6-0/dev-guide.html#Providers,
>> >>> it might be easy for Knox contributors, but it's a bit hard for me to
>> get
>> >>> in everything: can you or someone in the Knox community provides me an
>> >>> empty gateway-provider-security-pac4j module and the default
>> expectations
>> >>> from a Knox point of view?
>> >>> My main questions:
>> >>> 1) What do I do with the authenticated user: where / how do I fill
>> this
>> >>> identity in Knox?
>> >>> 2) How to handle errors: not authenticated, not authorized?
>> >>> 3) How to handle redirections to an external provider?
>> >>> 4) Should the pac4j filter also handle authorizations (pac4j can do
>> that)?
>> >>> 5) How to test?
>> >>>
>> >>> Thanks.
>> >>> Best regards,
>> >>> Jérôme
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> 2015-11-03 16:58 GMT+01:00 larry mccay:
>> >>>
>> >>>> Hi Jérôme -
>> >>>>
>> >>>> We were evaluating buji-pac4j for SSO with SAML and ended up going
>> with
>> >>>> Picketlink at the time.
>> >>>> That said, we do have a pluggable architecture that would allow for a
>> >>>> pac4j provider as well.
>> >>>>
>> >>>> If you are interested in contributing such a provider that would
>> >>>> certainly be welcome.
>> >>>> There is someone in the community working on an openid provider but
>> >>>> perhaps pac4j would be the way to go there?
>> >>>>
>> >>>> thanks,
>> >>>>
>> >>>> --larry
>> >>>>
>> >>>>
>>
>
>
Re: pac4j and Apache Knox
Posted by Jérôme LELEU <le...@gmail.com>.
Hi,
Perfect timing ;-) I have started implemented the pac4j support in Knox,
it's a very basic attempt: https://github.com/apache/knox/pull/2/files
This implementation reuses the pac4j implementation for J2E. I have a
ProviderDeploymentContributorBase which registers two filters:
- the first one is a dispatcher filter which uses the j2e-pac4j
CallbackFilter on the /callabck url (it finishes the authentication process
after a successful authentication at some identity provider) and uses the
j2e-pac4j RequiresAuthenticationFilter otherwise (redirection to the
identity provider to start the authentication when the user is not
authenticated)
- the second one is an identity adapter which gets the current
authenticated user from the pac4j point of view and populates the J2E
security context.
* I have the following error:
2015-11-10 16:30:22,347 ERROR hadoop.gateway
(GatewayFilter.java:doFilter(135)) - Gateway processing failed:
javax.servlet.ServletException: javax.servlet.ServletException:
Authentication type must be specified: simple|kerberos|<class>
javax.servlet.ServletException: javax.servlet.ServletException:
Authentication type must be specified: simple|kerberos|<class>
at
org.apache.hadoop.gateway.GatewayFilter$Holder.getInstance(GatewayFilter.java:354)
Notice I have changed the sandbox.xml file to use pac4j instead of Shiro,
maybe it's not the right way:
https://github.com/apache/knox/pull/2/files#diff-128ca80baa2dfd6c2d25de7b8160b9d9R24
Any idea of the problem?
* Am I understanding webflows correctly?
I use the default request to: curl -ivk "
https://localhost:8443/gateway/sandbox/webhdfs/v1/tmp?op=LISTSTATUS"
It looks like a REST request, though I'm expecting the following webflow:
redirection of the user to the identity provider, successful login,
redirection back to the /callback url of the gateway: do I get it right?
* The callback url
I currently do a check expecting the last part of the url to end with
/callback, but does the gateway will receive requests on this url? Do I
have to do something special?
It's highly recommended to only have one callback url as this url is
defined on the identity provider side.
* How to pass configuration?
Currently, I hardcoded a FacebookClient for Facebook authentication, but we
should be able to pass the appropriate client like Facebook or SAML.
Basically, we could do that using filter properties: facebook.key +
facebook.secret means we use Facebook authentication with the appropriate
key and secret for example. Any recommendation?
* Can I use the J2E session to store the requested protected url and other
information?
Or do I need to do something special?
Thanks.
Best regards,
Jérôme
2015-11-10 17:03 GMT+01:00 Kevin Minder <ke...@hortonworks.com>:
> Hi Jerome,
> This sounds very exciting and is just the sort of thing the open
> architecture of Knox is intended to allow. Larry and I have looked at
> pac4j a number of times thinking that it would be a good fit and would
> provide a great feature set to the Hadoop community.
> Kevin.
>
>
>
> On 11/6/15, 3:31 AM, "Jérôme LELEU" <le...@gmail.com> wrote:
>
> >Hi,
> >
> >Let's open this private discussion on the Knox dev mailing list.
> >
> >I'm Jerome Leleu and the creator of pac4j (https://github.com/pac4j/pac4j
> ),
> >a security engine for Java with many implementations for J2E, Play,
> Spring,
> >Vertx, Ratpack... The idea is to offer something as powerful as Spring
> >Security, but a lot easier and for all Java frameworks / tools and all
> >authentication mechanisms.
> >
> >Two years ago, we had a discussion with Larry on how pac4j could be used
> in
> >Knox.
> >
> >Meanwhile, both projects have grown up and I'm back to try to see if pac4j
> >can help Knox in terms of security.
> >
> >-----
> >
> >In its latest version, pac4j can be used to build a full security library,
> >not only focused on delegated authentication (Facebook, SAML). So we have
> >the concepts of direct clients (a client is an authentication mechanism):
> >basic auth, header, token... and indirect clients: SAML, Facebook, OpenID,
> >CAS...
> >It seems to be very close to the Authentication and Federation Providers
> >concepts from Knox.
> >
> >The provided article is great and as it's focused on authentication with a
> >real example, it's easier to start with it.
> >
> >Thanks for your answers.
> >
> >Like Shiro, pac4j has LDAP support and caching can be done. The only
> >difference is that pac4j relies on ldaptive (http://www.ldaptive.org/).
> But
> >I think you're right: it would be better to start by implementing the
> >Federation part which might be the most expected feature for Knox users (a
> >bit like buji-pac4j: https://github.com/bujiio/buji-pac4j is for Shiro)
> and
> >see if it's worth the work to have an authentication provider with pac4j
> in
> >addition to the one of Shiro.
> >
> >I plan to start working on that next week. Do you accept pull requests on
> >Github (it would make discussion easier on source code)?
> >
> >Any feedback will be appreciated.
> >
> >Thanks.
> >Best regards,
> >Jérôme
> >
> >
> >
> >
> >
> >
> >2015-11-05 17:13 GMT+01:00 larry mccay:
> >
> >> Hi Jérôme -
> >>
> >> Contributions coming from the community are owned and maintained by the
> >> entire community.
> >> You would certainly not be expected to do all work on it and at the same
> >> time any assistance and upgrade messages that you provided would be
> awesome.
> >>
> >> As for an empty module for pac4j, maybe the following example project
> >> would be helpful to you:
> >>
> >> https://github.com/lmccay/gateway-provider-security-pseudo
> >>
> >> It is in support of an article to illustrate how to go about adding a
> >> authentication or federation provider - as you would be doing:
> >>
> >>
> https://github.com/lmccay/gateway-provider-security-pseudo/blob/master/AddingFederationProvider.md
> >>
> >> That may be easier to consume than the entire developers guide.
> >> That said, it would be great if you could describe what makes the dev
> >> guide too much - if that is the case.
> >>
> >> I'll take a stab at your questions here but we should move more detailed
> >> discussions on the topic to the dev@ list in order to keep this in the
> >> open and provide insights to others:
> >>
> >> 1) What do I do with the authenticated user: where / how do I fill this
> >> identity in Knox?
> >>
> >> We normalize the authentication event into a Java subject to represent
> the
> >> user, groups and impersonated user as appropriate.
> >> In cases - like shiro - where we don't have access to the actual
> >> authenticating code and we need to normalize the provider specific
> security
> >> context, we add another filter. You can look at the shiro provider for
> an
> >> example. The code inside the simple example provider in the article also
> >> shows what is expected at least in terms of the PrimaryPrincipal.
> >>
> >> 2) How to handle errors: not authenticated, not authorized?
> >>
> >> We aren't intrusive on what should be done by a provider here.
> >> Generally, authentication failures result in a 401 and authorizations
> in a
> >> 403 and they are usually sent by the provider.
> >>
> >> 3) How to handle redirections to an external provider?
> >>
> >> Redirects are sent by the providers themselves with a 307 or 302.
> >> You can look at the SSOCookieFederationFilter in the jwt module as an
> >> example if you like.
> >>
> >> 4) Should the pac4j filter also handle authorizations (pac4j can do
> that)?
> >>
> >> This is an interesting question.
> >> Knox provides a separate slot in the provider chain for authorization.
> >> It is there because of the ability for identity assertion providers to
> map
> >> principals in order to impersonate another user or map external
> usernames
> >> to those used inside of hadoop clusters. So, the authorization decisions
> >> are made based on those identities.
> >>
> >> If we can add the authorization filter as an authorization provider
> rather
> >> than part of the authentication provider than that might make sense.
> >> Although, the security context is normalized as Knox expects not as
> pac4j
> >> authorization probably does. Now, if there is real value in doing so,
> the
> >> pac4j Subject adaptor could stuff additional context into the Subject or
> >> the request that can be accessed later by the pac4j authorization
> provider.
> >>
> >> So, it can be done - the question is whether there is compelling reason
> to
> >> do so.
> >>
> >> 5) How to test?
> >>
> >> This can be challenging especially for external authentications and web
> >> app flows.
> >> Generally, unit testing as much as possible is required.
> >> We would want to make sure that the security context normalization
> happens
> >> as expected, etc.
> >>
> >> Additional considerations:
> >>
> >> 1. Our Shiro provider does group lookup and caching of the
> authentication
> >> event for optimizing interactions with authentication servers, LDAP, AD,
> >> etc. We wouldn't want to lose these. Doing so would be a non-starter for
> >> most folks replacing what Shiro is used for today.
> >> 2. It is probably best to concentrate on the gaps that pac4j can fill
> for
> >> openid, oauth, etc for the initial contribution and if the usecases
> handled
> >> by Shiro can be done better, easier, simpler then we can consider a
> >> migration path.
> >>
> >> BTW - we have a couple very interesting possibilities for strong and
> >> multi-factor authentication that would be enabled by OpenID immediately.
> >>
> >> Hope this isn't too long a response and that it is helpful for you.
> >>
> >> Let's determine what an initial contribution would be for and bring a
> >> proposal to the dev@ list and/or file a jira for the integration.
> >> This would be great for adding features and growing the community - so
> we
> >> are all for it!
> >>
> >> thanks,
> >>
> >> --larry
> >>
> >>
> >> On Thu, Nov 5, 2015 at 9:43 AM, Jérôme LELEU <le...@gmail.com> wrote:
> >>
> >>> Hi,
> >>>
> >>> I see that Shiro is already used for basic auth and LDAP authentication
> >>> and Picketlink for SAML. pac4j v1.8 can now handle both cases and even
> >>> more. So I think we could create a gateway-provider-security-pac4j
> >>> supporting all authentication mechanisms and not only OpenID.
> >>>
> >>> pac4j implementations generally work with two filters: one to protect a
> >>> resource and play direct authentication like basic auth (and check
> >>> authorizations) and a callback filter to finish remote authentication
> like
> >>> Facebook, SAML, OpenID. The easiest one is the j2e-pac4j with:
> >>>
> https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/RequiresAuthenticationFilter.java#L96
> >>> and
> >>>
> https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/CallbackFilter.java#L65
> >>>
> >>> That said, I have already many pac4j implementations to handle so I'm
> >>> pushing communities to maintain on their own their pac4j
> implementations:
> >>> can we imagine having an official: gateway-provider-security-pac4j
> module
> >>> maintained by the Knox community with my help of course? This is the
> kind
> >>> of message I deliver to communities when a new version of pac4j is
> >>> available so that they can upgrade:
> >>> https://github.com/ratpack/ratpack/issues/819
> >>>
> >>> I read:
> https://knox.apache.org/books/knox-0-6-0/dev-guide.html#Providers,
> >>> it might be easy for Knox contributors, but it's a bit hard for me to
> get
> >>> in everything: can you or someone in the Knox community provides me an
> >>> empty gateway-provider-security-pac4j module and the default
> expectations
> >>> from a Knox point of view?
> >>> My main questions:
> >>> 1) What do I do with the authenticated user: where / how do I fill this
> >>> identity in Knox?
> >>> 2) How to handle errors: not authenticated, not authorized?
> >>> 3) How to handle redirections to an external provider?
> >>> 4) Should the pac4j filter also handle authorizations (pac4j can do
> that)?
> >>> 5) How to test?
> >>>
> >>> Thanks.
> >>> Best regards,
> >>> Jérôme
> >>>
> >>>
> >>>
> >>>
> >>> 2015-11-03 16:58 GMT+01:00 larry mccay:
> >>>
> >>>> Hi Jérôme -
> >>>>
> >>>> We were evaluating buji-pac4j for SSO with SAML and ended up going
> with
> >>>> Picketlink at the time.
> >>>> That said, we do have a pluggable architecture that would allow for a
> >>>> pac4j provider as well.
> >>>>
> >>>> If you are interested in contributing such a provider that would
> >>>> certainly be welcome.
> >>>> There is someone in the community working on an openid provider but
> >>>> perhaps pac4j would be the way to go there?
> >>>>
> >>>> thanks,
> >>>>
> >>>> --larry
> >>>>
> >>>>
>
Re: pac4j and Apache Knox
Posted by Kevin Minder <ke...@hortonworks.com>.
Hi Jerome,
This sounds very exciting and is just the sort of thing the open architecture of Knox is intended to allow. Larry and I have looked at pac4j a number of times thinking that it would be a good fit and would provide a great feature set to the Hadoop community.
Kevin.
On 11/6/15, 3:31 AM, "Jérôme LELEU" <le...@gmail.com> wrote:
>Hi,
>
>Let's open this private discussion on the Knox dev mailing list.
>
>I'm Jerome Leleu and the creator of pac4j (https://github.com/pac4j/pac4j),
>a security engine for Java with many implementations for J2E, Play, Spring,
>Vertx, Ratpack... The idea is to offer something as powerful as Spring
>Security, but a lot easier and for all Java frameworks / tools and all
>authentication mechanisms.
>
>Two years ago, we had a discussion with Larry on how pac4j could be used in
>Knox.
>
>Meanwhile, both projects have grown up and I'm back to try to see if pac4j
>can help Knox in terms of security.
>
>-----
>
>In its latest version, pac4j can be used to build a full security library,
>not only focused on delegated authentication (Facebook, SAML). So we have
>the concepts of direct clients (a client is an authentication mechanism):
>basic auth, header, token... and indirect clients: SAML, Facebook, OpenID,
>CAS...
>It seems to be very close to the Authentication and Federation Providers
>concepts from Knox.
>
>The provided article is great and as it's focused on authentication with a
>real example, it's easier to start with it.
>
>Thanks for your answers.
>
>Like Shiro, pac4j has LDAP support and caching can be done. The only
>difference is that pac4j relies on ldaptive (http://www.ldaptive.org/). But
>I think you're right: it would be better to start by implementing the
>Federation part which might be the most expected feature for Knox users (a
>bit like buji-pac4j: https://github.com/bujiio/buji-pac4j is for Shiro) and
>see if it's worth the work to have an authentication provider with pac4j in
>addition to the one of Shiro.
>
>I plan to start working on that next week. Do you accept pull requests on
>Github (it would make discussion easier on source code)?
>
>Any feedback will be appreciated.
>
>Thanks.
>Best regards,
>Jérôme
>
>
>
>
>
>
>2015-11-05 17:13 GMT+01:00 larry mccay:
>
>> Hi Jérôme -
>>
>> Contributions coming from the community are owned and maintained by the
>> entire community.
>> You would certainly not be expected to do all work on it and at the same
>> time any assistance and upgrade messages that you provided would be awesome.
>>
>> As for an empty module for pac4j, maybe the following example project
>> would be helpful to you:
>>
>> https://github.com/lmccay/gateway-provider-security-pseudo
>>
>> It is in support of an article to illustrate how to go about adding a
>> authentication or federation provider - as you would be doing:
>>
>> https://github.com/lmccay/gateway-provider-security-pseudo/blob/master/AddingFederationProvider.md
>>
>> That may be easier to consume than the entire developers guide.
>> That said, it would be great if you could describe what makes the dev
>> guide too much - if that is the case.
>>
>> I'll take a stab at your questions here but we should move more detailed
>> discussions on the topic to the dev@ list in order to keep this in the
>> open and provide insights to others:
>>
>> 1) What do I do with the authenticated user: where / how do I fill this
>> identity in Knox?
>>
>> We normalize the authentication event into a Java subject to represent the
>> user, groups and impersonated user as appropriate.
>> In cases - like shiro - where we don't have access to the actual
>> authenticating code and we need to normalize the provider specific security
>> context, we add another filter. You can look at the shiro provider for an
>> example. The code inside the simple example provider in the article also
>> shows what is expected at least in terms of the PrimaryPrincipal.
>>
>> 2) How to handle errors: not authenticated, not authorized?
>>
>> We aren't intrusive on what should be done by a provider here.
>> Generally, authentication failures result in a 401 and authorizations in a
>> 403 and they are usually sent by the provider.
>>
>> 3) How to handle redirections to an external provider?
>>
>> Redirects are sent by the providers themselves with a 307 or 302.
>> You can look at the SSOCookieFederationFilter in the jwt module as an
>> example if you like.
>>
>> 4) Should the pac4j filter also handle authorizations (pac4j can do that)?
>>
>> This is an interesting question.
>> Knox provides a separate slot in the provider chain for authorization.
>> It is there because of the ability for identity assertion providers to map
>> principals in order to impersonate another user or map external usernames
>> to those used inside of hadoop clusters. So, the authorization decisions
>> are made based on those identities.
>>
>> If we can add the authorization filter as an authorization provider rather
>> than part of the authentication provider than that might make sense.
>> Although, the security context is normalized as Knox expects not as pac4j
>> authorization probably does. Now, if there is real value in doing so, the
>> pac4j Subject adaptor could stuff additional context into the Subject or
>> the request that can be accessed later by the pac4j authorization provider.
>>
>> So, it can be done - the question is whether there is compelling reason to
>> do so.
>>
>> 5) How to test?
>>
>> This can be challenging especially for external authentications and web
>> app flows.
>> Generally, unit testing as much as possible is required.
>> We would want to make sure that the security context normalization happens
>> as expected, etc.
>>
>> Additional considerations:
>>
>> 1. Our Shiro provider does group lookup and caching of the authentication
>> event for optimizing interactions with authentication servers, LDAP, AD,
>> etc. We wouldn't want to lose these. Doing so would be a non-starter for
>> most folks replacing what Shiro is used for today.
>> 2. It is probably best to concentrate on the gaps that pac4j can fill for
>> openid, oauth, etc for the initial contribution and if the usecases handled
>> by Shiro can be done better, easier, simpler then we can consider a
>> migration path.
>>
>> BTW - we have a couple very interesting possibilities for strong and
>> multi-factor authentication that would be enabled by OpenID immediately.
>>
>> Hope this isn't too long a response and that it is helpful for you.
>>
>> Let's determine what an initial contribution would be for and bring a
>> proposal to the dev@ list and/or file a jira for the integration.
>> This would be great for adding features and growing the community - so we
>> are all for it!
>>
>> thanks,
>>
>> --larry
>>
>>
>> On Thu, Nov 5, 2015 at 9:43 AM, Jérôme LELEU <le...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I see that Shiro is already used for basic auth and LDAP authentication
>>> and Picketlink for SAML. pac4j v1.8 can now handle both cases and even
>>> more. So I think we could create a gateway-provider-security-pac4j
>>> supporting all authentication mechanisms and not only OpenID.
>>>
>>> pac4j implementations generally work with two filters: one to protect a
>>> resource and play direct authentication like basic auth (and check
>>> authorizations) and a callback filter to finish remote authentication like
>>> Facebook, SAML, OpenID. The easiest one is the j2e-pac4j with:
>>> https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/RequiresAuthenticationFilter.java#L96
>>> and
>>> https://github.com/pac4j/j2e-pac4j/blob/master/src/main/java/org/pac4j/j2e/filter/CallbackFilter.java#L65
>>>
>>> That said, I have already many pac4j implementations to handle so I'm
>>> pushing communities to maintain on their own their pac4j implementations:
>>> can we imagine having an official: gateway-provider-security-pac4j module
>>> maintained by the Knox community with my help of course? This is the kind
>>> of message I deliver to communities when a new version of pac4j is
>>> available so that they can upgrade:
>>> https://github.com/ratpack/ratpack/issues/819
>>>
>>> I read: https://knox.apache.org/books/knox-0-6-0/dev-guide.html#Providers,
>>> it might be easy for Knox contributors, but it's a bit hard for me to get
>>> in everything: can you or someone in the Knox community provides me an
>>> empty gateway-provider-security-pac4j module and the default expectations
>>> from a Knox point of view?
>>> My main questions:
>>> 1) What do I do with the authenticated user: where / how do I fill this
>>> identity in Knox?
>>> 2) How to handle errors: not authenticated, not authorized?
>>> 3) How to handle redirections to an external provider?
>>> 4) Should the pac4j filter also handle authorizations (pac4j can do that)?
>>> 5) How to test?
>>>
>>> Thanks.
>>> Best regards,
>>> Jérôme
>>>
>>>
>>>
>>>
>>> 2015-11-03 16:58 GMT+01:00 larry mccay:
>>>
>>>> Hi Jérôme -
>>>>
>>>> We were evaluating buji-pac4j for SSO with SAML and ended up going with
>>>> Picketlink at the time.
>>>> That said, we do have a pluggable architecture that would allow for a
>>>> pac4j provider as well.
>>>>
>>>> If you are interested in contributing such a provider that would
>>>> certainly be welcome.
>>>> There is someone in the community working on an openid provider but
>>>> perhaps pac4j would be the way to go there?
>>>>
>>>> thanks,
>>>>
>>>> --larry
>>>>
>>>>