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@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@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@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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user

_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user