WS-SecurityPolicy

WS-SecurityPolicy to specyfikacja usług sieciowych , stworzona przez IBM i 12 współautorów, która od wersji 1.2 stała się standardem OASIS . Rozszerza podstawowe protokoły bezpieczeństwa określone przez WS-Security , WS-Trust i WS-SecureConversation, oferując mechanizmy reprezentujące możliwości i wymagania usług sieciowych jako zasady. Asercje polityki bezpieczeństwa są oparte na strukturze WS-Policy .

Potwierdzeń zasad można używać do wymagania bardziej ogólnych atrybutów zabezpieczeń, takich jak zabezpieczenia warstwy transportowej <TransportBinding> , zabezpieczenia na poziomie komunikatów <AsymmetricBinding> lub sygnatury czasowe oraz określone atrybuty, takie jak typy tokenów.

Większość twierdzeń politycznych można znaleźć w następujących kategoriach:

• Potwierdzenia ochrony identyfikują elementy wiadomości, które muszą być podpisane, zaszyfrowane lub istnieć.
• Asercje tokenów określają dozwolone formaty tokenów (SAML, X509, nazwa użytkownika itp.).
• Potwierdzenia powiązań bezpieczeństwa kontrolują podstawowe zabezpieczenia, takie jak zabezpieczenia na poziomie transportu i komunikatów, zestaw algorytmów kryptograficznych i wymagane znaczniki czasu.
• Obsługa asercji tokenów dodaje funkcje, takie jak logowanie użytkownika przy użyciu tokenu nazwy użytkownika.

Zasady mogą być używane do kierowania narzędziami programistycznymi do generowania kodu z określonymi możliwościami lub mogą być używane w czasie wykonywania do negocjowania aspektów bezpieczeństwa komunikacji usługi sieciowej. Zasady mogą być dołączone do WSDL , takich jak usługa, port, operacja i komunikat, zgodnie z definicją w Załączniku zasad WS.

Przykładowe zasady

Przestrzenie nazw używane przez następujące fragmenty kodu XML:

<p:Policy 
   xmlns:p="http://www.w3.org/ns/ws-policy"
   xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200802"> ...</p:Policy>

Dołącz znacznik czasu:

<sp:IncludeTimestamp />

Użyj zabezpieczeń warstwy transportowej (https) lub zabezpieczeń na poziomie wiadomości (XML Dsig/XML Enc):

<ExactlyOne><sp:TransportBinding><i>...</i> <b>...</b></sp:TransportBinding><sp:AsymmetricBinding> <i>...</i> <b>...</b></sp:AsymmetricBinding ></ExactlyOne>

Aby zdefiniować asercję SAML jako token bezpieczeństwa:

<sp:IssuedToken><sp:RequestSecurityTokenTemplate><wst:TokenType>...#SAMLV2.0</wst:TokenType></sp:RequestSecurityTokenTemplate></sp:IssuedToken>

Wydane potwierdzenie tokena dostawców w odniesieniu do STS i wymaganego formatu tokena:

<sp:IssuedToken><sp:Issuer><wsa:EndpointReference><wsa:Address><i>http://sampleorg.com/sts</i> <b>http://sampleorg.com/sts</b></wsa:Address></wsa:EndpointReference></sp:Issuer><sp:RequestSecurityTokenTemplate><wst:TokenType> <i>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID</i> <b>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID</b></wst:TokenType> <i>...</i> <b>...</b></sp:RequestSecurityTokenTemplate> <i>...</i> <b>...</b></sp:IssuedToken>

Określ, że nagłówek i treść wiadomości mają być podpisane, a załączniki mają pozostać niepodpisane:

<sp:SignedParts xmlns:sp="..." ... ><sp:Body /><i>?</i> <b>?</b><sp:Header Name="Dx:NCName"? Namespace="Xd:anyURI" ... /> <i>* ...</i> <b>* ...</b></sp:SignedParts>

określ, że wiadomość ma zostać podpisana licencja open source, a zabezpieczenia hydra mają pozostać niepodpisane:

<sp:signedparts http:np="..."...><sp:Hydrasecurity /><i>?</i> <b>?</b><sp:Opensourcelicense Name="Hs:NCName"? Namespace="Sh:anyURI" .../> <i>* ...</i> <b>* ...</b></sp:SignedParts>

Inne języki zasad WS

Termin Język zasad zabezpieczeń usług sieci Web jest używany w odniesieniu do dwóch różnych języków opartych na XML:

1. Jak opisano powyżej, w oparciu o strukturę WS-Policy, zgodnie z definicją w, opublikowaną jako wersja 1.3 w lutym 2009 r.
2. WSPL, oparty na profilu XACML dla usług sieciowych , ale nie został sfinalizowany.

Zobacz też

• Lista specyfikacji usług internetowych

Linki zewnętrzne

• Standardy WS-SecurityPolicy w OASIS
• Bezpieczeństwo w świecie usług internetowych: proponowana architektura i plan działania (biały dokument IBM/Microsoft, 2002)