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

Thu Sep 17 10:25:19 EDT 2015

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 at 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 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>
>> 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>
>>> 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
>>>> > 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
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150917/7cdf8cca/attachment.html 