[keycloak-dev] PicketLink and KC Integration

[Bill Burke]

On 7/23/2014 8:46 AM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, July 23, 2014 1:04:31 AM
>> Subject: Re: [keycloak-dev] PicketLink and KC Integration
>>
>> Keycloak is about authentication *and* authorization.  We currently have
>> deep integration plugins for AS7/EAP6/Wildfly to provide auth and RBAC
>> for Servlet apps out of the box.  You can even take an existing WAR,
>> without cracking it open, using the Keycloak JBoss/Wildfly Subsystem.
>> We have plans for additional adapters post 1.0.Final for Node.js, JIRA,
>> Tomcat, and Jetty.
>
> What I'm doing is pretty much like what you have in third-party-cdi example. From this example, there is no security-constraint or adapter involved right ?
>



> And looking at the code (from upstream) I can see a org.keycloak.example.oauth.RefreshTokenFilter that does pretty much what PL is doing. Extracting the CODE from the request and configuring an "user" representation which in our case is the Identity bean. Beside that, PL is also validating the token and allowing the application to query roles or any other data from the token.
>
The third-party example is an example of traditional OAuth.  Traditional 
OAuth is not SSO, nor is it anything about identity.  It is about 
getting a temporary token so you can get access to a resource.  Generic 
oauth/openid connect client libraries is another intersection of 
Picketlink and Keycloak that should be shared.  I'm not happy with what 
we got right now.

Our adapters are different than the third-party example.  They are our 
integrated security story:  Single Sign On/Off.  Session management. 
Role mappings.  Component integration, etc.


> I've looked others examples as well. From a PL-only perspective, I was looking for an integration
> fully based on PL where all details from a specific IdP is abstracted from developers. For instance, KC from an application perspective is an implementation detail. If you want you can easily switch to another IdP without change a single line of code in your application. But just PL config. So they can still use our built-in authz annotations and injection to deal with the security context for their users.
>

This is something I'd like to see.  For PIcketlink, Spring security, and 
other security abstractions.  Keycloak 1.0 is 100% focused only on Java 
EE security integration.

> As far as I can see, most examples from KC are based on a coarse-grained authorization model based on a JEE security-constraint. Is that the authorization you're talking about ? Or KC also provides a more fine-grained mechanism to individual beans ?
>

Keycloak is just role based authorization right now.  Roles can be 
scoped at the Realm level, or scoped per application.  We also have some 
claim support (address, phone ,etc.) too.

Keycloak adapters create a principal and populates the Subject with role 
mappings. The adapters also provide REST endpoints for gathering 
management stats, to propagate revocation policies, and also to manage 
Single Sign Off.

>>
>> For the Keycloak 2.0 timeframe (2015), I'd also like to evolve our
>> Social Provider SPI into a full fledged generic Broker SPI, of which I'd
>> like a SAML plugin which could make use of any SAML client modules
>> Picketlink has.
>>
>> We're also missing integration with CDI and other component layers and a
>> better application API for injecting and obtaining security metadata.
>
> I think that is the area I'm trying to help. Considering that we already provide security for CDI applications,
> service providers can still benefit from :
>
> @Inject Identity identity; // representing the authenticated user
> @Inject IdentityManager identityManager; // provides ways to query information retrieved from a token
>

Keycloak has its own specific security model so it will need its own API 
in addition to integration with PL, Spring and other security abstractions.


> Actually, that was a requirement from WFK. They asked us about how to easily enable KC in a PL application.
>
> 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.
>

You don't need to look at the adapter. 
HttpServletRequest.getUserPrincipal() should return an instance of 
KeycloakPrincipal which has a method to get KeycloakSecurityContext 
which has access to the unmarshalled token.  KeycloakSecurityContext is 
also available as a HttpServletRequest attribute:

KeycloakSEcurityContext context = 
(KeycloakSecurityContext)request.getAttribute(KeycloakSecurityContext.class.getName());

Finally, tokens can have any number of claims in them too (address, 
phone, website, blog, picture, etc.).


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com