[
https://issues.apache.org/jira/browse/ARTEMIS-3102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17281856#comment-17281856
]
Justin Bertram commented on ARTEMIS-3102:
-----------------------------------------
bq. Yet, I think sending the proper message code would be an improvement for
the current ActiveMQSecurityManager5 implementation, but with low priority.
That's fair.
> 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
> Priority: Major
>
> 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)
