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

Fri Sep 18 04:15:01 EDT 2015

It makes sense.

Thanks for your help.

On Thu, Sep 17, 2015 at 7:54 PM, Marek Posolda <mposolda at redhat.com> wrote:

> 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 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>
>> 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>keycloak-user at 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 at lists.jboss.org>keycloak-user at lists.jboss.org
>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-user>
>>>>> 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/20150918/0162b62d/attachment-0001.html 