Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more ➡
Download
Standard view
Full view
of .
Add note
Save to My Library
Sync to mobile
Look up keyword
Like this
2Activity
×
0 of .
Results for:
No results containing your search query
P. 1
Role Based Authentication Schemes to Support Multiple Realms for Security Automation

Role Based Authentication Schemes to Support Multiple Realms for Security Automation

Ratings: (0)|Views: 529|Likes:
Published by ijcsis
Academy Automation implies to the various different computing hardware and software that can be used to digitally create, manipulate, collect, store, and relay Academy information needed for accomplishing basic Operation like admissions and registration to finance, student and faculty interaction, online library, medical and business development. Raw data storage, electronic transfer, and the management of electronic business information comprise the basic activities of an Academy automation system. The main aim of this work was to design and implement Multiple Realms Authentication where in each realm authentication can be implemented by using Role Based Authentication (RBA) System, where in each user has certain roles allotted to him/her which defines the user’s limits and capabilities of making changes, accessing various areas of the software and transferring/allotting these roles recursively. Strict security measures had kept in mind while designing such a system and proper encryption and decryption techniques are used at both ends to prevent any possibility of any third party attacks. Further, various new age authentication techniques like OpenID and WindowsCardSpace are surveyed and discussed to serve as a foundation for future work in this area.
Academy Automation implies to the various different computing hardware and software that can be used to digitally create, manipulate, collect, store, and relay Academy information needed for accomplishing basic Operation like admissions and registration to finance, student and faculty interaction, online library, medical and business development. Raw data storage, electronic transfer, and the management of electronic business information comprise the basic activities of an Academy automation system. The main aim of this work was to design and implement Multiple Realms Authentication where in each realm authentication can be implemented by using Role Based Authentication (RBA) System, where in each user has certain roles allotted to him/her which defines the user’s limits and capabilities of making changes, accessing various areas of the software and transferring/allotting these roles recursively. Strict security measures had kept in mind while designing such a system and proper encryption and decryption techniques are used at both ends to prevent any possibility of any third party attacks. Further, various new age authentication techniques like OpenID and WindowsCardSpace are surveyed and discussed to serve as a foundation for future work in this area.

More info:

Published by: ijcsis on Oct 12, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See More
See less

11/14/2012

pdf

text

original

 
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 09, No.09, 2011
Role Based Authentication Schemes to SupportMultiple Realms for Security Automation
Rajasekhar.B.M & Dr.G.A.Ramachandra
 Abstract
 Academy Automation implies to the various different computing hardware and software that can be used to digitally create, manipulate, collect, store, and relay Academy information needed for accomplishing basic Operation like admissions and  registration to finance, student and faculty interaction, onlinelibrary, medical and business development. Raw data storage,electronic transfer, and the management of electronic businessinformation comprise the basic activities of an Academy automation system. The main aim of this work was to design and implement Multiple Realms Authentication where in each realm authentication can be implemented by using Role Based  Authentication (RBA) System, where in each user has certain roles allotted to him/her which defines the user’s limits and capabilities of making changes, accessing various areas of the software and  transferring/allotting these roles recursively. Strict security measures had kept in mind while designing such a system and  proper encryption and decryption techniques are used at both ends to prevent any possibility of any third party attacks. Further,various new age authentication techniques like OpenID and WindowsCardSpace are surveyed and discussed to serve as a foundation for future work in this area. . Index Terms - RBA, Encryption/Decryption, OpenID,WindowsCard-Space.
I.
 
I
NTRODUCTION
 Starting in the 1970s, computer systems featured multipleapplications and served multiple users, leading to heightenedawareness of data security issues. System administrators andsoftware developers alike focused on different kinds of accesscontrol to ensure that only authorized users were given accessto certain data or resources. One kind of access control thatemerged is role-based access control (RBAC). A role is chieflya semantic construct forming the basis of access control policy.With RBAC, system administrators create roles accordingly tothe job functions performed in a company or organization,grant permissions (access authorization) to those roles, andthen assign users to the roles on the basis of their specific jobresponsibilities and qualifications “Role-based access controlterms and concepts”. A role can represent specific task competency, such as that of a physician or a pharmacist. A rolecan embody the authority and responsibility of, say , a projectsupervisor. Authority and responsibility are distinct fromcompetency. A person may be competent to manage severaldepartments but have the responsibility for only the departmentactually managed. Roles can also reflect specific dutyassignments rotated through multiple users for example, a dutyphysician or a shift manager. RBAC models andimplementations should conveniently accommodate all thesemanifestations of the role concept. Roles define both thespecific individuals allowed to access resources and the extentto which resources are accessed. For example, an operator rolemight access all computer resources but not change accesspermissions; a security-officer role might change permissionsbut have no access to resources; and an auditor role mightaccess only audit trails. Roles are used for systemadministration in such network operating systems as Novell’sNetWare and Microsoft’s Windows NT.In this article present a comprehensive approach to RBACon the Web. We identify the user-pull and server-pullarchitectures and analyze their utility. To support thesearchitectures on the Web, for relatively mature technologiesand extend them for secure RBAC on the Web. In order to doso, to make use of standard technologies in use on the Web:cookies [Kristol and Montulli 1999; Moore and Freed 1999],X.509 [ITU-TRecommendation X.509 1993; 1997; Housley eta1. 1998], SSL (Secure Socket Layer [Wagner and Schneier1996; Dierks and Allen 1999]), and LDAP (LightweightDirectory Access Protocol [Howes et a1. 1999] ), and LDAP(Lightweight Directory Access Protocol (LDAP) directoryservice already available for the purpose of web mailauthentication of Sri Krishna Devaray University, Anantapurusers has been used to do the basic Authentication. The clientcan request the application server for any web applicationwhich will ask for the user credentials which will be verified inthe LDAP server through an J2EE[17] Module. On successfulverification, the authorization module will contact the user roledatabase and fetch the roles for that user. In case of return of multiple roles user will be given the authorization of all theroles. The access to the application will be on the basis of privilege of the role of that particular user. The role database isimplementing in Oracle databse. On successful authentication,the Authentication and authorization module which has beendeveloped for this purpose is called and the role for the user isretrieved. Privileges are granted to roles and interns are grantedto users.The overall database server and application server isconsidered for possible attacks. The proposed schema is givenfigure 2. The database server and authentication server are in aprivate network and separated from the user network by afirewall. These servers can be accessed only throughapplication server, i.e through the authentication andauthorization module. Application server has an interface in theprivate network but can avail only the specific service whichhas been explicitly allowed in the firewall. Application serverhas another interface which is part of user network with afirewall to restrict the clients only to the desired service.The information flow security has been taken care bysecure http. The J2EE Application server has the support forHTTPS which was configured to make sure that data passing to
1. Dept of Computer Science & Technology, S.K. University, Anantapurrajasekhar3@gmail.com, chandragar@yahoo.com
67http://sites.google.com/site/ijcsis/ISSN 1947-5500
 
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 09, No.09, 2011
and from Application server is encrypted. From the ApplicationServer, a digital certificate in SSL [23] (Secure Socket Layer)has been generated. This needs to be installed on the clientmachine for server identity verification. Similarly clientcertificate can also be generated from the J2EE which can beused in the client which will update sensitive data. Suchoperation will be denied without client certificate.II.
 
L
ITERATURE
 
R
EVIEW
 A large number of research papers are published in the areaof Role Based Authentication In [5] Raymond emphasized thepurpose of Role Based Authentication. Authorizationarchitecture for authorizing access to resource objects in anobject-oriented programming environment is discussed in thispaper. In one distributed environment, the permission model of JAAS (Java Authentication and Authorization Service) isreplaced or enhanced with role-based access control. Thus,users and other subjects (e.g., pieces of code) are assignedmembership in one or more roles, and appropriate permissionsor privileges to access objects are granted to those roles.Permissions may also be granted directly to users. Roles maybe designed to group users having similar functions, duties orsimilar requirements for accessing the resources. Roles may bearranged hierarchically, so that users explicitly assigned to onerole may indirectly be assigned to one or more other roles(i.e.,descendants of the first role). A realm or domain may bedefined as a namespace, in which one or more role hierarchiesare established.Robert et al in [6] discussed about Methods, systems, andcomputer program products are disclosed for protecting thesecurity of resources in distributed computingenvironments.The disclosed techniques improve administrationand enforcement of security policies. Allowed actions onresources, also called permissions, (such as invocations of particular methods, read or write access of a particular row orperhaps a particular column in a database table, and so forth)are grouped, and each group of permissions is associated with arole name. A particular action on a particular resource may bespecified in more than one group, and therefore may beassociated with more than one role. Each role is administeredas a security object. Users and/or user groups may beassociated with one or more roles. At run-time, access to aresource is protected by determining whether the invoking userhas been associated with (granted) at least one of the rolesrequired for this type of access on this resource.In [7] Dixit et al discussed about an actor is associated witha role, a policy type is associated with the role, and a role scopeis associated with the role. One or more values are received forone or more corresponding context parameters associated withthe actor. A request for access to a resource is received fromthe actor. A policy instance is determined based on the policytype and the one or more values for the one or morecorresponding context parameters associated with the actor.One or more actor-role scope values are determined based onthe role scope and the one or more values for the one or morecorresponding context parameters associated with the actor. Aresponse to the request is determined based on the policyinstance and the actor-role scope values.Bindiganavale and Ouyang, in [8] presents the mostchallenging problems in managing large web-applications isthe complexity of security administration and user-profilemanagement. Role Based Access Control (RBAC) has becomethe predominant model for advanced access control because itreduces the complexity and cost of administration. UnderRBAC, security administration is greatly simplified by usingroles, hierarchies and privileges, and user management isuncomplicated by using LDAP API specification within theJ2EE application. System administrators create roles accordingto the job functions performed in an organization, grantpermissions to those roles, and then assign users to the roles onthe basis of their specific job Responsibilities andqualifications.A wireless networks proliferate, web browsers operate in anincreasingly hostile network environment. The HTTPSprotocol has the potential to protect web users from network attackers, but real-world deployments must cope withmisconfigured servers, causing imperfect web sites and users tocompromise browsing sessions inadvertently. Force HTTPS isa simple browser security mechanism that web sites or userscan use to opt in to stricter error processing, improving thesecurity of HTTPS by preventing network attacks that leveragethe browser's lax error processing. By augmenting the browserwith a database of custom URL rewrite rules, Force HTTPSallows sophisticated users to transparently retrofit security ontosome insecure sites that support HTTPS. We provide aprototype implementation of Force HTTPS as a Firefoxbrowser extension [9].A comparison of a simple RBAC model and a groupAccess Control List(ACL) mechanism by Barkley [10] showsthat even the simplest RBAC model is as effective in its abilityto express access control policy. An RBAC system with specialfeatures (which are not possible with ACLs) will be even moreeffective.III.
 
O
BSERVATIONS
 
A
ND
 
P
ROBLEM
 
D
ESCRIPTION
 The whole Collage Academy automation consists of manysections viz. Student Affairs, Academic Section, Research andDevelopment, Training and Placement, Finance and Accountsetc. For example if IPS Academy wants to integrate withdifferent Academy’s like Indore Institute of Science &Technology then in that case we can implement MultipleRealm Authentication System. Different individuals in IPSAcademy, Indore should be given access to different aspects of the systems based on their clearance level. For e.g. theAssistant Registrar of Student Affairs should have full accessto all the options of Student Affairs database but not that of theAcademic Section database. However, provisions have to bemade so that he/she is able to perform some student affairsrelated queries to the student affairs database. Similarly, astudent must have read-only access to his/her information inthe official records and modifying capabilities some of his/herdetails in the training and placement section database. Thiscalls for a role-based approach to access the databases. Eachperson has a certain role attached to it. This role corresponds tothe areas of the work his login account can access. If aviolation occurs, the user is immediately logged out.
68http://sites.google.com/site/ijcsis/ISSN 1947-5500
 
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 09, No.09, 2011
In this work the design and implementation of the RoleBased Authentication Schemes to Support Multiple Realms forSecurity Automation is described, developed at the IPSAcademy, Indore as an Java, J2EE [2005] web application inJSP server side code, HTML, and JavaScript for use on theInternet. The purpose work to deploy a cost-effective, web-based system that significantly extends the capabilities,flexibility, benefits, and confidentiality of paper-based ratingmethods while incorporating the ease of use of existing onlinesurveys and polling programs.
Figure 1: Basic Architecture of Academy A.
 
Problem Issues And Challenges
The following Problems are as Follows:-1) The information line must be completely secured.2) Proper Encryption must be used for storing the Password forthe User.3) The authorization token which is stored on the client sidehas to be encrypted so that the client cannot modify hisauthorization clearance level.4) Each userid-role mapping should have an expiry datebeyond which it will be invalid.5) Role Scoping: Local and Global Roles6) In each role, we have to have an owner. Normally the rolewill map to the user id of the owner. The owner can change themapping and can specify the time period of this change. Thenewly mapped user is not the owner and so cannot change theownership, but maybe allowed to map again. For example,HODCSE is the role and the owner’s user id is” Ram”.Normally, HODCSE maps to Ram. When Prof. Ram goes onleave, he fills up some form electronically and this triggers(among other things) a role change of HODCSE to the user hedesignates, say Prof.Shayam. Now” Ram” is going on leave till4/7/2010, so the changed mapping is till 4/7/2010(to”pshayam”; specified by” Ram” in the form he filled up).Now due to an emergency, ”pshayam” had to leave station on4/7/2010, making Prof manoj the Head. Since” pshayam” is notthe owner, he cannot change the validity date beyond 4/7/2010and”Ashish” takes over the HODCSE role till 4/7/2010. On5/7/2010 (or the next query of the role), the role remapsto”Ram”. Other cases (like”Ram” having to overstay beyond4/7) can be handled by the administrator.used in the text, evenafter they have been defined in the abstract. Abbreviations suchas IEEE, SI, MKS, CGS, sc, dc, and rms do not have to bedefined. Do not use abbreviations in the title or heads unlessthey are unavoidable.7) We need to write N no.of authenticators based onrequirements.8) Based on role name(which we can get it from login page),we can create associate authenticators through reflection api forauthenticating username and password.Figure 2: System and Server SecurityIV.
 
M
ETHODOLOGIES
1) We have 2 sets of Roles:
Global Roles:
These refer to the roles which are common tothe entire applications viz. root, Director. Their Role IDs areof single digit: 0, 1, and 2 etc.
Local Roles:
These are roles which are specific to a module.For E.g. for Student Affairs, the roles of Assistant Registrar,Academy in charge. Their IDs are of the Form: 10, 11, 12 ...110 etc. where first digit identifies the application to which allof them are common.2) There is a Global role to role id mapping table.3) Also there is a local mapping table for each section.Insertion/modification or deletion of any entry in the localtable generates a Microsoft SQL trigger for its ‘encoded’ entryaddition in the global table.Below table describes about the Realm association to thedomain as such, each domain is associated to unique domain.And where administrator can have to privileges to active orInactive domain level.For Example: Realm
Domain-
Users
69http://sites.google.com/site/ijcsis/ISSN 1947-5500

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->