[keycloak-dev] Adapters

[Bill Burke]

I disagree.  We need to expand our adapters everywhere.  Tomcat, Jetty, 
node.js, Rails, etc.  Pure servlet, pure Java, pure openid connect 
libraries are only a fallback plan.

Also, we can't rely on third-party libs for the reasons I mentioned 
below.  Bearer auth is also implementation dependent because tokens are 
opaque in oauth/openid specs.  So any rest service is going to have to 
understand our token format and extract and validate the JWS.



On 9/16/2014 7:59 AM, Stian Thorgersen wrote:
> 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 at redhat.com>
>> To: keycloak-dev at 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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com