Enterprise Identity Patterns with WSO2 IS: Complying to SOX with SaaS Applications

The Sarbanes-Oxley(SOX) act of 2002 is a legislation passed by the U.S. Congress to protect shareholders and the general public from accounting errors and fraudulent practices in the enterprise, as well as improve the accuracy of corporate disclosures[1]. The act require the identity and access management (IAM) program of an enterprise to meet the following to become compliant with the standards.

• Securely manage and assign and control user access rights
• Disseminate tasks and associated privileges among multiple users
• Adjust user access rights when responsibilities change
• Revoke user access upon termination
• Provide uniform access policy
• Manage access based on business roles
• Manage allocation of user credentials

In an enterprise, managing user credentials and access rights in a decentralized way to meet the above requirement is highly inefficient, costly, error prone and eventually will not meet the requirements. This is because today's enterprise has a large number of different systems commissioned over a time. The complexity becomes worse as some systems are cloud based SaaS applications while others are on-premise.

How do you establish a centralized IAM program to achieve the above requirements?

• Centrally manage credentials, access controls and profiles
• Connect all possible on-premise systems the centrally managed IAM system
• Provision users, profiles and access control to cloud and external domains
• Use single sign on protocols to validate credentials at central point and provide a token to authenticate to on-premise and cloud system

WSO2 Identity server is a central backbone that connects and manages multiple identities across applications, APIs, the cloud, mobile, and Internet of Things devices, regardless of the standards on which they are based built on. This is how one can use WSO2 Identity server to achieve the above requirements.

WSO2 IS connects to the enterprise LDAP, and the unified system meets above requirements. The principals of the design are,

• Configure WSO2 IS to maintain users and roles in the LDAP
• Design LDAP groups based on on business roles. Use required level of granularity provide segregation of duties. As users change business roles assign them roles at WSO2 IS admin console - the centralized IAM system
• Assign correct access controls to different business roles
• Configure SSO with on-premise and cloud services (SaaS and PaaS) based on SAML2, OpenID Connect and open standards
• For propagating access controls,
• Use SCIM or web APIs to provision/deprovision users into external system
• On-premise systems are in the same identity control domain. We can have a choice of provisioning, or providing roles along with the authentication toke, or LDAP synching.  Use one of the methods compatible with the system.
• Write connectors for automatic provisioning and de-provisioning of users

[1] https://en.wikipedia.org/wiki/Sarbanes%E2%80%93Oxley_Act
[2] http://wso2.com/products/identity-server/