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.
2. Are there any caches involved that won't be taken into account ?
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.
On Wed, Sep 16, 2015 at 3:45 PM, Marek Posolda <mposolda(a)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(a)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(a)redhat.com>
> bburke(a)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(a)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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>
>
> _______________________________________________
> keycloak-user mailing
listkeycloak-user@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>