Hello, Is it possible to apply programmatic access control i.e. retrieve KeycloakSecurityContext, get token, roles etc, when the <security-contraint/> elements have been removed from web.xml? The reason for that is that when <security-constraints/> are present the requests get dropped by the keycloak adapter before reaching the REST endpoints implementation in case they are not carrying a token. I'm trying to support an alternative authorization mechanism using a custom API Key parameter in case the Oauth token header is missing. Regards Orestis _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

Thanks Bill, I think i may tackle the issue for now through the KeycloakConfigResolver. Maybe return an empty deployment if the API Key is in the request. Regards Orestis On Wed, Sep 16, 2015 at 2:39 AM, Bill Burke <bburke(a)redhat.com <mailto:bburke@redhat.com>> wrote: I'll eventually implement adapter as a filter, but right now security constraints are required. On 9/15/2015 5:54 PM, Orestis Tsakiridis wrote: > Hello, > > Is it possible to apply programmatic access control i.e. retrieve > KeycloakSecurityContext, get token, roles etc, when the > <security-contraint/> elements have been removed from web.xml? > > The reason for that is that when <security-constraints/> are present the > requests get dropped by the keycloak adapter before reaching the REST > endpoints implementation in case they are not carrying a token. I'm > trying to support an alternative authorization mechanism using a custom > API Key parameter in case the Oauth token header is missing. > > > Regards > > Orestis > > > > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-user _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

Hi Marek, Yes, i'm talking about securing REST endpoints. I saw the BearerTokenRequestAuthenticator code. The problem is how to conditionally authenticate requests using a custom authentication method that does not rely on keycloak users, roles, clients etc. Would a custom MyCustomRequestAuthenticator do the job? Are there any examples on that? Ideally, an authenticator running inside the adapter that would compare against values in the application database wound to the job. The idea is to be compatible with an old security scheme that relies on API Keys stored in the application database. So i imagined some sort of dual authentication for the REST endpoints. On Wed, Sep 16, 2015 at 11:35 AM, Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: If you're focused on security for REST endpoints, I think it is quite easy to do it programaticaly. You may just need to parse the "Authorization" header from request with bearer token and verify it with RSATokenVerifier.verifyToken from which you also retrieve AccessToken . See BearerTokenRequestAuthenticator class for the inspiration. Marek On 16/09/15 09:04, Orestis Tsakiridis wrote: > Thanks Bill, > > I think i may tackle the issue for now through the > KeycloakConfigResolver. Maybe return an empty deployment if the > API Key is in the request. > > > Regards > > Orestis > > On Wed, Sep 16, 2015 at 2:39 AM, Bill Burke <bburke(a)redhat.com > <mailto:bburke@redhat.com>> wrote: > > I'll eventually implement adapter as a filter, but right now > security > constraints are required. > > On 9/15/2015 5:54 PM, Orestis Tsakiridis wrote: > > Hello, > > > > Is it possible to apply programmatic access control i.e. > retrieve > > KeycloakSecurityContext, get token, roles etc, when the > > <security-contraint/> elements have been removed from web.xml? > > > > The reason for that is that when <security-constraints/> > are present the > > requests get dropped by the keycloak adapter before > reaching the REST > > endpoints implementation in case they are not carrying a > token. I'm > > trying to support an alternative authorization mechanism > using a custom > > API Key parameter in case the Oauth token header is missing. > > > > > > Regards > > > > Orestis > > > > > > > > > > > > > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user(a)lists.jboss.org > <mailto:keycloak-user@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > <mailto:keycloak-user@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-user

Thanks Marek. Yes, you got the usecase right. Two questions come to my mind if i follow this manual approach: 1. Will this take into account a KeycloakConfigResolver that's in place and the deployment it creates ? RSATokenVerifier.verifyToken() seems to get all info it needs in the parameters so i guess not.

2. Are there any caches involved that won't be taken into account ?

3. What happens with 'enable-basic-auth' adapter option? I suppose it needs further manual operation. This case is probably handles by my custom auth so that doesn't seem like a big problem.

On Wed, Sep 16, 2015 at 3:45 PM, Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: I though that's why you want programmatic access because you want to have complete control? In that case you can remove all security constraints from web.xml and at your REST endpoints you would do the authentication/authorization exactly how you want. So at the beginning of REST endpoint you will do something like: if (request.containsHeader("Authorization: Bearer")) { do-keycloak-authentication-with-keycloak-access-token(); } else { do-legacy-authentication-or-whatever-based-on-yourAPI-keys-stuff(); } Or maybe I don't understand the usecase? Marek On 16/09/15 11:36, Orestis Tsakiridis wrote: > Hi Marek, > > Yes, i'm talking about securing REST endpoints. I saw the > BearerTokenRequestAuthenticator code. > > The problem is how to conditionally authenticate requests using a > custom authentication method that does not rely on keycloak > users, roles, clients etc. Would a custom > MyCustomRequestAuthenticator do the job? Are there any examples > on that? Ideally, an authenticator running inside the adapter > that would compare against values in the application database > wound to the job. > > The idea is to be compatible with an old security scheme that > relies on API Keys stored in the application database. So i > imagined some sort of dual authentication for the REST endpoints. > > > > > > On Wed, Sep 16, 2015 at 11:35 AM, Marek Posolda > <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: > > If you're focused on security for REST endpoints, I think it > is quite easy to do it programaticaly. You may just need to > parse the "Authorization" header from request with bearer > token and verify it with RSATokenVerifier.verifyToken from > which you also retrieve AccessToken . See > BearerTokenRequestAuthenticator class for the inspiration. > > Marek > > On 16/09/15 09:04, Orestis Tsakiridis wrote: >> Thanks Bill, >> >> I think i may tackle the issue for now through the >> KeycloakConfigResolver. Maybe return an empty deployment if >> the API Key is in the request. >> >> >> Regards >> >> Orestis >> >> On Wed, Sep 16, 2015 at 2:39 AM, Bill Burke >> <bburke(a)redhat.com <mailto:bburke@redhat.com>> wrote: >> >> I'll eventually implement adapter as a filter, but right >> now security >> constraints are required. >> >> On 9/15/2015 5:54 PM, Orestis Tsakiridis wrote: >> > Hello, >> > >> > Is it possible to apply programmatic access control >> i.e. retrieve >> > KeycloakSecurityContext, get token, roles etc, when the >> > <security-contraint/> elements have been removed from >> web.xml? >> > >> > The reason for that is that when >> <security-constraints/> are present the >> > requests get dropped by the keycloak adapter before >> reaching the REST >> > endpoints implementation in case they are not carrying >> a token. I'm >> > trying to support an alternative authorization >> mechanism using a custom >> > API Key parameter in case the Oauth token header is >> missing. >> > >> > >> > Regards >> > >> > Orestis >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > keycloak-user mailing list >> > keycloak-user(a)lists.jboss.org >> <mailto:keycloak-user@lists.jboss.org> >> > https://lists.jboss.org/mailman/listinfo/keycloak-user >> > >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user(a)lists.jboss.org >> <mailto:keycloak-user@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user(a)lists.jboss.org >> <mailto:keycloak-user@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/keycloak-user > >

Marek, you 're a life saviour! The concept worked perfect.

Btw, digging into BasicAuthRequestAuthenticator i noticed that whenever authenticate() is called, a request to the keycloak auth server is made to retrieve a token using username/password pair. So, it seems that in order to authenticate ANY request with Basic authentication credentials auth server need to be contacted. Is my assumption correct ?

If that's the case it seems that the 'enable-basic-auth' lays a heavy burden on the auth server with this per-request operation. It's of no value to me since i handle Basic authentication locally with a custom mechanism. I'm just asking for the record. Best regards Orestis On Wed, Sep 16, 2015 at 8:02 PM, Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: On 16/09/15 16:38, Orestis Tsakiridis wrote: > Thanks Marek. > > Yes, you got the usecase right. > > Two questions come to my mind if i follow this manual approach: > > 1. Will this take into account a KeycloakConfigResolver that's in > place and the deployment it creates ? > RSATokenVerifier.verifyToken() seems to get all info it needs in > the parameters so i guess not. nope, it won't. This approach is about ignoring the official adapter, which is triggered by security constraints from web.xml and works at servlet layer. So in your case, request will be always passed through servlet layer to REST endpoint when you need to do programmatic authentication by yourself. So you may also need to read the keycloak.json file manually and use KeycloakDeploymentBuilder.build to read KeycloakDeployment and read publicKey and realmInfoUrl from there, so you can do RSATokenVerifier.verifyToken by yourself. > 2. Are there any caches involved that won't be taken into account ? Not sure what you mean. I am not aware of any caches. > 3. What happens with 'enable-basic-auth' adapter option? I > suppose it needs further manual operation. This case is probably > handles by my custom auth so that doesn't seem like a big problem. It will be ignored and you will again need to do Basic Authentication by yourself if you want to support in addition to Bearer authentication. See BasicAuthRequestAuthenticator for inspiration. Marek > > > > On Wed, Sep 16, 2015 at 3:45 PM, Marek Posolda > <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: > > I though that's why you want programmatic access because you > want to have complete control? In that case you can remove > all security constraints from web.xml and at your REST > endpoints you would do the authentication/authorization > exactly how you want. So at the beginning of REST endpoint > you will do something like: > > if (request.containsHeader("Authorization: Bearer")) { > do-keycloak-authentication-with-keycloak-access-token(); > } else { > do-legacy-authentication-or-whatever-based-on-yourAPI-keys-stuff(); > } > > Or maybe I don't understand the usecase? > > Marek > > > On 16/09/15 11:36, Orestis Tsakiridis wrote: >> Hi Marek, >> >> Yes, i'm talking about securing REST endpoints. I saw the >> BearerTokenRequestAuthenticator code. >> >> The problem is how to conditionally authenticate requests >> using a custom authentication method that does not rely on >> keycloak users, roles, clients etc. Would a custom >> MyCustomRequestAuthenticator do the job? Are there any >> examples on that? Ideally, an authenticator running inside >> the adapter that would compare against values in the >> application database wound to the job. >> >> The idea is to be compatible with an old security scheme >> that relies on API Keys stored in the application database. >> So i imagined some sort of dual authentication for the REST >> endpoints. >> >> >> >> >> >> On Wed, Sep 16, 2015 at 11:35 AM, Marek Posolda >> <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: >> >> If you're focused on security for REST endpoints, I >> think it is quite easy to do it programaticaly. You may >> just need to parse the "Authorization" header from >> request with bearer token and verify it with >> RSATokenVerifier.verifyToken from which you also >> retrieve AccessToken . See >> BearerTokenRequestAuthenticator class for the inspiration. >> >> Marek >> >> On 16/09/15 09:04, Orestis Tsakiridis wrote: >>> Thanks Bill, >>> >>> I think i may tackle the issue for now through the >>> KeycloakConfigResolver. Maybe return an empty >>> deployment if the API Key is in the request. >>> >>> >>> Regards >>> >>> Orestis >>> >>> On Wed, Sep 16, 2015 at 2:39 AM, Bill Burke >>> <bburke(a)redhat.com <mailto:bburke@redhat.com>> wrote: >>> >>> I'll eventually implement adapter as a filter, but >>> right now security >>> constraints are required. >>> >>> On 9/15/2015 5:54 PM, Orestis Tsakiridis wrote: >>> > Hello, >>> > >>> > Is it possible to apply programmatic access >>> control i.e. retrieve >>> > KeycloakSecurityContext, get token, roles etc, >>> when the >>> > <security-contraint/> elements have been removed >>> from web.xml? >>> > >>> > The reason for that is that when >>> <security-constraints/> are present the >>> > requests get dropped by the keycloak adapter >>> before reaching the REST >>> > endpoints implementation in case they are not >>> carrying a token. I'm >>> > trying to support an alternative authorization >>> mechanism using a custom >>> > API Key parameter in case the Oauth token header >>> is missing. >>> > >>> > >>> > Regards >>> > >>> > Orestis >>> > >>> > >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > keycloak-user mailing list >>> > keycloak-user(a)lists.jboss.org >>> <mailto:keycloak-user@lists.jboss.org> >>> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> > >>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user(a)lists.jboss.org >>> <mailto:keycloak-user@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>> >>> >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user(a)lists.jboss.org >>> <mailto:keycloak-user@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> > >