ACWO SOA Security
IHE White Paper on Access Control
SOA Security Principles
Sharing medical resources in an automated fashion mandates authorization, authorization calls for authentication, and authentication depends on identifiers as well as credentials. This basic formula holds for IT-systems based on new architectural approaches such as SOA and Web services as well as for traditional systems in enterprise IT. While new architectural approaches do not change this formula, they impact the way how security should be realized. Separating clearly between the supply of security functionality in the security subsystem and its use in business services is important to avoid duplication of work, foster interoperability, and facilitate re-use.
Decouple Authorization and Authentication
Decoupling the tasks of authorization and authentication leads to a model where federation protocol endpoints are used to transfer authentication events in a trustworthy fashion. The standard approach is to have a normal authentication process, which verifies the identity of users or computing devices based on an authentication protocol and persisted reference data (e.g. identifiers, attributes, credentials), to marshal the transient, in-memory representation of authenticated subjects at authentication-side federation protocol endpoints and to transfer this representation for consumption to the authorization-side where corresponding federation protocol endpoints consume the network-representation of an identity that was authenticated remotely. An appropriate mechanisms for exchanging authentication information this way is provided by the IHE XUA interoperability profile which is based on the SAML standard.
Decouple Security Object Lookup and Use
Decoupling authorization and authentication is about separating the use of authenticated subject information from its construction. This pattern can also be applied to other abstractions such as dynamically created information related to an identity (e.g. pseudonyms) or authorization policy information and authorization decision information.
The abstraction of a Security Token Service (STS) provides the core mechanism for this architectural principle. STSs are actors (services) that are dedicated to the processing of security tokens such as SAML assertions. STSs are not confined to serve their local domains only as they allow for an easy federation between domains where security token issued in one domain are consumed by actors within another domain.
As a design principle, each abstraction where the security subsystem (e. g. authentication and authorization services) needs to provide information should be addressed by a (logical) STS dedicated to this abstraction. This serves a separation of concerns. The SOA security paradigm goes even further as it allows integrating the information provided by these STSs by invoking them iteratively or recursively (STSs ask for input from other STSs).
Discussion
- Are there any overlaps with the IHE SOA white paper? Joerg.caumanns 19:30, 27 January 2009 (UTC)
- Is this section understandable or would a figure help to understand the core idea? Joerg.caumanns 19:59, 27 January 2009 (UTC)
Change Requests
place your change requests here...