[
https://issues.apache.org/jira/browse/ARTEMIS-3102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17281080#comment-17281080
]
Luís Alves commented on ARTEMIS-3102:
-------------------------------------
I agree with "there's no security issue". My scenario is the living proof of
it. If token is expired you cannot do any operation.
Client cannot deal with it as it doesn't know if the user is not authenticated
or not authorized. I can have permission to SEND to A but not to B. When client
send to A it works and when doing to B it should fail, but in both connection
should be kept (as not authorized <> not authenticated). But when client is not
even authenticated a connection should not even exist. It's what it happens on
the initial negotiation, i.e. if you don't provide the proper username and
password, the connection is refused and not granted a connection with zero
permission.
Following [~gtully] example using some LDAP, image that SubjectA connects with
his user/password and granted authorization to do all (to simplify). Then
SubjectA leaves the company for a better job and they simply disable SubjectA
user in LDAP, but SubjectA keeps a connection to the broker opened, so he still
can do everything and he is not even allow to create a new connection to the
broker. If they remove the permissions for all, then he cannot do anything but
can keep the connection opened when it should be closed as the "session" (in my
case the token expiry) should already be over.
> 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)
