[keycloak-dev] PicketLink and KC Integration

[Pedro Igor Silva]

Maybe I should also take a look about how to use the adapter to provide all the token handling instead of doing it by my own ...

Just a note, PL just like Spring and Shiro are alternatives to JEE security.

----- Original Message -----
From: "Stian Thorgersen" <stian at redhat.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Wednesday, July 23, 2014 6:06:00 AM
Subject: Re: [keycloak-dev] PicketLink and KC Integration

As JavaEE security is lacking at best it would be nice to see integration with PL to use PL CDI and permissions. 

I haven't looked at PL for a while, so I'm not 100% up to date with how it all works now. However, this doesn't seem like the correct approach to me. As Bill pointed out our as7/undertow adapters already do this stuff. IMO an application should be secured using the KC adapters, then use PL CDI/permissions when JavaEE security mechanisms are not enough.

----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 23 July, 2014 3:27:33 AM
> Subject: [keycloak-dev] PicketLink and KC Integration
> 
> Hi All,
> 
>    Currently, I'm working in a new identity store to handle tokens issued by
>    a specific IdP. KeyCloak is one of them.
> 
>    So far, I'm trying to provide an easy way to integrate KC with PL. But it
>    will also be useful for SAML-based apps.
> 
>    My first use case is simple. A REST application provides endpoints
>    protected by roles. The client application authenticates using an IdP
>    (eg.: KC) and invoke the REST endpoints by sending the token on every
>    single request. The application then validates, extract user information
>    from the token and creates a security context for a specific request.
> 
>    This identity store will operate in two modes:
> 
>        1) Stateless. Useful for applications acting only as a Service
>        Provider. In this case, the app only wants to join a SSO session and
>        use all information provided by a token to perform in-house
>        authorization such as RBAC. Tokens are not persisted and are usually
>        short-lived.
> 
>        2) Stateful. Useful for applications that want to use a specific token
>        to invoke 3rd party APIs. In this case, the app wants to login using
>        a social provider (eg.: facebook, github or even KC) and store the
>        token and user information locally for later use. Once stored, the
>        app can retrieve the token and use it to invoke an external API.
> 
>    What I did so far is related with #1 and the functionality is covering:
> 
>        - Usage of keycloak.js to redirect users to login page and renew
>        tokens.
>        - Send KC token in every single request to a specific PL filter that
>        knows how to process tokens.
>        - Validate the token and create a security context for an user.
>        Considering KC, the validation involves the expiration time,
>        signature, audience, issuer, etc.
>        - Extract from the token identity information such as username, roles,
>        realm, etc.
>        - Support authorization checks based on the information extracted from
>        a token.
> 
>    I still have some gaps to fill, but I would like to know what are your
>    thoughts about how PL and KC can work together. AFAIK, KeyCloak is more
>    about authentication. If the application wants authorization based on the
>    information from a token (eg.: roles) it must do it by itself. Or you
>    guys already have code for that ?
> 
> Thanks.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>