UPDATE: Please review the comments for this post. There is a better, easier way to do this using OAuth that works with both the SOAP and REST/OData service.
Sometimes you need to run ASP.NET code outside of Dynamics CRM to achieve your goals. This usually manifests itself either as a page embedded in CRMs main content area which is accessible via a link in the sitemap similar to the following:
Another place this is often used is embedding external content through an IFrame in a CRM form. The general approach is covered in the SDK:
Implement Single Sign-on from an ASPX Webpage or IFRAME
Walkthrough: Single Sign-on from a Custom Web Page
Of course, your code will usually need to call back into Dynamics CRM through the organization (web) service to do things like CRUD on CRM data, etc. In this scenario, you want CRM to execute code under the context of the logged in user. The CRM SDK covers how to do this here:
Sample: Impersonate Using the ActOnBehalfOf Privilege
See my CRM Online & Windows Azure Series post for a walkthrough of the Single Sign On (SSO) configuration. The goal of this post is to bring all of these concepts together in as simple of a “hello world” style code sample as possible. The sample code is actually the code for the embedded page in the screenshot above (called ActOnBehalfOf.aspx). The solution is made up of an ASP.NET web form, some code behind the web form, and a helper class I built. In order to get this code to compile, you are going to have to add the necessary .NET assembly references and fix some of the namespaces. I’ll leave that exercise to you.
ActOnBehalfOf.aspx:
<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="ActOnBehalfOf.aspx.cs" Inherits="AdfsEnabledReportViewerWebRole.ActOnBehalfOf" %>
<html>
<head runat="server">
<title></title>
</head>
<body>
<form id="form1" runat="server">
<div>
<asp:GridView ID="GridView1" runat="server" AutoGenerateColumns="False">
<Columns>
<asp:BoundField DataField="Id" HeaderText="Id" />
<asp:BoundField DataField="Name" HeaderText="Name" />
</Columns>
</asp:GridView>
</div>
</form>
</body>
</html>
ActOnBehalfOf.aspx.cs:
1: using System;
2: using System.Linq;
3: using Microsoft.Xrm.Client;
4: using Microsoft.Xrm.Sdk.Client;
5:
6: namespace AdfsEnabledReportViewerWebRole
7: {
8: public partial class ActOnBehalfOf : System.Web.UI.Page
9: {
10: protected void Page_Load(object sender, EventArgs e)
11: {
12: var contextConnection = ActOnBehalfOfHelper.CreateContextAndConnection();
13: CrmConnection conn = contextConnection.Connection;
14: OrganizationServiceContext ctx = contextConnection.Context;
15:
16: // CallierId is what forces CRM to execute the API calls within the security context of the CRM User
17: conn.CallerId = ActOnBehalfOfHelper.GetCallerId();
18:
19: var accountQuery = from a in ctx.CreateQuery<Account>()
20: select new Account
21: {
22: Id = a.Id,
23: Name = a.Name
24: };
25:
26: var accounts = accountQuery.ToList();
27:
28: GridView1.DataSource = accounts;
29: GridView1.DataBind();
30: }
31: }
32: }
If you’ve reviewed the resources in this post, then ActOnBehalfOf.aspx and ActOnBehalfOf.aspx.cs should be pretty self explanatory. It’s a page with a GridView. The code behind queries CRM for data using the organization service. Note that Account from line 19 comes from a class file where I used crmsvcutil.exe to generate the class. I always use Erik Pool’s approach to only generate classes I need in my code. I digress. The code sets the CallerId property of the CrmConnection object instance before executing the code. By doing this, CRM will execute all calls made to through the OrganizationServiceContext instance as the CRM user based on the CallerId value passed in. CallerId is the GUID of the CRM user who needs to be impersonated. The ActOnBehalfOfHelper does the real work to get the proper GUID based on the claims available to the ASP.NET page. Specifically, it uses the UPN claim value to find the CRM user. Once the CRM user is found, the code returns the Id of the CRM user as a GUID.
ActOnBehalfOfHelper.cs:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using Microsoft.IdentityModel.Claims;
using Microsoft.Xrm.Client;
using Microsoft.Xrm.Client.Services;
using Microsoft.Xrm.Sdk.Client;
namespace AdfsEnabledReportViewerWebRole
{
public static class ActOnBehalfOfHelper
{
// ReSharper disable InconsistentNaming
private const string CRM_CALLERID = "CRM_CALLERID";
// ReSharper restore InconsistentNaming
public static ContextConnection CreateContextAndConnection()
{
var contextConnection = new ContextConnection();
// Connect to CRM with a single named user (i.e. system account / trusted subsystem model) who has the ActOnBehalfOf privelege
contextConnection.Connection =
CrmConnection.Parse("Url=[YOUR_ORG_URL];Username=[YOUR_USERNAME];Password=[YOUR_PASSWORD]");
contextConnection.Context =
new OrganizationServiceContext(new OrganizationService(contextConnection.Connection));
return contextConnection;
}
public static Guid GetCallerId()
{
Guid callerId;
var contextConnection = CreateContextAndConnection();
var ctx = contextConnection.Context;
// NOTE: I am caching the CallerId to minimize calls to the CRM Organization Service.
// For production code, you should not store the CallerId in plain text in a cookie.
// Malicious code, once authenticated, can change the cookie value and execute as another caller.
// You could apply encryption when creating the cookie and decryption when reading
// the cookie value:
// http://msdn.microsoft.com/en-us/library/windowsazure/hh697511.aspx
// You could even encrypt/decrypt the cookie name to obfuscate the purpose of the cookie.
// Alternatively, find a different approach to cache the CallerId value (ASP.NET Session for example)
// or simply don't cache the CallerId.
HttpCookie callerIdCookie = HttpContext.Current.Request.Cookies[CRM_CALLERID];
// If the cookie exists, reuse the Guid string value to execute the call as the current user
// If not, then query CRM to get the Guid of the authenticated user based on the upn claim
if (callerIdCookie == null)
{
ClaimCollection claims = ((IClaimsIdentity) HttpContext.Current.User.Identity).Claims;
IEnumerable<Claim> claimQuery = from c in claims
where
c.ClaimType ==
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"
select c;
Claim upnClaim = claimQuery.FirstOrDefault();
var userQuery = from user in ctx.CreateQuery<SystemUser>()
where user.DomainName == upnClaim.Value
select user.SystemUserId.Value;
callerId = userQuery.FirstOrDefault();
if (callerId == Guid.Empty)
{
// Send HTTP status code of 403
// See http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
HttpContext.Current.Response.StatusCode = 403;
HttpContext.Current.Response.End();
}
string callerIdString = callerId.ToString();
HttpContext.Current.Response.Cookies.Add(new HttpCookie(CRM_CALLERID, callerIdString));
}
else
{
callerId = new Guid(callerIdCookie.Value);
}
return callerId;
}
}
public class ContextConnection
{
public CrmConnection Connection { get; set; }
public OrganizationServiceContext Context { get; set; }
}
}
Note the comments in the code. I am doing some caching of the user GUID in a cookie. Right now, the cookie and cookie value is in plain text. As I state, this is done for simplicity of the sample. Make sure you read the comments and make the proper adjustments to protect access to the CallerID GUID from malicious code/callers.
Gold Coast 