From: <ani...@jb...> - 2006-06-29 19:10:24
|
Scott, could you give a glance at the following combination of module behavior and assert that the results derived are correct. | /** | * Test the AuthorizationModules combination behavior | */ | public void testCombinationBehavior() throws Exception | { | assertNotNull("PolicyConfig != null", policyConfig); | | int result = getResult("required-deny-sufficient-permit-policy"); | assertTrue("DENY?", AuthorizationContext.DENY == result); | | result = getResult("required-permit-sufficient-deny-policy"); | assertTrue("PERMIT?", AuthorizationContext.PERMIT == result); | | result = getResult("required-permit-required-deny-policy"); | assertTrue("DENY?", AuthorizationContext.DENY == result); | | result = getResult("required-permit-required-permit-policy"); | assertTrue("PERMIT?", AuthorizationContext.PERMIT == result); | | result = getResult("required-permit-required-permit-sufficient-deny-policy"); | assertTrue("PERMIT?", AuthorizationContext.PERMIT == result); | | result = getResult("required-permit-required-permit-requisite-deny-policy"); | assertTrue("PERMIT?", AuthorizationContext.PERMIT == result); | | result = getResult("required-permit-required-permit-optional-deny-policy"); | assertTrue("PERMIT?", AuthorizationContext.PERMIT == result) | | result = getResult("required-permit-required-deny-requisite-permit-policy"); | assertTrue("DENY?", AuthorizationContext.DENY == result); | | result = getResult("requisite-permit-requisite-permit-sufficient-deny-policy"); | assertTrue("PERMIT?", AuthorizationContext.PERMIT == result); | } | The combination of the module control flag can be derived from the name. For example: | <jbsx:application-policy name="requisite-permit-requisite-permit-sufficient-deny-policy"> | <jbsx:authorization> | <jbsx:policy-module code="org.jboss.security.authorization.modules.AllPermitAuthorizationModule" flag="requisite" /> | <jbsx:policy-module code="org.jboss.security.authorization.modules.AllPermitAuthorizationModule" flag="requisite" /> | <jbsx:policy-module code="org.jboss.security.authorization.modules.AllDenyAuthorizationModule" flag="sufficient" /> | </jbsx:authorization> | </jbsx:application-policy> | Here two modules (requisite) permit and one module(sufficient) denies. The overall decision should be PERMIT. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954485#3954485 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954485 |
From: <sco...@jb...> - 2006-06-29 20:07:04
|
For reference, the jaas definitions of the control flag: anonymous wrote : | 1) Required - The LoginModule is required to succeed. | If it succeeds or fails, authentication still continues | to proceed down the LoginModule list. | | 2) Requisite - The LoginModule is required to succeed. | If it succeeds, authentication continues down the | LoginModule list. If it fails, | control immediately returns to the application | (authentication does not proceed down the | LoginModule list). | | 3) Sufficient - The LoginModule is not required to | succeed. If it does succeed, control immediately | returns to the application (authentication does not | proceed down the LoginModule list). | If it fails, authentication continues down the | LoginModule list. | | 4) Optional - The LoginModule is not required to | succeed. If it succeeds or fails, | authentication still continues to proceed down the | LoginModule list. | Those tests results look correct. We need to test with sufficient at the start: | result = getResult("sufficient-permit-required-deny-policy"); | assertTrue("PERMIT?", AuthorizationContext.PERMIT == result); | result = getResult("sufficient-permit-sufficient-deny-policy"); | assertTrue("PERMIT?", AuthorizationContext.PERMIT == result); | result = getResult("optional-deny-sufficient-permit-required-deny-policy"); | assertTrue("PERMIT?", AuthorizationContext.PERMIT == result); | and that if nothing deterministically succeeds that we deny: | result = getResult("sufficient-deny-optional-deny-policy"); | assertTrue("DENY?", AuthorizationContext.DENY == result); | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954501#3954501 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954501 |
From: <ani...@jb...> - 2006-06-29 21:06:07
|
This has been added to the testcase that drove the culmination of this important JIRA feature request: http://jira.jboss.com/jira/browse/JBAS-3324 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954511#3954511 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954511 |
From: <ani...@jb...> - 2006-07-10 15:04:58
|
For the web layer, currently we have multiple JBoss realms namely JBossSecurityMgrRealm, JaccAuthorizationRealm (maybe more in future??) that have a variance in how they do authorization only. I would like to unify these realms into a single realm called as JBossRealm in which the authorization decisions for (hasResourcePermission, hasRole and hasUserDataPermission) will be delegated to the authorization framework(Authorization Modules that do default web behavior, jacc behavior, xacml behavior or custom authz behavior will drive the decision). To this end, I am planning to define a separate security domain for the realm (not to mix with the application defined realm). The authentication process still happens based on the app specified security domain, via the security manager obtained through the jndi binding. This separate security domain will have the authorization module that defines the default tomcat authorization logic (replacable with a module that does jacc). Questions: 1) Any issues in unification of the realm? 2) Will the separate security domain confuse the user? If not, we will have to force them to add the default web authorization module to their security domain. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3956614#3956614 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3956614 |