Flood of requests to Keycloak when accessing apiman UI
by Paul Blair
We are testing setting up a configuration where the API gateway, the API manager UI, and Keycloak are all behind their own load balancers on AWS. Keycloak is clustered using JDBC_PING.
When I try to access the apimanui URL after logging in via Keycloak, sometimes the admin page is rendered; sometimes it isn't and I have to refresh it a few times. I see a flood of requests coming into both of the Keycloak instances.
>From what I can see, after the POST to Keycloak happens, there is a sequence of 302 redirects that eventually results in a successful GET to index.html. After that, however, each request for a resource on the page — css, javascript, fonts, whatever — also gets a 302 and is redirected to Keycloak and redirected back before the request is successful. I'm getting the impression from what I'm seeing that the bearer token is not being received by the browser and/or submitted with requests.
Below is an example from the browser request log. All the browser requests are to various subdomains of us-west-2.elb.amazonaws.com (the load balancers); the instances of apiman and Keycloak are all on subdomains of us-west-2.compute.amazonaws.com. There is currently no session affinity set up in the load balancers for Keycloak, the apiman gateway, or the apiman management UI.
Any ideas on what might be causing this?
*** Part 1: Browser login via Keycloak and request for index.html ***
POST https://[KEYCLOAK]/auth/realms/apiman/login-actions/authenticate?code=[CO...
Cookie:"KC_RESTART=[RESTART-01]"
Response: 302
Location:"https://[KEYCLOAK]/auth/realms/apiman/login-actions/authenticate?code=[CO..."
GET https://[KEYCLOAK]/auth/realms/apiman/login-actions/authenticate?code=[CO...
Cookie:"KC_RESTART=[RESTART-01]"
Response: 302
Location:"https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?code=..."
GET https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?code=...
Cookie:"KC_RESTART=[RESTART-01]"
Response: 302
Location:"https://[API_MANAGER]/apimanui/index.html?state=[STATE-01]"
Set-Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-01]; Version=1; Path=/auth/realms/apiman; HttpOnly
KEYCLOAK_SESSION=apiman/[KC_SESS-01]; Version=1; Expires=Wed, 06-Jan-2016 06:09:59 GMT; Max-Age=36000; Path=/auth/realms/apiman
KC_RESTART=; Version=1; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/apiman; HttpOnly"
GET https://[API_MANAGER]/apimanui/index.html?state=[STATE-01]&code=[CODE-03]
Cookie:"OAuth_Token_Request_State=[STATE-01]"
Response: 302
Location:"https://[API_MANAGER]/apimanui/index.html"
Set-Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-01]; path=/apimanui
OAuth_Token_Request_State=; Max-Age=0; Expires=Thu, 01-Jan-1970 00:00:00 GMT"
GET https://[API_MANAGER]/apimanui/index.html
Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-01]"
Response: 302
Location:"https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/auth?respon..."
Set-Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-02]; path=/apimanui
OAuth_Token_Request_State=[STATE-02]; secure"
GET https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/auth?respon...
Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-01]; KEYCLOAK_SESSION=apiman/[KC_SESS-01]"
Response: 302
Location:"https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?code=..."
Set-Cookie:"KC_RESTART=[RESTART-02]; Version=1; Path=/auth/realms/apiman; HttpOnly"
GET https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?code=...
Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-01]; KEYCLOAK_SESSION=apiman/[KC_SESS-01]; KC_RESTART=[RESTART-02]"
Response: 302
Location:"https://[API_MANAGER]/apimanui/index.html?state=[STATE-02]&code=[CODE-05]"
Set-Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-02]; Version=1; Path=/auth/realms/apiman; HttpOnly
KEYCLOAK_SESSION=apiman/[KC_SESS-01]; Version=1; Expires=Wed, 06-Jan-2016 06:10:00 GMT; Max-Age=36000; Path=/auth/realms/apiman
KC_RESTART=; Version=1; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/apiman; HttpOnly"
GET https://[API_MANAGER]/apimanui/index.html?state=[STATE-02]&code=[CODE-05]
Cookie:"OAuth_Token_Request_State=[STATE-02]; JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-02]"
Response: 200
Set-Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-01]; path=/apimanui"
*** Part 2: Subsequent requests for resources (here, bootstrap-select.css) ***
GET https://[API_MANAGER]/apimanui/libs/bootstrap-select/bootstrap-select.css...
Cookie:"OAuth_Token_Request_State=[STATE-02]; JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-01]"
Response: 302
Location:"https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/auth?respon..."
Set-Cookie:"JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-02]; path=/apimanui
OAuth_Token_Request_State=[STATE-03]; secure"
GET https://[KEYCLOAK]/auth/realms/apiman/protocol/openid-connect/auth?respon...
Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-03]; KEYCLOAK_SESSION=apiman/[KC_SESS-01]"
Response: 302
Location:"https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?code=..."
Set-Cookie:"KC_RESTART=[RESTART-03]; Version=1; Path=/auth/realms/apiman; HttpOnly"
GET https://[KEYCLOAK]/auth/realms/apiman/login-actions/required-action?code=...
Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-03]; KEYCLOAK_SESSION=apiman/[KC_SESS-01]; KC_RESTART=[RESTART-03]"
Response: 302
Location:"https://[API_MANAGER]/apimanui/libs/bootstrap-select/bootstrap-select.css..."
Set-Cookie:"KEYCLOAK_IDENTITY=[IDENTITY-04]; Version=1; Path=/auth/realms/apiman; HttpOnly
KEYCLOAK_SESSION=apiman/[KC_SESS-01]; Version=1; Expires=Wed, 06-Jan-2016 06:10:02 GMT; Max-Age=36000; Path=/auth/realms/apiman
KC_RESTART=; Version=1; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/apiman; HttpOnly"
GET https://[API_MANAGER]/apimanui/libs/bootstrap-select/bootstrap-select.css...
Cookie:"OAuth_Token_Request_State=445/4a12cbb7-c16d-42a5-90c7-cf296616674a; OAuth_Token_Request_State=[STATE-02]; JSESSIONID=[APIMAN_JSESS-01].[SUFFIX-02]"
Response: 400
Set-Cookie:"OAuth_Token_Request_State=; Max-Age=0; Expires=Thu, 01-Jan-1970 00:00:00 GMT"
*** Meanwhile, in Keycloak — the logs have the following segment repeatedly: ***
DEBUG [org.keycloak.protocol.oidc.utils.RedirectUtils] (default task-23) replacing relative valid redirect with: https://[API_MANAGER]/apimanui/*
DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default task-23) AUTHENTICATE
DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default task-23) authenticator: auth-cookie
DEBUG [org.keycloak.services.managers.AuthenticationManager] (default task-23) token active - active: true, issued-at: 1,452,019,157, not-before: 1,452,014,329
DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default task-23) authenticator SUCCESS: auth-cookie
DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default task-23) execution is processed
9 years, 11 months
Should the apiman-gateway-api client have direct access grants enabled?
by Paul Blair
Today I've been having a lot of trouble creating a gateway. When I put in the gateway name, description, configuration endpoint and configuration endpoint credentials, I kept getting "Authentication to the gateway failed. Perhaps check that your credentials are correct." I was able to log in to Keycloak using the apimanager credentials, so I know they are correct.
In the Keycloak log I see:
WARN [org.keycloak.events] type=LOGIN_ERROR, realmId=apiman, clientId=apiman-gateway-api, userId=null, ipAddress=[x.x.x.x], error=not_allowed, grant_type=password, auth_method=oauth_credentials, client_auth_method=client-secret
I couldn't figure out why the userId should be null. The apimanager user has the apipublisher role, the apiman-gateway-api client has the proper valid redirect URI and uses the openid-connect protocol with a confidential access type, and the application configurations are using the correct client secret.
I was finally able to fix the issue by enabling direct access grants on the apiman-gateway-api client. Should this be part of the default configuration for apiman-gateway-api in the apiman-realm.json, file, or is there something I'm misssing?
9 years, 11 months
Login failure message shows password in the clear
by Paul Blair
I'm setting up a new gateway in apiman. I put in the wrong password for the configuration endpoint credentials, and this is what I got on the "New Gateway" screen:
Gateway Configuration Invalid
Something has gone wrong when testing the Gateway. Hopefully the details (below) will help you figure out what.
{"data":"<html><head><title>Error</title></head><body>Unauthorized</body></html>","status":401,"config":{"method":"PUT","transformRequest":[null],"transformResponse":[null],"data":{"name":"The Gateway","description":"Gateway to back-end services","configuration":"{\"endpoint\":\"https://[GATEWAY_URI]/apiman-gateway-api/\",\"username\":\"apimanager\",\"password\":\"api-manager$65454\"}","type":"REST"},"url":"https://[APIMAN_URI]/apiman/gateways","headers":{"Accept":"application/json, text/plain, */*","Content-Type":"application/json;charset=utf-8","Authorization":"Bearer [TOKEN]"}},"statusText":"Unauthorized"}
Granted that only a mistaken password is shown, this still doesn't seem secure, and also makes me wonder if the credential may be exposed in other similar places. Should I raise an issue on this?
9 years, 11 months
Integration with separate Keycloak server?
by Guy Davis
Good day,
I currently have a test instance of Wildfly 9 running both Keycloak 1.5 and
Apiman 1.1.8. I'm using Keycloak 1.5 as Apiman makes a Keycloak getTime()
call somewhere that was removed in Keycloak 1.6's adapters.
So I'm seeing that trying to put Keycloak and Apiman in the same Wildfly
container is probably not a good plan going forward due to
incompatibilities as each project progresses.
Today, I noticed that Hawkular announced
<http://www.hawkular.org/blog/2015/12/16/hawkular-1.0.0.Alpha8-released.html>
that they now allow startup of their container with a property pointing to
a remote Keycloak server.
Is this possible with Apiman today? If not, is it on the roadmap? I'd
like to upgrade to Keycloak 1.7
<http://blog.keycloak.org/2015/12/keycloak-170final-released.html> following
this approach with Keycloak, Apiman, and Hawkular all in their own
containers.
By the way, I'm really stoked to see the excellent integration and progress
being made by all these projects! Keep up the good work.
Thanks,
Guy
9 years, 11 months
Re: [Apiman-user] Integration with separate Keycloak server?
by Guy Davis
Hi Marc,
Yes! Thanks for the workaround. After your report, I went back and
imported the default 'apiman
<https://raw.githubusercontent.com/apiman/apiman/master/distro/data/src/ma...>'
realm into my Keycloak 1.7 server. In this case, I was able to login to
/apimanui with no 403 error. Since my production deployment will involve
multiple apps, I had setup APIMan to be secured in our single realm, all
under a single KC Client named 'apiman' with client roles of 'apiuser,
apipublisher, and apiadmin'. After much trial and error I discovered the
difference in my multi-app setup and the APIMan example realm was the level
of the roles. In particular, if the apiman roles are declared on the
apiman client itself, then role mapping them to users won't allow login.
However, if the apiman roles are realm-wide roles, then a role mapping
seems to work and users can login.
It's unfortunate that a single application like APIMan should require it's
own realm-wide roles for security, not KC-client level roles. None of the
other apps that I have secured with Keycloak seem to require more than
KC-client level roles. So I consider this a defect in Keycloak, likely due
to the use of the old Keycloak adapter in the APIMan 1.1.9 bundle. I look
forward to an upcoming release of APIMan with updated Keycloak integration.
Best regards,
Guy
On Thu, Dec 31, 2015 at 4:19 AM, Marc Savy <msavy(a)redhat.com> wrote:
> Hi,
>
> I actually tried this about a week or fortnight ago (see the thread with
> pblair), and I got it working pretty easily.
>
> The only thing I had to change was in the Keycloak console, where I
> enabled 'Direct API Grants' on the apiman gateway api clients (or similar
> wording, I'm on mobile), and everything worked fine despite adaptor version
> mismatches.
>
> Regards,
> Marc
>
> ----- Original Message -----
> From: Guy Davis <guydavis.ca(a)gmail.com>
> To: Eric Wittmann <eric.wittmann(a)redhat.com>
> Cc: apiman-user(a)lists.jboss.org
> Sent: Thu, 31 Dec 2015 01:00:23 -0500 (EST)
> Subject: Re: [Apiman-user] Integration with separate Keycloak server?
>
> Hi Eric,
>
> Thanks for the quick response. I tried this using a separate Keycloak
> 1.7.0 server and am encountering errors that, after debugging thru the
> Keycloak OAuth flow, seem linked to the use of the earlier version of the
> Keycloak adapter which is bundled with APIMan 1.1.9. Do you have an
> planned release date for a Keycloak 1.7.0 compatible version of APIMan?
> Continued successful integration between these two projects is a big
> benefit.
>
> If try to use APIMan 1.1.9 with the Keycloak 1.7.0 adapter for Wildfly, I
> encounter a problem in
> io.apiman.manager.ui.server.wildfly8,KeyCloakBearerTokenGenerator where the
> use of:
>
> org.keycloak.util.Time,getTime()
>
> errors out at runtime with ClassNotFoundException as this class was dropped
> from the Keycloak 1.7.0 API.
>
> Thanks again.
> Guy
>
> On Thu, Dec 17, 2015 at 3:35 PM, Eric Wittmann <eric.wittmann(a)redhat.com>
> wrote:
>
> > This is absolutely possible. Have a look through the production guide
> and
> > see if it helps:
> >
> > http://www.apiman.io/latest/production-guide.html
> >
> > If you continue to have issues let us know so that we can update the
> > guide. We already have at least one update to make:
> >
> > https://issues.jboss.org/browse/APIMAN-842
> >
> > -Eric
> >
> > On 12/17/2015 3:48 PM, Guy Davis wrote:
> >
> >> Good day,
> >>
> >> I currently have a test instance of Wildfly 9 running both Keycloak 1.5
> >> and Apiman 1.1.8. I'm using Keycloak 1.5 as Apiman makes a Keycloak
> >> getTime() call somewhere that was removed in Keycloak 1.6's adapters.
> >>
> >> So I'm seeing that trying to put Keycloak and Apiman in the same Wildfly
> >> container is probably not a good plan going forward due to
> >> incompatibilities as each project progresses.
> >>
> >> Today, I noticed that Hawkular announced
> >> <
> >>
> http://www.hawkular.org/blog/2015/12/16/hawkular-1.0.0.Alpha8-released.html
> >> >
> >> that they now allow startup of their container with a property pointing
> >> to a remote Keycloak server.
> >>
> >> Is this possible with Apiman today? If not, is it on the roadmap? I'd
> >> like to upgrade to Keycloak 1.7
> >> <http://blog.keycloak.org/2015/12/keycloak-170final-released.html>
> >> following
> >> this approach with Keycloak, Apiman, and Hawkular all in their own
> >> containers.
> >>
> >> By the way, I'm really stoked to see the excellent integration and
> >> progress being made by all these projects! Keep up the good work.
> >>
> >> Thanks,
> >> Guy
> >>
> >>
> >> _______________________________________________
> >> Apiman-user mailing list
> >> Apiman-user(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/apiman-user
> >>
> >>
>
>
9 years, 11 months