[
https://issues.apache.org/jira/browse/ARTEMIS-2886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17279637#comment-17279637
]
Gary Tully commented on ARTEMIS-2886:
-------------------------------------
Where is the loop here, does a client in a loop doing send get a security
exception as a response, but the connection stays valid?
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.
Do you have any tests that can demonstrate the current problem?
> Optimize security auth
> ----------------------
>
> Key: ARTEMIS-2886
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2886
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Reporter: Justin Bertram
> Assignee: Justin Bertram
> Priority: Major
> Fix For: 2.16.0
>
> Time Spent: 6h 10m
> Remaining Estimate: 0h
>
> Both authentication and authorization will hit the underlying security
> repository (e.g. files, LDAP, etc.). For example, creating a JMS connection
> and a consumer will result in 2 hits with the *same* authentication request.
> This can cause unwanted (and unnecessary) resource utilization, especially in
> the case of networked configuration like LDAP.
> There is a rudimentary cache for authorization, but it is cleared *totally*
> every 10 seconds by default (controlled via the
> {{security-invalidation-interval setting}}), and it must be populated
> initially which still results in duplicate auth requests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
