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 <[email protected]> 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 <[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. >>> > > >> >>> > > > >>> > > >>> > >>> >> >> >
