[
https://issues.apache.org/jira/browse/ARTEMIS-2886?focusedWorklogId=478078&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-478078
]
ASF GitHub Bot logged work on ARTEMIS-2886:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 02/Sep/20 19:18
Start Date: 02/Sep/20 19:18
Worklog Time Spent: 10m
Work Description: luisalves00 commented on pull request #3246:
URL: https://github.com/apache/activemq-artemis/pull/3246#issuecomment-685944634
My use case is quite simple. I'll try to describe as best as I can, but
please note that not all is decided yet.
Clients (services) will connect to the broker using an access token
(https://auth0.com/docs/flows/client-credentials-flow) for a given realm
[domain] (Keycloak is the OpenID provider).
The token contains the identification of the service (ClientID) and their
roles (if needed). I want everything to be dynamic, so every authenticated
client can create addresses under a certain domain that include their clientID.
E.g I'm app-a then I can create (checkType.CREATE_ADDRESS) the address
"org.artemis.app-a.event". So on ActiveMQSecurityManager4 this was already in
place. Now I want to be able to control who subscribes to my address (their
might be some sensible data and I don't want all clients snooping arround).
Here is the part that I requested on the ticket of the FQQN. The flow will be
the same as the client that created the address but the operation will be
CheckType.CREATE_DURABLE_QUEUE (as it's subscribing) over the resource
"org.artemis.app-a.event::app-c". As you've might guessed the clientID is
"app-c" and on his access token it will have a role that allow it to subscribe.
Something like "org.artemis.app-a.event::app-c::subscribe". This was granted by
AppA on Keycloak. This last part is not yet defined as it's also possible to
use a Request Party Token (RPT), but in each case I need the CLIENTID (maps to
Subject), RESOURCE (maps to an FQQN), SCOPE (maps to the CheckType) and the
Permission (maps to RESOURCE::CHECK_TYPE) where I can apply policies to grant
or not access (reference:
https://www.keycloak.org/docs/latest/authorization_services/#_overview_terminology).
Does it make sense?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 478078)
Time Spent: 1h 20m (was: 1h 10m)
> 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: 1h 20m
> 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)
