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