A few weeks ago I wrote a post called "Custom WCF service authentication using Microsoft Dynamics CRM credentials" in which I showed how to secure Windows Communication Foundation (WCF) web services using Dynamics CRM usernames and passwords. In that post, I used a GenericIdentity object to store the CRM user information, but unfortunately the GenericIdentity class is extremely limited in the amount of user-related information it can hold, so in this post I will show how to create and use a custom identity object to represent CRM users. In addition to making it simple to store and use attributes like phone number, name and address, this will also allow you to easily enumerate a CRM user's roles or team assignments where necessary, which cannot be done directly with a GenericIdentity object.

Here's a visual depiction of how my custom WCF service authentication helps facilitate easier integration between external systems and a Dynamics CRM solution.

There are three things I want to cover in this post:

1. The custom identity class
2. Retrieving and storing user data in a custom identity object
3. Accessing the stored user data

The custom identity class

The CrmIdentity class implements the System.Security.Principal.IIdentity interface. My class includes the following public properties and methods:

public string Name

public string Email

public string FirstName

public string LastName

public Guid UserId

public string[] Teams

public string[] Roles

public bool IsAuthenticated

public string AuthenticationType

public void SetAuthenticated(bool authFlag)

public void AddRole(string roleName)

public void RemoveRole(string roleName)

public bool InRole(string roleName)

public void AddTeam(string teamName)

public void RemoveTeam(string teamName)

public bool InTeam(string teamName)

You can download the complete CrmIdentity class
here.

Retrieving and storing the user data

I've updated the Validate method from my original post to store the retrieved user attributes and roles in a CrmIdentity object. (Retrieving and storing teams is left as an exercise for the reader.) The CrmIdentity object is then used to create a GenericPrincipal object that will be used in the actual service class. Here is the updated Validate method:

public override void Validate(string username, string password)
{
	//get the httpcontext so we can store the user guid for impersonation later
	HttpContext context = HttpContext.Current;
	//if username or password are null, obvs we can't continue
	if (null == username || null == password)
	{
		throw new ArgumentNullException();
	}
	//get the crm connection
	Microsoft.Xrm.Client.CrmConnection connection = CrmUtils.GetCrmConnection(username, password);
	//try the whoami request
	//if it fails (user can't be authenticated, is disabled, etc.), the client will get a soap fault message
	using (OrganizationService service = new OrganizationService(connection))
	{
		try
		{
			WhoAmIRequest req = new WhoAmIRequest();
			WhoAmIResponse resp = (WhoAmIResponse)service.Execute(req);
			Entity systemuser = CrmUtils.GetSystemUser(resp.UserId, service);
			CrmIdentity crmIdentity = new CrmIdentity();
			crmIdentity.Name = (string)systemuser["fullname"];
			crmIdentity.FirstName = (string)systemuser["firstname"];
			crmIdentity.LastName = (string)systemuser["lastname"];
			crmIdentity.Email = (string)systemuser["emailaddress1"];
			crmIdentity.UserId = resp.UserId;
			crmIdentity.SetAuthenticated(true);
			List roles = CrmUtils.GetUserRoles(resp.UserId, service);
			foreach (string role in roles)
			{
				crmIdentity.AddRole(role);
			}
			context.User = new GenericPrincipal(crmIdentity, roles.ToArray());
		}
		catch (System.ServiceModel.Security.MessageSecurityException ex)
		{
			throw new FaultException(ex.Message); 
		}
		catch (Exception ex)
		{
			throw new FaultException(ex.Message);
		}
	}
}

Accessing the stored user data

Finally, when you want to access the stored user data inside your service, you access the current request's HttpContext object and cast its User.Identity object as a CrmIdentity object like so:

HttpContext context = HttpContext.Current;
CrmIdentity crmIdentity = (CrmIdentity)context.User.Identity;

How do you handle authentication and authorization for your custom Dynamics CRM solution web services? Would you find it easier to use a completely separate authorization mechanism? Let us know in the comments!

A version of this post was originally published on the HP Enterprise Services Application Services blog.

Last week I wrote a post called "Introducing the Diesel Xrm Service Wrapper," in which I presented a generic WCF wrapper for the Dynamics CRM Organization Service. Almost immediately I had several ideas about updates I wanted to make, so I've decided to host the project on GitHub. The project GitHub page is here, and you can find the code repository here.

Here's a current list of enhancements I plan to add over the coming months:

2. Storing query FetchXml and related configuration data as custom entities in Dynamics CRM
3. Role-based authorization for individual queries
4. Varying impersonation settings per individual query
5. Updates
6. REST/JSON interfaces

If you'd like to contribute or have any other interesting ideas, please drop me a line via my contact page.

Enterprise Microsoft Dynamics CRM implementations frequently require developing custom Windows Communication Foundation (WCF) web services to be used for integration with external systems. Typical use cases for custom web services would include situations in which a consuming system can't easily access the Dynamics CRM Organization Service, or a custom service is required to do some data processing above and beyond the capabilities of the CRM Organization Service. Because these custom web services are separate from the actual Dynamics CRM system, user authentication and authorization has to be handled via a separate mechanism.

In this post I will show how you can use a custom WCF username and password validator to authenticate consumers using their Dynamics CRM credentials. In addition to providing an easy-to-use authentication mechanism, this approach will give you the ability to authorize consumers’ access to web services based on their assigned Dynamics CRM roles.

There are three steps required to set up custom username and password validation for a WCF service:

1. Create the custom validator class
2. Update the service binding's security configuration
3. Update the service behavior to use the custom validator

Let's look at all three in more detail.

The custom validator

The custom validator is a class that inherits from the System.IdentityModel.Selectors.UserNamePasswordValidator class. That class contains a Validate method that we will need to override. The Validate method accepts two parameters, username and password, and if the validation fails, it throws a SecurityTokenException. If validation is successful, the method exits without returning anything.

In our custom validator class, we need to do the following:

1. Create a connection to the Dynamics CRM Organization Service via the CRM SDK
2. Execute a WhoAmIRequest using the provided user credentials
3. If successful, retrieve the CRM user roles and store the CRM systemuserid and roles in a GenericPrincipal object
4. If unsuccessful, throw an error

Here is the overridden Validate method:

///<summary>
/// Validate method to attempt to connect to CRM with supplied username/password and then execute a whoami request
/// </summary>
/// <param name="username">crm username</param>
/// <param name="password">crm password</param>
public override void Validate(string username, string password)
{
	//get the httpcontext so we can store the user guid for impersonation later
	HttpContext context = HttpContext.Current;
	//if username or password are null, obvs we can't continue
	if (null == username || null == password)
	{
		throw new ArgumentNullException();
	}
	//get the crm connection using the simplified connection string method
	// the following assumes the server url is stored in the web.config appsettings collection like so:
	// <add key="crmconnectionstring" value="Url=https://crm.example.com"/>
	string connectionString = ConfigurationManager.AppSettings["crmconnectionstring"];
	connectionString += " Username=" + username + "; Password=" + password;
	Microsoft.Xrm.Client.CrmConnection connection = CrmConnection.Parse(connectionString);
	//try the whoami request
	//if it fails (user can't be authenticated, is disabled, etc.), the client will get a soap fault message
	using (OrganizationService service = new OrganizationService(connection))
	{
		try
		{
			WhoAmIRequest req = new WhoAmIRequest();
			WhoAmIResponse resp = (WhoAmIResponse)service.Execute(req);
			List<string> roles = GetUserRoles(resp.UserId, service);
			context.User = new GenericPrincipal(new GenericIdentity(resp.UserId.ToString()), roles.ToArray());
		}
		catch (System.ServiceModel.Security.MessageSecurityException ex)
		{
			throw new FaultException(ex.Message); 
		}
		catch (Exception ex)
		{
			throw new FaultException(ex.Message);
		}
	}
}

And here is the GetUserRoles method called in the Validate method:

/// <summary>
/// retrieves a list of CRM roles assigned to a specific user
/// </summary>
/// <param name="userid"></param>
/// <param name="service"></param>
/// <returns></returns>
private List<string> GetUserRoles(Guid userid, OrganizationService service)
{
	List<string> roles = new List<string>();
	string fetchXml = @"<fetch version='1.0' output-format='xml-platform' mapping='logical' distinct='true'>
	 <entity name='role'>
		<attribute name='name' />
		<attribute name='businessunitid' />
		<attribute name='roleid' />
		<order attribute='name' descending='false' />
		<link-entity name='systemuserroles' from='roleid' to='roleid' visible='false' intersect='true'>
		 <link-entity name='systemuser' from='systemuserid' to='systemuserid' alias='af'>
			<filter type='and'>
			 <condition attribute='systemuserid' operator='eq' uitype='systemuser' value='{$USERID}' />
			</filter>
		 </link-entity>
		</link-entity>
	 </entity>
	</fetch>";
	fetchXml = fetchXml.Replace("$USERID", userid.ToString());
	EntityCollection results = service.RetrieveMultiple(new FetchExpression(fetchXml));
	foreach (Entity entity in results.Entities)
	{
		roles.Add((string)entity["name"]);
	}
	return roles;
}

You can download the complete CrmUsernamePasswordValidator.cs class here.

The service binding configuration

A custom validator can work with WCF Transport, Message or TransportWithMessageCredential security. Inside the security element of your service binding in your web.config file, you must specify a clientCredentialType value of "UserName."

Here's an example that uses a basicHttpBinding:

<basicHttpBinding>
	<binding name="BasicHttpEndpointBinding">
		<security mode="TransportWithMessageCredential">
			<message clientCredentialType="UserName"/>
		</security>
	</binding>
</basicHttpBinding>

For more information on WCF service bindings and security modes, please see this overview from the Microsoft Patterns and Practices guide "Improving Web Services Security: Scenarios and Implementation Guidance for WCF."

The service behavior configuration

The final step is to add a behaviors element to your web.config file that tells WCF to use the custom validator. Here is an example:

<behaviors>
	<serviceBehaviors>
		<behavior name="Behavior1" >
			<serviceCredentials>
				<userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType="CustomValidators.CrmUsernamePasswordValidator, CustomValidators" />
			</serviceCredentials>
		</behavior>
	</serviceBehaviors>
</behaviors>

Note that "Behavior1" in line 3 should match the behaviorConfiguration attribute where you define the service. The customUserNamePasswordValidatorType is the name of your custom validator class and its assembly.

Wrapping it up

Once you're finished with these updates, your WCF service will now require the username and password to be supplied with inbound requests, and if the user can't be authenticated, a SOAP fault message will be returned. If you want to use the user's assigned CRM roles in your web service's business logic, you can check role membership using the HttpContext.Current.User.IsInRole method. You can also impersonate the user in subsequent calls to the Dynamics CRM Organization Service using the systemuserid value stored in the HttpContext.Current.User.Identity.Name field.

A version of this post was originally published on the HP Enterprise Services Application Services blog.

In this post, I will present a generic Windows Communication Foundation (WCF) wrapper for the Dynamics CRM Organization Service that lets you turn any FetchXML query into a web service interface without needing to write any code at all. I call my solution the Diesel Xrm Service Wrapper after Diesel, my Great Dane. Just like the CRM Organization Service, he's big and sometimes aggravating, so it's a perfect name!

Usually I like to go into a lot of detail in my blog posts, but frankly WCF gives me such a headache that today I'm just going to explain how the things work at a high level and offer the solution for download without much commentary.

An administrator stores predefined FetchXML queries on the server where the service is hosted. The service's consumers all access a single endpoint, and a "query" parameter is used to load and execute the correct FetchXML query. The consumers authenticate using Dynamics CRM credentials, and a service account executes the queries while impersonating the calling user so that native Dynamics CRM security functionality authorizes all data requests.

Initial Configuration

First, download the solution here: DieselXrmSvcWrapper.zip (Updated Aug. 5, 2013 - This project is now hosted on GitHub. The original solution file download link in this post has been left unchanged, however.)

To configure the solution, you store the URL for your Dynamics CRM server and credentials for a user account to be used as a service account in the appSettings section of the web.config file. The service account should have fairly broad read permissions, including "Act On Behalf Of Another User." You can also modify the WCF configuration if you want to use different bindings or security modes. In the solution download, I'm using a basicHttpBinding with a "UserName" message clientCredentialType (that's WCF-speak for HTTP basic authentication over SSL).

Query Definition

After you've finished the configuration, you can now create the FetchXML queries that will be used for the actual web service interfaces. The queries are stored in individual XML files in a specific directory on the web server, and when a web service consumer calls the service, the "query" parameter maps queries to requests.

In addition to predefined FetchXML, queries can contain paramter substitution placeholders in the format of {$PARAMETER_NAME} that will be replaced with values supplied by the web service consumer. Here's an example query that is stored in a file called contacts.xml:

<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="false">  
 <entity name="contact">  
 <attribute name="fullname" />  
 <attribute name="contactid" />  
 <attribute name="ownerid" />  
 <attribute name="address1_stateorprovince" />  
 <attribute name="gendercode" />  
 <attribute name="createdon" />  
 <order attribute="fullname" descending="false" />  
 <filter type="and">  
 <condition attribute="lastname" operator="like" value="{$lastnameletter}%" />  
 </filter>  
 </entity>  
</fetch> 

Sample SOAP Messages

1
Here's what the corresponding SOAP request method for the query above looks like:

<soapenv:Envelope   
 xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"   
 xmlns:tem="http://tempuri.org/"   
 xmlns:dies="http://schemas.datacontract.org/2004/07/DieselXrmSvcWrapper"  
 xmlns:i="http://www.w3.org/2001/XMLSchema-instance">  
 <soapenv:Header/>  
 <soapenv:Body>  
 <tem:Retrieve>  
 <tem:query>contacts</tem:query>  
 <tem:inputParameters>  
 <!--Zero or more repetitions:-->  
 <dies:ParameterItem>  
 <dies:Name>lastnameletter</dies:Name>  
 <dies:Value i:type="b:string" xmlns:b="http://www.w3.org/2001/XMLSchema">C</dies:Value>  
 </dies:ParameterItem>  
 </tem:inputParameters>  
 </tem:Retrieve>  
 </soapenv:Body>  
</soapenv:Envelope>  

The number of ParameterItems in the request should match the number of substitution placeholders in the query. If there are no placeholders, then you should omit the InputParameters section completely.

The SOAP response for the request above is attached here: soap-response.txt.

Wrapping Up

Now that you understand how the solution behaves and how to configure it, here's an overview of the solution components:

1. FetchXML queries - As mentioned above, each query is stored in a separate XML file in a single directory. In my solution, the directory is called "RetrieveQueries," but you can change it in the web.config file.
2. CrmUsernamePasswordValidator.cs - This custom username/password validator lets WCF validate the Dynamics CRM user credentials via TransportWithMessageCredential security. This also stores the users' CRM roles in an HttpContext.User object, so you could add some sort of role-based authorization to your service if you want.
3. SoapSvc.svc - This actually does the request/response processing.

Once you have everything set up, you'll want to try it out, and I suggest using SoapUI. To get up and running with SoapUI, you basically just point it at your service's auto-generated WSDL, and SoapUI will figure out most everything it needs to work. If you use my solution without modifying the WCF configuration, you will need to change the WSS-Password Type setting for your request to "PasswordText," and you'll have to supply the username and password either in the request properties menu or on the Authorization tab. I've circled these fields in the screenshot below.

In the future, I plan to update the solution to handle create/update/delete requests, and I may look at setting up a REST interface, too. If you have any thoughts or feedback, please share in the comments.

Happy web service wrapping!

One of the things I have always found frustrating about WCF is that it effectively hides the actual SOAP message XML requests and responses in web service calls. From a Dynamics CRM perspective, I can think of at least three good reasons it would be nice to be able to access the raw XML generated and consumed by clients built with the SDK:

1. Display retrieved results with XSL like I demonstrated in this client-side FetchXML example
2. Log the raw messages for QA, auditing or regulatory reasons
3. Process the XML to easily generate "wrapper" interfaces

In this post I will show how to capture client requests and service responses for interfaces built with the CRM SDK as well as interfaces that use a WSDL-based proxy using a client message inspector.

The message inspector class

The easiest way to capture the actual SOAP messages is to use a client message inspector object (IClientMessageInspector). The BeforeSendRequest and AfterReceiveReply methods of the client message inspector will give you the SOAP request and response as string objects that you can process however you want. Here is a class called MyInspector that stores requests and responses in list objects called sentMessages and receivedMessages respectively MyInspector.cs (1.55 kb). The original source for this code is http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/fa3f4c55-5835-43f2-892f-737b4bccb598.

Using the message inspector

Once you have your message inspector ready, you have to have to update the behaviors for the destination endpoint to use it. If you are using the SDK, all you have to do is instantiate a new MyInspector object and then add it to your OrganizationServiceProxy's ServiceConfiguration.CurrentServiceEndpoint behaviors. The code below contains a helper function that creates a new OrganizationServiceProxy object and adds the message inspector.

static OrganizationServiceProxy createProxy(string orgUri, string username, string password)  
{  
ClientCredentials credentials = new ClientCredentials();  
Uri organizationUri = new Uri(orgUri);  
  
IServiceConfiguration<IOrganizationService> config =  
ServiceConfigurationFactory.CreateConfiguration<IOrganizationService>(  
organizationUri);  
  
credentials.UserName.UserName = username;  
credentials.UserName.Password = password;  
  
OrganizationServiceProxy serviceProxy = new OrganizationServiceProxy(config, credentials);  
  
MyInspector inspector = new MyInspector();  
serviceProxy.ServiceConfiguration.CurrentServiceEndpoint.Behaviors.Add(inspector);  
  
return serviceProxy;  
}

If you are using WSDL-based proxy, adding the message inspector is slightly different, but just as simple. As with the SDK, you first have to instantiate a new MyInspector object, but you then add it to your WCF client's Endpoint.Behaviors object. The code below shows an version of the ExecuteWhoAmI method from the CRM SDK WsdlBasedProxies sample with the message inspector added.

private static void ExecuteWhoAmI(ClientCredentials credentials, string serviceUrl)  
{  
using (OrganizationServiceClient client = new OrganizationServiceClient("CustomBinding_IOrganizationService",  
new EndpointAddress(serviceUrl)))  
{  
ApplyCredentials(client, credentials);  
MyInspector inspector = new MyInspector();  
client.Endpoint.Behaviors.Add(inspector);  
  
OrganizationRequest request = new OrganizationRequest();  
request.RequestName = "WhoAmI";  
  
OrganizationResponse response = (OrganizationResponse)client.Execute(request);  
  
foreach (KeyValuePair<string, object> result in response.Results)  
{  
if ("UserId" == result.Key)  
{  
Console.WriteLine("User ID: {0}", result.Value);  
break;  
}  
}  
}  
}

Accessing the messages

Once you have added the message inspector to your endpoint behaviors, you are ready to call the CRM web service and access the request and response messages. Here is an updated version of the ExecuteWhoAmI method that writes the request and response messages to the console:

private static void ExecuteWhoAmI(ClientCredentials credentials, string serviceUrl)  
{  
using (OrganizationServiceClient client = new OrganizationServiceClient("CustomBinding_IOrganizationService",  
new EndpointAddress(serviceUrl)))  
{  
ApplyCredentials(client, credentials);  
MyInspector inspector = new MyInspector();  
client.Endpoint.Behaviors.Add(inspector);  
  
OrganizationRequest request = new OrganizationRequest();  
request.RequestName = "WhoAmI";  
  
OrganizationResponse response = (OrganizationResponse)client.Execute(request);  
  
foreach (KeyValuePair<string, object> result in response.Results)  
{  
if ("UserId" == result.Key)  
{  
Console.WriteLine("User ID: {0}", result.Value);  
break;  
}  
}  
  
Console.WriteLine("****REQUEST****");  
foreach (string sent in inspector.sentMessages)  
{  
Console.WriteLine(sent);  
Console.WriteLine();  
  
}  
  
Console.WriteLine("****RESPONSE****");  
foreach (string received in inspector.receivedMessages)  
{  
Console.WriteLine(received);  
Console.WriteLine();  
}  
Console.ReadLine();  
}  
}

I think the Dynamics CRM 2011 SDK is swell for interoperability, but I wanted to get a closer look at how the actual web service calls work, so I decided to access the sandbox CRM instance my company provides using a WSDL-based proxy as described here. Because the SDK has several examples for connecting to CRM instances using different kinds of authentication in the SDK\SampleCode\CS\WsdlBasedProxies directory, I figured this would be a piece of cake. As it turns out, I was wrong.

Disclaimer: before asking anyone read through to the end of this post, let me say I think the problem I ran into may be fairly specific to my organization's ADFS setup because despite a lot of web searches, I couldn't find anything that specifically addressed my issue from a Dynamics CRM perspective. On the other hand, if you are having the same problem I did, maybe this post will save you some time.

Because my CRM sandbox instance is an Internet-facing (IFD) deployment, I looked at the ifd project in the SDK's wsdlbasedproxies solution and followed the setup instructions. I ran into a problem almost immediately. After creating service references for the Discovery and Organization services, the next instruction is:

In the "" node, locate the "<issuer ...>" node. This node allows the user to specify which Issuer should be used when issuing a token. The various STS endpoints will be present in the commented out "alternativeIssuedTokenParameters" node. In my example, UserNameMixed is used. In order to use UserNameMixed, the "binding" and "bindingConfiguration" attributes need to be updated to match the node in "alternativeIssuedTokenParameters". The easiest way to find this endpoint is to search for "https://adfs.contoso.com:555/adfs/services/trust/13/usernamemixed". In the generated configuration file, you'll find: Copy this node and replace the current issuer node in the "" node.

Well, in my app.config file, there was no alternativeIssuedTokenParameters node. All I had was these two elements in my CustomBinding_IOrganizationService and CustomBinding_IDiscoveryService bindings:

<issuer address="http://schemas.microsoft.com/2005/12/ServiceModel/Addressing/Anonymous" />  
<issuerMetadata address="https://ADFS.SOMEDOMAIN.COM/adfs/services/trust/mex" />

I figured what the heck, let's try to run the sample in debug mode anyway and see if it works. Spoiler alert: it didn't. Instead of connecting to CRM, I got a Windows CardSpace (never heard of it before) screen pop up asking me if I wanted to send a card to the site. Seeing as the SDK readme doc had made of mention of CardSpace, I figured something must be misconfigured, so I closed the window and stopped debugging.

It took me a while to figure it out (I'm a developer, not a networking guy), but I finally realized that my WCF client knew it should be using a token from the SOMEDOMAIN.COM STS to talk to CRM, but it didn't know how to get one. After some fruitless searching, I stumbled upon a post by the MCS UK dev team called "Federated Security: How to setup and call a WCF service secured by ADFS 2.0." At first I looked at programmatically getting a token, but then I decided it would be much simpler to take the config-based approach described in this MSDN tutorial: http://msdn.microsoft.com/en-us/gg557876. Also, the config-based approach is what should have been happening in the SDK sample anyway.

To get the issuer element of my bindings right, I first created a service reference for the address in the issuerMetadata element. As soon as I did, my app.config file was updated with lots of binding and endpoints that looked like what was described in the SDK sample setup file, so I figured I must be on the right track.

Knowing that my sandbox CRM instance used the "/adfs/services/trust/13/username" endpoint for getting a token from the ADFS STS (thanks to watching Fiddler while a desktop application that uses the SDK connected to my CRM instance), I searched in the updated app.config file for that string, and I found this element:

<endpoint address="http://ADFS.SOMEDOMAIN.COM/adfs/services/trust/13/username"  
binding="ws2007HttpBinding" bindingConfiguration="UserNameWSTrustBinding_IWSTrust13Async"  
contract="STS.IWSTrust13Async" name="UserNameWSTrustBinding_IWSTrust13Async">  
<identity>  
<certificate encodedValue="REALLY_LONG_CERTIFICATE_STRING..." />  
</identity>  
</endpoint>

Next, I commented out the existing issuer and issuerMetadata elements in my CRM service bindings and replaced them with the address, binding, binding configuration and identity details from the STS endpoint like so:

<issuer address="http://ADFS.SOMEDOMAIN.COM/adfs/services/trust/13/username" binding="ws2007HttpBinding" bindingConfiguration="UserNameWSTrustBinding_IWSTrust13Async" >  
<identity>  
<certificate encodedValue="REALLY_LONG_CERTIFICATE_STRING..." />  
</identity>  
</issuer>

After that, I ran the sample project in debug mode, and it worked perfectly.

Why did this happen?

I will readily admit I don't understand the ins and outs of ADFS. I get the point of it and the basics of how it works, but I certainly don't know why the configuration of my CRM instance would lead to these results. All I can say at this point is that I'm glad I've got it working, and I'll know what to do in the future if a problem like this ever comes up again.