The Microsoft Dynamics CRM Team Blog
News and views from the Microsoft Dynamics CRM Team
Power users and vendors are always excited about SDKs to their favorite applications. The ability to build solutions on top of powerful interfaces can go a long way towards extending the capabilities of a product. CRM’s SDK is proof of that; but when it is applied in a CRM Online situation, the challenges inherent to cloud computing mean the technical hurdles are higher.
Authentication is the primary culprit. To authenticate to the CRM Online system you need to obtain a Windows Live ID (WLID) ticket, and the only way to do that has been to dance to IdCrl’s tune (there are actually ways to bypass IdCrl, but they are unsupported.) IdCrl is only intended to be used when there’s ‘a warm body at the keyboard’ to enter credentials, so service accounts (who are often more useful when it comes to taking advantage of SDKs) weren’t invited to the party. On-premises and partner-hosted deployments have been able to simply let Active Directory handle all aspects of authentication, which has no such limitations.
Fortunately, recent functionality additions to Windows Live ID allow CRM Online to reach parity with its counterparts. SDK consumers will now be able to use certificates to obtain WLID tickets. This opens up a wide range of possibilities that can expand CRM’s functionality with web services and third-party solutions. The CRM Online team recognized that once service accounts were able to do business in CRM Online, impersonation would need to be supported. So that’s an area where complementary improvements were made.
The main obstacles remaining are the expense of obtaining a certificate, and, for impersonation scenarios – the fact that it’s fairly involved to manage Windows Live identities for the amateur developer. You’ll need to register your app with Windows Live and make use of their Relying Party Suite (RPS) libraries. This allows, for example, the ability to obtain the unique id (aka puid or Net Id) of a user browsing your site when they’ve signed in with their WLID account. You’ll need that unique id, among other authorization prerequisites, if you want to impersonate that user in CRM.
For example, a vendor could build a service to provide an easy way to send a small gift to a client after closing a sale (perhaps with real estate agencies in mind.) This service can be added to your CRM Online organization by configuring a page from the vendor’s web site to appear as a tab on your account form. The vendor’s page allows you to make a gift selection and send it with one click. To put the icing on the cake, the vendor could suggest customizations to your data model so that records of gifts associated with accounts would be kept and gift expense items are saved to another table.
In addition to the aforementioned configuration tasks, there other prerequisites needed to enable this scenario. The vendor will likely want to take responsibility for making sure all of these preparatory steps are taken care of by providing a hassle-free installer.
Here is a list:
This is where the new MIS feature called Enhanced Id (EID) comes into play. It has its own sub list of prerequisites:
1. A WLID account 2. A private key certificate, installed in a store where it is available for use by the service. 3. The Windows Live Sign-In Assistant, which you can obtain from the EID page in April 2009. This is a browser helper object that lets Windows Live ID communicate with your certificate store. By default, it’s only looking for smart card certificates. But a pair of registry changes will remove this restriction: [HKEY_CURRENT_USER\Software\Microsoft\IdentityCRL\Certificate] "BypassCSP"=dword:00000001 "BypassRootCert"=dword:00000001 4. You’ve associated the service account’s WLID to the certificate using theWLID EID page, https://login.live.com/beta/manageeids.srf. After signing in with the service account’s WLID, you should be able to select your certificate from a drop down, provide your password, enter some dummy text in the Smart Card PIN field (the small price of outsmarting software) , and click add to create the association.
1. A WLID account
2. A private key certificate, installed in a store where it is available for use by the service.
3. The Windows Live Sign-In Assistant, which you can obtain from the EID page in April 2009. This is a browser helper object that lets Windows Live ID communicate with your certificate store. By default, it’s only looking for smart card certificates. But a pair of registry changes will remove this restriction:
4. You’ve associated the service account’s WLID to the certificate using theWLID EID page, https://login.live.com/beta/manageeids.srf. After signing in with the service account’s WLID, you should be able to select your certificate from a drop down, provide your password, enter some dummy text in the Smart Card PIN field (the small price of outsmarting software) , and click add to create the association.
Making the web service call to get the ticket can be tricky. The protocol is based on WS-TRUST, but it doesn’t follow the standard exactly. So we provide a class in the CRM SDK, WindowsLiveIdTicketAcquirer.cs to do it for you. You just need to provide the following:
1. The System.Security.Cryptography.X509Certificates.X509Certificate2 object corresponding to your certificate 2. The service account’s WLID user name 3. Which WLID environment you want to use (usually PROD = 2) 4. The WLID partner name of CRM, crm.dynamics.com 5. The policy name, obtained from the discovery service
1. The System.Security.Cryptography.X509Certificates.X509Certificate2 object corresponding to your certificate
2. The service account’s WLID user name
3. Which WLID environment you want to use (usually PROD = 2)
4. The WLID partner name of CRM, crm.dynamics.com
5. The policy name, obtained from the discovery service
Budget-conscious admins may still be hearing alarm bells. But thanks to another new feature, no, the service account won’t need to consume one of your precious licenses. If an account doesn’t need to use an interface other than the SDK, it can be flagged as a ‘non-interactive’ user, which won’t count against the license total because it can’t use a GUI to access CRM.
The ability to impersonate another user is secured in CRM Online through a new security role, Proxy. The service account needs to be assigned this role in order to successfully impersonate a user. The service account would also need basic access to the entities it needed to operate on. Read access to accounts, for example. During impersonation, the service account will only be able to perform actions that both it and the impersonated user have permissions to do (the intersection of the two privilege sets.) Also, the service account will assume the impersonated user’s security context, so accounts created by the impersonated user are treated as ‘owned’ accounts.
Impersonation makes the most sense when the user is generating CRM SDK activity through the vendor’s web site. The vendor needs to use RPS to authenticate the user, and also make use of a new Discovery service request class, RetrieveCrmUserIdByExternalIdRequest, that allows translation of Windows Live unique ids (obtained via RPS) into CRM user ids (as long as you share an org with them.)
It’s also worth mentioning that an action performed while impersonating a user is distinguishable from the same action performed by the user. There are new entity properties that will tell you if impersonation was involved or not and the identity of the proxy.
Once everything is in place, a successful scenario would unfold like this:
After closing a big sale, the CRM user clicks over to the gifts tab, opening the vendor’s web site via an iframe. The user selects an impressive Mardi Gras themed flower arrangement, and confirms the purchase.
Meanwhile, the vendor has noted the org name from the incoming request, and authenticated the user with RPS. It obtains a WLID and CRM ticket for the service account, translates the CRM user’s WLID unique id into a CRM user id, and then enables impersonation on the CRM ticket by setting the token’s CallerId property to the user’s CRM user id.
The rest should be easy: read the contact info from CRM (you’re impersonating the user, so you can access their contacts), bill the customer, and add the gift and expense item records to CRM (as the user.) It’s a win for all parties involved!
Hopefully, the vendors who have put in a lot of effort to create innovative solutions targeting the on-premise CRM SDK will find it easy to enhance those offerings to make them available to the CRM Online community. That would represent a big boost in the options that our users have when putting together a killer CRM solution for their business.
Is there any cost involved in order to use the new authentication methods between services i.e. external connector as with on-premises, or is this now essentially free with online?
PingBack from http://www.toolworld.ca/microsoft-dynamics-crm-team-blog-new-authentication-tools-to.html
The only additional cost that's necessary is the purchase of a client certificate that is trusted by Windows Live if you don't already have one. This is a one-time cost and can vary anywhere between $50-$500, depending on the issuer.
Is this approach now required for interacting with the CRM Service? I have a web site that uses Windows Live ID authentication, can I just use the token I get back from that? I'm using the approach here: http://msdn.microsoft.com/en-us/library/bb676640.aspx.
If I set the user.Token value on the RetrieveOrganizationsRequest.PassportTicket when getting the CRM Orgs for the user, would that work?
I have no need to act as a service account, there is always a user present to login, and I always want to act as the logged in user, and read data filtered to their privileges.
You're right; the client-to-server auth story hasn't changed, so that will continue to work and be supported as usual. The approach in this article primarily concerns server-to-server auth scenarios.
Thanks Pat, I'm still a little unclear as to how a web page would need to connect to CRM Online.
- A windows client app can use LogonManager/IdCrl.
- A service should uses the new method above.
- What can a web site do? Sounds like IdCrl is unsupported for a web site.
If I want to host a web page on my web server that has a form and saves data to my own CRM Online organization, how can I connect? I've used the Windows Live SDK so my users are directed to the Windows Live logon page to sign in. So, I'm not asking for their credentials. Once they sign in, I can access their WindowsLiveLogin object (from the SDK) at the return url and get their token, etc. But I don't know how to turn around and use that to connect to CRM Online CrmService.
Is this possible, or is there another method for connect my own web page to my own CRM Online org?
If I understand the Windows Live ID SDK stuff correctly, I don't think you get back a user's PUID from that. I think they give you a site-specific identifier for the user. In order to get PUID, you'll need to use the Windows Live ID "RPS" package, available on PartnerSource. You can then exchange the PUID for the user's CrmUserId. CrmUserId is then used in the impersonation calls to get access to that user's data.
It's not a supported scenario to get the user's token and send it over to us, due to security considerations. If some third-party site leaks the token, the user's data could be compromised. Also, the Live ID team frowns on third-party sites (even other Microsoft sites) from collecting username and password from Live ID users. (It doesn't sound like you're doing this today, but it's a likely next-step once you realize the token is no help.)
You must act as a service account and use CRM impersonation. We don't allow you to log in directly as the user, either by replaying the token or by collecting credentials directly.
Thanks, that all makes sense. If we're hosted in an IFrame with the CRM app, does that make a difference? Can we still use this approach?
That way, we're calling the GenerateAuthenticationHeader of the host page and never touching the authentication or token info ourselves.
If not, I'll take a look at the RPS SDK.
Can this scenario work with Windows Azure?
How would I associate the certificate?
The certificate store is handled differently in Azure, but I don't fully understand the details.
Another issue is that RPS isn't supported in Azure, but alternatives (Geneva) will eventually become available for that platform.
I've looked all through the CRM Online Users pages and cannot find "non-interactive" user anywhere. Exactly where do you go to specify this?
Sorry for the late response. Non-interactive is a possible value for the User field 'Access Mode'. That field isn't visible by default.