As vrea sa cryptez dialogul in service broker imi puteti recomanda ceva comprehensive in sensul asta ,presupun ca implica obiectele astea rempte service binding?

Si inca ceva am facut o replicare simpla folosind sb intre doua servere de pe doua ip-uri din lan-ul in care sunt eu si observ un lag totusi ,adica mesajul nu ajunde instananeu pe calculatorul receptor,e normal asa,transmisia avand loc intr-o retea locala libera iar serverele sql nu executa alte tranzactii?

Multumesc

---

Secolul XXI ori va fi religios ori nu va fi deloc

Despre lag, depinde de cit lag vorbim. Milisecunde sint normale, citeva secunde deja ar pune intrebari. Un lucru de retzinut este ca sender-ul nu trimite mesajul pina cind tranzactzia care la trimis nu sa comis. Deasemenea, primul mesaj totdeauna va fi un pic mai incet daca trebuie sa deschida prima oara conexiunea, pentru ca trebuie sa astepte hadshake-ul conexiunii (authentifacare, authorizare, stabilirea incriptarii etc).

In momentul acesta traficul intre servere este deja incriptat (de catre cele doua 'endpoint'-uri, nu de catre 'service'-uri). Pentru a stabili si o sesiune de securitate la nivel 'service', i-tzi recomand sa folosesti tool-ul de la www.codeplex.com/slm

---

http://rusanu.com

Pai eu credeam ca dupa ce primul mesaj s-a trimis conexiunea tcp-iop se inchide am pus in stocata end conversation,tu spui ca e folosita si pentru conversatii ulterioare?\SI inca ceva te rog cu remote binding object alea ce sunt la ce folosesc ,eu am inteles ca la cryptarea dialogului asta cand specific optiunea de cryptare la comanda sent pe sender.\

Multumesc

---

Secolul XXI ori va fi religios ori nu va fi deloc

Conexinea este refolosita pentru tot traficul de Broker intre cele doua instante de SQL Server. Conexiunile se inchid automat dupa o perioada de inactivitate.

Pentru securizarea conversatziilor trebuie sa ne gindim ca exista doua puncte de vedere: aplicatzia cere ca sa existe securitate (o decizie care se stie in momentul in care se scrie codul aplicatziei) sau aplicatzia nu cere securitate dar 'deployment'-ul cere securitate (o decizie care nu este cunoscuta la momentul scrierii codului aplicatziei ci depinde de administrarea unui 'deployment' al aplicatziei).

Cind o aplicatzie cere securitate specifica in codul ei prin folosirea optiunii WITH ENCRYPTION = ON la verbul BEGIN DIALOG. Daca aceasta optiune este folosita, situl unde aplicatatia a fost instalat trebuie sa configureze securitatea (folosind REMOTE SERVICE BINDING).

Cind aplicatia nu cere securitate, atunci trebuie sa specifice WITH ENCRYPTION = OFF. In acest caz administratorul sitului aplicatziei are optiunea sa lase conversatziile fara securitate sau sa impuna securitatea (creeind un REMOTE SERVICE BINDING).

Aceleasi lucruri le-am descris si in blogul meu mai demult: http://blogs.msdn.com/remusrusanu/archive/2006/07/07/with-encryption-off-is-the-conversation-encrypted-or-not.aspx

Deci cind scrii o aplicatie e recomandata totdeauna sa folosesti WITH ENCRYPTION = OFF daca securitatea nu este ceruta, lasind administratorului sitului unde aplicatzia ruleaza sa aleaga daca instaleaza sau nu securitate.

 Despre ce sint si la ce folosesc REMOTE SERVICE BINDING (RSB) ele au rolul sa asocieze un serviciu remote (deci doar un nume de serviciu, un string, nu un obiect in baza de date locala) cu un 'database principal' (un user). Prin aceasta se declara ca mesajele sint trimise acelui user specificat in RSB. Folosind principiile criptografiei cu cheie publica, daca vrei sa trimitzi un mesaj care sa poata fi citit doar de un anumit user trebuie sa incriptezi mesajul folosind cheia lui publica, pentru ca numai el il poate decripta folosind cheia sa privata corespunzatoare. De aceea user-ul specificat in RSB trebuie sa posede un certificat care va fi folosit ca sa se incripteze mesajul si acest certificat trebuie sa fie obtiut prin importul certificatului folosit de owner-ul serviciului destinatie. Pe baza acelorasi principii ale criptografiei cu cheie publica cineva poate semna un mesaj folosind o cheie privata pentru ca oricine sa poata verifica semnatura folosind cheia publica. In cazul conversatiilor Service Broker user-ul care este owner-ul serviciului initiator trebuie sa posede un certificat care va fi folosit pentru a semna mesajele. Pentru ca mesajele sint semnate cu acest certificat, serviciul target poate folosi aceasta semnatura ca sa autentifice user-ul care a trimis mesajul (owner-ul certificatului importat in baza de date target) si acest user poate fi autorizat (SEND permission).
 

---

http://rusanu.com

rremus:

Conexinea este refolosita pentru tot traficul de Broker intre cele doua instante de SQL Server. Conexiunile se inchid automat dupa o perioada de inactivitate.

Pentru securizarea conversatziilor trebuie sa ne gindim ca exista doua puncte de vedere: aplicatzia cere ca sa existe securitate (o decizie care se stie in momentul in care se scrie codul aplicatziei) sau aplicatzia nu cere securitate dar 'deployment'-ul cere securitate (o decizie care nu este cunoscuta la momentul scrierii codului aplicatziei ci depinde de administrarea unui 'deployment' al aplicatziei).

Cind o aplicatzie cere securitate specifica in codul ei prin folosirea optiunii WITH ENCRYPTION = ON la verbul BEGIN DIALOG. Daca aceasta optiune este folosita, situl unde aplicatatia a fost instalat trebuie sa configureze securitatea (folosind REMOTE SERVICE BINDING).

Cind aplicatia nu cere securitate, atunci trebuie sa specifice WITH ENCRYPTION = OFF. In acest caz administratorul sitului aplicatziei are optiunea sa lase conversatziile fara securitate sau sa impuna securitatea (creeind un REMOTE SERVICE BINDING).

Aceleasi lucruri le-am descris si in blogul meu mai demult: http://blogs.msdn.com/remusrusanu/archive/2006/07/07/with-encryption-off-is-the-conversation-encrypted-or-not.aspx

Deci cind scrii o aplicatie e recomandata totdeauna sa folosesti WITH ENCRYPTION = OFF daca securitatea nu este ceruta, lasind administratorului sitului unde aplicatzia ruleaza sa aleaga daca instaleaza sau nu securitate.

 Despre ce sint si la ce folosesc REMOTE SERVICE BINDING (RSB) ele au rolul sa asocieze un serviciu remote (deci doar un nume de serviciu, un string, nu un obiect in baza de date locala) cu un 'database principal' (un user). Prin aceasta se declara ca mesajele sint trimise acelui user specificat in RSB. Folosind principiile criptografiei cu cheie publica, daca vrei sa trimitzi un mesaj care sa poata fi citit doar de un anumit user trebuie sa incriptezi mesajul folosind cheia lui publica, pentru ca numai el il poate decripta folosind cheia sa privata corespunzatoare. De aceea user-ul specificat in RSB trebuie sa posede un certificat care va fi folosit ca sa se incripteze mesajul si acest certificat trebuie sa fie obtiut prin importul certificatului folosit de owner-ul serviciului destinatie. Pe baza acelorasi principii ale criptografiei cu cheie publica cineva poate semna un mesaj folosind o cheie privata pentru ca oricine sa poata verifica semnatura folosind cheia publica. In cazul conversatiilor Service Broker user-ul care este owner-ul serviciului initiator trebuie sa posede un certificat care va fi folosit pentru a semna mesajele. Pentru ca mesajele sint semnate cu acest certificat, serviciul target poate folosi aceasta semnatura ca sa autentifice user-ul care a trimis mesajul (owner-ul certificatului importat in baza de date target) si acest user poate fi autorizat (SEND permission).
 

Cum anume as putea asocia unui user/login un anumit certificat in cazul meu cand am creat certificatul s-a atasat auto userului sa cu care era logat  nu?

---

Secolul XXI ori va fi religios ori nu va fi deloc

Pentru a da drepturi unui user să folosească un certificat pe care l-a creat un alt user, se foloseşte instrucţiunea:

GRANT <permisiune> ON CERTIFICATE :: <nume certificat> TO <nume user>

unde <permisiune> poate fi: CONTROL, TAKE OWNERSHIP, ALTER, REFERENCES sau VIEW DEFINITION. Dacă vrem ca user-ul respectiv să poată cripta datele cu acel certificat, dar să nu poată să le decripteze, atunci îi acordăm permisiunea VIEW DEFINITION sau REFERENCES. Dacă vrem să poată să encripteze şi să decripteze, atunci îi acordăm permisiunea CONTROL.

Îl rog pe Remus să corecteze şi să completeze ce am scris mai sus.

Răzvan
 

In cazul authorizarii SSB relatia cu pricina este cea de 'ownership' care se controleaza fie prin clause AUTHORIZATION la crearea obiectului, fie prin ALTER AUTHORIZATION:

CREATE CERTIFICATE [<certname>] AUTHORIZATION [<ownername>] WITH SUBJECT = '...';

ALTER AUTHORIZATION ON CERTIFICATE::[<certname>] TO [<newowner>];

---

http://rusanu.com

Multumesc pentru raspunsuri

---

Secolul XXI ori va fi religios ori nu va fi deloc