次の方法で共有

MCF from non-Windows Clients

  • [アーティクル]

Note: This will only work in RTM

In order to make our MCF web-service work from non-windows clients, the first step is to actually change the binding the MCF web-service uses. In theory, what we ship with (wsHttpBinding) should work cross-platform, but at the moment there are no non-Windows products that generate a proper proxy and thus make it difficult to use (See Update below). If at all possible, please use a windows based client to talk to MCF or a non-Windows based proxy that fully supports wsHttpBinding as the functionality is much richer, especially around errors. If you choose to proceed down this route, note that exceptions are not properly propagated (they all show up as generic fault exceptions) and it will be impossible to tell from the client what server-side errors occurred. If you have no choice, keep reading...

If we switch the proxy to use basicHttpBinding, the service will act like an asmx web-service and everything should work cross-platform with existing web-service products. In order to actually use basicHttpBinding, however, the service will require some additional configuration. Ultimately, we need the caller to be presented as a windows account. For cross platform, since you can't use windows authentication, you are forced to use client certificates and map them accordingly. In order to use client certificates, however, you need to setup SSL (you can also use Message level security but I only setup and tested Transport level). Here are the steps:

 

1. Create a server certificate to use for your MCF endpoint to enable SSL (this certificate will need to be trusted by your clients)

2. Import this certificate into the Local Machine store on the Root Management Server

3. Setup the MCF endpoint to use SSL

Since we are self-hosted, this cannot be done in IIS. You will need to find HttpCfg.exe (for Win2K3 this is found under SupportTools on the CD) and run the following command:

HttpCfg.exe set ssl -i 0.0.0.0:6000 -h 82e8471434ab1d57d4ecf5fbed0f1ceeba975d8d -n LOCAL_MACHINE -c MY -f 2
 
The 6000 is the port you are using in the configuration file. The "82e8471434ab1d57d4ecf5fbed0f1ceeba975d8d " is the thumbprint of the certificate you want to use (this can be found under the Details tab of the certificate snap-in after viewing the certificate). The -f 2 enables the server to accept client certificates.

4. Update Microsoft.Mom.Sdk.ServiceHost.exe.config to look like the attached file

You can pick whatever port you want to use, although I was never able to get 80 to work in testing.

Also note that when I tried this out generating the proxy using wsdl.exe from a machine other than the server itself, it failed when my endpoint was defined as localhost. I had to specify the server name in the endpoint definition for the tool to work.

5. Restart the omsdk (OpsMgr Sdk Service) service

6. Generate a client certificate

There seem to be two ways to do this. The first, and the one I tried successfully, is to generate a client certificate that has, in the Subject Alternate Name field the principal name of the user you want to map to. This will work if the CA that issues the certificate is an Enterprise CA on the domain your OpsMgr Sdk Service is running on. In the details under the Subject Alternate Name field this looks something like this:

Other Name:
Principal Name=youruser@yourdomain

Alternatively, AD allows for the configuration of certificate mapping directly on the respective user object. I did not try this method as I do not have domain admin access on the domain I was testing on, but this should work as well.

7. Use the client certificate in the request

 

I tested this out using a proxy generated by wsdl.exe from the 2.0 .Net Framework and everything seemed to work ok. Things didn't work well with the 1.1 Framework wsdl.exe as some of the normally non-nullable fields (such as DateTime fields) are not nullable in 1.1, but can be null from MCF. Thus, whatever tool you use to generate proxies, it needs to be able to handle null values for value types.

Update: I did some digging around, and although I did not test any of these, it seems there are some java projects for WCF interop that should allow you to communicate directly with our wsHttpBinding. There is the JAX-WS project and Project Tango. There are probably more out there, but I was reading about this in particular and people having success using them to interop specifically with wsHttpBinding.

Microsoft.Mom.Sdk.ServiceHost.exe.config

Comments

  • Anonymous
    March 10, 2009
    hello, Jakub I am using java code to interact with SCOM through webservice. And I have read this aritcle on your blog: http://blogs.msdn.com/jakuboleksy/archive/2007/04/02/mcf-from-non-windows-clients.aspx I tried to ues JAX-WS, using wsimport tool to generate the proxy of webservice. But when I used this proxy like this: //Create the proxy of WebService ConnectorFrameworkDataAccess service = new ConnectorFrameworkDataAccess(); System.out.println("starting create port."); IConnectorFramework cf = service.getMain(); the code can' t move on.There is no exception or errors. I didn't know what had happened. Have you ever write any non-Window Client of Webservice? And Could you give me some advice? Thank you in advance. -Li Yang

  • Anonymous
    March 11, 2009
    I haven't personally written one. I know some of our partners have successfully done it, but I don't have any insight to provide beyond what is written in this post.

  • Anonymous
    March 15, 2009
    Hi, Jakub I am using WSIT(previously known as Tango) to access the WCF of SCOM2007, but it also has problems. It seems like that WSIT doesn't support SpnegoContextToken which is included in the WSDL. So could you tell me who have successfully done this. Maybe he/she could give me some help? Thanks a lot.

  • Anonymous
    March 16, 2009
    I don't have any particular contact info here. The problem is a generic one, not something necessarily specific to our WCF service.

  • Anonymous
    July 23, 2009
    The comment has been removed

  • Anonymous
    July 25, 2009
    If I understand your alternate configuration correctly, you are not giving the service windows credentials from your client, that won't work. Some way, your client needs to provide windows credentials to the server.

  • Anonymous
    July 29, 2009
    The comment has been removed