The Internet and Web services have made it easy for organizations to open their business applications and databases and share data with just about anyone, in any place. What’s a little less easy is capturing, defining, and managing the issues of trust, identity management, and service rights in relation to all this information and data that’s being shared—especially when the application or data access is cutting across organizations and systems outside the traditional trust boundaries of the corporate network.
For example, whether it’s a mobile telephone company that wants to develop, manage, and profit from the sales of additional services that may be delivered to groups of subscribers or government agencies that want to collaborate across department boundaries while observing appropriate security requirements, organizations are starting to realize that managing the identity rights related to data or application components is an important part of applications that serve dynamic environments.
Service-oriented architectures are giving organizations a more flexible, adaptable, and ultimately more manageable way to create business logic and applications that can be used to address changing business needs. But simply creating flexible and dynamic services for data and applications isn’t always enough, especially if you need to provide those services in a secure or controlled way across a dynamic user population. That’s where the idea of identity rights management comes in. A serviced-oriented design for identity rights management—an intermediary service that controls and manages who has access to what data as well as one that provides virtual, real-time updating of reference data—enables a range of applications and services that would be difficult to create and manage using traditional approaches.
Let’s look a little more closely at the issue of exposing data more broadly. While Web services make many things easier, the widespread use of them can also increase the risk of exposing sensitive corporate data or compounding corporate security issues. For example, user and group role-based systems typically define permission and access rules broadly, allowing greater than intended access to data sources. In many cases, this results in access policy consistency issues across applications, where users may have access to more data or application components than intended. In addition, the burden of access enforcement is often left to the developers, although building full and highly granular policy and access control for data and application components into applications is typically prohibitively expensive from a time and cost perspective.
-1-
Print this article
Email this article
Talk Back!
Write to Editor
