[anil.saldhana]

Here is a convergence of our discussion. Correct me wherever I am wrong.

Authentication

a) JASPISecurityManager is a standalone implementation class that implements the interface called "GeneralizedAuthenticationManager" (which is ServerAuthContext and AuthenticationManager interfaces). The way an implementation gets access to this through the AuthContextFactory mechanism. This is MC friendly.

Sideeffects:
- The marker interface SubjectSecurityManager will be retired.
- No extension of ServiceMBeanSupport.

b) Since the JASPISecurityManager is a POJO friendly implementation, we are going to bring in a JMX wrapper called "JASPISecurityManagerService" (Actually can really use JaasSecurityManagerService, but lets retire him). Now since the wrapper binds the JASPISecurityManager to JNDI, there is no reason to go the AuthContextFactory way, for any service that needs authentication. Just look up the JNDI to get the securitymanager. This is what the JBossSecurityMgrRealm and the security interceptors will do.

The above two take care of the generalized authentication mechanism.

Authorization

Here is a a generic set of API that I think is suitable for an AuthorizationManager interface:

public interface AuthorizationManager
{
 //Permission can be of type WebUserDataPermission,

 //WebResourcePermission and WebRoleRefPermission
 public boolean hasPermission(Permission perm, Principal principal);

 public boolean doesUserHaveRole(String roleName);

}

This is of the assumption that the deployers have conveyed to this service the roles (both in the application domain as well as in the deployment domain) plus the authenticated subject is available via the securityassociation.

[starksm64]

a) Yes, but if this is ported to 4.0, the SubjectSecurityManager needs to stay in the branch.

b) We will have to support the AuthContextFactory approach. Our default implementation can just do the jndi lookup. Its not clear we want to go down the Permission based authorization route as the only acl representation. Its an ok starting point, but we need to talk with the other teams to get an acceptable representation.

[anil.saldhana]

public interface AuthorizationManager
{
//Permission can be of type WebUserDataPermission,

//WebResourcePermission and WebRoleRefPermission
public boolean hasPermission(Permission perm, Principal principal);

public boolean doesUserHaveRole(String roleName);

}

Its not clear we want to go down the Permission based authorization route as the only acl representation. Its an ok starting point, but we need to talk with the other teams to get an acceptable representation.

Scott, the first method of the interface takes care of all JACC users who create various permissions and check if it is valid for the provided principal(maybe the passage of the Principal is redundant as it can be obtained from the authenticated subject).

The second interface method atleast takes care of the web and the ejb layers with isUserInRole and isCallerInRole requirements.

What other teams have requirements for authorization? Portal, Federation and maybe the JCA(???)

For the record:
In the long run, ws-security from the WS layer should also make use of JSR-196. Remoting layer has good usecases for jsr-196.

[anil.saldhana]

The associated JIRA tasks are:
http://jira.jboss.com/jira/browse/JBAS-2623
http://jira.jboss.com/jira/browse/JBAS-2624

I am wondering if the authenticationcache (which is a timed cache) that sits inside the securitymanager services (JaasSecurityManagerService and JASPISecurityManagerService can also be externalized into a service of its own).

[starksm64]

The JaasSecurityManagerService already has support for externalizing the cache via an old school factory jndi mechanism. See the AuthenticationCacheJndiName attribute and cacheJndiName configuration.

It should be made independent of jndi using the injection. The direct use of jndi as a mechanism for exposing the security managers should also be aspectized such that this is not required.

[anil.saldhana]

The direct use of jndi as a mechanism for exposing the security managers should also be aspectized such that this is not required.

Can you explain a bit more on this statement, please?

The pattern of using a factory that internally may lookup a security manager via JNDI, will suffice??

[starksm64]

This is the only depenendency on jndi. Such a dependency means that the security service cannot be started before the naming service. There is not a good reason for this. Its simply the way its been since I inherritted it.

The security service can be looked up using jmx or the kernel registry in jboss5. The jndi lookup can be supported as a backward compatibility aspect, but it should be a seperate service/aspect.

[anil.saldhana]

If we remove the JNDI dependence and the establishment of a securitydomain context for securitymanagers, cache etc, it greatly simplifies the codebase.

Along these lines, I have factories to obtain AuthenticationManager (JASPI AuthContextFactory) and AuthorizationManager instances. Internally jmx based services are used.

An issue that I have seen is that the JBoss tomcat realms do not have any idea as to what securitydomain they belong to. Previously they had a preconfigured security manager bound in the java:/comp/env/security/securityMgr namespace and they could get hold of it.

But now since the realms have no idea about what security domain they belong to, I am using the contextid set on the PolicyContext by the JaccContextValve [I do remember you talking about changing the context id to be different from the war name].

FYI, JBossSecurityMgrRealm will have:

 protected AuthenticationManager getSecurityManager() throws AuthException
 {
 String contextId = PolicyContext.getContextID();
 AuthContextFactory authFactory = AuthContextFactory.getFactory();
 MessageLayer mlayer = new MessageLayer(MessageLayer.HTTP_SERVLET);
 ServerAuthConfig sConfig = null;
 try
 {
 sConfig = authFactory.getServerAuthConfig(mlayer,new URI(contextId),null);
 }
 catch (AuthException e)
 {
 log.error("getSecurityManager::" + e.getLocalizedMessage());
 }
 catch (URISyntaxException e)
 {
 log.error("getSecurityManager::" + e.getLocalizedMessage());
 }
 return (AuthenticationManager)authFactory.getAuthContext(sConfig,null);
 }

 protected AuthorizationManager getAuthorizationManager(String securityDomain)
 {
 return AuthorizationManagerFactory.getAuthorizationManager(securityDomain);
 }

and the securityDomain is obtained in the realm as:

 String contextId = PolicyContext.getContextID();

Also as agreed, I am going to externalize the cache from the current JNDI infrastructure inside the securitymanager, to a jmx based service that both the authenticationmanager and the authorizationmanager can use.

[anil.saldhana]

Also, the contextid is used because the AuthContextFactory uses it to obtain the securitydomain internally by querying the authenticationmgr and appropriately returning the authenticationmgr.

/**
 * @see AuthContextFactory#getAuthContext(ServerAuthConfig, String)
 */
 public ServerAuthContext getAuthContext(ServerAuthConfig config, String operation) throws AuthException
 {
 ServerAuthContext sc = null;
 try
 {
 if(config instanceof WebContainerServerAuthConfig)
 {
 WebContainerServerAuthConfig wconfig = (WebContainerServerAuthConfig)config;
 MBeanServer server = MBeanServerLocator.locateJBoss();
 ObjectName oname = new ObjectName("jboss.security:service=JASPISecurityManager");
 String contextId = wconfig.getContextId();
 String securityDomain = (String)server.invoke(oname,"getSecurityDomain", new Object[] {contextId}, new String[]{"java.lang.String"});;
 sc = (ServerAuthContext)server.invoke(oname,"getSecurityManager", new Object[] {securityDomain}, new String[]{"java.lang.String"});
 }
 }catch(Exception e)
 {
 log.error(e);
 log.error("Error in getAuthContext::" + e.getLocalizedMessage());
 }
 return sc;
 }

[anil.saldhana]

I have a prototype of JASPI integration with the tomcat layer checked in HEAD for form-auth.

asaldhana~/jboss-5.0/jboss-head/testsuite>ant tests-security-jaspi-unit
Buildfile: build.xml
Overriding previous definition of reference to xdoclet.task.classpath

tests-security-jaspi-unit:
 [echo] creating jaspi config
 ...
 [junit] Running org.jboss.test.web.test.JASPIFormAuthUnitTestCase
 [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 2.344 sec
....

The interface that extends the basic tomcat realm interface is called the "ExtendedRealm" interface.
http://fisheye.jboss.com/viewrep/JBoss/jboss-tomcat/src/main/org/jboss/web/tomcat/security/ExtendedRealm.java?r=1.1

A Form Authenticator that is aware of this extended interface is called as JASPIFormAuthenticator (look at lines 185-187).
http://fisheye.jboss.com/viewrep/JBoss/jboss-tomcat/src/main/org/jboss/web/tomcat/security/authenticators/JASPIFormAuthenticator.java?r=1.1

Now the realm that is injected into the container is the JBossExtendedSecurityMgrRealm.
http://fisheye.jboss.com/viewrep/JBoss/jboss-tomcat/src/main/org/jboss/web/tomcat/security/JBossExtendedSecurityMgrRealm.java?r=1.2

The prototype is available for review and comment.

The JASPISecurityManager has no auth cache currently. It needs to be added.

Had a question:
* Since I have a seperate Authorization Manager (wrapped via a jmx service), it is possible to inject various authorization providers (one based on jacc, xacml, custom etc) based on the Security Domain. So for a particular security domain, a user can define one particular authz provider. Thoughts on this(good, bad, ok?)

[gastaldi]

Excelent !! This is exactly what I was looking for !
Enabling authorization on login-config.xml is the right choice to center security-related issues per-application.