[keycloak-dev] Accessing KeycloakDeployment from KeycloakSecurityContext
Bill Burke
bburke at redhat.com
Wed Jan 6 10:17:34 EST 2016
A bearer token request does not have RefreshableKeycloakSecurityContext.
On 1/6/2016 9:48 AM, Scott Rossillo wrote:
> 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 at smartling.com <mailto:srossillo at smartling.com>
>
> Latest News + Events <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
> Powered by Sigstr <http://www.sigstr.com/>
>
>> On Jan 6, 2016, at 4:51 AM, Thomas Raehalme
>> <thomas.raehalme at aitiofinland.com
>> <mailto:thomas.raehalme at aitiofinland.com>> wrote:
>>
>> On Wed, Jan 6, 2016 at 11:11 AM, Marek Posolda <mposolda at redhat.com
>> <mailto:mposolda at 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 at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
More information about the keycloak-dev
mailing list