5:53 a.m.
Hi!
At the moment KeycloakDeployment is accessible from
RefreshableKeycloakSecurityContext, but now from its superclass
KeycloakSecurityContext. Is there a reason why the deployment cannot be
accessed through the base class?
When using KeycloakConfigResolver it would simplify things if one could
access the deployment context from the security context.
Best regards,
Thomas
3:11 a.m.
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 think you can just cast KeycloakSecurityContext to
RefreshableKeycloakSecurityContext and get KeycloakDeployment from there?
Marek
On 04/01/16 12:53, Thomas Raehalme wrote:
Hi!
At the moment KeycloakDeployment is accessible from
RefreshableKeycloakSecurityContext, but now from its superclass
KeycloakSecurityContext. Is there a reason why the deployment cannot
be accessed through the base class?
When using KeycloakConfigResolver it would simplify things if one
could access the deployment context from the security context.
Best regards,
Thomas
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3:51 a.m.
On Wed, Jan 6, 2016 at 11:11 AM, Marek Posolda <mposolda(a)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
8:48 a.m.
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(a)smartling.com
<https://app.sigstr.com/uc/55e5d41c6533390d03580000>
<http://www.sigstr.com/>
On Jan 6, 2016, at 4:51 AM, Thomas Raehalme
<thomas.raehalme(a)aitiofinland.com> wrote:
On Wed, Jan 6, 2016 at 11:11 AM, Marek Posolda <mposolda(a)redhat.com
<mailto: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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
9:17 a.m.
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(a)smartling.com <mailto:srossillo@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(a)aitiofinland.com
> <mailto:thomas.raehalme@aitiofinland.com>> wrote:
>
> On Wed, Jan 6, 2016 at 11:11 AM, Marek Posolda <mposolda(a)redhat.com
> <mailto: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(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3030
days inactive
3032
days old
4 comments
4 participants
participants (4)
-
Bill Burke -
Marek Posolda -
Scott Rossillo -
Thomas Raehalme