[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978577#comment-16978577
]
Angela Schreiber commented on OAK-8710:
---------------------------------------
[~baedke], while i am working on a fix for the clear-state issue mentioned
above, i would very much appreciate if you could provide a test case with a
realistic oak authentication setup as it is present in the repository you took
the attached screen shot (including a list of login modules associated with the
given setup (you can replace that with a place-holder name in case you don't
want to share adobe internal information and send me the corresponding info in
the adobe-internal communication channel). the test should include the
login/commit/logout that results in the scenario you took the screen-shot from.
in particular i am wondering about the {{ImpersonationCredentials}} and the
fact that the impersonated user has the name of a system-user used for Adobe
AEM social... one reason why I am asking about this is the following:
service-user login with adobe AEM is _not_ done with impersonation and does
neither use {{SimpleCredentials}}... so i am really not sure how you got there.
additional reasoning behind this: i want to make sure we actually have a
reproducible integration test for the issue you are describing, that we can
verify that we actually fix the issue if we commit any modifications and don't
introduce regressions (as we would with the patch attached to OAK-8763).
> AbstractLoginModule#logout() must not remove 'foreign' principals/credentials
> ------------------------------------------------------------------------------
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external, core, security-spi
> Reporter: Manfred Baedke
> Assignee: Angela Schreiber
> Priority: Major
> Attachments: OAK-8710.patch, logout.png
>
>
> See
> https://github.com/apache/jackrabbit-oak/blob/9569d659f0655d3ba16c1cfe1fbb5f53959f701f/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/AbstractLoginModule.java#L189:
> The criterion for logout() to succeed is
> {code}!subject.getPrincipals().isEmpty() &&
> !subject.getPublicCredentials(Credentials.class).isEmpty(){code}
> This did not work in a case where the subject was created by a thread
> handling an authenticated JMX connection (and later passed on to other
> threads due to AccessControlContext inheritage).
> I'd propose to make logout() succeed unconditionally, but I'm not entirely
> sure about side effects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)