Dynamics CRM Customer Portal ACS Authentication sends me in loop

תשובה Dynamics CRM Customer Portal ACS Authentication sends me in loop

  • quinta-feira, 5 de janeiro de 2012 17:00
     
     

    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.

     

Todas as Respostas

  • domingo, 15 de janeiro de 2012 11:42
     
     

    I have the same problem.

    Any suggestions?

  • segunda-feira, 16 de janeiro de 2012 16:25
     
     

    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.

  • quarta-feira, 18 de janeiro de 2012 17:33
     
     
    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.
  • quarta-feira, 18 de janeiro de 2012 18:53
     
      Contém Código

    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.
  • segunda-feira, 23 de janeiro de 2012 16:40
     
     Respondido Contém Código
    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>.
    • Marcado como Resposta JCaulfield segunda-feira, 23 de janeiro de 2012 17:30
    •  
  • segunda-feira, 23 de janeiro de 2012 17:30
     
     

    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!

  • segunda-feira, 2 de abril de 2012 05:12
     
     

    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);

  • quinta-feira, 19 de abril de 2012 23:08
     
     

    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.