6:59 a.m.
What I was hoping to be able to achieve was a pure Java adapter, with an easy to use and
well documented API. This would allow anyone to use Keycloak from anything Java. Most of
the code is there, but we can clean-up the API IMO, and also provide some examples and
documentation.
Further, we'd provide a pure Servlet adapter. As you point out it can't provide
the same level of integration as our WildFly and AS7/EAP adapters. However, providing
bespoke adapters for Tomcat, Jetty, etc. is going to be too much of an overhead, so I
don't think we should provide bespoke adapters for non Red Hat products.
For mobile could just delegate to AeroGear. Ideally, AeroGear would provide the SDKs and
documentation to use Keycloak with Android, iOS, Windows Mobile, Firefox, etc. and we
would just add references to AeroGear in our documentation and webpage.
For other programming languages (php, ruby, etc.) I'm less sure what we can achieve.
Perhaps we can delegate to existing OpenID Connect client libraries?
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Monday, 15 September, 2014 5:17:35 PM
Subject: Re: [keycloak-dev] Adapters
Much of you want is already the reality, but there are some caveats you
must know about:
* Adapters need specific integration with each app server as they need
to extract and set role mappings prior to the servlet container's roles
allowed checks. This can't be done in a filter.
* Being able to propagate the Subject between component layers
(Servlet->EJB) requires specific app server integration.
* A keycloak logout invokes on adapter's admin url to invalidate the
HTTP session. The HTTP session invalidation is app server specific.
* I don't believe you can obtain client cert information from the
servlet API which will be come important when we add client-cert support
Wildfly and JBossWeb have different integration SPIs for security, but
most of the adapter code lives in a common library whose only dependency
is Apache HTTP Client. The core adapter library has a tiny Http message
and http session mgmt facde to bridge between the two different containers.
On 9/15/2014 10:38 AM, Stian Thorgersen wrote:
> I think it would make sense to provide a plain Java adapter, as well as a
> plain Servlet adapter. Further this should be the base for all other
> adapters.
>
> +--------+ +---------+ +-----------+ +---------+
> | Tomcat | |JBoss AS | |PicketLink | | WildFly |
> | Jetty | |JBoss EAP| | | | |
> | ... | | | | | | |
> +----+---+ +---+-----+ +---+-------+ +----+----+
> | | | |
> | +---v-----+ | +----v----+
> +----->Servlet <------+ | Undertow|
> | | | |
> +----+----+ +----+----+
> | +---------+ |
> +------->Java <------------+
> | |
> +---------+
>
> The Java adapter should have minimum dependencies (maybe only
> http-client?).
>
> Don't get to hung-up with the syntax (I knocked this together in 2 min),
> but the general idea would be something like:
>
> InputStream is = new FileInputStream("keycloak.json");
>
> KeycloakOAuthClient client = KeycloakClient.createOAuth(is);
>
> // get login url
> URL loginUrl = client.createLoginUrl(redirectUri);
>
> // exchange code to token
> AccessTokenResponse response = client.getToken(code,
> clientCredentials);
>
> // refresh token
> client.refreshToken(response.getToken());
>
> We have most of the code, but what we don't is a public Java API.
> _______________________________________________
> 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