Retrieve current user token in custom services about alfresco-keycloak HOT 5 OPEN

So the beans of the classes listed only exist within the Keycloak authentication subsystem, which is a child application context of the regular Alfresco Spring context. This is why you cannot inject them (directly) for beans in your extension, since extensions "typically" have their beans in the regular Alfresco Spring context.

The acosix-keycloak-ticketTokenCache bean is a global cache of authentication tickets to JWT tokens that can technically be injected. Though it is meant as an internal implementation bean, it exists in the global context just like all Alfresco caches do. You could use the TicketComponent bean of Alfresco to retrieve the ticket for the current user and use that as the lookup key for the cache.

The AccessTokenService is a publicly exposed service bean that you can inject and use to obtain access tokens for the Alfresco client, a user, and exchange tokens for tokens to specific clients (using Keycloaks access delegation feature).

And just by writing this I realise where there is a gap in use case coverage: It should be possible via the AccessTokenService to obtain the access token for the current user (without manually using the cache, which is a workaround you can use for the time being), since one may want to exchange that token for a token to an external system to delegate a request in the name of the logged in user.

What is your specific use case of wanting to access the JWT token? Ideally an authentication subsystem should handle anything specific to it internally and only expose as little as possible to avoid module implementations creating hard dependencies on it. The AccessTokenService is one way of providing this separation while still allowing some functionality to be exposed. If there are other use cases that should legitimately have access to the JWT details outside of ths subsystem, I would want to support them in a similar manner.

from alfresco-keycloak.

To answer your question, my use case is the following: I have a cloud microservice protected via Keycloak Auth which I need to call from the service I'm currently developing in my Alfresco instance. To actually use this microservice, the best way to do that would be retrieving the JWT token from the currently logged user and using it as a Bearer to authenticate him with my cloud microservice. I don't think I need to generate another token for the same user since I already have one associated with the Alfresco ticket.

It seems the first method you described (using the ticketTokenCache and the TicketComponent) might be the best way to solve my problem. I will try that and let you know if it worked.

from alfresco-keycloak.

While you can potentially use the JWT token used for authenticating a user in Alfresco to call another service, in a clean / secure Keycloak setup, this would/should not be possible, as each token is issued for a very specific application, and apps should validate / verify that tokens have been issued for them instead of blindly accepting any token. From my experience though, most Keycloak / OAuth setups are rarely clean or secure in that regard.
Thanks for confirming that the use case is essentially what I realised was missing earlier, even without wanting to exchange the token.

from alfresco-keycloak.

I managed to get the token with these lines:

String currentUserName = authenticationComponent.getCurrentUserName();
String currentTicket = ticketComponent.getCurrentTicket(currentUserName, true);
RefreshableAccessTokenHolder token = keycloakTicketTokenCache.get(currentTicket);

The boolean parameter for the getCurrentTicket method is an autoCreate boolean. If I set it to false, it always returns me null, but if I set it to true, it returns a ticket and it is actually the one stored in the cache, just like if it didn't create a new one at all. Do you know why it behaves like this?

from alfresco-keycloak.

This is a kink of the implementation by Alfresco - if the ticket has not yet been retrieved / validated / created within the current request, it is not stored in a static ThreadLocal which is checked first, and the cache is only checked on a last-ditch before creating a new ticket. See https://github.com/Alfresco/alfresco-community-repo/blob/ef441fc2c80fea43e70bbfa7171448729c8cb6cb/data-model/src/main/java/org/alfresco/repo/security/authentication/InMemoryTicketComponentImpl.java#L710

from alfresco-keycloak.