Browse Prior Art Database

Access Controller In The Service-Oriented Architecture

IP.com Disclosure Number: IPCOM000180678D
Original Publication Date: 2009-Mar-13
Included in the Prior Art Database: 2009-Mar-13
Document File: 5 page(s) / 79K

Publishing Venue

IBM

Abstract

The disclosed method introduces and implements an access controller component to control the data object access across the different data sources in order that it provides one-stop central control hub to help the system administrator/DBA to simply the maintainence workload. At the same time, by introducing the local access control files, it discloses a method of verifying the user's data access right aggressively in the middleware layer so that it improves the overall application response time.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 62% of the total text.

Page 1 of 5

Access Controller In The Service-Oriented Architecture

Disclosed is a method to control the data object access across the different data sources by introducing and implementing an access controller component. So it can provide one-stop central control hub to help the system administrator/DBA to simply the maintenance workload.

It also contains a method to verify the user's data access right aggressively in the middleware layer so that it improves the overall application response time.

Access controller can consist of 1 mapping attribute and 3 major actions:

"mapping attribute" -- access right distribution across the different databases:

If userA's access right on a data object1 in database1 is defined to be same with its access right on a data object2 in database2, the access right update for userA on a data objects2 in database2 will be automatically reflected on the data object1 in DB1.

On another hand, if userA's access right on a data object1 in database1 is defined to be equal to userB's access right on a data object2 in database2, the access update for either userA or userB will be kept consistent with the access controller.

The access right mapping across the user and database is defined in a local mapping control file.

For example, mappingControl.xml,

<userA dbLocation="db

_

<group01 dbLocation="db

_101/>

_201/>

01">

<table

_

01>

_

01">

<table

<table

1

[This page contains 1 picture or other non-text object]

Page 2 of 5

</table

_

01>

<view

_

01>

<userB dbLocation="db

_

03">

<view

_031/>

<view

_032/>

<userC dblocation="db

_04">

<view

_

01/>

<view

_101/>

<view

_401/>

</view

_01>

<groupA dbLocation="db

_

02">

... /* mapping user/group on the given data objects in the specific database*/

<userB dbLocation="db

_

03">

... /* mapping user/group on the given data objects in the specific database*/

... /* other users/groups */

"Action 1" -- push:

By default, if a user/group is not defined in the local access control file, the user/group have all the rights of accessing the data objects in the given database. If the front client changes a user's access right on the certain data object, the push action can update the local access definition files(for example, localControl.xml) and the related privilege in the database. It also checks the local mapping control file(for example, mappingControl.xml). If the updated user has the mapping entry in the local mapping control file, the access right of the mapped user(s)/group(s) will also be updated in the related database(s).

For example, localControl.xml,

<userA dbLocation="db

_

01">

01>

<relational

_column/>

<xml

<table

_

_path

_document/>

2

Page 3 of 5

<relational

_columne/>

<xml

_path

_document/>

<xml

_path

_document/>

</table

_01>...