----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Tuesday, 16 September, 2014 3:10:20 PM
Subject: Re: [keycloak-dev] Adapters
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.
Who is going to implement and maintain all those adapters? I just can't see us having
enough man-power to do that. Especially if we start venturing into non-java land.
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.
What parts of the token are non-standard other than the roles? OAuth2 has a standard param
for roles 'scope', couldn't we use that?
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(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
>>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com