----- 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:54:50 PM
Subject: Re: [keycloak-dev] Adapters
On 9/16/2014 9:15 AM, Stian Thorgersen wrote:
>
>
> ----- 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.
>
You're starting to sound like a whiny product manager instead of
somebody that wants a successful keycloak project. :)
You're wrong, I'm a whiny developer ;)
I give in, but we'll have to automate testing of all these adapters. I'm going to
sink into depression if I have to manually test all of this for every release...
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.
I thought there was a standard 'scope' param in the jwt, but looks like I'm
wrong.
I might need to brush up on these specs, and now I'm also going to have to read about
SAML
>>
>>
>>
>> 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
>>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com