Microsoft Dynamics March Service Update – Authentication

Who are you ?

With the March Service update for Dynamics CRM Online, we have a few additions to the authentication programming model that enables more scenario’s and is more secure. If you recall from an earlier post, I discussed some of the challenges with authentication using Windows Live ID. I posted a work around that was based on using WS-Trust Soap calls. This method is technically workable but not as secure because the user name and password must be used. The new authentication model uses the same architecture but requires a digital certificate to be used. In addition, we now have the concept of a service account that can update and create records.

Server to Server or Service to Service or Client to Server

Don't let the use of the words client/server/service confuse you. Whether it's from a client machine or a server or web page, it all the same with minor twist.

In the service account model, you must have a certificate that is registered with a Windows Live Service Account. Also, you will invite this Windows Live ID to be a user in your system with the newly added proxy role. You can purchase the certificate from Verisign.

Look in the sdk @ SDK\Walkthroughs\Authentication\CS\ServerToServer\Cert to WLID Association.doc for details on how to establish your certificate.

There is no cost for the service user account in CRM Online.

Server to Server - No need for the user to enter creds. Example - Web leads, customer service case, or back end integration.

Client to Server - User wants to update a record via custom portal to CRM. Records can be updated directly using the user creds or the service account updates on behalf of user.

Whenever something is performed against the CRM system under the authentication of the service account, it is bound by the security rights set for it by the proxy role. The second flavor is the service software is to include a user id that represents the action is performed on behalf of. Under this, all action is done on behalf of that user’s account. The on behalf user and the service account must have equal rights to the object being modified/created. Typically, the term client might imply the user submits their user name and password while the server term means that 'software' is doing it without user interaction. Whether the user is involved or not, you can use the service account certificate to update/create/etc records in the CRM data storage.

Summarize:

·     Digital certificates are used to establish credentials for software service accounts to update/create CRM records.

· Code can update/create records in CRM under service account. Service account rights are set by proxy role

· Code can update/create records in CRM via the service account on behalf of ‘a user’. Rights of on behalf user and service account must be equal.

· Look in the SDK for details on setting up your certificate

SDK\Walkthroughs\Authentication\CS\ServerToServer\Cert to WLID Association.doc

Tracking Who did what  

There are new system attributes modifiedonbehalfby and createdonbehalfby that will track who updates/creates records when the service account does work on behalf of. These attributes allow you to track that the proxy user ( that’s your service account ) has modified/created a record. The modifiedon and createdon fields hold the user names of who the records where modified/created for.

Example – The service account is named “ERP_Integration” and JonW is the user. During an integration process, the integration software using the service account could create/update the records simply as the service account. In that case, modifiedonbehalfby and createdonbehalfby are blank and createdon/modifiedon are set the service account id.

The integration software using the service account could also create/update the records on behalf of jonw using the service account. In that case, modifiedonbehalfby and createdonbehalfby are set as the service account and createdon/modifiedon are set to jonw.

If you are developing integration software, it’s a best practice to use on behalf to reduce the number of transactions. Under the previous model, most integration software would first have to create new records and then have to go back and re-assign them to specific users. This was due to the record being created under the authentication of the logged in user token of the integration software. Typically, this would have been just an admin or plain user account. The new model lets the integration software create records on behalf of so there’s no need to do the additional step of re-assigning the record.

The new additions to the authentication model is great to allow software to update records with or without user interaction.

You’ll be able to do authentication from Client applications, Web pages, and Windows services.

And remember this is for CRM Online .... the OnPremise and IFD use active directory authentication.

Keep an eye for some samples I'll be posting. I'm thinking an Azure Web to Lead might be fun...

We’ve just published version 4.0.8 of the CRM SDK! The online content is here and the download is here

Microsoft Dynamics CRM Online Authentication

Walkthrough: Server-to-Server Authentication with CRM Online

WindowsLiveIdTicketAcquirer Helper Code

-cheers

jonw