Sign in
Microsoft.com
 
Microsoft
 
 
 

locked
Dynamics CRM Customer Portal ACS Authentication sends me in loop RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    I've set up the new version of the customer portal (1.0.0013) and find my question is somewhat similar to other authentication questions, but different enough that it probably should be a new thread. I'm watching http://social.microsoft.com/Forums/en/crmlabs/thread/99d35e87-0965-45d4-a297-565cbf4558cf but that is not resolved and the customer portal does not seem to use the service certificate in the web.config.

    I am able to send out the invitation code. If I follow this link I am prompted for the question response that I have provided. I enter the response and I am directed to sign in. This screen looks as it should and I choose LiveID and sign in. After this I am back to the invitation page and directed to enter the code, then the response, then the login, and around and around. I am including the relevant portions of the webconfig below with appname (namespace is the same) and thumbprint removed.

     <appSettings>
        <add key="FederationMetadataLocation" value="https://[myapp].accesscontrol.windows.net/FederationMetadata/2007-06/FederationMetadata.xml"/>
      </appSettings>


     <microsoft.identityModel>
        <service>
          <audienceUris>
            <add value="http://[myapp].cloudapp.net/"/>
          </audienceUris>
          <federatedAuthentication>
            <wsFederation passiveRedirectEnabled="false" issuer="https://[myapp].accesscontrol.windows.net/v2/wsfederation" realm="http://[myapp].cloudapp.net/" requireHttps="false"/>
            <cookieHandler requireSsl="false"/>
          </federatedAuthentication>
          <issuerNameRegistry type="Microsoft.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
            <trustedIssuers>
              <add thumbprint="[thumbprint from azure]" name="https://[myapp].accesscontrol.windows.net/"/>
            </trustedIssuers>
          </issuerNameRegistry>
          <certificateValidation certificateValidationMode="None"/>
        </service>
      </microsoft.identityModel>

     

    I believe that I have followed all the set up steps for the of the Access Control Service including adding the new rule group, and my return path is : http://[myapp].cloudapp.net/federation.axd

    If no one else is having this problem, then I am guessing I did something simple wrong, but I am not seeing it. Does anyone have any suggestions?

    Thank you.

     

    Thursday, January 5, 2012 5:00 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote
    Is the invitationCodeKey attribute of the <registration/> element being set to a custom value in the web.config? I've identified a bug in the custom portal website that would cause the behavior you are describing (which will be fixed in the next custom portal release). If so there are two approaches:
    1) Take out the custom invitation code key name. In this case, you will need to make sure emails that are sent out with invitation URLs use the correct default of "invitation".
    For example: http://contoso.cloudapp.net/confirm-invite?invitation=ABCDEFG
    2) Fix the ConfirmInvite.aspx.cs page. Update line 134 to look like:
    fam.RedirectToSignIn(Context, returnUrl, invitationCode, null, RegistrationSettings);

    and also update line 190 to:
    fam.RedirectToSignIn(Context, returnUrl, invitation, answer, RegistrationSettings);
    If the error persists, take a look at the details of POST requests in the Trace.axd for indication of errors.
    Regarding the <serviceCertificate> configuration. This is not strictly required for ACS to work but where it is required is in Azure (where there are multiple role instances) and also in a web farm environement. It provides an encrpytion key that is consistent throughout the farm much like setting the <machineKey>.
    • Marked as answer by JCaulfield Monday, January 23, 2012 5:30 PM
    Monday, January 23, 2012 4:40 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    I have the same problem.

    Any suggestions?

    Sunday, January 15, 2012 11:42 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I don't have any suggestions. I haven't got this resolved yet. I tried everything I could think of before posting then moved on to another task, hoping someone would have some insight. I will post again if I do figure out what I am doing wrong. If anybody has this working correctly, could you post and let me know, even if you don't know why mine isn't working. I'd feel better delving into it again if I know that there is a hope of getting it right if I go back through it.

    Thank you.

    Monday, January 16, 2012 4:25 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    After adding the rule group, did you also generate default claims for the group? See the "Generate Rules for the Rule Group" section from here for details.
    Wednesday, January 18, 2012 5:33 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi, John,

    I did add the rules. It looks like this:

    <form id="form1" action="/v2/mgmt/web/Claim/Delete" method="get">
    Rules
    <input id="SelectAll" name="SelectAll" type="checkbox" value="true" /><input name="SelectAll" type="hidden" value="false" /> Output Claim Claim Issuer Rule Description
    <input name="IdCheckBox" type="checkbox" value="11186275" /> emailaddress Google Passthrough "emailaddress" claim from Google as "emailaddress"
    <input name="IdCheckBox" type="checkbox" value="11186279" /> emailaddress Yahoo! Passthrough "emailaddress" claim from Yahoo! as "emailaddress"
    <input name="IdCheckBox" type="checkbox" value="11186274" /> name Google Passthrough "name" claim from Google as "name"
    <input name="IdCheckBox" type="checkbox" value="11186278" /> name Yahoo! Passthrough "name" claim from Yahoo! as "name"
    <input name="IdCheckBox" type="checkbox" value="11186276" /> nameidentifier Google Passthrough "nameidentifier" claim from Google as "nameidentifier"
    <input name="IdCheckBox" type="checkbox" value="11186277" /> nameidentifier Windows Live ID Passthrough "nameidentifier" claim from Windows Live ID as "nameidentifier"
    <input name="IdCheckBox" type="checkbox" value="11186280" /> nameidentifier Yahoo! Passthrough "nameidentifier" claim from Yahoo! as "nameidentifier"
    </form>
                        
    I had noticed that the certificate section is different in the adx portal and the microsoft free one. Specifically the section:
    <issuerNameRegistry>
    15. <trustedIssuers>
    16. <add thumbprint="[Thumbprint]" name="https://[Service Namespace].accesscontrol.windows.net/" />
    17. </trustedIssuers>
    18. </issuerNameRegistry>
    19. <serviceCertificate>
    20. <certificateReference x509FindType="FindByThumbprint" findValue="[Cookie Encrpytion Certificate Thumbprint]"/>
    21. </serviceCertificate>       
    vs.
     
    <issuerNameRegistry type="Microsoft.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
         <trustedIssuers>
           <add thumbprint="[thumbprint from azure]" name="https://[myapp].accesscontrol.windows.net/"/>
         </trustedIssuers>
       </issuerNameRegistry>
    If you have a portal working, is it the commercial adx version or the newest microsoft distributed version?  Thank you for your help.
    Wednesday, January 18, 2012 6:53 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Is the invitationCodeKey attribute of the <registration/> element being set to a custom value in the web.config? I've identified a bug in the custom portal website that would cause the behavior you are describing (which will be fixed in the next custom portal release). If so there are two approaches:
    1) Take out the custom invitation code key name. In this case, you will need to make sure emails that are sent out with invitation URLs use the correct default of "invitation".
    For example: http://contoso.cloudapp.net/confirm-invite?invitation=ABCDEFG
    2) Fix the ConfirmInvite.aspx.cs page. Update line 134 to look like:
    fam.RedirectToSignIn(Context, returnUrl, invitationCode, null, RegistrationSettings);

    and also update line 190 to:
    fam.RedirectToSignIn(Context, returnUrl, invitation, answer, RegistrationSettings);
    If the error persists, take a look at the details of POST requests in the Trace.axd for indication of errors.
    Regarding the <serviceCertificate> configuration. This is not strictly required for ACS to work but where it is required is in Azure (where there are multiple role instances) and also in a web farm environement. It provides an encrpytion key that is consistent throughout the farm much like setting the <machineKey>.
    • Marked as answer by JCaulfield Monday, January 23, 2012 5:30 PM
    Monday, January 23, 2012 4:40 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thank you so much, John. You are correct. Originally I wasn’t getting the invitation screen at all (as the workflow parameter was set to Invitation Code), so after a quick Google search I found your suggestion in another thread (for the partner portal) to add the InvitationCodeKey=InvitationCode to my web.config. This of course got me closer to the desired behavior for the customer portal as well so that I thought of as a step in the solution and forgot to even mention that I had made that change. Can’t believe that I didn’t note that, but it seemed like progress at the time. Per your reply, I took the “InvitationCodeKey=InvitationCode “out of my web.config and changed my workflow to send out with “Invitation” instead of InvitationCode and the portal is working.

    Thank you for you help and I apologize for leaving out key information!

    Monday, January 23, 2012 5:30 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi!

    I was hoping to obtain some direction, I have made the changes in the ConfirmInvite.aspx.cs to both line 134 and 190. Upon signing in with LiveID, I continue to cycle to provide and invitation code. Any assistance you could lend is appreciated, please see description below:

    Removed from microsoft.xrm.portal.identityModel in Web.config:

     invitationCodeKey="InvitationCode"/>

     and replaced CRM invitation workflow with:

     http://xband.cloudapp.net/login?Invitation={(Contact)}

     File ConfirmInvite.aspx.cs:

     Line 134:

    Appended:         fam.RedirectToSignIn(Context, returnUrl, invitationCode, null);

    With:         fam.RedirectToSignIn(Context, returnUrl, invitationCode, null, RegistrationSettings);

    Line 190:

    Appended:     fam.RedirectToSignIn(Context, returnUrl, invitation, answer);

    With:         fam.RedirectToSignIn(Context, returnUrl, invitation, answer, RegistrationSettings);

    Monday, April 2, 2012 5:12 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi, XbandNet,

    Sorry, I haven't checked this thread in a while. Did you get your portal working? From your reply, it looks like you did both approaches that John suggested. I think only one is necessary. I used approach 1 and left the confirminvite file alone. If you don't have yours working yet, are you using the customer or partner portal? I haven't looked at this since mine started working, but I'd be happy to delve into it if you still need help.

    Thursday, April 19, 2012 11:08 PM