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

[Brian Stansberry]

It seems very much equivalent to system properties.

With system properties:

1) We support passing them via a cmd line switch

-D
-P

2) For a standalone server, we also have the <system-properties> element 
in standalone.xml. But if set that way the property is actually set a 
bit later than if passed via -D.

3) For servers in a managed domain, <system-properties> elements at the 
domain, host, server-group or server levels in domain.xml or host.xml 
end up driving what gets passed to the server.

A full solution would parallel that. That's a lot of work though, 
particularly for the managed domain case. The good news is it would 
basically just be duplicating what is already there, substituting 
"security" for "system".

I'm sorely tempted to say "just do it part way; e.g. for a managed 
domain only allow the setting at the host.xml server level." But we 
should be sure we'd stick with that resolution. It will be quite a bit 
less work to semi-blindly recreate everything we already have for system 
properties than to do them kinda-similar but not the same, debate it for 
a while and then change our minds and do the full job.

On 10/3/11 6:53 PM, Anil Saldhana wrote:
> Jason,
> should we enable Security.setProperty at the host/server level? Maybe there is some element where we can add this additional behavior.
>
> ----
> sent on a train
>
> On Oct 3, 2011, at 10:38 AM, Anil Saldhana<Anil.Saldhana at redhat.com>  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
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat