[
https://issues.apache.org/jira/browse/KNOX-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15116498#comment-15116498
]
Larry McCay commented on KNOX-655:
----------------------------------
Okay, I had to change the saml.serviceProviderEntityId to have the
pac4jCallback and to also escape the ampersand for the second parameter.
Otherwise, the SP Id doesn't match without the new param and with just an
ampersand the topology fails to deploy.
<param>
<name>saml.serviceProviderEntityId</name>
<value>https://www.local.com:8443/gateway/knoxsso/api/v1/websso?pac4jCallback=true&client_name=SAML2Client</value>
</param>
This will also need to be accounted for in the docs.
Otherwise, it appears to be working with an explicit Login with Okta and Login
with Twitter pair of links in an application.
Regarding the template topologies, it's great that you have provided them. If
you have no objections, I'd like to rename the pac4j-idp.xml to
pac4j-knoxsso.xml and the pac4j-sandbox.xml to knoxsso-sandbox.xml. For the
idp.xml, the default topology for this will be knoxsso and not idp as was the
original thinking. As for the sandbox.xml, this configuration really has more
to do with SSOCookieProvider and not tied to any particular
authentication/federation provider that is used in the knoxsso endpoint.
I will create a new patch to reflect these changes and attach for your review.
If all is fine with you then I will likely commit this tomorrow.
> Pac4j Provider Client Selection from client_name Query Parameter
> ----------------------------------------------------------------
>
> Key: KNOX-655
> URL: https://issues.apache.org/jira/browse/KNOX-655
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
> Reporter: Larry McCay
> Assignee: Jérôme Leleu
> Fix For: 0.8.0
>
> Attachments: knox655.patch
>
>
> From dev@ list:
> "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."
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
