[keycloak-dev] Adapters
Bill Burke
bburke at redhat.com
Tue Sep 16 09:54:50 EDT 2014
On 9/16/2014 9:15 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at 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.
>
You're starting to sound like a whiny product manager instead of
somebody that wants a successful keycloak project. :)
We're just going to have to do it. Having an IAM that only works well
in a JBoss ecosystem is unacceptable, IMO. LIke I said, most of the
logic in Java is in a common core adapter library already. People are
already demanding Tomcat support. Netty won't be far behind.
These integration requirements are just going to become worse and worse.
We just have to deal with it if we want to succeed.
>>
>> 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?
>
Token formats are not standardized at all, not even around JWT. Go read
oauth2/openid connect. Access tokens (and codes) are completely opaque.
I even had a talk with somebody on Oauth-WG about this as I wanted to
standardize our CORS stuff. He told me that nobody will ever agree on
the token format. At least not at this point in time. Also scope has
nothing to do with roles. Scope doesn't solve bearer auth token
validation problem.
>>
>>
>>
>> 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
>>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
More information about the keycloak-dev
mailing list