Luís Alves created ARTEMIS-3102:
-----------------------------------
Summary: ActiveMQSecurityManager5 should disconnect user when his
authentication is not valid anymore
Key: ARTEMIS-3102
URL: https://issues.apache.org/jira/browse/ARTEMIS-3102
Project: ActiveMQ Artemis
Issue Type: Improvement
Components: Broker
Affects Versions: 2.16.0
Reporter: Luís Alves
On the following code block:
{code:java}
final Boolean validated;
if (securityManager instanceof ActiveMQSecurityManager5) {
Subject subject = getSubjectForAuthorization(session,
((ActiveMQSecurityManager5) securityManager));
validated = ((ActiveMQSecurityManager5)
securityManager).authorize(subject, roles, checkType, fqqn != null ?
fqqn.toString() : bareAddress.toString());
}
{code}
when the retrieved Subject is null (means the user cannot authenticate anymore)
the connection should be terminated. If not this will cause that the user is
not authorized to do the operation, but in fact he shouldn't not even be
allowed to connect.
Quoting [~gtully] on https://issues.apache.org/jira/browse/ARTEMIS-2886 where
he explains very well the problem:
{quote}I don't think your use case is unique to OpenID, the cached ldap jaas
login module can find that permissions have been removed from ldap at runtime
and that authorization has been removed. Once the cache expires and jaas is
again asked, it too will return a null subject i think and subsequent
operations will result in exceptions in the same way. I don't know how it will
behave if a user is no longer valid.
typically a security exception on initial connection, a failure to
authenticate, will cause the connection to be rejected, the connection to
close. But security exceptions are expected at runtime if you have access to
some resources and not others and are not aware of that. If permissions change
at runtime, some variation here is ok.
If however, a users is no longer able to authenticate (in your case, the token
has expired and cannot be renewed, then we need to drop the connection.
as a straw man design:
We may have to change the use of Subject in the code, a valid subject is non
null and has a valid artemis user principal. We need to check for the presence
of the user principal. That can indicate if the authentication is still valid.
If we can proceed with authorization checks.
At runtime, we may find that the non null subject becomes invalid b/c the
artemis principal is removed and that should cause any authorisation attempt to
fail and the connection to error out or be forcefully closed.
I think we need to do something like this.{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
