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 <[email protected]> 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 <[email protected]>: > > > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>: > >>> > >>> > 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 <[email protected] > > > >>> > 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 <[email protected]> > >>> wrote: > >>> > > > >>> > >> Should we add a link in the documentation to point to the demo? > >>> > >> > >>> > >> 2016-01-19 14:19 GMT+01:00 larry mccay <[email protected]>: > >>> > >> > >>> > >> > That's great! > >>> > >> > > >>> > >> > On Tue, Jan 19, 2016 at 7:53 AM, Jérôme LELEU <[email protected] > > > >>> > 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 <[email protected]>: > >>> > >> > > > >>> > >> > > > 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 <[email protected]>: > >>> > >> > > > > >>> > >> > > >> 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. > >>> > >> > > >> > >>> > >> > > > > >>> > >> > > > >>> > >> > > >>> > >> > >>> > > > >>> > > > >>> > > >>> > >> > >> > > >
