Tipi di asserzioni e soggetti delle policies

Una asserzione di policy è un modo per definire un requisito, un vincolo o una proprietà. Il linguaggio WS-SecurityPolicy introduce un insieme di asserzioni per abilitare i requisiti di sicurezza dei Web services in modo che possano essere dichiarati in un modo standard e interoperabile. A questo proposito segue un esempio di asserzione che definisce che il body dei messaggi SOAP deve essere firmato.

<sp:SignedParts>
<sp:Body/>
</sp:SignedParts>

Nel linguaggio sono definiti cinque principali tipi di asserzioni, descritti di seguito.

Security binding assertions

Usate per definire il meccanismo di base impiegato per rendere sicuro lo scambio di messaggi. Definiscono alcune proprietà come chiavi da adottare, algoritmi e così via. Inoltre, alcune proprietà comuni con altre asserzioni vengono qui definite ed iniettate nelle altre qualora necessario. Nella specifica sono definite tre asserzioni per questo tipo, ognuna usabile in un dato scenario.

1. Transport binding assertion: la protezione del messaggio è fornita dal mezzo di trasporto, di norma HTTPS. E’ possibile stabilire un token di trasporto attraverso cui vincolare i messaggi ad essere scambiati solo attraverso un mezzo specifico.
2. Asymmetric binding assertion: adatto ad essere usato quando entrambe le parti (client e provider del servizio) sono in possesso di tokens di sicurezza, ad esempio certificati X509, con il client che usa la chiave privata per firmare e la chiave pubblica del destinatario per criptare, mentre il destinatario usa la propria chiave privata per decriptare e la chiave pubblica del client per verificare la firma. Con il binding asimmetrico è possibile definire tokens usati dal client e dal provider utilizzando le properties Initiator Token e Recipient Token.
3. Symmetric binding assertion: usato quando solo una parte necessita di generare security tokens. Il security token è impiegato per stabilire una chiave simmetrica eventualmente usata per firma e criptazione. Ad esempio, questa asserzione può essere usata se il solo provider dispone di un Token X509. Il client in questo caso genererà una chiave effimera utilizzando la chiave pubblica del server, chiave effimera che verrà usata per firmare e criptare i messaggi di andata e ritorno. Questo meccanismo permette a un Web service di firmare e criptare messaggi anche con clients anonimi, capacità estremamente utile in ambiente reale. Il binding simmetrico definisce tre tipi di properties, ossia protection token, signature token ed encryption token. Vengono inoltre definite un insieme di proprietà utilizzate nello scambio sicuro dei messaggi. I principali riguardano gli algoritmi usati per la criptografia, il timestamp, la protezione della firma e del token, ossia se devono essere criptati a loro volta, se la firma deve coprire l’intero corpo del messaggio SOAP o solo l’header.

Protection assertions

Asserzioni che definiscono quali parti dei messaggi vengono protette e come. Sono principalmente di due tipi, Integrity Assertions e Confidentiality Assertions. Le prime definiscono quali elementi dei messaggi firmare mentre le seconde quali criptare.

Token assertions

Asserzioni che specificano i tipi di tokens usati per proteggere i messaggi. Definiscono inoltre due proprietà usate per proteggere i messaggi.

1. Derived Keys property: usata per definire se possono essere usate chiavi derivate, nel qual caso i tokens derivati dal token originale dovrebbero essere adottati per firmare e criptare i messaggi.
2. Token Inclusion property: usati per definire quando i tokens vanno inserire nei messaggi scambiati. I possibili valori sono Never (token non incluso nel messaggio ma che può essere referenziato verso fonti esterne), Once (inviato una volta dal client che successivamente può ometterlo), AlwaysToRecipient (tutti i messaggi inviati dal client devono contenere il token), Always (tutti i messaggi nelle due direzioni devono contenere il token).

Tra i tipi di token definiti in WS-SecurityPolicy troviamo Username Tokens, X509 Tokens, Issued Tokens, Secure Conversation Tokens, SAML Tokens e HTTPS Tokens.

Supporting token assertions

Usati per fornire claims aggiuntivi per un client, permettendo inoltre di firmare e criptare elementi aggiuntivi con il supporto dei protection assertions. Ve ne sono di quattro tipi (Supporting Tokens, Signed Supporting Tokens, Endorsing Supporting Tokens, Signed Endorsing supporting tokens) che descrivono quattro scenari in cui la firma può avvenire o meno riguardando token primario e/o elementi definiti nelle policy di sicurezza.

Protocol assertions

Vi sono tre tipi di asserzioni (WSS10, WSS11, Trust10) usate per fornire sicurezza al messaggio SOAP e opzioni di trust. Sono opzioni che definiscono requisiti che client e server devono supportare.

1. WSS10: le proprietà definiscono se client e provider devono essere in grado di processare riferimenti diretti, riferimenti a identificatori di chiavi, riferimenti seriali, URI esterni, riferimenti a tokens.
2. WSS11: le proprietà descrivono se client e provider devono essere in grado di processare riferimenti di identificazioni personali, chiavi criptate, firme che seguono le specifiche di SOAP Message Security 1.1, riferimenti diretti, identificatori di chiavi, riferimenti seriali, URI esterni, embedded tokens.
3. Trust10: le proprietà descrivono se devono essere supportati problemi del client o del server (ad esempio se il client non si autentica si potrebbe rispondere con un messaggio che indica cosa fare), entropia del client o del server (chiavi randomiche), o se deve essere supportato l’header wst:IssuedTokens nell’header SOAP.