[ 
https://issues.apache.org/jira/browse/ARTEMIS-2886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17279478#comment-17279478
 ] 

Luís Alves commented on ARTEMIS-2886:
-------------------------------------

I'm having a small issue with these blocks of code:

{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}

and

{code:java}
   /**
    * Get the cached Subject. If the Subject is not in the cache then 
authenticate again to retrieve it.
    *
    * @param auth contains the authentication data
    * @param securityManager used to authenticate the user if the Subject is 
not in the cache
    * @return the authenticated Subject with all associated role principals
    */
   private Subject getSubjectForAuthorization(SecurityAuth auth, 
ActiveMQSecurityManager5 securityManager) {
      Pair<Boolean, Subject> cached = 
authenticationCache.getIfPresent(createAuthenticationCacheKey(auth.getUsername(),
 auth.getPassword(), auth.getRemotingConnection()));
      /*
       * We don't need to worry about the cached boolean being false as users 
always have to
       * successfully authenticate before requesting authorization for anything.
       */
      if (cached == null) {
         return securityManager.authenticate(auth.getUsername(), 
auth.getPassword(), auth.getRemotingConnection(), auth.getSecurityDomain());
      }
      return cached.getB();
   }
{code}

As I said I'm doing authN with OpenID Connect, and the Subject is a token that 
eventually expires, so when the authenticate method is called it return null. 
This doesn't cause the connection to drop so a new token can be generated. 
Instead it just say the user is not authorized to do the operation and keeps 
looping that.
The protocol used for communication wasn't design to send new tokens when they 
expire, at least I couldn't figure out a way to do it. So after the connection 
is established I cannot send a fresh token. I've seen the interceptors, but I 
think we can only fiddle with the payload.
That said I think my tokens need to last more or even never expire. If they 
don't expire I loose the concept of session, so it's my last option. Is there a 
way to send some exception the cause the connection to be restarted? That way I 
can make my connection to last 1hour or even 1 day and after that the 
connection is trashed and on the new one I'll have a fresh token with the 
proper authorization.  
 

> 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)

Reply via email to