We’re casting as well. I think the only time a KeycloakSecurityContext is not a RefreshableKeycloakSecurityContext is when you make a request from one client to another. I agree the codebase could really be improved here to avoid the constant casts. I’m thinking of sending a PR to improve this.


Scott Rossillo
Smartling | Senior Software Engineer
srossillo@smartling.com

Latest News + Events
Powered by Sigstr

On Jan 6, 2016, at 4:51 AM, Thomas Raehalme <thomas.raehalme@aitiofinland.com> wrote:

On Wed, Jan 6, 2016 at 11:11 AM, Marek Posolda <mposolda@redhat.com> wrote:
Not sure, I am like 50/50 . I agree it can simplify some scenarios when KeycloakDeployment is accessible from KeycloakSecurityContext. On the other hand, KeycloakDeployment exposes some info, which is not necessary to be exposed in client apps.

I haven't really studied the details of KeycloakDeployment, but was under the impression that it just holds the data from keycloak.json with the addition of some client related info obtained from Keycloak. Is there anything that needs to be hidden from the client especially if the client can still obtain the object through RefreshableKeycloakSecurityContext?

What I was interested in was the accountUrl and resourceName so that I can provide a link to users to change their password. 
 
I think you can just cast KeycloakSecurityContext to RefreshableKeycloakSecurityContext and get KeycloakDeployment from there?

That's what I'm doing now, but I think it's more of a hack than a real solution.

Best regards,
Thomas
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev