[
https://issues.apache.org/jira/browse/KNOX-641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15061992#comment-15061992
]
Larry McCay commented on KNOX-641:
----------------------------------
Hi [~jleleu] - you can certainly weigh in on the dev@ DISCUSS thread as well.
To me, it comes down to whether we could get our heads around testing it as a
new major feature in 0.7.0 without delaying that release.
For some of the authentication mechanisms, we need public facing applications -
IIUC.
What has been proposed is to release the features and bugs fixes that comprise
0.7.0 and shortly after identify those pac4j usecases and testing requirements
for a quick follow up release introducing the new capabilities.
Removing the identity provider session will absolutely work. I just want to
make sure that we understand what it will mean behavior-wise though:
* IdP is configured for some session lifetime and expectations are that
authentication will not be needed until it expires
* Where this authentication event is being federated by KnoxSSO however the IdP
session will be removed by the pac4j-provider
QUESTION: is this IdP session KnoxSSO/pac4j provider specific through the
KnoxSession of the provider or is it browser wide for the IdP itself?
* Since the IdP session is now removed, as soon as the KnoxSSO token/cookie
expires the user will need to be rechallenged.
UNLESS: there is an application level session that is based on their own cookie
that supersedes the KnoxSSO cookie use. This is the case in some integrations
like Ambari. They use the KnoxSSO cookie to establish an application level
session and that takes over until it expires. If, once it does expire, the
KnoxSSO cookie is still valid then they are not rechallenged and that cookie is
used again to create a new Ambari session.
I do want to double check that removing the pac4j session doesn't remove the
idp session for other applications that the browser may be using with a SSO
session with that idp. We don't want to log them out of other apps.
Comparing this to other implementations:
* Shibboleth/Keystone (SAML) through Picketlink - will continue to leverage the
shibboleth session until it expires therefore even though the KnoxSSO
token/cookie expires once redirected back to the IdP they are not presented
with a login page until that session expires.
* HTTP Basic Auth - not entirely sure this is the same thing or not but the
Basic credentials are cached by the browser so that the user isn't challenged
again with the browser Basic dialog.
There is an alternative to consider however, a test specific cookie could be
added when a user is authenticated with the testBasicAuth mechanism. We could
look for this cookie before accepting the previous session as valid against
whether testBasicAuth is currently enabled. If it is not, remove the idp
cookies and redirect back to KnoxSSO to reauthenticate. This would prevent a
testBasicAuth session from being valid when it is no longer actively configured.
I look forward to the new patch and drilling down into the specific usecases to
support for 0.8.0 and how to test them.
> Support CAS / OAuth / OpenID C / SAML protocols using pac4j
> -----------------------------------------------------------
>
> Key: KNOX-641
> URL: https://issues.apache.org/jira/browse/KNOX-641
> Project: Apache Knox
> Issue Type: New Feature
> Reporter: Jérôme Leleu
> Assignee: Jérôme Leleu
> Fix For: 0.7.0
>
> Attachments: KNOX-641.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
