"Dynamic" SAML

In an article at http://www.computer.org Patrick Harding, Leif Johansson, and Nate Klingenstein talk about a way to reduce the time to deploy SAML-based projects.
Dynamic SAML reduces this time through the exchange of configuration information via the metadata:

Dynamic SAML takes advantage of security best practices and the exchange of configuration information to minimize the manual steps that administrators must currently perform to configure SAML connections securely. Although it isn’t yet possible to completely automate a decision of human trust, dynamic SAML can automate the underlying exchanges to make this decision fast, simple, and secure.

Dynamic SAML simplifies the trust establishment between two partners because it allows you to send your keys used to sign and validate SAML SSO messages with the metadata:

Dynamic SAML prescribes that the partner keys used to sign and validate SAML SSO messages are included in the SAML metadata document. Trust in these keys is derived from the established trust in the metadata document itself. In effect, dynamic SAML moves trust management from a runtime issue (applicable to each protocol message) to a configuration-time issue (applicable to the overall metadata document).

Dynamic SAML is also automating the metadata exchange so that partners can retrieve the metadata when needed.

Dynamic SAML handles about the Metadata exchange and how this can help to reduce deployment times. The time reduced from creating partner connections is really signifcant and will absolutely help reducing the overal time.

Source: Patrick Harding, Leif Johansson, and Nate Klingenstein, "Dynamic Security Assertion Markup Language: Simplifying Single Sign-On, " IEEE Security & Privacy, vol. 6, no. 2, March/April 2008, pp. 83-85.

Server Encryption key

When you setup a development and testing environment with Sun Identity Manager, you are going to get some problems with Server Encryption Keys when you try to import encrypted objects from one server instance into the other.

Server encryption keys are symmetric, triple-DES 168-bit keys. A server can have more then one key. Every encrypted object is prefixed by the ID of the encryption server that is used. So Identity Manager knows which Server Encryption Key to use.

For the testing and development environment it's usefull to have the same encryption keys so you can exchange your encrypted objects without much effort. You can use the Manage Encryption Key feature to create new encryption keys, export them and re-encrypt the objects with the current encryption key. This feature doesn't allow you to set the current encryption key to a specific imported encryption key. So it can't help us to get the same key on both the test and development installation.

For this problem we had to make a custom workflow that invoked a custom java class. The java class just gets and sets the current Server Encryption Key. The workflow displays the current key and a drop-down-box to pick your new Current Server Encryption Key. Once you imported the new Server Encryption Key (through import exchange file) and set it to the current key, you can re-encrypt all objects with this current key through the Manage Server Key feature.
With this solution you can have the same Server Encryption Key on all your Identity Manager instances.

Roles become cards ?

I agree with Dave Kearns when he says

Good post today ("No User Context Decisions in your Enterprise?") from Pam Dingle ...

Situations #1 and #4 in Pam's post are theoretically resolved using a role based access control approach. This leads me to the following two questions:

1. Does role equal context ?
2. Do (virtual) cards become a convenient means for activating one's role ?
   

Answering my own questions, I would say "yes" for both situations.