[keycloak-user] Brokering with OIDC and Direct Access Grant
Marek Posolda
mposolda at redhat.com
Thu Jan 26 14:01:52 EST 2017
Not OOTB. You can create JIRA though (or search if JIRA already exists)
for better OOTB brokering support with the directGrant. But I guess we
are not going to add that in the near future unless there is bigger
demand for it...
Other option is, that for AngularJS you can use keycloak.js adapter. We
have examples for that in the example distribution. We have also support
for themes, so you can customize login page.
Marek
On 26/01/17 18:58, Alexander Chriztopher wrote:
> Thanks for all the tips Marek.
>
> Does this mean that for any Single Page Application where we do not
> want to take the user outside of the single application page to a
> login page there are no solutions with Keycloak when brokering ?
> Actually, this is our real use case. Our SPA (Angular JS) is
> configured with Keycloak A and we want users known by Keycloak B to be
> able to authenticate on our app but we don't want them to lose the
> context of the app by redirecting there navigator to another page.
>
> On Thu, Jan 26, 2017 at 9:35 AM, Marek Posolda <mposolda at redhat.com
> <mailto:mposolda at redhat.com>> wrote:
>
> 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/identity-broker/overview.html
>> <https://keycloak.gitbooks.io/server-adminstration-guide/content/topics/identity-broker/overview.html>.
>> 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 at redhat.com <mailto:mposolda at 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 at redhat.com <mailto:mposolda at 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 at lists.jboss.org
>>> <mailto:keycloak-user at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>> <https://lists.jboss.org/mailman/listinfo/keycloak-user>
>>>
>>>
>>>
>>>
>>
>>
>
>
More information about the keycloak-user
mailing list