I try to explain with examples :-)
JAAS Authorization
currently in jboss we have a AllPermission grant :-(
I propose, for ejbs:
<jboss>
<enterprise-beans>
<session>
<ejb-name>SampleEJB</ejb-name>
<jndi-name>SampleJEB</jndi-name>
<security-configuration>
<authorization type="merge-with-parent">
<principal name="role1" code="org.jboss.security.RolePrincipal"/>
<permission code="org.jboss.mx.security.MBeanServerPermission"
name="invoke"/>
<!-- this is a ejb spec violations, see ejb 2.1 pag 553, I must
grant this explicitly -->
<permission code="java.io.FilePermission" name="/home/ejb-app/tmp"
actions="read,write"/>
</authorization>
</security-configuration>
</session>
</enterprise-beans>
<security-configuration>
<authorization type="override">
<principal name="role2" code="org.jboss.security.RolePrincipal"/>
<permission code="org.jboss.mx.security.MBeanServerPermission"
name="get-attribute"/>
</authorization>
</security-configuration>
</jboss>
or for a sar:
<server>
<mbean code="com.foo.service.Authorized"
name="com.foo:name=authorized">
<security-configuration>
<authorization type="override">
<permission code="java.io.FilePermission" name="/tmp"
actions="write"/>
</authorization>
</security-configuration>
</mbean>
</server>
we must have a similar configuration for connector (spec requirement)
we can have a similar configuration form client app
JAAS Authentication (this part can be simulated with the existing
architecture in jboss, I propose a semplification and being able to
associate the security domain to ejb and not to the application server and
so on)
currently in jboss.xml we have:
<jboss>
<container-configurations>
<container-configuration extends="Standard Stateless SessionBean">
<container-name>Domain Stateless SessionBean</container-name>
<security-domain>java:/jaas/security-domain</security-domain>
</container-configuration>
</container-configurations>
</jboss>
this make a LinkRef from java:comp/env/security/* to
java:/jaas/security-domain/*
I propose:
<jboss>
<enterprise-beans>
<entity>
<ejb-name>SecureEJB</ejb-name>
<jndi-name>SecureJEB</jndi-name>
<security-configuration>
<authentication>
<login-module
code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required"/>
</authentication>
</security-configuration>
</entity>
</jboss>
this make a new instance of AuthenticationManager + RealmMapping in
java:comp/env/security-domain/*
or for a sar (!!!):
<server>
<mbean code="com.foo.AuthenticatedMBean"
name="com.foo:name=authenticated">
<security-configuration>
<authentication type="override">
<login-module
code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required"/>
</authentication>
</security-configuration>
</mbean>
</server>
and so on...
I hope that these examples are clearer than what I wanted to say in my ugly
English :-)
These proposals are partially independent from the necessity to introduce
JACC in jboss, we can start to code :-)))
Claudio
> -----Original Message-----
> From: Scott M Stark [SMTP:[EMAIL PROTECTED]
> Sent: Thursday, November 13, 2003 8:06 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] 4.0 Roadmap
>
> The big change in the current JBoss security layer in terms of
> MBeans and interfaces is that the extension point for security
> needs to be based on the JACC apis as much as possible with
> any extensions we deem neccessary. Currently the contract is
> just the AuthenticationManager, RealmMapping.
>
> You'll have to clarify the notion of association with the j2ee
> component modules.
>
> --
> xxxxxxxxxxxxxxxxxxxxxxxx
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
> xxxxxxxxxxxxxxxxxxxxxxxx
>
> Vesco Claudio wrote:
>
> > Hi alls!
> >
> > Sorry for my english... :-)
> >
> > I am also interested in working in the JACC area.
> >
> > I propose this roadmap:
> >
> > 1) implementing the required javax.security.jacc.* classes/interfaces in
> > j2ee module.
> > this javax.security.jacc.* does not depend on jboss
> >
> > 2) implementing a MBean that manage jacc
> >
> > 3) [the dirty work] rewrite/restyle the jboss security system :-)
> >
> >
> > For point 3, I have in mind this proposal:
> >
> > - we need j2sdk 1.4 then we can remove deprecated classes
> >
> > - jaas authentication with
> javax.security.auth.conf.AppConfigurationEntry[]
> > associated to single module (ejb, ejbjar, ear, web, sar etc) with
> default to
> > parent module.
> > in this way a ejb is self contained and we don't need to modify the
> global
> > configuration
> >
> > - jaas authorization associated to single module with merging to parent
> > module (so we can run ejb/sar & co in a sandbox)
> >
> > Claudio
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> JBoss-Development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
