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 . 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.

Definition by Ian Glazer, in Access Certification and Entitlement Management v1, September 9, 2009.

http://www.burtongroup.com/Client/Research/Document.aspx?cid=1732 (login required)

These objectives are attained by creating a set of robust, consistent processes to grant and revoke entitlements across multiple systems and applications:

1. Create and regularly update a consolidated database of entitlements.
2. Define roles, so that entitlements can be assigned to users in sets that are easier for business users to understand.
3. Enable self-service requests and approvals, so that decisions about entitlements can be made by business users with contextual knowledge, rather than by IT staff.
4. Synchronize entitlements between systems, where appropriate.
5. Periodically invite business stake-holders to review entitlements and roles assigned to users and identify no-longer-appropriate ones for further examination and removal.

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 .

Meta directories are used to implement auto-provisioning , auto-termination and identity synchronization .

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 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 and that users change their passwords regularly .

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 , which should be at least as strong as the policies in each of the target applications .

Transparent password synchronization typically must enforce a multi-system password policy 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 .

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

on his own account can authenticate with something other than his password and have a new password administratively set on his account.

Password resets may be performed by a support analyst 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.

User provisioning is intended to make the creation, management and deactivation of login accounts and other user objects, which are spread across multiple systems, faster, cheaper and more reliable. This is done by automating and codifying business processes such as onboarding and termination and connecting these processes to multiple systems.

User provisioning systems work by automating one or more processes:

• Identity synchronization:
  Detect changes to personal data, such as phone numbers or department codes, on one system and automatically make matching changes on other systems for the same user.
• Auto-provisioning:
  Detect new user records on a system of record (such as HR) and automatically provision those users with appropriate access on other systems and applications.
• Auto-deactivation:
  Detect deleted or deactivated users on an authoritative system and automatically deactivate those users on all other systems and applications.
• Self-service requests:
  Enable users to update their own profiles (e.g., new home phone number) and to request new entitlements (e.g., access to an application or share).
• Delegated administration:
  Enable managers, application owners and other stake-holders to modify users and entitlements within their scope of authority.
• Authorization workflow:
  Validate all proposed changes, regardless of their origin and invite business stake-holders to approve them before they are applied to integrated systems and applications.
• Consolidated reporting:
  Provide data about what users have what entitlements, what accounts are dormant or orphaned, change history, etc. across multiple systems and applications.

As well, a user provisioning system must be able to connect these processes to systems and applications, using connectors that can:

• List existing accounts and groups.
• Create new and delete existing accounts.
• Read and write identity attributes associated with a user object.
• Read and set flags, such as "account enabled/disabled," "account locked," and "intruder lockout."
• Change the login ID of an existing account (rename user).
• Read a user's group memberships.
• Read a list of a group's member users.
• Add an account to or remove an account from a group.
• Create, delete and set the attributes of a group.
• Move a user between directory organizational units (OUs).

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 despite being locked out of the initial workstation login screen.