[security-dev] New SSO/OAuth2 Project

Bill Burke bburke at redhat.com
Thu Apr 18 15:38:24 EDT 2013



On 4/18/2013 11:52 AM, Bolesław Dawidowicz wrote:
> Ok, but first of all I would like to understand better where Bill is
> aiming and what does he want to cover. From the requirements it looks
> like everything tbh
>

Boleslaw.  I told Markthat I didn't want to do this without signoff from 
both Anil and *YOU*.  As Anil said, I've been working on OAuth2/REStful 
IDM for awhile now (Since September 2012) in some form or another and 
already have something being used by people. Resteasy has also had 
rudimentary OAuth1 support for years now.  But, I don't want to compete 
with another JBoss project.  To some degree, I don't want to step on any 
toes either, but I also want something usable!

It seemed to me that you guys were already extremely busy with the IDM 
API, AS8 security SPI/AP rework, and all the other WS-*/Oasis specs.  I 
saw Anil's hacked together, zero functionality IDP UI on OpenShift.  It 
was clear he was busy with other things.  You go to the Picketlink 
webpage and it looks nothing like a solution.  Links to incomplete 
projects, unreleased code, incomplete requirements documents.

What do you think should be done by this new project vs. Picketlink?  I 
thought I would build something on top of:

http://www.jboss.org/picketlink/IDM.html

Isn't that your project Boleslaw?  Your IDM project isn't a good enough 
division of labor/SPI between the two projects?  You guys are already 
doing this?  Or just planned on doing this?


> We are very interested for example to have full OAuth2 support (server
> side) in PL - even in subsystem. Better with whole SCIM implementation
> and handy REST endpoints. So if this could be provided by Bill I'm more
> then happy to benefit from his project in our identity related components.
>

SCIM is interesting for identity management, not so interesting or 
needed for auth or even app development.


> I'm also interested to learn if Bill is aiming to cover full OAuth2 spec
> in his implementation or only server side application flow. Because
> otherwise it will be hard to reuse on our side and I imagine it will be
> similar for AeroGear as well.
>

YOu need to specify what you mean by "server-side application flow 
only".  OAuth from a client perspective (thirdparty or user agent) is 
really very simple.  Its just a matter of the client of obtaining a 
token and transmitting it via a bearer token header.  The code I 
currently ship with resteasy has an auth server, oauth thirdparty, and 
user examples.  So, while I dont' cover every flow type in OAuth 
(specifically the "implicit" model as it is very insecure (see 
Facebook), I do cover the other modes.

> What are the components and services that RestEasy would aim to deliver
> What would be reusability of this work?
>

I've already spelled it out.  I want a AS plugin, an auth server, and a 
cloud service with SaaS capability.  It would be a separate project from 
Resteasy and would probably leverage it and Picketlink as needed.  Is 
there an existing IDM server project I can build off from or contribute 
to?  It is very unclear to me a) what you guys are working on b) what is 
available c) the direction of Picketlink, etc.

As for *reusability* of this work...I'm really not interested in doing 
this project just for the sake of doing it.  If there is going to be 
competing work in our BU, then, I'm not going to do this project.  Yes, 
I plan to have separate maven modules for different types of 
functionality that can be reused. i.e. components like JWT.

> If PicketLink is just internally consumed component by RestEasy aimed to
> only handle storage it doesn't sound very appealing to us.
>


The current stuff I already have in Resteasy (linked earlier) delegates 
to Picketlink's legacy LoginModule infrastructure to perform auth.  Its 
also limited because it can't get at any other metadata other than 
principal and roll mappings.  Would be cool to be able to generate more 
complex tokens, add support for OAuth scope, things like that. 
Impossible without being able to pull information from a real identity 
repository.

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


More information about the security-dev mailing list