[keycloak-user] Programmatic access control with no <security-constraints/> in web.xml
Marek Posolda
mposolda at redhat.com
Thu Sep 17 12:54:54 EDT 2015
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
> <mailto: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 <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/20150917/fccea98e/attachment-0001.html
More information about the keycloak-user
mailing list