from the article:
"In the past, most systems were designed under the assumptions that a single system would posses all of the information necessary to make access control decisions and all the data would be recorded in the audit trail. However, large-scale distributed systems are always built by multiple organizations with a mixture of products. Thus, users may be authenticated by different authorities using different methods. In addition, different authorities retain different information about user properties and attributes. Centralizing all capabilities and information is just not practical. SAML provides standard formats to express authentication and user attributes, and the protocols to request and receive. "
With regard to service-enablement for our customers, I've been primarily focused on the ability of our Virtual Directory to enable service-based access (DSML, SPML, other) to identity data in practically any back-end format. I see this as very cool technology. Simple, but effective.
This article lays out another concept I've been thinking about, which is IdM as providing security for the SOA environment itself. That is, playing its role in locking down access to and from the services themselves. I've seen a number of articles and analyst reports that expect SOA deployments to take off throughout 2006 and 2007. Even if companies aren't ready to transform their entire infrastructure to an SOA, we can expect some degree of adoption within most large organizations.
An efficient and flexible Identity Management infrastructure is going to be critical in securing access to the SOA services themselves and their access to other systems and applications. Our Federation Server, using SAML, is an ideal candidate for enabling a secure SOA environment.
The scenario would look like this:
- Application-A (portal) requests data from Application-B (HR System).
- Federation Server authenticates Application-A and generates a SAML assertion.
- Application-A forwards the assertion to Application-B, which verifies the assertion and grants or denies access to its resources based on the information in the assertion.
The next step might be to add-on a provisioning environment that captures audit data on service access rights for SOA governance. I'd be curious to hear how people are implementing SOA governance. Would traditional user-provisioning systems fit the bill?
1 comment:
Couldn't agree with you more Matt. This is something we discuss in our recent report on identity management which you can access (you just need to subscribe - it's published under a Creative Commons license) here: http://www.mwdadvisors.com/articles/index.php?m=P
Below as an extract:
As a direct consequence of the pervasiveness of IT and a general desire (described in more detail in our report SOA: Handle with care) to more closely align investment in and delivery of IT with business objectives, enterprises are looking to breakdown organisational, functional and resource stovepipes through service-oriented architecture (SOA) initiatives. As they embark on these initiatives they are grappling with the challenge of IT environments which bury identity within a variety of infrastructure and application domains. As a result, they are faced with a fragmented identity management deployment architecture spanning multiple application silos; with each silo addressing particular functional/organisational domains with domain-specific, tightly-coupled, identity management policies, processes and technologies. This challenge is compounded by the development and acquisition of application-specific identity management solutions to address short-term needs which then have to be integrated with each other...
The advent of service-oriented architecture approaches is already being felt in the area of identity management and the impact is only likely to increase in the future. As automation of business processes through IT evolves to require the orchestration of multiple services, potentially operating across trust boundaries, there will be a consequent need to authorise access to business functions and information at the level of each service. Furthermore, the ability to dynamically compose services will depend on policy-based approaches to the definition and enforcement of access control requirements, unless a requester were granted access to all of the services which could participate in a composite service...
Some identity management capabilities reflect the history and evolution of the technology, perhaps most noticeably in the distinction between “web single-sign-on” and “enterprise single-sign-on”. The reality is that this is an artificial distinction: organisations need single sign-on irrespective of the nature of the resource. SOA initiatives will exacerbate this further. For example, a web-based portal may provide access to mainframe-resident business logic exposed as a service, requiring a combination of web SSO and enterprise SSO, when in reality what is required is a policy-based approach which facilitates single sign-on at the resource tier which can be exploited in the portal tier.
The report then goes on to define an architectural framework for identity management in which identity management capabilities are delivered as shareable infrastructure services which can be exploited by services in the same was as you describe
Post a Comment