Difference between revisions of "ACWO SOA Security"
| Line 2: | Line 2: | ||
== SOA Security Principles == | == 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 | + | 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 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. Hence, security tasks such as identification, authentication, and authorization are externalized from business services. |
| − | + | 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 results in a transferable representation of authenticated subject information that can be consumed by the authorization side. An appropriate mechanism for exchanging authentication information this way is provided by the IHE XUA interoperability profile which is based on the SAML standard. | |
| − | 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 | ||
| − | + | Decoupling authorization and authentication is about separating the use of authenticated subject information from its construction. 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. Security tokens are not restricted to subject authentication, they can as well be used for decoupling the issuance and consumption of policies, policy decisions, and all kinds of attributes that are needed for the evaluation of a policy. | |
| + | 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. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
<hr> | <hr> | ||
| − | == | + | == Open Issues == |
:Are there any overlaps with the IHE SOA white paper? [[User:Joerg.caumanns|Joerg.caumanns]] 19:30, 27 January 2009 (UTC) | :Are there any overlaps with the IHE SOA white paper? [[User:Joerg.caumanns|Joerg.caumanns]] 19:30, 27 January 2009 (UTC) | ||
| − | + | == Closed Issues == | |
| − | |||
| − | == | ||
| − | |||
Latest revision as of 15:34, 19 February 2009
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 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. Hence, security tasks such as identification, authentication, and authorization are externalized from business services.
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 results in a transferable representation of authenticated subject information that can be consumed by the authorization side. An appropriate mechanism for exchanging authentication information this way is provided by the IHE XUA interoperability profile which is based on the SAML standard.
Decoupling authorization and authentication is about separating the use of authenticated subject information from its construction. 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. Security tokens are not restricted to subject authentication, they can as well be used for decoupling the issuance and consumption of policies, policy decisions, and all kinds of attributes that are needed for the evaluation of a policy. 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.
Open Issues
- Are there any overlaps with the IHE SOA white paper? Joerg.caumanns 19:30, 27 January 2009 (UTC)