[keycloak-dev] PicketLink and KC Integration

[Pedro Igor Silva]

----- 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.

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.

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 ?

> 
> We have both a stateless mode (bearer-only)as well as a stateful mode as
> well (HTTP Sessions).  We have revocation policies.  We have user
> session management.  Single Log Out, etc.  I urge you to try our demos,
> read our docs, and view our screencasts.  We do TONS OF SHIT :)
> 
> Right now, everything is OAuth2/OpenID Connect based with a small
> extension to JWT for role mappings.  Starting in September, I'll be
> adding SAML support in addition to OAuth/OpenID Connect.  I hope to
> incorporate much of the SAML modules in Picketlink IDP.  This will
> require a lot of refactoring in Keycloak to pull out all the
> non-protocol specific logic like UI rendering, browser authentication,
> and user management workflows (forgot password, totp setup,
> registration, etc.).  It will probably require refactoring of Picketlink
> as well.

Anil told me about it. That would be great.

> 
> 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

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.

> 
> Other areas Anil and I talked about are pulling out our Social Provider
> code into do-it-yourself APIs.  Really improving and expanding
> Picketlink Social.  I haven't looked at Picketlink Social, but I think
> Keycloak may be much more comprehensive.
> 
> Honesty, there is just so much shit to do.  Tons of it.  A lot of
> interesting (and not so interesting) work to go around.  I'd be happy to
> talk to you about it sometime soon.

Sure :)

> 
> On 7/22/2014 10:27 PM, Pedro Igor Silva wrote:
> > 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
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>