Re: [keycloak-user] Programmatic access control with no <security-constraints/> in web.xml

On 17/09/15 16:25, Orestis Tsakiridis wrote: Marek, you 're a life saviour! The concept worked perfect. Nice :-) 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 ? Yes, it works how you described. The Basic authentication support was added just for legacy applications support. It's not something recommended. Marek 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&gt; 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&gt; > mposolda(a)redhat.com&gt; 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&gt; >> mposolda(a)redhat.com&gt; 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&gt; >>> bburke(a)redhat.com&gt; 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@lists.jboss.org&gt;keycloak-user(a)lists.jboss.org >>>> > <https://lists.jboss.org/mailman/listinfo/keycloak-user> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> > >>>> >>>> -- >>>> Bill Burke >>>> JBoss, a division of Red Hat >>>> <http://bill.burkecentral.com>http://bill.burkecentral.com >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> <keycloak-user@lists.jboss.org&gt;keycloak-user(a)lists.jboss.org >>>> <https://lists.jboss.org/mailman/listinfo/keycloak-user> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >>> >>> >>> >>> _______________________________________________ >>> keycloak-user mailing listkeycloak-user@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>> >>> >> >> > >