9:30 a.m.
Hi,
as I didn't receive any feedback on this question yet, I will resend it
(perhaps due to pending subscription)
On Tue, Dec 8, 2015 at 12:09 PM, Dirk Franssen <dirk.franssen(a)gmail.com>
wrote:
Hi,
how would one configure Keycloak to obtain following scenario's?
Scenario 1:
client A: public (angular app)
client B: bearer-only (microservice)
client C: bearer-only (microservice)
- microservice B is allowed to call microservice C, but an authenticated
user in the js app A should be forbidden to call microservice C directly.
Scenario 2:
client A: public (angular app)
client B: confidential (1 war with a REST service AND a JSF application,
both using the same EJB business layer which is accessing microservice C)
client C: bearer-only (microservice)
- a user authenticated in the angular app can use the REST service of app
B and will see the results of microservice C, but the user may not call
microservice C directly
- a user authenticated in the JSF application will see the results of
microservice C when using the JSF application, but should not be able to
use microservice C directly (if the user would reuse the same access_token)
- should there be different roles for the REST part and the JSF part of
app B (for accessing microservice C)?
Kind regards,
Dirk
2:19 p.m.
It seems you’re trying to enforce that only client B can call client C. This isn’t really
something considered by OpenID Connect Spec. Are you using the access token from client A
to call client C (from B)? If so, the client adapter can’t help you here. If your intent
is just to protect service C from being called directly, just secure it behind a firewall
so that only client B may access it.
It’s also not very clear what you’re try to accomplish by “protecting” access to client
C.
Scott Rossillo
Smartling | Senior Software Engineer
srossillo(a)smartling.com
<http://www.sigstr.com/>
On Dec 16, 2015, at 10:30 AM, Dirk Franssen
<dirk.franssen(a)gmail.com> wrote:
Hi,
as I didn't receive any feedback on this question yet, I will resend it (perhaps due
to pending subscription)
On Tue, Dec 8, 2015 at 12:09 PM, Dirk Franssen <dirk.franssen(a)gmail.com
<mailto:dirk.franssen@gmail.com>> wrote:
Hi,
how would one configure Keycloak to obtain following scenario's?
Scenario 1:
client A: public (angular app)
client B: bearer-only (microservice)
client C: bearer-only (microservice)
- microservice B is allowed to call microservice C, but an authenticated user in the js
app A should be forbidden to call microservice C directly.
Scenario 2:
client A: public (angular app)
client B: confidential (1 war with a REST service AND a JSF application, both using the
same EJB business layer which is accessing microservice C)
client C: bearer-only (microservice)
- a user authenticated in the angular app can use the REST service of app B and will see
the results of microservice C, but the user may not call microservice C directly
- a user authenticated in the JSF application will see the results of microservice C when
using the JSF application, but should not be able to use microservice C directly (if the
user would reuse the same access_token)
- should there be different roles for the REST part and the JSF part of app B (for
accessing microservice C)?
Kind regards,
Dirk
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
3 p.m.
On 12/16/2015 10:30 AM, Dirk Franssen wrote:
Hi,
as I didn't receive any feedback on this question yet, I will resend it
(perhaps due to pending subscription)
On Tue, Dec 8, 2015 at 12:09 PM, Dirk Franssen <dirk.franssen(a)gmail.com
<mailto:dirk.franssen@gmail.com>> wrote:
Hi,
how would one configure Keycloak to obtain following scenario's?
Scenario 1:
client A: public (angular app)
client B: bearer-only (microservice)
client C: bearer-only (microservice)
- microservice B is allowed to call microservice C, but an
authenticated user in the js app A should be forbidden to call
microservice C directly.
Clients request to obtain tokens on behalf of a user. Via the scope
setting in the admin console for the client, you can control what roles
are embedded in the token. So, in this example, it really depends how
the token was created. If Client A asks for the token, you can
completely control what roles are embedded in the token, so you can only
allow access to B. But, if you are expecting to re-use the token to
make an extra communication to C, then it won't work. Keycloak doesn't
have a "token exchange" service where you can take one token and convert
it to another.
Scenario 2:
client A: public (angular app)
client B: confidential (1 war with a REST service AND a JSF
application, both using the same EJB business layer which is
accessing microservice C)
client C: bearer-only (microservice)
- a user authenticated in the angular app can use the REST service
of app B and will see the results of microservice C, but the user
may not call microservice C directly
- a user authenticated in the JSF application will see the results
of microservice C when using the JSF application, but should not be
able to use microservice C directly (if the user would reuse the
same access_token)
- should there be different roles for the REST part and the JSF part
of app B (for accessing microservice C)?
Play around with AdminConsole->Clients->Client->Scope Mapping. It will
get you some of what you want, but not all.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3298
days inactive
3298
days old
2 comments
3 participants
participants (3)
-
Bill Burke -
Dirk Franssen -
Scott Rossillo