9:27 p.m.
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
11:04 p.m.
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.
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.
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.
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.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
7:46 a.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
9:08 a.m.
On 7/23/2014 8:46 AM, Pedro Igor Silva wrote:
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: keycloak-dev(a)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
10:33 a.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>
Cc: keycloak-dev(a)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(a)redhat.com>
>> To: keycloak-dev(a)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
4:58 p.m.
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-witho...
(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-witho...
(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-witho...
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(a)redhat.com>
To: "Bill Burke" <bburke(a)redhat.com>
Cc: keycloak-dev(a)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(a)redhat.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>
Cc: keycloak-dev(a)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(a)redhat.com>
>> To: keycloak-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:44 p.m.
Good work. This is precisely the type of integration with Picketlink I
was hoping for.
On 7/25/2014 5:58 PM, Pedro Igor Silva wrote:
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.
This could work for Bearer token requests, but not for the oauth
redirection protocol. Unless Picketlink has a pure-servlet
authentication SPI that we could write an adapter for.
I want to write a pure-servlet adapter and a pure-jaxrs adapter just
haven't had the time yet.
BTW, take a look at Ubefire security SPIs. It might be interesting to
get them to move it to Picketlink. Then Picketlink could have a
pure-servlet, portable authentication layer. I don't know anything
about Spring Security, but maybe this is in the same area.
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.
I don't care where the code lives. Up to you. We can maintain it so
long as you provide some unit tests. (it would go under integration/)
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9 p.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Friday, July 25, 2014 10:44:47 PM
Subject: Re: [keycloak-dev] PicketLink and KC Integration
Good work. This is precisely the type of integration with Picketlink I
was hoping for.
On 7/25/2014 5:58 PM, Pedro Igor Silva wrote:
> 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.
>
This could work for Bearer token requests, but not for the oauth
redirection protocol. Unless Picketlink has a pure-servlet
authentication SPI that we could write an adapter for.
I think we have that. Today we provide an AuthenticationFilter (which we want to review
and provide a better servlet-security support) that is based
on different authentication schemes to provided different methods of authentication.
Currently we support BASIC, DIGEST, FORM, CLIENT-CERT and TOKEN.
You can provide your own custom scheme too.
Regarding oAuth, that is one of the scenarios I testing. I think we can use oAuth
redirection considering what we have. Let's see ...
I want to write a pure-servlet adapter and a pure-jaxrs adapter just
haven't had the time yet.
BTW, take a look at Ubefire security SPIs. It might be interesting to
get them to move it to Picketlink. Then Picketlink could have a
pure-servlet, portable authentication layer. I don't know anything
about Spring Security, but maybe this is in the same area.
I'll, thanks for the heads up. And yes, PL and Spring Security are in the same area.
But as I said, we have a big TODO here:
https://gist.github.com/pedroigor/5852028
Anil and I wrote that some time ago, but you can have an idea about our plans for servlet
security.
> 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.
>
I don't care where the code lives. Up to you. We can maintain it so
long as you provide some unit tests. (it would go under integration/)
Cool. We can also support that.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:02 a.m.
On 7/25/2014 10:00 PM, Pedro Igor Silva wrote:
I'll, thanks for the heads up. And yes, PL and Spring Security
are in the same area. But as I said, we have a big TODO here:
https://gist.github.com/pedroigor/5852028
Anil and I wrote that some time ago, but you can have an idea about our plans for servlet
security.
That would be interesting if it was cross-platform and did tight
integration with each platform (i.e. AS7, EAP, Wildfly 8-9, Jetty,
Tomcat, etc...) as well with Java EE security. Then Keycloak could get
out of the adapter business. At least for Java...
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:37 a.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Saturday, July 26, 2014 10:02:15 AM
Subject: Re: [keycloak-dev] PicketLink and KC Integration
On 7/25/2014 10:00 PM, Pedro Igor Silva wrote:
> I'll, thanks for the heads up. And yes, PL and Spring Security are in the
> same area. But as I said, we have a big TODO here:
>
> https://gist.github.com/pedroigor/5852028
>
> Anil and I wrote that some time ago, but you can have an idea about our
> plans for servlet security.
>
That would be interesting if it was cross-platform and did tight
integration with each platform (i.e. AS7, EAP, Wildfly 8-9, Jetty,
Tomcat, etc...) as well with Java EE security. Then Keycloak could get
out of the adapter business. At least for Java...
Interesting. We can consider that. In theory, JASPI can help here. Problem is how it is
currently offered by those different platforms.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
4:06 a.m.
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(a)redhat.com>
To: keycloak-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
7:48 a.m.
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(a)redhat.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>
Cc: keycloak-dev(a)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(a)redhat.com>
To: keycloak-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3804
days inactive
3809
days old
11 comments
3 participants
participants (3)
-
Bill Burke -
Pedro Igor Silva -
Stian Thorgersen