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.
>> > >> > > >>
>> > >> > > >
>> > >> > >
>> > >> >
>> > >>
>> > >
>> > >
>> >
>>
>
>
