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

Marek Posolda mposolda at redhat.com
Wed Sep 16 13:02:02 EDT 2015


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 at redhat.com 
> <mailto:mposolda at 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 at redhat.com <mailto:mposolda at 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 at redhat.com <mailto:bburke at 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 at lists.jboss.org
>>>             <mailto:keycloak-user at 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 at lists.jboss.org
>>>             <mailto:keycloak-user at lists.jboss.org>
>>>             https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>>
>>>
>>>
>>>         _______________________________________________
>>>         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
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150916/72706ab2/attachment-0001.html 


More information about the keycloak-user mailing list