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