2:35 a.m.
We don't have brokering for directGrant flow though. You would need to
code authenticator by yourself.
Maybe I would do something like the authenticator where you can send the
parameters like for example
"grant_type=password&client_id=your-client&external_idp=true&external_username=john-from-kc-b&external_password=johnspassword"
You will create new directGrant flow and you will put your authenticator
to it. Your authenticator will then do something like:
- Check if there is "external_idp=true" parameter. If not, then just
passthrough to other authenticators in the chain to do classic
directGrant login against "local" Keycloak server (like default
directGrant flow do)
- Then check the parameters external_username and external_passsword to
login against your Keycloak B (Assuming you know where Keycloak B is and
what is the desired clientId of Keycloak B to authenticate against it)
- If authentication against Keycloak B successful, you will successfully
finish the authenticator, so your client will receive the accessToken
from Keycloak A, which can be used to access your API.
You can take a look at existing Authentication SPI docs and examples and
at the existing implementations of DirectGrant authenticators for the
inspiration (ValidateUsername, ValidatePassword, ValidateOTP)
Marek
On 24/01/17 15:13, Alexander Chriztopher wrote:
What i need at the end is to be able to call an API protected by
Keycloak A with a user Known by Keycloak B.
In another way what we want is to do is brokering but with Direct
Access Grant and not in the browser as it is described here in the
Keycloak documentation here :
https://keycloak.gitbooks.io/server-adminstration-guide/content/topics/id....
What would be the Direct Access Grant flow to achieve the same thing ?
On Tue, Jan 24, 2017 at 12:49 PM, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
We have support for identity brokering, but not sure if that helps
with your usecase. As if I understand correctly, you have token
for B and you want to access API protected by A with the B-token,
right?
If you don't want to use multitenancy for some reason, I think you
may have to validate token by yourself and your application side
instead of using our adapters. As even if A and B use the same
publicKey for token verification, the issuer in the B-Token will
be different though, so our adapter (which verifies the issuer)
will fail.
Also you can implement your own directGrant authenticator in the
Keycloak-A, which will allow you to authenticate with the b-token
(sent to it in some parameter) and then return you back the
a-token, which you can then validate. Defacto exchange b-token for
a-token. See Authentication SPI docs for more details.
Marek
On 24/01/17 12:14, Alexander Chriztopher wrote:
> Actually, we dont' want our API to know the B instance.
>
> Is there any other solution (am thinking about brokering between
> A and B and creating a client for instance B in instance A etc.) ?
>
> And yes, A and B are not in a cluster for organisation matters.
>
> On Tue, Jan 24, 2017 at 11:25 AM, Marek Posolda
> <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote:
>
> I assume that Keycloak instances A and B are not in cluster?
> If you can put them in cluster, you will have this supported
> OOTB.
>
> Also did you see our multitenancy feature and multi-tenant
> example? This allows that application (API) is protected by
> both instance A or B. So based on the token from the request,
> you will see if you should use keycloak A or B to validate token.
>
> Marek
>
>
> On 24/01/17 11:05, Alexander Chriztopher wrote:
>
> Hello,
>
> Am looking for the flow to get an access token with OIDC
> and 2 Keycloak
> instances (A and B).
>
> User is Known by instance B and gets an access token from
> instance B then
> needs to access an API protected with instance A.
>
> What would be the best way to do it ?
>
> Thanks for any help.
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> <mailto:keycloak-user@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
> <https://lists.jboss.org/mailman/listinfo/keycloak-user>
>
>
>
>
2817
days inactive
2817
days old
0 comments
1 participants
participants (1)
-
Marek Posolda