[security-dev] New SSO/OAuth2 Project

Anil Saldhana Anil.Saldhana at redhat.com
Thu Apr 18 16:05:32 EDT 2013


Bill - right now based on my priorities, I am not planning to build a 
SaaS authentication/SSO service which primarily
will be REST based. That is why I am ok with you proceeding to build a 
Saas authentication/SSO service.

PicketLink2 does have an IDP web app. We will probably have that too for 
SAML support. The IDP only does SAML11/SAML2
at the moment.

On 04/18/2013 02:38 PM, Bill Burke wrote:
>
> 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.
>



More information about the security-dev mailing list