Name ID Claim type

Category: azure security

Question

D039113 on Fri, 06 May 2011 15:45:13


I'm trying to configure ACS to issue a SAML2 token which includes a NameIdentifier element for usage with WebService . This should look like

...
<saml:AuthenticationStatement AuthenticationInstant="2011-03-10T02:04:26Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password">
<saml:Subject>
<saml:NameIdentifier Format="http://schemas.xmlsoap.org/claims/UPN">XXXXXXXXX@Live.com</saml:NameIdentifier></saml:Subject>
</saml:AuthenticationStatement>
...

(Example taken from http://msdn.microsoft.com/en-us/library/gg185950.aspx).

When using AD FS 2.0, I'd configure a rule with:

LDAP Attribute: SAM Account name
Outgoing Claim Type: Name ID

But for ACS, I don't see any option to configure a Name ID claim.

Authentication is done with u/pw of a ACS service identitiy. The complete setup is:

1) WCF client obtains SAML2 token from ACS and authenticates with u/pw

2) WCL client sends SOAP message with SAML Assertion to an SAP system

Any recommendation on how to include the NameIdentifier element in the SAML 2 Assertion?


Replies

Oren Melzer on Fri, 06 May 2011 19:30:51


When you authenticate to ACS using a Service Identity, a name identifier claim is generated, issued by ACS ("LOCAL AUTHORITY" if you're using the management service).  So to do what you want, you just need a rule to pass through the NameIdentifier from ACS.  The name you get out will be the configured name of the service identity.

D039113 on Tue, 10 May 2011 20:01:51


I succeeded with that one. When using a SAML 1.1 assertion, things work fine now. However, when using a SAML 2.0 assertion, the SAP implementation expects an AuthnStatement with the information how the authentication was done at the ACS.

What rule do I need to configure to get an AuthnStatement included in the Assertion?

billb08 - MSFT on Fri, 13 May 2011 20:08:15


Hi,

This question is going to be best answered via Azure Support due to time involved to determine.

Please go to the Azure support link and click on the Windows Azure under Platform and Developer Support

http://www.microsoft.com/windowsazure/support/


bill boyce

Peter Williams (Security Engineer) on Wed, 14 Nov 2012 17:23:06


you have to include an authenticationtimestamp claim.

...sigh.

Its the only way to make WIF/ACS stuff act like an old PRIP-complying ws-fedp implementation - such as the servers we have in our farm. The WIF team didn't seem to give a damn about the topic, online or in person. There seemed an intent to deflect the issue (such interworking was "not desired", but we cannot say that formally).

Of course, typically the underlying reason is more simple (than the evil conjecture). I just don't know what it is, so am left with worst case conjecturing.

Peter Williams (Security Engineer) on Fri, 19 Apr 2013 23:56:33


I succeeded with that one. When using a SAML 1.1 assertion, things work fine now. However, when using a SAML 2.0 assertion, the SAP implementation expects an AuthnStatement with the information how the authentication was done at the ACS.

What rule do I need to configure to get an AuthnStatement included in the Assertion?

What used to work no longer does. One  used to be able to insert an authenticationInstanct and authenticationMethod claim (by ACS) that would induce, along with the nameidentifier claim, an authenticationStatement REQUIRED by many vendors.

If you note Azure AD continues to make the same VENDOR-BREAKING practices regarding authenticationstatements and [microsoft missing] subjects within.

If im dissonant, its a vendor playing games with the market, by playing with non-interoperability. Some shades of old Microsoft never die, apparently.