[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969340#comment-16969340
]
Angela Schreiber commented on OAK-8710:
---
[~baedke], so, i will adjust the subject and components accordingly
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Assignee: Angela Schreiber
>Priority: Major
> Attachments: 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)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969307#comment-16969307
]
Manfred Baedke commented on OAK-8710:
-
[~angela],
Yes, of course that's a new issue.
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Assignee: Angela Schreiber
>Priority: Major
> Attachments: 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)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969292#comment-16969292
]
Angela Schreiber commented on OAK-8710:
---
[~baedke], but that would be quite a different issue, wouldn't it? let's make
this issue about the logout only and not mix different issues after all we
already had OAK-8404, which turned out to not properly reflect the customer
reported issue.
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Assignee: Angela Schreiber
>Priority: Major
> Attachments: 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)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969283#comment-16969283
]
Manfred Baedke commented on OAK-8710:
-
[~angela],
bq. ok. i guess what is really important for the issue at hand is that only
principals/credentials that have been set by the commit of this login module
get removed upon logout (or destroyed in case the subject is readonly
Not quite. I'll attach a debugger screenshot where you can see that the
inherited subject is readonly and there is only one principal. Maybe
LoginContextProviderImpl#getSubject() is the real problem, because in this case
it does not return a pre-authenticated subject created by Oak, but instead the
subject from the inherited AccessControlContext.
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Assignee: Angela Schreiber
>Priority: Major
> Attachments: 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)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16968476#comment-16968476
]
Angela Schreiber commented on OAK-8710:
---
[~baedke], ok. i guess what is really important for the issue at hand is that
only principals/credentials that have been set by the commit of this login
module get removed upon logout (or destroyed in case the subject is readonly).
will ping you to review the patch (and tests) to make sure we have the same
reading of the contract and to make sure the original issue reported with jmx
gets actually solved.
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Assignee: Angela Schreiber
>Priority: Major
>
> 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)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16968404#comment-16968404
]
Manfred Baedke commented on OAK-8710:
-
[~angela],
Re tests: I was trying to keep in line with other tests in the same test class
(like testLogoutSuccessClearsSubject()), which test single aspects of the
contract only and also do not login. TestLoginModule#login() doesn't do
anything anyway. But yes, in view of that JAAS tech notes, that needs to be
reworked.
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Assignee: Angela Schreiber
>Priority: Major
>
> 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)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16967611#comment-16967611
]
Angela Schreiber commented on OAK-8710:
---
[~baedke], i will take a look how to be make use of the 2 methods and fix the
logout, without cause major compatibility issues with custom sub-classes that
are not under the oak umbrella.
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Assignee: Angela Schreiber
>Priority: Major
>
> 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)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16967605#comment-16967605
]
Angela Schreiber commented on OAK-8710:
---
[~baedke], the complete quote from
https://docs.oracle.com/javase/8/docs/technotes/guides/security/jaas/JAASLMDevGuide.html#logout
says:
{quote}
the logout method is called to log out a Subject.
This method removes Principals, and removes/destroys credentials associated
with the Subject during the commit operation. This method should not touch
those Principals or credentials previously existing in the Subject, or those
added by other LoginModules.
If the Subject has been marked read-only (the Subject's isReadOnly method
returns true), then this method should only destroy credentials associated with
the Subject during the commit operation (removing the credentials is not
possible). If the Subject has been marked as read-only and the credentials
associated with the Subject during the commit operation are not destroyable
(they do not implement the Destroyable interface), then this method may throw a
LoginException.
The logout method should return true if logout succeeds, or otherwise throw a
LoginException.
{quote}
my understanding of that is:
- if the login failed, commit must not update the subject and thus the logout
step must not succeed
- if the login succeeds and commit updats the subject, logout should remove
just those credentials/principals from the subject that have been added upon
commit and return true if that succeeds.
- in case the login/commit steps are missing the logout cannot succeed
- also we need to have a test that verifies that only those
principals/credentials of that particular loginmodule are removed and foreign
principals/credentials are left untouched.
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Priority: Major
>
> 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)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16967528#comment-16967528
]
Manfred Baedke commented on OAK-8710:
-
[~angela],
bq. Also, I still think the test case you provided above is not properly
reflecting the scenario you are describing.
Why?
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Priority: Major
>
> 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)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16967521#comment-16967521
]
Manfred Baedke commented on OAK-8710:
-
[~angela],
bq. has methods for getCredentials and getPrincipals, we already have the basic
functionality in place to actually know the credentials/principals that have
been used for the login/commit
That makes sense.
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Priority: Major
>
> 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)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16964675#comment-16964675
]
Angela Schreiber commented on OAK-8710:
---
[~baedke], I don't think this is correct. If you look at the principal
interfaces defined just with Oak you will notice that not all of them are
{{JackrabbitPrincipal}}. IMO this assumption is not accurate. However, given
your comment above and the given the fact that {{AbstractLoginModule}} actually
has methods for {{getCredentials}} and {{getPrincipals}}, we already have the
basic functionality in place to actually know the credentials/principals that
have been used for the login/commit. Having said that, I feel that the fix
needs a bit of a broader effort, as we probably don't want to re-calculate
either of them... I will think about a solution.
Also, I still think the test case you provided above is not properly reflecting
the scenario you are describing. So, I think there is some additional effort
needed on the testing side as well.
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Priority: Major
>
> 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)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16964365#comment-16964365
]
Manfred Baedke commented on OAK-8710:
-
I'd propose to ignore all principals that are not JackrabbitPrincipals and all
credentials that are not javax.jcr.Credentials.
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Priority: Major
>
> 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)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16963967#comment-16963967
]
Manfred Baedke commented on OAK-8710:
-
[~angela],
bq. the test case you provided seems odd to me as it doesn't include the login
step
Yes, because it doesn't test that. Like e.g. testLogoutSuccessClearsSubject(),
it's just about one single aspect of the logout behavior, namely that logout
ignores unknown principals.
Quote from
https://docs.oracle.com/javase/8/docs/technotes/guides/security/jaas/JAASLMDevGuide.html#logout:
"This method removes Principals, and removes/destroys credentials associated
with the Subject during the commit operation. This method should not touch
those Principals or credentials previously existing in the Subject".
I'll send you a link to the describing the scenario where the issue happened.
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Priority: Major
>
> 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)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16963722#comment-16963722
]
Angela Schreiber commented on OAK-8710:
---
[~baedke], i am not familiar with the circumstances you describe. what i wanted
to indicate was the test case you provided seems odd to me as it doesn't
include the login step. however, i would appreciate if you could provide
additional information that would help me understand what kind of login was
associated with the scenario you are describing.
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Priority: Major
>
> 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)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16963021#comment-16963021
]
Manfred Baedke commented on OAK-8710:
-
[~angela],
There is no login of an unknown principal. I don't think that the JAAS config
matters here much. The unknown principal comes from the fact that a newly
created thread gets an AccessControlContext which inherits the
AccessControlContext of the creating thread. This may, e.g., be a thread
handling an authenticated JMX connection, in which case it contains a subject
with a principal like "JMXPrincipal: xyz".
So this principal will make it's way into the AccessControlContext of a thread
handling a logout call. If you know a way to avoid that, please let me know.
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Priority: Major
>
> 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)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16961950#comment-16961950
]
Angela Schreiber commented on OAK-8710:
---
[~baedke], but why would {{LoginModule.logout()}} succeed if the {{login}} step
is missing altogether (as in your test) or didn't succeed? how is the JAAS
configuration in the scenario you are describing? does {{LoginModule.login}}
succeed? with any of the {{Configurations}} we ship with oak, login will fail
for an unknown set of principal/credentials. what am I missing?
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Priority: Major
>
> 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)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958906#comment-16958906
]
Manfred Baedke commented on OAK-8710:
-
Hi [~angela],
I'll try to come up with a test case. Not sure yet how that will go.
Please note
https://docs.oracle.com/javase/8/docs/technotes/guides/security/jaas/JAASLMDevGuide.html#logout,
which states a different logout contract.
But you're right, the JavaDoc should matter, so succeeding unconditionally is
not an option. Anyway, we don't implement that contract, too. Currently, the
criterion for success is the presence of any principal and the presence of
public credentials, which has nothing to do with the question if the Module
should be ignored (actually, in the case mentioned in the description, it
certainly should not, because it did the login).
Will we need to keep track of principals?
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Priority: Major
>
> 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)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16957989#comment-16957989
]
Angela Schreiber commented on OAK-8710:
---
[~baedke], i am not entirely sure that making logout() always succeed is
correct. the javadoc of {{LoginModule.logout}} states
{code}
Method which logs out a Subject.
An implementation of this method might remove/destroy a Subject's Principals
and Credentials.
Returns:
true if this method succeeded, or false if this LoginModule should be
ignored.
{code}
can you provide a test case that illustrates the behavior you are describing?
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Priority: Major
>
> 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)
