Hi, I've been configuring Azure ACS for a SharePoint 2013 farm using this small step by step. http://blah.winsmarts.com/2011-12-Integrate_Azure_ACS_with_SharePoint_in_2_minutes_or_less.aspx First thing, it seems that the author made a mistake for the claim mapping, so i replaced "Email" by "EmailAddress". (i had an error message in Windows events saying something like "The trusted login provider did not supply a token accepted by this farm") Once that fixed, i've been able to authentify via Google but not via live. So I went to the rules groups (in ACS admin console) and changed the output claim type to emailaddress. (a weird thing, in incomming types i only have the choice of "nameidentifier"). Since then, I have no more error messages (including SharePoint logs) but loging in via Live leads to a "this site is not shared with you" message (but the autorization is set in people and groups). Please find below the SAML token. <wst:RequestSecurityTokenResponse xmlns:wst=&quot;http://schemas.xmlsoap.org/ws/2005/02/trust&quot;><wst:RequestedSecurityToken> <saml:Assertion xmlns:saml=&quot;urn:oasis:names:tc:SAML:1.0:assertion&quot; AssertionID=&quot;uuid-b078262b-fcea-41af-88ca-c8b9f44f0b99&quot; IssueInstant=&quot;2012-11-20T04:04:22Z&quot; Issuer=&quot;uri:WindowsLiveID&quot; MajorVersion=&quot;1&quot; MinorVersion=&quot;1&quot;> <saml:Conditions NotBefore=&quot;2012-11-20T04:04:23Z&quot; NotOnOrAfter=&quot;2012-11-20T12:04:23Z&quot;> <saml:AudienceRestrictionCondition> <saml:Audience>accesscontrol.windows.net</saml:Audience> </saml:AudienceRestrictionCondition> </saml:Conditions> <saml:AuthenticationStatement AuthenticationInstant=&quot;2012-11-19T23:08:01Z&quot; AuthenticationMethod=&quot;urn:oasis:names:tc:SAML:1.0:am:password&quot;> <saml:Subject> <saml:NameIdentifier Format=&quot;http://schemas.xmlsoap.org/claims/UPN&quot;>0006000008142BD63@Live.com</saml:NameIdentifier> </saml:Subject> </saml:AuthenticationStatement> <saml:AttributeStatement> <saml:Subject> <saml:NameIdentifier Format=&quot;http://schemas.xmlsoap.org/claims/UPN&quot;>0006000008142BD63@Live.com</saml:NameIdentifier> </saml:Subject> <saml:Attribute AttributeName=&quot;Managed&quot; AttributeNamespace=&quot;http://schemas.xmlsoap.org/claims&quot;> <saml:AttributeValue>TRUE</saml:AttributeValue> </saml:Attribute> <saml:Attribute AttributeName=&quot;Child&quot; AttributeNamespace=&quot;http://schemas.xmlsoap.org/claims&quot;> <saml:AttributeValue>FALSE</saml:AttributeValue> </saml:Attribute> <saml:Attribute AttributeName=&quot;TOUAccepted&quot; AttributeNamespace=&quot;http://schemas.xmlsoap.org/claims&quot;> <saml:AttributeValue>TRUE</saml:AttributeValue> </saml:Attribute> <saml:Attribute AttributeName=&quot;CID&quot; AttributeNamespace=&quot;http://schemas.xmlsoap.org/claims&quot;> <saml:AttributeValue>dfe1cdd940359b2d</saml:AttributeValue> </saml:Attribute> <saml:Attribute AttributeName=&quot;EmailAddress&quot; AttributeNamespace=&quot;http://schemas.xmlsoap.org/claims&quot;> <saml:AttributeValue>me@hotmail.com</saml:AttributeValue> </saml:Attribute> <saml:Attribute AttributeName=&quot;PUID&quot; AttributeNamespace=&quot;http://schemas.xmlsoap.org/claims&quot;> <saml:AttributeValue>0006000008142BD63</saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> <Signature xmlns=&quot;http://www.w3.org/2000/09/xmldsig#&quot;> <SignedInfo> <CanonicalizationMethod Algorithm=&quot;http://www.w3.org/2001/10/xml-exc-c14n#&quot;></CanonicalizationMethod> <SignatureMethod Algorithm=&quot;http://www.w3.org/2000/09/xmldsig#rsa-sha1&quot;></SignatureMethod> <Reference URI=&quot;#uuid-b078262b-fcea-41af-88ca-c8b9f44f0b99&quot;> <Transforms> <Transform Algorithm=&quot;http://www.w3.org/2000/09/xmldsig#enveloped-signature&quot;></Transform> <Transform Algorithm=&quot;http://www.w3.org/2001/10/xml-exc-c14n#&quot;></Transform> </Transforms> <DigestMethod Algorithm=&quot;http://www.w3.org/2000/09/xmldsig#sha1&quot;></DigestMethod> <DigestValue>7DIBPHI9VhEdoyjgsImH827yono=</DigestValue> </Reference> </SignedInfo> <SignatureValue>41kMRhSXDX7x8VENG8UUU4QvsnO84vgQ23caX2SysKY3eLQxjqwo92ClEvaa0Sa010dUCknyd7DBdbpz4w7eFSXNSltYaYoiHgH8ubzeHtaZjVKAKQKHHSCWzctAEC+R3mUj2PcPFNnQIZpds2pG+XoYSWPaj73TZ5hWXgsvXfc=</SignatureValue> <KeyInfo> <X509Data><X509SKI>H1D81qx0njcaeJ3fI6gkm6N/jpA=</X509SKI></X509Data><KeyName>Window Live ID</KeyName></KeyInfo></Signature></saml:Assertion></wst:RequestedSecurityToken><wsp:AppliesTo xmlns:wsp=&quot;http://schemas.xmlsoap.org/ws/2004/09/policy&quot;><wsa:EndpointReference xmlns:wsa=&quot;http://schemas.xmlsoap.org/ws/2004/08/addressing&quot;><wsa:Address>http://accesscontrol.windows.net</wsa:Address></wsa:EndpointReference></wsp:AppliesTo></wst:RequestSecurityTokenResponse> Thanks for helping! PS: another thing that made my day in configuring ACS is this resource: http://blogs.southworks.net/fboerr/2011/04/15/sliding-sessions-in-sharepoint-2010/ Cya

>> loging in via Live leads to a "this site is not shared with you" message (but the autorization is set in people and groups). How did you grant permission to Live users? assign permission with which claim? And what is the claim mapping for your on-premise SharePoint farm? you can check it with powershell: $T=Get-SPTrustedIdentityTokenIssuer $T[0].claimtypeinformation It can be $T[0] or $T[1] or $T[x] depending on your specific case

>> loging in via Live leads to a "this site is not shared with you" message (but the autorization is set in people and groups). How did you grant permission to Live users? assign permission with which claim? And what is the claim mapping for your on-premise SharePoint farm? you can check it with powershell: $T=Get-SPTrustedIdentityTokenIssuer $T[0].claimtypeinformation It can be $T[0] or $T[1] or $T[x] depending on your specific case

Hi GuYuming, Thank you for helping! Update : Facebook also works via ACS, live is still missing. It appears that Live provider via ACS doesn't share the user's e-mail address as discribed here http://msdn.microsoft.com/en-us/library/gg185944.aspx This is sad because all other services do it. So when i give an autorisation i give it to someone@hotmail.com. The fact is live provider only shares the user's Public UID (type nameidentifier). My provider is configured to use only emailaddress in mapping (and so as the principal claim). And i changed the live id claim rule to convert the nameidentifier to emailaddress in ACS portal. (otherwise i get the "no supported claim" error message), but that's not the user's email transmitted, in facts it's his PUID. This is why it doesn't work. It would be very helpfull that Microsoft changes this and also tranmits user's e-mail address as a claim in the token. (because now we don't have a solution for "i want to set the permission because i have user's liveid e-mail address and i want him to be able to authentify via live id") This is well explained on that ACS post http://social.msdn.microsoft.com/Forums/en/windowsazuresecurity/thread/b83796ac-76e9-432c-b356-47870833b10b The only solution would be to use this old trick but it's complicated, it requires a Microsoft's manual approval and it seems that it will be soon deprecated (replaced by ACS) http://technet.microsoft.com/en-us/library/ff973117.aspx If i forgot something or missed information, just tell me, i would be very cool to have a solution as easy as ACS working properly for that use case. Thanks!Cya

Hi GuYuming, Thank you for helping! Update : Facebook also works via ACS, live is still missing. It appears that Live provider via ACS doesn't share the user's e-mail address as discribed here http://msdn.microsoft.com/en-us/library/gg185944.aspx This is sad because all other services do it. So when i give an autorisation i give it to someone@hotmail.com. The fact is live provider only shares the user's Public UID (type nameidentifier). My provider is configured to use only emailaddress in mapping (and so as the principal claim). And i changed the live id claim rule to convert the nameidentifier to emailaddress in ACS portal. (otherwise i get the "no supported claim" error message), but that's not the user's email transmitted, in facts it's his PUID. This is why it doesn't work. It would be very helpfull that Microsoft changes this and also tranmits user's e-mail address as a claim in the token. (because now we don't have a solution for "i want to set the permission because i have user's liveid e-mail address and i want him to be able to authentify via live id") This is well explained on that ACS post http://social.msdn.microsoft.com/Forums/en/windowsazuresecurity/thread/b83796ac-76e9-432c-b356-47870833b10b The only solution would be to use this old trick but it's complicated, it requires a Microsoft's manual approval and it seems that it will be soon deprecated (replaced by ACS) http://technet.microsoft.com/en-us/library/ff973117.aspx If i forgot something or missed information, just tell me, i would be very cool to have a solution as easy as ACS working properly for that use case. Thanks!Cya

Hi GuYuming, Thank you for helping! Update : Facebook also works via ACS, live is still missing. It appears that Live provider via ACS doesn't share the user's e-mail address as discribed here http://msdn.microsoft.com/en-us/library/gg185944.aspx This is sad because all other services do it. So when i give an autorisation i give it to someone@hotmail.com. The fact is live provider only shares the user's Public UID (type nameidentifier). My provider is configured to use only emailaddress in mapping (and so as the principal claim). And i changed the live id claim rule to convert the nameidentifier to emailaddress in ACS portal. (otherwise i get the "no supported claim" error message), but that's not the user's email transmitted, in facts it's his PUID. This is why it doesn't work. It would be very helpfull that Microsoft changes this and also tranmits user's e-mail address as a claim in the token. (because now we don't have a solution for "i want to set the permission because i have user's liveid e-mail address and i want him to be able to authentify via live id") This is well explained on that ACS post http://social.msdn.microsoft.com/Forums/en/windowsazuresecurity/thread/b83796ac-76e9-432c-b356-47870833b10b The only solution would be to use this old trick but it's complicated, it requires a Microsoft's manual approval and it seems that it will be soon deprecated (replaced by ACS) http://technet.microsoft.com/en-us/library/ff973117.aspx If i forgot something or missed information, just tell me, i would be very cool to have a solution as easy as ACS working properly for that use case. Thanks!Cya

In addition this is really silly that ACS doesn't transmit the email, beacause as you can see in my first post, Live tranmits it to ACS...Cya

In addition this is really silly that ACS doesn't transmit the email, beacause as you can see in my first post, Live tranmits it to ACS...Cya