Enforcement of Separation Of Duty (SOD) rules for the enterprise is very complicated when it is done per application. For each application like SAP, Oracle eBS, Peoplesoft or JD Edwards the SOD rules would have to be defined. But there is no sight on the overall SOD rules that would prevent a person to have rights in the Peoplesoft HR as well as the SAP order management or General ledger.
Theoretically it would be possible to have a meta SOD system to enforce these kind of rules. But that would be complex to implement and use. When a user would get a role it would need to be checked in the specific systems as well as the meta system.
The solution is in the future of Service Orientation. When would would have an authorization service for the total enterprise the SOD rules could be enforced in this service. Each application like SAP, EBS or Peoplesoft would check the authorization level of the person in the authorization service.
That would mean a change in architecture for the different ERP application. Oracle is working on that in their fusion applications. The authorization server used by the authorization service they already have. They got it through the Bea systems acquisition. It is the former aqua logic server now called Entitlement server.
Sunday, 28 December 2008
Saturday, 6 December 2008
Application Separation Of Duty
Separation of Duty (SOD) is often enforced per application. Within a ERP application like JD Edwards, SAP or Oracle E-Business Suite the roles are checked against a list of roles that can't be shared.
The roles that can't be shared are defined by business standards for the specific market, laws like Sarbanes Oxley and company specific.
Because the SOD enforcement wasn't build in the core of the systems the SOD checks are post role assignment. On a regular basis the roles assignments to the persons, groups or department are checked against the SOD list.
Then these SOD need to be resolved. This can work but will mean extra work since the roles assignments are checked after the fact. When an SOD is found these need to be resolved by assigning the role to another person or group of persons.
Off course when the roles were defined they needed to be checked that they only have SOD conflicts within the role.
The roles that can't be shared are defined by business standards for the specific market, laws like Sarbanes Oxley and company specific.
Because the SOD enforcement wasn't build in the core of the systems the SOD checks are post role assignment. On a regular basis the roles assignments to the persons, groups or department are checked against the SOD list.
Then these SOD need to be resolved. This can work but will mean extra work since the roles assignments are checked after the fact. When an SOD is found these need to be resolved by assigning the role to another person or group of persons.
Off course when the roles were defined they needed to be checked that they only have SOD conflicts within the role.
Subscribe to:
Posts (Atom)