Monday, March 19, 2012

Dialog Security questions

Hi Remus

Thank you for the email reply.

However i am still not 100% clear, dialog security with certificates when there are hundreds of remote services seems a bit complicated.

I have a few more questions.

1. you said "When sending the first message (any direction), we look up the 'best' certificate for each user"

My inititor sevice is owned by dbo, i have created certificates only for named users not dbo, how would this work?

2. I am going to try settin gup this again, but at the central service i will create a seprate user for each remote service, authorize the remote certificate for this user and use this user in the remote service binding for that remote service, is this correct or am i still doing somehting wrong?

3. How does all of this relate to the endpoint security, i ahve the same scenario, 1 pricipal id with all remote certificates authorized for it for the endpoint? I have no idea how i would have to setup different user for each remote servcie as far as the endpoint goes as there is no remote service binding to dictate which user to use ?

I will keep try and experimenting maybe i will get it right sooner or later.

Thank You

Dietz wrote:

1. you said "When sending the first message (any direction), we look up the 'best' certificate for each user". My inititor sevice is owned by dbo, i have created certificates only for named users not dbo, how would this work?

If 'dbo' is the owner of the service, then dbo must have a certificate. I'm not a fan of having dbo own the services, but there isn't anything to prevent this from working.

Dietz wrote:

2. I am going to try settin gup this again, but at the central service i will create a seprate user for each remote service, authorize the remote certificate for this user and use this user in the remote service binding for that remote service, is this correct or am i still doing somehting wrong?

Yes, you will need a separate user for each service you are trying to address.

Dietz wrote:

3. How does all of this relate to the endpoint security, i ahve the same scenario, 1 pricipal id with all remote certificates authorized for it for the endpoint? I have no idea how i would have to setup different user for each remote servcie as far as the endpoint goes as there is no remote service binding to dictate which user to use ?

Dialog messages may hop multiple hosts (forwarders) and may be stored by intermediaries for a long time. This loosely coupled patern of dialogs prevents them from being able to do a handshake before exchanging messages. If the initiator is up from 6 am to 6 pm and the target is up from 6 pm to 6 am, a handshake involving 3 messages (quite typical in world of security: a request, a chalenge and a response to the challenge) would mean that any new dialog would first have to wait more than 24 hours for the handshake to complete. W/o the luxury of a handshake, dialogs must choose upfront the appropiate certificate to use. This is why dialog security needs a concept like a 'remote service binding', that binds the remote service name to a certificate to be used before sending the first message.

Endpoints/transport security on the other hand is always between two instances that can open a direct connection, so they can afford the luxury of a handshake. So there is no need to choose a certificate upfront, a handshake can exchange and then validate the certificates used (there's nothing new here, this is how SSL and TLS were working for years). As a result, there is no need for a concept like a 'remote endpoint binding'. This also implies that you can have one user own all the endpoint certificates from all the peers.

Thanks,
~ Remus

P.S. I've split your original post because I don't like 2 page threads, I have to scroll down all the time to get to the second page.

|||

Hi Remus

Thank you very much for all your help, i guess i am just going to have to keeping messing around until i truely understand it.

Thank you for all the assistance, i have this working now with a user for each remote service, i still dont understand how to properly create a non dbo certified user on both sides, and i cannot find any examples, i will just keep messing around i guess that is the best wat to learn.

Thanx

|||

"If 'dbo' is the owner of the service, then dbo must have a certificate. I'm not a fan of having dbo own the services, but there isn't anything to prevent this from working."

I would love to not use dbo, however i cannot find a good code examples with the proper steps and explanations on how to do this? Only good example i have uses dbo. Only other example i have found not using dbo is too simple for my solution with hundreds of possible initiators, and i am not sure how to implement properly. No offense but BOL sucks, and i cannot find any decent examples and the webcasts on service broker are very high level. Bottom line is that finding good Service broker resources on this type of scenario is virutally impossible.

But i do really do appreciate your feedback, Thanx

|||

You should use either the AUTHORIZATION clause of the CREATE statement, either the ALTER AUTHORIZATION statement. Here is an example:

-- when starting from scratch

create user [InitiatorServiceUser] without login;

create certificate [InitiatorServiceCertificate]

authorization [InitiatorServiceUser]

with subject = 'InitiatorService';

create service [InitiatorService]

authorization [InitiatorServiceUser]

on queue q;

-- when changing an existing 'dbo' owned service and certificate

create user [InitiatorServiceUser] without login;

alter authorization on certificate::[InitiatorServiceCertificate] to [InitiatorServiceUser];

alter authorization on service::[InitiatorService] to [InitiatorServiceUser];

HTH,
~ Remus

|||

Thanx Remus

This is also the section in Roger Wolter's book under dialog securoty that i did nto understand since i never did it and everything worked.

Does dbo automatically have any certificate cereated in the database, if not i dont really understand how it works without running this. But thanx for the answer i will do this in future Thanx

No comments:

Post a Comment