9 p.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Friday, July 25, 2014 10:44:47 PM
Subject: Re: [keycloak-dev] PicketLink and KC Integration
Good work. This is precisely the type of integration with Picketlink I
was hoping for.
On 7/25/2014 5:58 PM, Pedro Igor Silva wrote:
> Another aspect is the possibility to provide a deep integration with a
> specific IdP in order to properly manage tokens by a consumer
> application. This is specially useful when your application does not
> use KC adapter, but only keycloak.js or something else to update and
> send tokens in every single request to the server.
>
This could work for Bearer token requests, but not for the oauth
redirection protocol. Unless Picketlink has a pure-servlet
authentication SPI that we could write an adapter for.
I think we have that. Today we provide an AuthenticationFilter (which we want to review
and provide a better servlet-security support) that is based
on different authentication schemes to provided different methods of authentication.
Currently we support BASIC, DIGEST, FORM, CLIENT-CERT and TOKEN.
You can provide your own custom scheme too.
Regarding oAuth, that is one of the scenarios I testing. I think we can use oAuth
redirection considering what we have. Let's see ...
I want to write a pure-servlet adapter and a pure-jaxrs adapter just
haven't had the time yet.
BTW, take a look at Ubefire security SPIs. It might be interesting to
get them to move it to Picketlink. Then Picketlink could have a
pure-servlet, portable authentication layer. I don't know anything
about Spring Security, but maybe this is in the same area.
I'll, thanks for the heads up. And yes, PL and Spring Security are in the same area.
But as I said, we have a big TODO here:
https://gist.github.com/pedroigor/5852028
Anil and I wrote that some time ago, but you can have an idea about our plans for servlet
security.
> With that in mind, I would like to know if we can provide the KC
> related implementation from KC itself. The motivation is that in
> order to properly handle KC tokens we need some KC libraries and I
> think the best place to put this is in KC. Any change to API or
> something we get during KC build. KC users looking for PL integration
> just get it from KC OOTB.
>
I don't care where the code lives. Up to you. We can maintain it so
long as you provide some unit tests. (it would go under integration/)
Cool. We can also support that.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com