issrg.test.isSufficient
Class TestIt

java.lang.Object
  issrg.test.isSufficient.TestIt

public class TestIt
extends java.lang.Object

Author:

anhnt This program tests the isSufficient method of the issrg.pba.rbac.xmlpolicy.DefaultRuleComparator class. The issue is that when we constrain an assertion (of a holder) with the set of valid RARs of the issuer of the assertion (either a role or a RAR), each valid RAR of the issuer could create a valid role or a valid RAR for the holder, and a set of valid RARs of the issuer could create a set of valid roles or a set of valid RARs for the holder. Note that at the current implementation, one credential issued by the issuer can only be supported by one credential of the issuer. We have not combined several credentials of the issuer to issue one credential to the subordinate. The valid RARs of the issuer are chosen in the following order (see AllocationPolicy class): the ones in the policy (if the issuer has) and then the ones come from the issuer's credentials. We finish the validation process until we get a valid holder's role (or a valid holder's RAR) which is "good enough". We do not try to use all the valid RARs of the issuer to validate the assertion nor compare the set of results. The reason for this is the performance (speed of the validation process). So, what is "good enough"? It totally depends on the application and the implementation of the isSufficient method. In our implementation prototype, a valid RAR of the issuer is "good enough" for an assertion if the result of the constraining process is not empty (the assertion is constrained to a role or a RAR). As the consequence, the constrained role (or RAR) then is "good enough". There are two independent tests in this program. They use the same policy (policy.ace). In this policy, there are two independent roles (Admin and Staff), six entities (SOA, DIS, aa1, aa2, aa3, aa4). Who holds the Admin role can "open the door", otherwise he can not. SOA is the one who creates the policy. SOA and DIS are the trusted issuers specified in the policy. In the policy, SOA can assign the Admin role to people and DIS can assign the Staff role to people. Note that there is only one subject domain specified in the policy, it means that if someone issued the Admin role to DIS then DIS can issue the Admin role to other entities (DIS has one RAR specified in the policy and may has other RARs from its credentials). In these tests, the validity period of the credentials is the same and is very long (31 March, 2000 to 31 March, 2020). The delegation depth of them are similar: unlimited. Only roles are concerned in these tests. All credentials are issued by using the ACM tool.

Constructor Summary

TestIt(java.lang.String[] args)
Creates a new instance of TestIt.

Method Summary

void	doTest1(java.lang.String[] args) In this test, DIS has the Admin role issued by SOA, aa1 has the Admin role issued by DIS and aa2 has the Staff role issued by DIS.
void	doTest2(java.lang.String[] args) In this test, aa1 has the Admin role issued by SOA, DIS has the Admin role issued by aa1, aa2 has the Admin role issued by DIS, aa3 has the Staff role issued by DIS, aa4 initially has both the Staff role and the Admin role issued by DIS.
static void	main(java.lang.String[] args)

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail

TestIt

public TestIt(java.lang.String[] args)

Creates a new instance of TestIt. This function creates a PERMIS instance to use in two tests (doTest1 and doTest2).

Method Detail

doTest1

public void doTest1(java.lang.String[] args)

In this test, DIS has the Admin role issued by SOA, aa1 has the Admin role issued by DIS and aa2 has the Staff role issued by DIS. aa1 can "open door". His Admin role is valid because DIS has two RARs. The first RAR is from the policy, which can not be use to issue the Admin role to aa1 (empty role is returned, means "not enough"). The second RAR allows DIS to issue the Admin role to aa1 ("good enough"). aa2 can not "open door". His Staff role is valid because DIS has a RAR specified in the policy which allows DIS to issue the Staff role to people. Note that this RAR is used before the RAR that comes from DIS's credential.

Parameters:

args - is an array of String. Only the first element is used. It specifies the path to credentials, so that we can pick them up.

doTest2

public void doTest2(java.lang.String[] args)

In this test, aa1 has the Admin role issued by SOA, DIS has the Admin role issued by aa1, aa2 has the Admin role issued by DIS, aa3 has the Staff role issued by DIS, aa4 initially has both the Staff role and the Admin role issued by DIS. aa2 can "open door" because DIS has a RAR that allows DIS to issue the Admin role to people. aa3 can not "open door" although aa3's Staff role is valid. aa4 at this step can not "open door" because the DIS's RAR from the policy is used to validate aa4's credential first and the Staff role of aa4 is valid (the Staff role is "good enough" for the constraining process). Now aa4's old credential is removed from the repository and DIS issued the Admin role to aa4 in another credential. Now aa4 can "open door" because the first RAR of DIS is "not good enough" and the second RAR gets through - "good enough".

Parameters:

args - is an array of String. Only the first element is used. It specifies the path to credentials, so that we can pick them up.

main

public static void main(java.lang.String[] args)