Security Domain Config: JASPI vs Classic?

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Security Domain Config: JASPI vs Classic?

jtgreene
Administrator
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.
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Security Domain Config: JASPI vs Classic?

Marcus Moyses
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.

--
Marcus Moyses
Senior JBoss Core Developer
JBoss by Red Hat

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Security Domain Config: JASPI vs Classic?

jtgreene
Administrator
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.
>


--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Security Domain Config: JASPI vs Classic?

Stefan Guilhen
In reply to this post by Marcus Moyses
Anil has created the original jaspi configuration, so he can provide
further details in case I miss anything here.

The JASPI config consists of two sections: one identifies the module
that is capable of handling the request message and extract security
attributes from this message, and one section that identifies the set of
modules that will handle the JAAS authentication once the attributes
have been obtained.

An example of the former is the HTTPBasicServerAuthModule - this module
gets the HTTPServletRequest from the MessageInfo and searches for the
username and password in the proper HTTP headers. Once this data is
retrieved, this module delegates the real authentication to the set of
modules that have been configured in the login-module-stack. Something
like this:

<authentication-jaspi>
<login-module-stack name="myConfig">
<login-module name="UsersRoles"....>
        ..
</login-module>
</login-module-stack>
<auth-module code="org.jboss....HTTPBasicServerAuthModule"
login-module-stack-ref="myConfig"/>
</authentication-jaspi>

In a sense the login-module-stack is just a wrapper with a name for a
set of modules and we surely could have it for the classic
authentication modules too, but I think this would just unnecessarily
add an extra element to every security domain config.

On 10/03/2011 10: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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Security Domain Config: JASPI vs Classic?

Stefan Guilhen
In reply to this post by jtgreene
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Security Domain Config: JASPI vs Classic?

Anil Saldhana
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Security Domain Config: JASPI vs Classic?

Anil Saldhana-2
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 <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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<[hidden email]>  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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Security Domain Config: JASPI vs Classic?

Bill Burke
In reply to this post by Anil Saldhana
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Security Domain Config: JASPI vs Classic?

Bill Burke


On 10/4/11 10:29 AM, Bill Burke wrote:

> <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>
>

Then, your web.xml could look like this:

     <login-config>
         <auth-method>JBOSS</auth-method>
         <realm-name>jmx-console</realm-name>
     </login-config>

And you don't have to do any real configuration from an application
perspective if there are already built in security domains that support
what you want to do.

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Security Domain Config: JASPI vs Classic?

Darran Lofthouse
In reply to this post by Bill Burke
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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Security Domain Config: JASPI vs Classic?

Darran Lofthouse
In reply to this post by Bill Burke


On 10/04/2011 03:44 PM, Bill Burke wrote:

>
> Then, your web.xml could look like this:
>
>       <login-config>
>           <auth-method>JBOSS</auth-method>
>           <realm-name>jmx-console</realm-name>
>       </login-config>
>
> And you don't have to do any real configuration from an application
> perspective if there are already built in security domains that support
> what you want to do.
>

I have a similar issue to some of your concerns to solve for JBoss
Remoting and inserting the 'Authenticator' during deployment has been
suggested - if we pick out the <realm-name> specified here an
authenticator based on the capabilities of the realm can be inserted
although you may still want app specific config when deciding between
say BASIC and FORM auth.
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Security Domain Config: JASPI vs Classic?

Darran Lofthouse


On 10/04/2011 03:57 PM, Darran Lofthouse wrote:

>
>
> On 10/04/2011 03:44 PM, Bill Burke wrote:
>>
>> Then, your web.xml could look like this:
>>
>>        <login-config>
>>            <auth-method>JBOSS</auth-method>
>>            <realm-name>jmx-console</realm-name>
>>        </login-config>
>>
>> And you don't have to do any real configuration from an application
>> perspective if there are already built in security domains that support
>> what you want to do.
>>
>
> I have a similar issue to some of your concerns to solve for JBoss
> Remoting and inserting the 'Authenticator' during deployment has been
> suggested - if we pick out the<realm-name>  specified here an
> authenticator based on the capabilities of the realm can be inserted
> although you may still want app specific config when deciding between
> say BASIC and FORM auth.

Sorry that should have been 'JBoss Negotiation' not Remoting.

> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Security Domain Config: JASPI vs Classic?

Bill Burke
In reply to this post by Darran Lofthouse


On 10/4/11 10:52 AM, Darran Lofthouse wrote:
> 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.
>

What Java EE SPI is there for authorization?  Is there even one?  In
looking at our code, it just looks we just decided that our LoginModules
are responsible for adding role information.

In the architecture I proposed, we just had another callback interface:

public interface RoleSetCallback {

    Principal getPrincipal();
    Set<Group> getRoleSet();
    void setRoleSet(Set<Group> set);
}

And a handler can decide whether or not it supports that interface.

Another interface we could add for AuthModules is a required callbacks
method:

interface RequiredCallbackInterfaces {

    Class<? extends Callback> getRequiredInterfaces();

}

Then we could do some checking at deployment time to catch the case
where an AuthModule needs a callback interface that isn't provided by
the security domain.


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Security Domain Config: JASPI vs Classic?

Darran Lofthouse
In reply to this post by Bill Burke
On 10/04/2011 03:29 PM, Bill Burke wrote:
> Callback handlers would give you a "storage" abstraction driven by any
> arbitrary interface.  We'd implement a different SPI for it

One thing this does change is that the location of any caching based on
the authentication needs to be moved to a different location and in a
different context.

In the context of JAAS as we have a username and credential these are
cached and if the same pair are encountered again the details in the
cache can be used - once we switch to different mechanisms we are no
longer sure we have either of these values so caching at the point we
access the storage starts to become the requirement.

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Security Domain Config: JASPI vs Classic?

Bill Burke
In reply to this post by Darran Lofthouse


On 10/4/11 10:57 AM, Darran Lofthouse wrote:

>
>
> On 10/04/2011 03:44 PM, Bill Burke wrote:
>>
>> Then, your web.xml could look like this:
>>
>>        <login-config>
>>            <auth-method>JBOSS</auth-method>
>>            <realm-name>jmx-console</realm-name>
>>        </login-config>
>>
>> And you don't have to do any real configuration from an application
>> perspective if there are already built in security domains that support
>> what you want to do.
>>
>
> I have a similar issue to some of your concerns to solve for JBoss
> Remoting and inserting the 'Authenticator' during deployment has been
> suggested - if we pick out the<realm-name>  specified here an
> authenticator based on the capabilities of the realm can be inserted
> although you may still want app specific config when deciding between
> say BASIC and FORM auth.


So, it could also be:

<login-config>
    <auth-method>Basic</auth-method>
    <realm-name>jmx-console</realm-name>
</login-config>

Then, we write a AuthModule that looks at the HttpServletRequest's
authtype, and decides what to delegate to.

So, maybe instead of a JBOSS auth-method, it could be a DEFAULT
auth-method.  That way a security domain can provide a default mechanism
for web security, and allow the user to override this default within
web.xml.

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Security Domain Config: JASPI vs Classic?

Darran Lofthouse
In reply to this post by Bill Burke
On 10/04/2011 04:11 PM, Bill Burke wrote:

>
>
> On 10/4/11 10:52 AM, Darran Lofthouse wrote:
>> 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.
>>
>
> What Java EE SPI is there for authorization?  Is there even one?  In
> looking at our code, it just looks we just decided that our LoginModules
> are responsible for adding role information.
>
> In the architecture I proposed, we just had another callback interface:

For me the bigger problem I have encountered is on the authentication
side rather than the loading the additional identity side but I see
where you are coming from.

I think one requirement will be backwards compatibility where users have
invested in using LoginModules - but I suppose we could always supply
handler implementations ourselves to delegate to JAAS definitions where
those are still needed.

> public interface RoleSetCallback {
>
>      Principal getPrincipal();
>      Set<Group>  getRoleSet();
>      void setRoleSet(Set<Group>  set);
> }
>
> And a handler can decide whether or not it supports that interface.
>
> Another interface we could add for AuthModules is a required callbacks
> method:
>
> interface RequiredCallbackInterfaces {
>
>      Class<? extends Callback>  getRequiredInterfaces();
>
> }
>
> Then we could do some checking at deployment time to catch the case
> where an AuthModule needs a callback interface that isn't provided by
> the security domain.
>
>
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Security Domain Config: JASPI vs Classic?

Bill Burke
In reply to this post by Darran Lofthouse


On 10/4/11 11:13 AM, Darran Lofthouse wrote:
> On 10/04/2011 03:29 PM, Bill Burke wrote:
>> Callback handlers would give you a "storage" abstraction driven by any
>> arbitrary interface.  We'd implement a different SPI for it
>
> One thing this does change is that the location of any caching based on
> the authentication needs to be moved to a different location and in a
> different context.
>

Ya, the whole caching mechanism of JBoss security APIs are built on the
premise that LoginModules are stateless.  This goes to the point I've
made in the past that if you're building your code on top of a flawed
architecture you're going to have flawed code no matter how good of an
engineer you are.  Its time to redefine the problem.

In the API/SPI i'm proposing CallbackHandlers are stateful and thus can
decide whether or not to cache information.

For example, it doesn't make sense to reload the user.properties file,
for every single new user (which I believe our code actually does).
Just load it up once and cache it within memory. For LDAP integration,
it does make sense to cache individual user/password combos.  An HTTP
based IDP could use Cache-Control protocol to tell the IDP's callback
handler how to cache.

So the caching mechansim really depends on the "security storage
mechanism".  The CallbackHandler interface and config I'm proposing
totally abstracts this out.

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Security Domain Config: JASPI vs Classic?

Anil Saldhana
Jaas framework was created before EE adopted it. It is supposed to be a
stateless model.

CBH are stateful.  The authentication cache in the JBoss security
subsystem caches entries at the security domain level. There is no need
to go to the jaas framework every time you need to authenticate an user.
If the cache is missed, that is when you invoke the stateless jaas
framework with a stateful cbh.  After successful auth, cache is updated.

Why would I cache a properties data?  Each time I want to add an user to
the props file, I have to bounce the server? Also in regular usage of
JBoss apps, we do not recommend the users/roles props security.

On 10/04/2011 10:42 AM, Bill Burke wrote:

> On 10/4/11 11:13 AM, Darran Lofthouse wrote:
>> On 10/04/2011 03:29 PM, Bill Burke wrote:
>>> Callback handlers would give you a "storage" abstraction driven by any
>>> arbitrary interface.  We'd implement a different SPI for it
>> One thing this does change is that the location of any caching based on
>> the authentication needs to be moved to a different location and in a
>> different context.
>>
> Ya, the whole caching mechanism of JBoss security APIs are built on the
> premise that LoginModules are stateless.  This goes to the point I've
> made in the past that if you're building your code on top of a flawed
> architecture you're going to have flawed code no matter how good of an
> engineer you are.  Its time to redefine the problem.
>
> In the API/SPI i'm proposing CallbackHandlers are stateful and thus can
> decide whether or not to cache information.
>
> For example, it doesn't make sense to reload the user.properties file,
> for every single new user (which I believe our code actually does).
> Just load it up once and cache it within memory. For LDAP integration,
> it does make sense to cache individual user/password combos.  An HTTP
> based IDP could use Cache-Control protocol to tell the IDP's callback
> handler how to cache.
>
> So the caching mechansim really depends on the "security storage
> mechanism".  The CallbackHandler interface and config I'm proposing
> totally abstracts this out.
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Security Domain Config: JASPI vs Classic?

Darran Lofthouse
No CallbackHandlers don't need to be stateful, they do tend to require
some form of access to a backing store but there is no need for the
actual state to be held within the CallbackHandler - the CallbackHandler
is just a proxy to this store.

Saying that picking up changes to a properties file would require a
server reboot is like saying picking up a users changed password or
roles from the DB after they have connected also requires a reboot.
There are various options to pick up a modified properties file without
restarting the server.

Regards,
Darran Lofthouse.


On 10/07/2011 05:18 AM, Anil Saldhana wrote:

> Jaas framework was created before EE adopted it. It is supposed to be a
> stateless model.
>
> CBH are stateful.  The authentication cache in the JBoss security
> subsystem caches entries at the security domain level. There is no need
> to go to the jaas framework every time you need to authenticate an user.
> If the cache is missed, that is when you invoke the stateless jaas
> framework with a stateful cbh.  After successful auth, cache is updated.
>
> Why would I cache a properties data?  Each time I want to add an user to
> the props file, I have to bounce the server? Also in regular usage of
> JBoss apps, we do not recommend the users/roles props security.
>
> On 10/04/2011 10:42 AM, Bill Burke wrote:
>> On 10/4/11 11:13 AM, Darran Lofthouse wrote:
>>> On 10/04/2011 03:29 PM, Bill Burke wrote:
>>>> Callback handlers would give you a "storage" abstraction driven by any
>>>> arbitrary interface.  We'd implement a different SPI for it
>>> One thing this does change is that the location of any caching based on
>>> the authentication needs to be moved to a different location and in a
>>> different context.
>>>
>> Ya, the whole caching mechanism of JBoss security APIs are built on the
>> premise that LoginModules are stateless.  This goes to the point I've
>> made in the past that if you're building your code on top of a flawed
>> architecture you're going to have flawed code no matter how good of an
>> engineer you are.  Its time to redefine the problem.
>>
>> In the API/SPI i'm proposing CallbackHandlers are stateful and thus can
>> decide whether or not to cache information.
>>
>> For example, it doesn't make sense to reload the user.properties file,
>> for every single new user (which I believe our code actually does).
>> Just load it up once and cache it within memory. For LDAP integration,
>> it does make sense to cache individual user/password combos.  An HTTP
>> based IDP could use Cache-Control protocol to tell the IDP's callback
>> handler how to cache.
>>
>> So the caching mechansim really depends on the "security storage
>> mechanism".  The CallbackHandler interface and config I'm proposing
>> totally abstracts this out.
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
12