A Stringent Authorization using Principles and Policy for Grid Computing

: Problem statement: The current information security mechanisms are insufficient to address authorization issues. The access control models today are mostly static and they are not well-suited for the service-oriented environments where information access is dynamic in nature. Traditional authorization security techniques do not directly address these concerns as they primarily use access control lists for authorization, where the user whose name appears in the list is authorized to access the grid with some privileges associated with the names, which requires the resource provider to maintain authorization decisions for every user, which is very time consuming and non-scalable solution. Approach: Organizations pass user roles instead of name and date of birth but it used Public Key Infrastructure user certificate for authorization which is inflexible when it comes to open distributed systems (Grid) as it assumes a pre-agreed trust between Service Provider and the Service consumer. Usage of Java authentication and authorization services is performed in a pluggable fashion. It permits the application to remain independent from underlying authentication technology. Results: Our implementation provides service providers with full control over authentication and authorization of accounts that access services. Implementation of the proposed technique has proved to be less time consuming and more secured for authentication and authorization as compared to the traditional way of authenticating the users. The Policy Decision Service is envisioned to be used by many Web services protected by their PEPs. Conclusion: The model brings out many advantages over traditional identity. It is more flexible and more powerful and is suited for dynamic environments for Web services.


INTRODUCTION
The emergence of web service technologies has enabled information systems to interoperate in a platform-independent fashion, promoting unprecedented collaboration and information sharing, often across enterprise and network boundaries. As more organizations and users are becoming interested in using grid computing systems in a variety of application domains, security becomes a key issue (Simmons et al., 1991;Stell, 2004;Welch et al., 2003;Yagoubi and Slimani, 2007). Public Key Infrastructure assumes a pre-agreed trust between the service provider and the service consumer. However, in an open distributed environment such as Grid systems, resource providers and consumers can join the grid dynamically and these pre-agreements cannot be presumed. The use of JAAS authentication is performed in a pluggable fashion and it makes the applications remain independent of the underlying authentication technology. The Login Modules remain independent of the different types of user interaction. SAML technology provides a way to represent authentication, attribute and authorization decision information in XML. XACML provides XML schema for expressing policies and rules. SAML and XACML are combined to support distributed authentication and authorization. Authorization based on users' credentials is difficult to manage and PKI is inflexible when it comes to Grid. Our work uses XACML, a general purpose access control policy language. It provides syntax in XML to define action (request) rules for subjects (users) and targets (resources). It describes both access control policy language and a request/response language. Access control policy language is used to express access control policies (who can do what, where and when). The request/response language expresses queries about whether a particular access should be allowed.

MATERIALS AND METHODS
Authorization approaches: Currently existing Grid authorization consists of access control lists (grid mapfile) which is not scalable as it requires the Resource Provider to maintain authorization state for every user which is time consuming. User Credential for one gird cannot be used directly to access resources at another (Shamir, 1979). A user needs to maintain multiple credentials if he/she wants to use multiple grids.Recent grid security trends try to overcome this problem by introducing a new authorization technique, which supports policy based authorization, which means authorization decisions are not based on the users' identity but on the policies generated and sent to the service providers. PKI presumes a pre-agreed trust between the service provider and the service consumer. In an open distributed environment such as grid systems, service providers and resource consumers can join the grid dynamically. PKI certificate contains a set of user attributes for determining authorization. These attributes have to remain static. If the user changes his/her role, some attributes could change as well (Ito et al., 1987). Thereby the certificates need to be invalidated and revoked. Hence, a user has to have multiple certificates for each service and remember which certificate to use, which is infeasible (Benaloh and Leichter, 1989). Implementations of authorization in recent years have largely adopted the XML based SAML and XACML standards for authentication and authorization. Combination of SAML and XACML proves more beneficial.

Implementation of JAAS: JAAS uses an updated
technology that is plugged without requiring modifications to the application. It uses different underlying technologies such as Kerberos. There are different ways of communicating with the user. The Login Module performs authentication by remaining independent of the different types of user interaction. Figure 1 demonstrates the architecture of JAAS. For communication KDC generates a session key which is used for secure interaction.
The Login Context constructs the configured login module and initializes it with new subject and callback handlers. In order to authenticate a user, javax.security.auth.login.Login Context is required.

Login contextlc:
NewLoginContext(<config file entry name>, <CallbackHandler to be used for user interaction>) The LoginModule invokes a javax.security.auth.callback.Callback Handler to perform the user interaction and obtain the requested information, such as the user name and password. Snippet1 shows different ways of interacting with the user. The calling application can subsequently retrieve the authenticated Subject by calling the Login Context's getSubject method. Figure 1 shows the architecture of JAAS.  System.out.println("ERROR: " + toc.getMessage()); break; caseTextOutputCallback.WARNING: System.out.println("WARNING: " + toc.getMessage()); break; default: throw new IOException("Unsupported message type: " + toc.getMessageType()); } Snippet1 for authentication.
The Login Configuration specifies that the module which uses Kerberos for authentication is required to have success for authentication: Let K a bethe master key for A shared by A and KDC. K ab session key shared by A and B. T b Ticket to use B. K{data} data encrypted with key K A -K a {K ab ,B} K ab K b {K ab ,A}-B Performs mutual authentication to prove that A and B know each other. User logs in with the granted identity, based on which KDC generates password for further communication for accessing services by granting a ticket.

Implementation of JAAS Authorization:
JAAS authorization extends the java security architecture that uses security policy to specify the access rights to execute. The permissions are granted based on code characteristics. A subject is created when a user is authenticated. The Subject carries the identity that distinguishes it from other Subjects. The purpose of the Subject is to represent the authenticated user. A Subject is comprised of a set of Principals, where each Principal represents an identity for that user. For example, a Subject could have a name Principal ("SS") and a Social Security Number thereby distinguishing this Subject from other Subjects. A Policy file is generated that includes one or more principal fields: grant codebase "file:./trialact.jar", Principal trial.principal.trialPrincipal "tsttrial"{ permissionjava.util.PropertyPermission "java.home", "read"; permissionjava.util.PropertyPermission "user.home", "write"; permissionjava.io.FilePermission "", "read" }; Snippet2 for policy file Permissions can be granted in the policy to specific Principals. After the user has been authenticated, the application can associate the Subject with the current access control context. For each subsequent securitychecked operation (a local file access, for example), the Java runtime will automatically determine whether the policy grants the required permission only to a specific Principal and if so, the operation will be allowed only if the Subject associated with the access control context contains the designated Principal (Brickell, 1989). A subject is associated with access control after it is authenticated and authorized. Figure 2 shows the permit and deny override. The doAs method is called with an authenticated subject. It associates the subject with the current access control and invokes run method from the action. The run method implementation contains all the code to be executed as the specified subject: Privileged Action act = new trialAction(); Subject.doAsPrivileged(subject,action,null); Snippet 3 for Privileges.

XACML formulation: Implementation of SAML and XACML:
The Security Assertion Markup Language is an XML framework for exchanging authentication and authorization information (Zhang et al., 1999). This security information is expressed in the form of assertions about subjects, where a subject is an entity that has an identity within a security domain. Assertions can convey information about authentication acts performed by subjects, attributes of subjects and authorization decisions about where subjects are allowed to access a certain resources. Our XACML based policy management and authorization system allows a authoritative entity to create, modify and package resource policies. The Policy Decision Point (PDP) answers authorization queries based on the resource policies: A Rule is represented as Pre(r) Con(r) Rule Set = Strict-rulesχ χ χ χDefeasible-rules Policy Enforcement Point: The Policy Enforcement Point (PEP) is responsible for requesting authorization decisions and enforcing them. Figure 3 and 4 shows the flow of sequences among the subjects and the resources. In essence, it is the point of presence for access control and must be able to intercept service requests between information consumers and providers. Although the diagram depicts the PEP as a single point, it may be physically distributed throughout the network. The most important security engineering consideration for the implementation of a PEP is that the system must be designed such that the PEP cannot be bypassed in order to invoke a protected resource: <Target> <Subjects> <AnySubject/> </Subjects> <Resources> <Resource> <ResourceMatchMatchId= "urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValueDataType= "http://www.w3.org/2001/XM #string">MainServer</AttributeValue> <ResourceAttributeDesignatorDataType= "http://www.w3.org/2001/XMLSchema#string" AttributeId= "urn:oasis:names:tc:xacml:1.0:resource:resource-id"/> </ResourceMatch> </Resource> </Resources> <Actions> <AnyAction/> </Actions> </Target> The Policy Decision Point (PDP) is responsible for evaluating the applicable policies and making the authorization decision (permit or deny). The PDP is in essence a policy execution engine. When a policy references a subject, resource, or an environment attribute that is not present in the request, it contacts the appropriate AA to retrieve the attribute value(s).

RESULTS AND DISCUSSION
User authorization: XACML implementation is used as a part of the authorization system. Their main function is to bind the XACML schemato javarepresentations, handles the attributes and marshals the contents to XACML request format. In the most general form, a Policy Rule that decides on whether a subject s can access a resource r in a particular environment e, is a Boolean function of s, r and e's attributes: Rule: can_access (s, r, e) ∫ (ATTR(s), ATTR(r), ATTR(e)) Given all the attribute assignments of s, r and e, if the function's evaluation is true, then the access to the resource is granted; otherwise the access is denied. A Policy rule base or Policy Store may consist of a number of policy rules, covering many subjects and resources within a security domain. The access control decision process in essence amounts to the evaluation of applicable policy rules in the policy store.
Results obtained using JAAS has been compared with the results of the earlier authenticating system. It proves less time consuming and more secured: Enter the user name: JAVA Enter the pwd: object oriented programming language Inside get dbconnection Elapsed time is 6 ms Bash-3.004 java time diffcheck Enter the user name system1 Enter the pwd: systemadminone Inside getdbconnection Elapsed time is 6 ms Bash-3.004 java time diffcheck Enter the user name: user name Enter the pwd: password Inside getdbconnection Elapsed time is 4 ms Bash-3.004 java time diffcheck Enter the user name: cbe Enter the pwd: hindusthan 0 coimbatore Inside getdbconnection Elapsed time is 4 ms Bash-3.004 java time diffcheck  The conventional way of authentication is analyzed and compared with the newly developed JAAS authentication. Table 1 show the time measured during conventional authentication. Figure 5 demonstrates the varying time consumed during authentication.

Algorithm:
• The main assumption is the Service providers and the Identity providers trust each other within in a VO • The application sends the authentication and authorization service its request for authentication • Login context and callbacks determine the technology to be used for authentication • Successful authentication generates a subject/Principal with SSN number which is its unique identity • Users are authorized based on the SSN and a policy file is generated • Policy file carries the identity of the user with the resource/services that he/she is authorized for • Depending on the users' request, a SAML assertion is send to the Identity Provider • The Identity Provider after matchmaking forwards to the service Provider • Based on the assertion, a XACML request is marshaled to a file. It also contains Policy Enforcement Point(PEP) and Policy Decision Point (PDP) • XACML PDP generates authorization decision statement and forward the decision to the XACML PEP • Finally, the response is send to the subject in the form of a SAML response

CONCLUSION
This study analyzed the requirement of authorization services and proposed the use of JAAS and combination of SAML and XACML as a basic mechanism for implementing authorization services in large scale distributed computing systems.
While pointing out the desirable features of the complex authorization policies, the study also discussed the practical limitations of traditional authorization in such environment and designed an new authorization service architecture for VO. authorization service for VO. Further research includes satisfactory of protocol authentication and visualization monitor to the execution effect of authorization scheme.