Considering Assumptions, Dependencies, and Constraints

Before you can implement Secure Attributes Exchange, you must consider the following assumptions and constraints.

Assumptions

• The implementation will automatically use the authn=Force functionality to allow Identity Provider applications to repeatedly invoke the secure attribute transfer feature.

• The mappings between the Service Provider application URL prefix to the Service Provider id have been explicitly defined in the product configuration.

• Local Service Provider single logout functionality relies on OpenSSO Enterprise be able to redirect to an external URL during SAMLv2 single logout processing, and then resume the original SAMLv2 single logout when redirected back.

• Cryptography APIs are assumed to be available on all targeted platforms and programming languages.

Constraints

• The scope of the current OpenSSO Enterprise implementation is limited to SAMLv2–based single sign-on only. However, it is possible for you to extend this to other single sign-on protocols such as the Liberty Identity Federation Framework (ID-FF) and Web Service Federation (WS-F) specifications.

• The existing implementation supports only simple HTTP GET and POST based mechanisms. However, you should be able to use the same APIs to do XML-based attribute transfer as well.

• Integration with specific proprietary application server technologies such as WebSphere LTPA and WebLogic for single sign-on as well as single logout are not addressed in this document.

• Limited single logout functionality is implemented. Logout from multiple Identity Provider applications and multiple Service Provider applications is not directly addressed in this document. The Identity Provider and Service Provider must implement logout appropriately to meet their own needs.