Entrust Resources

Standards

SPML Interoperability Demonstration
2003 Burton Catalyst Conference

The OASIS-sponsored SPML interoperability demonstration held July 8-9th, 2003 at the Burton Catalyst Conference, displayed how SPML will enable federated identity management. The demonstration portrayed a business scenario of contractors from a Supplier domain being provisioned to multiple Customer domains.

The Scenario

The interoperability scenario involved the provisioning of contractors from a Supplier company to enable them to legitimately gain authorized access to the information assets of their Customer.

Upon hiring, accounts are created for each new contractor at all relevant customer applications so that the contractors can seamlessly access the information and resources necessary for them to perform their duties. The customer controls the access of the contractors by defining appropriate policies in terms of the attributes of the contractors; this information is communicated in the provisioning message.

Walking Through the Scenario

A Supplier company administrator uses a Human Resources Identity Management Application to add the new contractor.

SPML <addRequest> messages are automatically (controlled by workflow) sent to the appropriate Customer applications.

The standardized nature of SPML ensures that the Requesting Authorities (RA), Provisioning Service Points (PSP), and Provisioning Service Targets (PST) need not be from the same vendor.

Entrust GetAccess plays the role of a PST in the interoperability scenario. Entrust GetAccess will accept and validate SPML <addRequest> messages and then create appropriate accounts such that the subject contractor will be able to subsequently access the Entrust GetAccess protected information resources and applications.

Security Considerations

As the Customers will grant access to their information systems based on the SPML provisioning requests they receive from the Supplier - the security of these messages is critical. SPML does not stipulate a particular technology or protocol for securing the SPML messages. Rather, SPML leverages other existing and emerging mechanisms and standards.

The general security requirements for a message are:

• Authentication
  • how can a Customer be confident that an SPML message does indeed come from the Subscriber? (Message authentication can be achieved through XML Signatures - supported through both the Entrust Authority Toolkit for Java and Entrust Secure Transaction Platform Verification Server)
  • how can the Supplier ensure that only strongly authenticated administrators are able to access the HR Identity Management system. (Strong authentication and auditability for administrators can be provided through Entrust TruePass)
• Confidentiality
  • how can the Supplier ensure that only the appropriate Customers can view a contractor's identity information? (Message Confidentiality can be ensured through the use of XML Encryption afforded by the Entrust Authority Toolkit for Java)
• Integrity
  • how can a Customer be sure that an SPML message it received was not tampered with in transit? (Message integrity can be achieved through XML Signatures - supported through both the Entrust Authority Toolkit for Java and Entrust Secure Transaction Platform Verification Server)
• Authorization
  • how can a Customer be sure that it acts on the requests only of appropriately authorized Suppliers? (Request Authorization can be controlled through Entrust GetAccess)
  • how can the Supplier ensure that only authorized administrators are able to access the HR system from which provisioning requests are instigated. (Administrator Authorization can be controlled through Entrust GetAccess)

To address the limitations of transport-layer security mechanisms like SSL for addressing certain of these requirements, standards are emerging that define security protection at the message-layer. WS-Security (under standardization at OASIS) is a proposal for adding security information to SOAP messages, standardizing how this information (e.g. X.509 certificates, Kerberos tickets, SAML assertions, XML Signatures, etc) is added to the SOAP <Header> element in order to protect the fundamental payload within the SOAP <Body>.