The examples are all point-to-point and seem to require separate logins for each initiator and corresponding exchange of certificates using a multi-pass installation.
E.g. Rushi's ServiceListing API.
We have an application with several hundred workstations which need to send transaction data to department servers and then on to corporate. There is also a need to replicate small amounts of reference data to all levels.
The examples seem to generate an installation and administrative nightmare.
I have a question - would the following scheme work?
1. All our machines are on the same domain so transport security can be handled by Windows Security (One less set of certificates to exchange).
2. Generate 2 Certificates on the Corporate database and export them to the department and workstations
use these pre-installed certificates in each database to handle dialog security for all converations.
Ie. multiple workstations feed into one user id on the
department server using a single certificate. Ditto for all the department servers feeding into corporate.
3. Use Service broker id's to determine where messages are sent (as the same services would be installed at multiple locations).
4. When a database is intalled/restored at a workstation does this invalidate any certificates that are shipped with it?
Carl Berger wrote:
Information for configuring Service Broker when you have multiple initiators seems to be thin on the ground.
The examples are all point-to-point and seem to require separate logins for each initiator and corresponding exchange of certificates using a multi-pass installation.
E.g. Rushi's ServiceListing API.
We are working on an tool that uses the service listing concept that should make this much, much easier. My plan is to release it within days.
We have an application with several hundred workstations which need to send transaction data to department servers and then on to corporate. There is also a need to replicate small amounts of reference data to all levels.
The examples seem to generate an installation and administrative nightmare.
You might want to consider a BCN (Broker Configuration Notice) Service for your environment: http://msdn2.microsoft.com/en-us/library/ms166054(SQL.90).aspx
This can take care of the service routes and service security settings, acting as a UDDI or Active Directory service (in fact it can be implemented as a wrapper around AD). The BCN service is interogated whenever a routes is missing or a remote service binding is missing. The BCN service itself can be configured to accept anonymous dialogs and validates the request by out of band means (e.g. validates that the requestor host machine is a machine member of your domain).
1. All our machines are on the same domain so transport security can be handled by Windows Security (One less set of certificates to exchange).
Yes, this works. If you plan to use machine accounts instead of a domain user account for the SQL Serverr serviceaccount, my recommendation is to make all machines member of a Windows Group and then grant CONNECT permission on endpoints to this group, instead of individual machines. Note that using machine accounts (domain\machine$) requires (manual) registration of SPNs.
2. Generate 2 Certificates on the Corporate database and export them to the department and workstations
use these pre-installed certificates in each database to handle dialog security for all converations.
Ie. multiple workstations feed into one user id on the
department server using a single certificate. Ditto for all the department servers feeding into corporate.
I believe the BCN service can implement this in a more manageable way. When it will receive a request for a missing REMOTE SERVICE BINDING it can create and deploy a certificate for the requesting service as part of processing the request.
3. Use Service broker id's to determine where messages are sent (as the same services would be installed at multiple locations).
That's exactly the purpose of the broker id.
4. When a database is intalled/restored at a workstation does this invalidate any certificates that are shipped with it?
No, certificates are not affected. However, private keys associated with certificates are stored encrypted with the database master key. The Service Broker background threads can access the database master key only if is encrypted with the service master key (since a background thread cannot have access to the password). So as part of the install/restore, these steps are necessary:
- open database master key using the password
- add the service master key encryption to the database master key
One note is that if you plan to use this install/restore to create new instances of a service, you'll have to generate a new broker id ( ALTER DATABASE ... SET NEW_BROKER).
HTH,
~ Remus
The BCN service seems to be a good solution for setting up the route.
My proposal here was to create only two certificates to handle all dialog security and to preship them with an installation package for each workstation. There would be only a single certificate/remote-user at the target and a single predefined remote-user and certificate which is reused on every workstation.
The "Can you hear me now?" type of installation would be avoided, new workstations could be installed without a single change at the corporate end.
Comments?
|||The BCN also is used for querying missing REMOTE SERVICE BINDINGs, so it can trigger all the steps for a security configuration deployment (certs). The BCN is not queried continously, a query is sent when an ROUTE or RSB is missing, and the BCN service is expected to actually create the missing route or RSB. So the BCN should normally be interogated only once per new workstation. I think the more appropiate analogy is plug-n-play configuration, rather than 'can you hear me now'.
Shiping a pre-packaged database, with all services, keys, code (including CLR assemblies) and permissions it sure is an attractive deployment solution. Unless you care about things like nonrepudiation of dialogs/messages (workstation cannot later deny that it sent a given message), having once cert/private key duplicated for each workstation works fine. Another thing to consider is that a private key shared by hundreds of workstation cannot be really considered private anymore, so you might as well use anonymous dialogs (they don't require private keys on the initiator side, traffic is encrypted).
Also, many of the problems avoided by shipping the database will come back when the certificates start expiring. Just to keep in mind...
HTH,
~ Remus
We don't need repudiation. The messages are generated by a trusted sales application.
It looks like anonymous dialogs might be the best way to go.
Many thanks.
No comments:
Post a Comment