[jboss-as7-dev] security APIs/SPIs really need a redesign

[Bill Burke]

On 9/22/11 7:12 PM, Anil Saldhana wrote:
> On 09/22/2011 05:56 PM, Bill Burke wrote:
>> On 9/22/11 5:46 PM, David M. Lloyd wrote:
>>> I'm going to put on my Bill hat here and say, "JSR 196 is crap".
>>>
>> Its not just JSR196.  SAML is crap. XACML is crap.  Its horrible
>> horrible stuff.  The only reason we should implement it is to integrate
>> with other vendor's products.
> I am not preaching JSR 196 here. Because of EE6, my team has to
> implement it for AS7.1.  I don't magically get hours to figure out
> abstract uber APIs and slowly plug in the EE specs.
>
> That way, security is a mess.  Too bad, you don't get a call when there
> is a major
> issue with some security mechanism that was put in some weird corner of
> the JBoss ecosystem.
>

We're all busy.  We all have our own projects to support, maintain, and 
specs we have to be on committees for and implement.  It would be nice 
if I could just implement and integrate what I have to do on top of a 
usable security SPI and configuration model.  But, unforunately, I have 
to spend time creating an "uber" API thats pretty much been promised and 
undelivered since like 2005.

>> Also plugging in your own authentication mechanism in AS7 is crap too,
>> specially, modules are a mess.  Unless you fixed some things in the last
>> month.  But thats another conversation I want to have.
>>
> Rather than just complaining, please provide feedback on what gives you
> a heartburn. Suggest alternatives.  It is not like I have a telepathic
> hat to just wear and understand you.

Maybe you just didn't read my email at all.  I'm trying to map out what 
exactly the needs are (generic storage, stateful login modules, walking 
through hoops to interact with security domain, etc.).  I started to 
suggest some things that could be done.

I've already "written a Tomcat Authenticator".  Although I was able to 
get something to work, I encountered integration problems which are a 
real pain.  This is the whole reason I'm writing this email.  I know 
what the issues are, and I know what issues I'm going to encounter when 
I integrate more of the work I'm doing.

As it stands, your own work (IDP, SAML, etc.) could greatly benefit from 
a rework of the security SPIs.  Users currently have to do a crazy 
amount of configuration to get any piece of Picketlink to work.  We 
really need to think how this all maps together, security protocols, 
security metadata, configuration, security management, and security 
deployment.  YOu have a load of user experience in dealing with what 
various customers and users want us to support.  If you are too busy to 
think about these things, how about about sharing a little of this 
knowledge so that others can pick up the ball and run with it?


>>> I've been saying this exact thing for over a year now.  And the response
>>> has ever been "we'll have a call, we'll talk about it, we'll gather
>>> requirements, let's write an agenda, get some minutes, talk talk talk talk".
>>>
>> Yup.  I can't wait any longer.  Too many of our users want our OAuth
>> work integrated.  THere's a whole story around security, web-apps, and
>> REST I'm trying to putting together as well.  The thing is we also need
>> some *real* management on this stuff as well.
>>
> For your kind information, OAuth spec is not even final. I think they
> are at Draft 21 and hopefully in this millennium, they will finish the
> spec.  Same goes with OpenID also. OpenID schema types refer to
> www.axschema.org and that domain does not even exist.
>

FYI, OAUTH and OpenID 1.x have been final and deployed for years.  At 
this point, I could care less about OAuth 2.0 as none of our users are 
currently asking for it.

Bill

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