xsd.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 specs-saml-assertion Show documentation
Show all versions of specs-saml-assertion Show documentation
Generated sources from the SAML Assertion XML Schemas.
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.
© 2015 - 2025 Weber Informatics LLC | Privacy Policy