SecurityKeyType Énumération

Définition

Espace de noms:

System.IdentityModel.Tokens

Assembly:

System.ServiceModel.Primitives.dll

Paquet:

System.ServiceModel.Primitives v6.2.0

Source:

SecurityKeyType.cs

Spécifie le type de clé associé à un jeton de sécurité.

public enum class SecurityKeyType

public enum SecurityKeyType

type SecurityKeyType = 

Public Enum SecurityKeyType

Héritage

Object

ValueType

Enum

SecurityKeyType

Champs

AsymmetricKey	1	Spécifie que la clé est une clé asymétrique.
BearerKey	2	Spécifie que le jeton de sécurité ne contient pas de clé preuve-de-possession.
SymmetricKey	0	Spécifie que la clé est une clé symétrique.

Remarques

Utilisez l'énumération SecurityKeyType pour définir la propriété KeyType.

Le champ BearerKey est utilisé avec la propriété KeyType.

BearerKey requiert Wsu:Id ou une sécurité de transport avec informations d'identification dans le message

Dans les scénarios de fédération, un jeton émis est généralement configuré comme un jeton de prise en charge d'approbation pour la sécurité des messages entre un client et les parties de confiance. Toutefois, lorsqu’un service STS (Security Token Service) émet un jeton sans clé (BearerKey), WCF le configure en tant que SecurityTokenAttachmentMode.SignedEncrypted jeton de prise en charge (WCF ne peut pas approuver sans clé). Cela implique que le jeton émis soit référencé dans la signature. WCF utilise actuellement les éléments suivants : http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd:Id comme mécanisme de référence (Wsu:Id).

Si un jeton émis ne possède pas d'attribut de ce type, sur un client, une MessageSecurityException est levée avec le texte « L'élément à signer doit avoir un identificateur ». Cela se produit lorsqu'un jeton SAML 1.1 est utilisé en tant que jeton émis (le Wsu:Id n'est pas défini dans la spécification SAML 1.1).

Pour contourner cette situation, utilisez la sécurité de transport avec les informations d’identification de message (par exemple, AuthenticationMode.IssuedTokenOverTransport) ou un STS doit ajouter le http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd:Id (Wsu:Id) au jeton émis.

Notez que si le Wsu:Id est ajouté à un jeton SAML 1.1, le XML produit n'est alors pas conforme à la spécification SAML 1.1. L'autre approche consiste à ajouter un Wsu:Id à l'élément EncryptedData qui découle du chiffrement du jeton émis. Cette procédure est conforme à la spécification SAML 1.1 puisque l'élément EncryptedData prend en charge l'attribut Wsu:Id.

Par conséquent, pour satisfaire à la spécification, le jeton de porteur doit être chiffré par le STS.