[keycloak-dev] PicketLink and KC Integration
Pedro Igor Silva
psilva at redhat.com
Fri Jul 25 17:58:28 EDT 2014
Hi All,
I had some progress with PL and Federation Protocols support. I've provided implementations for both KC and PL SAML support. I think that would be a nice feature for our users, so they can use our stuff all together.
Basically, what we have is a federated identity store on PL side, which knows how to consume a specific token from a federation protocol and extract its information to properly integrate with PL identity model. From a SPI perspective, federation providers must implement a Token Consumer and an Custom Authentication Scheme.
The Token Consumer is responsible for understand how to parse a specific token and extract identity information from it (eg.: claims or any other kind of attributes). The Authentication Scheme is responsible for providing a entry point in order to extract the token from the request or in some other way. For instance, when using KC adapter the custom scheme uses the KeycloakSecurityContext to get the token.
One of the most interest thing about this support in PL is that you can switch from different federation providers without change the rest of your application. In other words, if you are already using PL to protected/authorize your beans and using the Identity bean to handle the authenticated user, you still use it in the same way as a "regular" PL application.
Another aspect is the possibility to provide a deep integration with a specific IdP in order to properly manage tokens by a consumer application. This is specially useful when your application does not use KC adapter, but only keycloak.js or something else to update and send tokens in every single request to the server.
With that in mind, I would like to know if we can provide the KC related implementation from KC itself. The motivation is that in order to properly handle KC tokens we need some KC libraries and I think the best place to put this is in KC. Any change to API or something we get during KC build. KC users looking for PL integration just get it from KC OOTB.
As I said, that would be 2 or 3 simple classes. Something like:
https://github.com/pedroigor/jboss-wfk-quickstarts/blob/token-store-without-js/contacts-mobile-picketlink-secured/src/main/java/org/jboss/quickstarts/wfk/contacts/security/authentication/KeyCloakToken.java (See, we can use KC API to properly parse and handle tokens. Instead of PL-JSON)
https://github.com/pedroigor/jboss-wfk-quickstarts/blob/token-store-without-js/contacts-mobile-picketlink-secured/src/main/java/org/jboss/quickstarts/wfk/contacts/security/authentication/KeyCloakAuthenticationScheme.java (Used only KC adapter is present. Otherwise users can just use our TokenAuthenticationScheme when sending tokens to the server)
https://github.com/pedroigor/jboss-wfk-quickstarts/blob/token-store-without-js/contacts-mobile-picketlink-secured/src/main/java/org/jboss/quickstarts/wfk/contacts/security/authentication/KeyCloakTokenConsumer.java
I'm still changing code. But those three core concepts (Token, Scheme and Consumer) are almost consolidated. Just need to test some other scenarios to make sure we're on the right path.
Any thoughts ?
----- Original Message -----
From: "Pedro Igor Silva" <psilva at redhat.com>
To: "Bill Burke" <bburke at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Wednesday, July 23, 2014 12:33:06 PM
Subject: Re: [keycloak-dev] PicketLink and KC Integration
----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, July 23, 2014 11:08:12 AM
> Subject: Re: [keycloak-dev] PicketLink and KC Integration
>
>
>
> 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.
Agree on the oAuth stuff. But as I told you there is a pretty common scenario where an application provides a social login. IMO, social logins can be used as follows:
1) Account Linking. In this case, the application may want to provide its own registration (username/password) and only link user's account to a specific social one. Eg.: JBoss Developer Site.
2) Account Linking + Remember-Me. In this case, the application does not store user credentials at all but relies on the social provider to authenticate based on the token retrieved from the social provider. As long the token is valid and your browser has a valid session in a social provider, you're always redirected back to app with a token and authenticated by the application. It is a fake "SSO" :)
There is another scenario that I'm considering that is related with scopes. In this case, the oAuth server authorizes a client application to use a set of scopes (eg.: read public profile). The client application then uses the token to invoke an API provided by another application. I want to use the token to extract the authorized scopes and protect my API.
>
> 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.
Yeah, they remind me PL SAML Authenticators :)
>
>
> > 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.
I see. I'm preparing some quickstarts to showcase this. Let's see ...
>
> > 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.).
Cool. Tks.
>
>
> --
> 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
More information about the keycloak-dev
mailing list