1:30 a.m.
Hi,
The AWS ALB will allow you to authenticate to cognito or OIDC nowadays.
I thought "Great, I can connect it up to my KeyCloak".
Sadly not. Well, I can connect it to KeyCloak and see sensible looking
headers and JWTs flowing back and forth.
And then the ALB says "500 Internal Server Error" :-(
I can see a request to keycloak (from the client) :
https://auth.care.surevine.com/auth/realms/care/protocol/openid-connect/a...
And it 302 redirects back to the ALB :
https://dev.care.surevine.com/oauth2/idpresponse?state=8sp1j3N3baPa1r%2BE...
On the KeyCloak server I can see the POST requests from the browser coming
in and hitting the authenticate URL, KC hands back a 302 (the URL above)
Then the ALB does a POST to the token endpoint and gets a 200 response with
a nice chunk of access token. I can decode it and see my details quite
happily. I even validated the signature. (Using jwt.io 's debugger.)
Although the ALB doesn't ask for the certificate at any stage, so I don't
think it even bothers validating it.
But it doesn't seem to like it. And gives me a 500 error.
(I can authenticate with Google OIDC without any trouble...)
(NB Any secrets in any of those strings won't get you very far, there is no
content yet :-) )
3:29 p.m.
Hi Max,
I tried integrating AWS ELB and Keycloak one month ago
and I encountered same problem.
Because AWS ELB doesn't follow the OAuth2 spec correctly,
it rejects the token endpoint response from Keycloak.
The response from Keycloak contains "token_type" as follows:
"token_type":"bearer"
But AWS ELB expects as follows:
"token_type":"Bearer"
OAuth2 spec says the value is case insensitive as below.
https://tools.ietf.org/html/rfc6749#section-4.2.2
token_type
REQUIRED. The type of the token issued as described in
Section 7.1. Value is case insensitive.
So, I think we need to wait until AWS fixes this issue...
If you want to try it now, you can do it by replacing the response
in front of Keycloak using Apache HTTPD Server and so on.
I tried the below setting for Apache HTTPD Server and it works!!
I used Substitute Directive to replace the value.
<VirtualHost *:80>
ProxyPass / http://localhost:8080/
ProxyPassReverse / http://localhost:8080/
ProxyErrorOverride off
AddOutputFilterByType SUBSTITUTE application/json
Substitute
s/"token_type":"bearer"/"token_type":"Bearer"/n
</VirtualHost>
Best Regards,
--
Hiroyuki Wada
Nomura Research Institute, Ltd.
h2-wada(a)nri.co.jp
--------------------------------------------------------------------
PLEASE READ:This e-mail is confidential and intended for
the named recipient only. If you are not an intended recipient,
please notify the sender and delete this e-mail.
--------------------------------------------------------------------
On 2018/07/14 1:30, Max Allan wrote:
Hi,
The AWS ALB will allow you to authenticate to cognito or OIDC nowadays.
I thought "Great, I can connect it up to my KeyCloak".
Sadly not. Well, I can connect it to KeyCloak and see sensible looking
headers and JWTs flowing back and forth.
And then the ALB says "500 Internal Server Error" :-(
I can see a request to keycloak (from the client) :
https://auth.care.surevine.com/auth/realms/care/protocol/openid-connect/a...
And it 302 redirects back to the ALB :
https://dev.care.surevine.com/oauth2/idpresponse?state=8sp1j3N3baPa1r%2BE...
On the KeyCloak server I can see the POST requests from the browser coming
in and hitting the authenticate URL, KC hands back a 302 (the URL above)
Then the ALB does a POST to the token endpoint and gets a 200 response with
a nice chunk of access token. I can decode it and see my details quite
happily. I even validated the signature. (Using jwt.io 's debugger.)
Although the ALB doesn't ask for the certificate at any stage, so I don't
think it even bothers validating it.
But it doesn't seem to like it. And gives me a 500 error.
(I can authenticate with Google OIDC without any trouble...)
(NB Any secrets in any of those strings won't get you very far, there is no
content yet :-) )
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
11:41 p.m.
FYI, if you are using an ALB with Keycloak, AWS appear to have quietly
fixed the B/b problem and it all works nicely out of the box now.
Problem solved.
Max
On Tue, 17 Jul 2018 at 07:29, Hiroyuki Wada <h2-wada(a)nri.co.jp> wrote:
Hi Max,
I tried integrating AWS ELB and Keycloak one month ago
and I encountered same problem.
Because AWS ELB doesn't follow the OAuth2 spec correctly,
it rejects the token endpoint response from Keycloak.
The response from Keycloak contains "token_type" as follows:
"token_type":"bearer"
But AWS ELB expects as follows:
"token_type":"Bearer"
OAuth2 spec says the value is case insensitive as below.
> https://tools.ietf.org/html/rfc6749#section-4.2.2
>
> token_type
> REQUIRED. The type of the token issued as described in
> Section 7.1. Value is case insensitive.
So, I think we need to wait until AWS fixes this issue...
2017
days inactive
2125
days old
2 comments
2 participants
participants (2)
-
Hiroyuki Wada -
Max Allan