[ https://issues.apache.org/jira/browse/ARTEMIS-3102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17279812#comment-17279812 ]
Justin Bertram commented on ARTEMIS-3102: ----------------------------------------- At this point I'm not convinced that the connection should be forcibly closed. The {{null}} subject will never be authorized to do _anything_ so there's no security issue, and as t[his comment on ARTEMIS-2886|https://issues.apache.org/jira/browse/ARTEMIS-2886?focusedCommentId=17279712&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17279712] indicates the proper {{javax.jms.JMSSecurityException}} is thrown on the client. It seems reasonable for the client to deal with this exception and reconnect if necessary. > 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)