schema.saml-schema-authn-context-types-2.0.xsd Maven / Gradle / Ivy
Go to download
Show more of this group Show more artifacts with this name
Show all versions of opensaml Show documentation
Show all versions of opensaml Show documentation
The OpenSAML-J library provides tools to support developers working with the Security Assertion Markup Language
(SAML).
The newest version!
Document identifier: saml-schema-authn-context-types-2.0 Location:
http://docs.oasis-open.org/security/saml/v2.0/ Revision history: V2.0 (March, 2005): New core authentication
context schema types for SAML V2.0.
A particular assertion on an identity provider's part with respect to the authentication context
associated with an authentication assertion.
Refers to those characteristics that describe the processes and mechanisms the Authentication Authority
uses to initially create an association between a Principal and the identity (or name) by which the
Principal will be known
This element indicates that identification has been performed in a physical face-to-face meeting with
the principal and not in an online manner.
Refers to those characterstics that describe how the 'secret' (the knowledge or possession of which
allows the Principal to authenticate to the Authentication Authority) is kept secure
This element indicates the types and strengths of facilities of a UA used to protect a shared secret key
from unauthorized access and/or use.
This element indicates the types and strengths of facilities of a UA used to protect a private key from
unauthorized access and/or use.
The actions that must be performed before the private key can be used.
Whether or not the private key is shared with the certificate authority.
In which medium is the key stored. memory - the key is stored in memory. smartcard - the key is stored
in a smartcard. token - the key is stored in a hardware token. MobileDevice - the key is stored in a
mobile device. MobileAuthCard - the key is stored in a mobile authentication card.
This element indicates that a password (or passphrase) has been used to authenticate the Principal to a
remote system.
This element indicates that a Pin (Personal Identification Number) has been used to authenticate the
Principal to some local system in order to activate a key.
This element indicates that a hardware or software token is used as a method of identifying the
Principal.
This element indicates that a time synchronization token is used to identify the Principal. hardware -
the time synchonization token has been implemented in hardware. software - the time synchronization
token has been implemented in software. SeedLength - the length, in bits, of the random seed used in the
time synchronization token.
This element indicates that a smartcard is used to identity the Principal.
This element indicates the minimum and/or maximum ASCII length of the password which is enforced (by the
UA or the IdP). In other words, this is the minimum and/or maximum number of ASCII characters required
to represent a valid password. min - the minimum number of ASCII characters required in a valid
password, as enforced by the UA or the IdP. max - the maximum number of ASCII characters required in a
valid password, as enforced by the UA or the IdP.
This element indicates the length of time for which an PIN-based authentication is valid.
Indicates whether the password was chosen by the Principal or auto-supplied by the Authentication
Authority. principalchosen - the Principal is allowed to choose the value of the password. This is true
even if the initial password is chosen at random by the UA or the IdP and the Principal is then free to
change the password. automatic - the password is chosen by the UA or the IdP to be cryptographically
strong in some sense, or to satisfy certain password rules, and that the Principal is not free to change
it or to choose a new password.
Refers to those characteristics that define the mechanisms by which the Principal authenticates to the
Authentication Authority.
The method that a Principal employs to perform authentication to local system components.
The method applied to validate a principal's authentication across a network
Supports Authenticators with nested combinations of additional complexity.
Indicates that the Principal has been strongly authenticated in a previous session during which the IdP
has set a cookie in the UA. During the present session the Principal has only been authenticated by the
UA returning the cookie to the IdP.
Rather like PreviousSession but using stronger security. A secret that was established in a previous
session with the Authentication Authority has been cached by the local system and is now re-used (e.g. a
Master Secret is used to derive new session keys in TLS, SSL, WTLS).
This element indicates that the Principal has been authenticated by a zero knowledge technique as
specified in ISO/IEC 9798-5.
This element indicates that the Principal has been authenticated by a challenge-response protocol
utilizing shared secret keys and symmetric cryptography.
This element indicates that the Principal has been authenticated by a mechanism which involves the
Principal computing a digital signature over at least challenge data provided by the IdP.
The local system has a private key but it is used in decryption mode, rather than signature mode. For
example, the Authentication Authority generates a secret and encrypts it using the local system's public
key: the local system then proves it has decrypted the secret.
The local system has a private key and uses it for shared secret key agreement with the Authentication
Authority (e.g. via Diffie Helman).
This element indicates that the Principal has been authenticated through connection from a particular IP
address.
The local system and Authentication Authority share a secret key. The local system uses this to encrypt
a randomised string to pass to the Authentication Authority.
The protocol across which Authenticator information is transferred to an Authentication Authority
verifier.
This element indicates that the Authenticator has been transmitted using bare HTTP utilizing no
additional security protocols.
This element indicates that the Authenticator has been transmitted using a transport mechanism protected
by an IPSEC session.
This element indicates that the Authenticator has been transmitted using a transport mechanism protected
by a WTLS session.
This element indicates that the Authenticator has been transmitted solely across a mobile network using
no additional security mechanism.
This element indicates that the Authenticator has been transmitted using a transport mechnanism
protected by an SSL or TLS session.
Refers to those characteristics that describe procedural security controls employed by the
Authentication Authority.
Provides a mechanism for linking to external (likely human readable) documents in which additional
business agreements, (e.g. liability constraints, obligations, etc) can be placed.
This attribute indicates whether or not the Identification mechanisms allow the actions of the
Principal to be linked to an actual end user.
This element indicates that the Key Activation Limit is defined as a specific duration of time.
This element indicates that the Key Activation Limit is defined as a number of usages.
This element indicates that the Key Activation Limit is the session.