The premise is that adding authentication factors makes it more difficult for a would-be attacker to simulate a legitimate authentication and consequently impersonate a legitimate user.

An example of the latter is a PIN-based enrollment of challenge/response data. In this scenario, users are e-mailed a PIN, which they use to authenticate and complete a personal challenge/response profile. This profile may later be used in the context of self-service password reset. In this scenario, the PINs are equivalent to the challenge/response data, and that is equivalent to user login passwords -- so ultimately enrollment PINs are security-equivalent to login passwords (a bad thing!).

On some systems, intruder lockouts are cleared automatically, after a period of time has elapsed. On others, administrative intervention is required to clear a lockout.

Note that on some systems and applications, intruder lockouts and administrator lockouts are entangled (they use the same flag). This is a poor but common design.

Administrator lockouts normally precede permanent deletion of the account, and provide an opportunity to retrieve data from the account before it is removed.

Note that on some systems and applications, intruder lockouts and administrator lockouts are entangled (they use the same flag). This is a poor but common design.

Since the CA's business is to verify that a given public key was generated by the user it purportedly comes from, public keys signed by the CA can be trusted to really belong to their stated owner.

Certificates are useful for signature verification (a document is encrypted by the user's private key, and this is verified using the user's certificate) and authentication (a user is asked to encrypt something, and if the user's certificate can decrypt it, then the user must have possessed the matching private key).

Smart cards are useful for authentication since they constitute an authentication factor (something the user has) and they often require a second factor (e.g., user typing in a password) to be activated, which is a second factor (something the user knows).

With more modern technology, a user may sign into a corporate network, identify himself and wait for a single-use random PIN to be phoned or text messaged to his home or cellular telephone. This PIN is subsequently used to authenticate to a network service.

1. The user identifies himself to an application by typing his e-mail address.
2. An e-mail containing a randomized URL is sent to that address.
3. If the user can click on the e-mail, he has demonstrated that he has access to the e-mail account, and is therefore authenticated.

This is a weak form of authentication, since it is impossible to say how secure the user's e-mail service is, but it is adequate for many applications.

In these cases, it may be preferable to create a "virtual" group, whose membership is not explicitly defined. Instead, membership in a virtual group is calculated at runtime, by evaluating a logical expression based on identity attributes ([link]). For example, users may be said to belong to a group "Dallas-Managers" if their location attribute is equal to "DFW" and their position attribute is set to "Manager."

In other words, virtual groups are named expressions that evaluate to boolean true for users that are considered to be members of a group.

Parallel authorization has the advantage of completing more quickly, as the time required to finish an authorization process is the single longest response time, rather than the sum of all response times.

Consensus authorization is implemented in order to expedite the approvals process and make sure that it is completed even in cases where some authorizers are unavailable to respond.

Sequential (or serial) authorization has the advantage of minimizing the nuisance to authorizers in the event that an early authorizer rejects a change request ([link]).

Please see also auto-provisioning: [link], auto-termination: [link] and identity synchronization: [link].

SAML allows for single sign-on between domains, in cases where cookies, for example, cannot be used (web browsers in general only allow cookies to be submitted to the same domain that issued them).

In practical terms, users authenticate to the identity provider. When users attempt to access content or applications on the service provider, their web browser is directed to request SAML assertions from the identity provider and pass those back to the service provider. In this way, the service provider no longer has to authenticate the user directly, and instead relies on statements about the user made by the identity provider, which does authenticate the user.

In short, applications are unmodified and continue to perform user authentication. Reduced sign-on is achieved by auto-populating rather than removing login prompts.

One of the advantages of WebSSO is that multiple, separate login pages are replaced by a single, shared authentication process, so the frequency of user logins is reduced.

Web proxies act on behalf of one or more users.

Reverse web proxies act on behalf of one or more web servers.

WebSSO systems ([link]) may be implemented using a reverse web proxy architecture, which insert user application credentials into each HTTP stream.

The reverse web proxy architecture has the advantage of not requiring software to be installed on each web application -- attractive when a WebSSO system is integrated with a large number of web applications.

The server agent architecture has the advantage of not requiring new hardware to be deployed when implementing a WebSSO system.

This technology depends on a business relationship with implicit trust of B by A.

Simple trust relationships are two-way, while complex ones may have groups of multi-way trust (i.e., any organization in a group trusts any other to make assertions about its own users).

Password policies may require a minimum length, a mixture of different types of characters (lowercase, uppercase, digits, punctuation marks, etc.), avoidance of dictionary words or passwords based on the user's name, etc.

Password policies may also require that users not reuse old passwords ([link]) and that users change their passwords regularly ([link]).

The reason for password history is the notion that, given enough time, an attacker could guess a given password. To avoid this, passwords should be changed periodically and not reused.

The reason for password expiry is the notion that, given enough time, an attacker could guess a given password. To avoid this, passwords should be changed periodically and not reused.

Users typically sign into the password synchronization web page using a primary login ID and password and can then specify a new password, which will be applied to multiple systems and applications.

A password synchronization web application typically must enforce a password policy ([link]), which should be at least as strong as the policies in each of the target applications ([link]).

Transparent password synchronization typically must enforce a multi-system password policy ([link]) in addition to the native policy of the system where synchronization is initiated. This policy should be at least as strong as the policies in each of the target applications ([link]).

The only credentials involved in a routine password change are the user's identifier, old password and new password.

Password resets may be performed by a support analyst ([link]) or by the user himself (self-service).

SSPR is normally deployed to reduce IT support cost, by diverting the resolution of password problems away from the (expensive, human) help desk.

It should be noted that automated provisioning normally operates without a user interface -- i.e., data flows in from one system and out to one or more other systems, without any further user input in between.

Auto-provisioning reduces IT support costs and can shorten the time required to provision new users with requisite access rights.

It should be noted that automated termination normally operates without a user interface -- i.e., data flows in from one system and out to one or more other systems, without any further user input in between.

Auto-termination reduces IT support costs and can make access deactivation both faster and more reliable than manual processes.

It should be noted that identity synchronization normally operates without a user interface -- i.e., data flows in from one system and out to one or more other systems, without any further user input in between.

For example, an e-mail system may be authoritative for each user's SMTP e-mail address, an HR system for the same users' employee number and department code, a white pages application for each user's phone number and so on. An identity synchronization system makes sure that all of these systems have correct and up-to-date information in each of these fields.

Delegated user administration may be thought of as consolidated user administration plus filters that limit what one user can see of and do to another.

Installation of local agents requires change control on the target system itself -- something which may be difficult and/or undesirable on a production system or application.

Local agents are well positioned to detect changes to user objects on a target system in real time, forwarding these changes to an identity management system which may act on them.

Communication between an identity management system and a local agent can always be protected, even if the native communication protocols of the target system are insecure.

Installation of remote agents requires no change control on the target system itself, making them easier to deploy and possibly more scalable, when hundreds or thousands or target systems are involved.

Local agents normally cannot detect changes to user objects on a target system in real time, so must poll target systems for changes periodically.

Communication between an identity management system and a local agent may not be secure, since it relies on the native communication protocols of the target system, which in some cases may be vulnerable to eavesdropping or data injection.

This may be easier to automate and faster to deploy, but requires further, manual intervention before a new user can be fully productive.

This may be more complex to automate and longer to deploy, but eliminates further, manual intervention before a new user can be fully productive.

For example, only a single person might be granted administrative privileges (via disclosure of an administrator password) to a given system at once.

A checkin/checkout process is one where a user "checks out" a password, much like a library book, and "checks it back in" when finished. The password may be changed at checkin time.

When users forget their Windows password, some mechanism is required to present them a user interface despite the fact that they cannot get by the GINA and access their desktop.

A SKA is a mechanism that allows users to access a self-service password reset web application ([link]) despite being locked out of the initial workstation login screen.