Hi, In addition to the profile Id claim, I found some other gaps in the current specification that should be addressed before starting doing the interop testing between the different implementations. I can update the specification If we all agree on making these changes.
1. The active STS is who initially add the profile ID into the SAML token that the business services will use. However, the passive STS needs to pass some claims in the ActAs token to the Active STS, so this one can resolve the profile ID in the StockTrader DB. I think we could use a "Name" claim, so the Active STS can use that claim to look for the profile ID in the DB. For example, Name => Profile Id "John Foo" => uid:0 "John Bar" => uid:1 This info should be stored in the StockTraderDB. The identifier for the claim name could be "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"; Or we could simply assume that the Passive STS and Active STS uses the profile id claim, so the passive STS adds the profile id claim to the original SAML token, and the Active STS just copies that claim into the ActAs token that will be used by the services 2. We need to define the security policy that the Web application uses to request the ActAs token to the active STS. Metro is currently using Username over Certificate. I think a client certificate would work better than an username, as usernames are more for identifying final users, and here the Active STS only wants to identify the client application (The Web trader application). So, the security policy would be Mutual Certificate (Client Certificate to identity the Web Application, and a Service Certificate provided by the Active STS to protect the communication) + ActAs Token representing the user claims. What do you all think about this, shall we use username over certificate or mutual certificate ? If we go with username over certificate, we need to define which username the web application will pass to the Active STS. If we go with Mutual Certificate, we can use the BSL.Com certificate as client certificate. Regarding the service certificate, I think we should create a new certificate for the ActiveSTS. This certificate can be either used to protect the communication with the web application, and to sign the SAML tokens. I can create a new certificate "Broker.com" (or other name) issued by "Trade.com" (as the rest of the certificates) and make it available in the Jira ticket so the rest of the implementations can use it. 3. We need to define the certificate that the Passive STS will use to sign the tokens. Again, I can create a new certificate and make it available in the Jira ticket Thanks Pablo.
