With the roll out of the CRM 2011 on Office 365, a new authentication process was added to support it and allow for delegated authentication for CRM online. This authentication method also works for CRM Online (Live) and all forms of Premise base authentication.
Lets talk about History for just min.
There are several ways to do authentication from client applications that have existed since RTM, as a general rule, they are either done using the simple constructor on the proxy, or the IServiceConfiguration interface.
What I call simple constructor approach provides two constructors, one for the Discovery Service Proxy, and one for the Organization Service Proxy
For the Discovery Service Proxy, the simple constructor requires you to know a lot about the server connection up front, the same is true for the simple constructor for the Organization Service Proxy
You need to know what the URL of the service you want to connect too is, you need to know the user and device credentials, the home realm URI, and the right parameters to use with the right settings for the type of auth you want.
Seems simple, what’s going on there behind the scenes though is pretty complicated and fairly time consuming. In short, for each type of of Service Proxy, the SDK is calling the WCF MEX service on CRM to get the WSDL to build the proxy for the type of server connection, then wiring up that proxy and returning it to the caller. Notice I didn’t say “Authenticate” there… Authentication happens the first time to you try to do something with the newly created service proxy.
From a time perspective, that’s a pretty heavy operation. One of the worst things that can happen here its to create, use, destroy , recreate , etc…
For performance, you really need to hold on to the constructed proxy and use it for the life of your connect. The other challenge here is that you don’t have visibility to what is taking up time in this operation… is it the WSDL create? or the Auth? or the proxy Generation ? or perhaps the call to CRM itself.
In the RTM Release, we were also provided the IServiceConfiguration interface.. which provided us with a more component based capability to set up the Proxy, Authenticate, and create the Discovery Service or Organization Service proxy. Using the IServiceConfiguration Method, via the ServiceConfigurationFactory.CreateConfiguration method, we can setup the Proxy, then manage authentication, then create the proxy we wish with the preconfigured IServiceConfiguration interface.
Now, the sticky part in the IServiceConfiguration interface is authentication. there are several different ways to do it, based on the authentication type you need and the CRM Server type you are connected too.
There are several examples in the CRM SDK that cover this process.
The new IServiceManagment interface provides a us the same ability of the IServiceConfigurationmethod, with a much more straight forward and easy to use authentication process, Additionally it fully supports OSDP ( that’s CRM on Office 365 ) via the authentication process, without having to do anything “special”, and allows for a fairly easy centralization of proxy generation for the CRM connection.
With the release of the service management interface, I moved much of my code over to use it in order to streamline the CRM connect process in my environment, however in testing I was challenged with Delegated Claims authentication.
Using Delegated Claims Auth and the IServiceManagement interface.
In an attempt to be clear:
I had an on premise CRM instance that was configured for claims… lets call it crm.contso.com. It is also configured to accept authentication for users in the Fabrikam.com domain.
Now, in the IServiceConfiguration interface, I would need to write code to deal with this using the cross domain auth process, using the HomeRealm URI to access the correct auth store. The code that supports that , of course, was unique and different then using the code to hit windows live, IFD or AD.
Using the IServiceManagement interface, I set up my code to look a like this:
Where userCredentials is firstname.lastname@example.org + the password, and homeRealm pointed at the ADFS Auth service for Fabrikam.com
As the Homerealm is provided , I set the AppliesTo property of the AuthenticationCredentials class to it. That will tell the authentication method to authenticate against Fabrikam’s ADFS system.
Next I get the Security Token and pass it to the Proxy Constructor that I want.. in this case the discovery server:
This call generates a a MessageSecurityException exception. But why ?
Well, going back over the SDK docs and other sample code… I was unable to come with an answer, I had even tried to use the sample code provided in the SDK to do this. Still no luck.
Reach out internally I found out that there is one extra step that needs to be done to make delegated claims auth work.
In sum, what needed to be done was to check the IServiceManagement PolicyConfiguration.SecureTokenServiceIdentifier against homeRealm, if they were different, I needed to execute a second auth on the IServiceManagement endpoint using SecurityTokenResponse of the auth against Fabrikam.
once I had done that… it worked.. so it ended up looking like this:
That allowed me to auth across claims realms, create the proxy I was interested.
Helper method to build the Discovery Service and Organization Service Proxies Supporting all current forms of CRM 2011 auth.
I have wrapped up the code I used to do this into a helper method supporting both the Organization and Discovery server proxy’s is here, it will also appear in the update to the UII Solution Starters Agent desktop starter code once I release the update to that. ( soon ) .. as with all code .. use at your own risk..
To use it to create a connection to a discovery server :
To use it to create a connection to Live’s Organization service, You call it as such:
Hope this helps someone else along the way.