[jboss-as7-dev] Security Domain Config: JASPI vs Classic?

[Darran Lofthouse]

I am just in the middle of writing up some other thoughts regarding how 
we are going to work with Remoting performing authentication as 
connections to the server are established especially when the connection 
is going to be used to access security subsystem secured resources.

So far we are really at the point where we need some form of 
CallbackHandler provider that can return callback handlers with 
different capabilities.

I see in your suggestion you mention a "getSupportedInterfaces()" method 
- for domain management this is exactly what we have today, the SASL 
mechanism offered to the client is based on the capabilities of the 
CallbackHandler e.g. we offer Digest if we can obtain the password, 
Plain if we can only verify the password.

For the loading of additional identity information for the authenticated 
user such as role information I believe JAAS still has a place and JAAS 
as a complete authentication approach works with mechanisms such as 
Plain where we have a password we want to validate but I also agree we 
have moved beyond the point where we can assume we always have 
everything in the incoming request to pass to JAAS to verify in isolation.

For Remoting / SASL at the moment the mechanisms we potentially have are 
Anonymous, Plain, Digest, GSSAPI, External - JAAS works well for Plain, 
is not too bad for External and doesn't really apply to Anonymous but 
for things such as Digest and GSSAPI it becomes quite contrived.

Regards,
Darran Lofthouse.



On 10/04/2011 03:29 PM, Bill Burke wrote:
> Do think maybe that my previous idea of having a security domain define
>
> * How different types of requests are authenticated: for Web (Basic,
> Client-Cert, custom), for EJB (password, message signing, custom), etc...
> * security metadata
> * security config
>
> Is relevant here?
>
> Then the AS7 config could look like something like this:
>
> <security-domain name="jmx-console">
>     <server-auth-modules>
>       <auth-module .../>
>       <auth-module-stack .../>
>     </server-auth-modules>
>
>     <callback-handers>
>        <callback-handler class="org.jboss.PasswordPropertyFile>
>           <attribute name="user-file">user.properites</attribute>
>        </callback-hander>
>     </callback-handlers>
> </security-domain>
>
> IMO, this is much much more sane than the whole Login Module mess we
> currently have.  Something like this would really solve some of the
> integration problems.
>
> Callback handlers would give you a "storage" abstraction driven by any
> arbitrary interface.  We'd implement a different SPI for it
>
> interface JBossCallbackHandler extends CallbackHandler {
>
>      Class<? extends Callback>[] getSupportedInterfaces();
>
> }
>
>
>
>
>
> On 10/3/11 11:38 AM, Anil Saldhana wrote:
>> The JASPI config is an on demand configuration that provides
>> capabilities to configure
>> authentication config providers (similar to the JAAS login modules).  If
>> the jaspi modules
>> want to delegate the core authentication aspects to the jaas login
>> modules, they do
>> it via the login config bridge name.
>>
>> On 10/03/2011 09:16 AM, Stefan Guilhen wrote:
>>> I forgot to comment about this reference in the other e-mail. There's no
>>> authorization ->    authentication reference, its all about authentication.
>>> This reference is just a way to tell the jaspi authenticator which JAAS
>>> config it should use to delegate the authentication to once the security
>>> attributes have been established.
>>>
>>> 10/03/2011 10:45 AM, Jason T. Greene wrote:
>>>> Right now I'm preserving the existing layout of two separate sections, I
>>>> was just wondering if there was any benefit I was missing. For example,
>>>> is the authorization ->     authentication reference a problem for classic auth?
>>>>
>>>> On 10/3/11 8:43 AM, Marcus Moyses wrote:
>>>>> Do you plan to make those attributes optional or mandatory? I guess if
>>>>> they were optional there would be no problem to merge the
>>>>> configurations. Making them required would add some confusion to
>>>>> customers I guess.
>>>>> Anyway, Stefan implemented the JASPI integration last week and was about
>>>>> to send a pull request so you might want to check with him so your
>>>>> commits don't conflict.
>>>>>
>>>>> On 10/03/2011 02:28 AM, Jason T. Greene wrote:
>>>>>> Right now the security domain configuration has separate sections for
>>>>>> JASPI and Classic/Basic authentication. The only difference seems to
>>>>>> be that JASPI authentication requires an additional name field per
>>>>>> module, and JASPI authorization requires an additional login-module
>>>>>> reference. So essentially its a superset.
>>>>>>
>>>>>> Is there a reason we would not want to just switch to the JASPI style
>>>>>> of specification, and eliminate the classic style. A name per login
>>>>>> module seems useful anyway.
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>