Abstract: Techniques are disclosed for enabling a user to validate the authenticity of a computing system (e.g., an access management system) such as one which controls access to one or more resources. A user can determine the authenticity of an access management system before the user provides credential information to the access management system. A user can be presented at a client system with an interface to request authentication of an access management system. The access management system may provide the user at the client system with temporary access information to submit back to the access management system. The access management system may provide recent personal information to the user at the client system to verify the access management system. Upon verification of the personal information, the access management system may prompt the user for credential information to establish a session.

Abstract: Techniques are disclosed for a single sign-on (SSO) enterprise system with multiple data centers that can use a lightweight cookie on a user's client device. The lightweight cookie can include a reference to a data center in which the user is already authenticated, and a new data center can contact the old data center for creating a session for the user on the new data center. If the old data center is unavailable, then the new data center may fall back to accessing a local security store, a backup of keys, security tokens, and/or other security data, in order to create a local session for the user on the new data center.

Abstract: Techniques are disclosed for using a global unified session identifier across data centers. Upon creating an initial session in the data center for a user first accessing the data center, a session identifier is generated for the user session. Because the initial session is the first session created for that user, the initial session identifier is designated as the global unified session identifier for all sessions that may be created for the user in other data centers within the enterprise network. Data centers may then map the global unified session identifiers to locally generated session identifiers for the user. A global unified session identifier enables various user session actions to be performed globally across the data centers, including global logout, global session termination, global session updates, and/or the like. A global unified session identifier prevents the risk of collision that can occur between randomly generated numbers of different data centers.

Abstract: Techniques are disclosed for providing users of an access management system the capability to manage the user's active sessions. The system may receive a first request by a user at a first device to modify one or more sessions established for the user. The system may access session information about the one or more sessions that are associated with the user, wherein a session of the one or more sessions provides the user with access to one or more resources. The system may send the session information to the first device, the session information causing the first device to display a graphical interface including the session information about the one or more sessions. The system may receive, from the first device, a second request indicating a modification to the session. The system may modify the session in accordance with the modification indicated in the second request.

Abstract: Techniques are disclosed for managing session activity of SSO access across multiple data centers. Session activity of SSO access is managed across multiple geographically disperse computing systems clustered together to form a multi-data center (MDC) system. A first data center in the MDC system may implement session adoption to manage an SSO session of the user in the MDC system. Information about subsequent sessions established by other data centers may be adopted by the first data center. The first data center may obtain session activity data from each session that is adopted for the user. The session activity may be used to determine whether SSO session is active for the user across data centers in the MDC system. Authorization to access a resource at any data center in the MDC system may be granted based on the status of the SSO session using session adoption among the data centers.

Abstract: Systems and methods are disclosed for a single sign-on (SSO) enterprise system with multiple data centers that use a lightweight cookie on a user's client device. The lightweight cookie includes a reference to a data center in which the user is already authenticated, and a new data center contacts the old data center for creating a session for the user on the new data center. If the old data center is unavailable, then the new data center may fall back to accessing a local security store, a backup of keys, security tokens, and/or other security data, in order to create a local session for the user on the new data center.

Abstract: Techniques are disclosed for managing session activity of SSO access across multiple data centers. Session activity of SSO access is managed across multiple geographically disperse computing systems clustered together to form a multi-data center (MDC) system. A first data center in the MDC system may implement session adoption to manage an SSO session of the user in the MDC system. Information about subsequent sessions established by other data centers may be adopted by the first data center. The first data center may obtain session activity data from each session that is adopted for the user. The session activity may be used to determine whether SSO session is active for the user across data centers in the MDC system. Authorization to access a resource at any data center in the MDC system may be granted based on the status of the SSO session using session adoption among the data centers.

Abstract: Techniques are disclosed for protecting a user from denial of service (DOS) to access his/her a user account that has been locked. An access management system can provide features that enable an owner of an account to prevent the account from becoming locked. Specifically, the techniques disclosed herein enable an account holder to circumvent procedures of the access management system that lock an account after several unsuccessful attempts to access the account. The access management system may operate according to a configuration for managing access to account. The access management system can manage access to an account by presenting a user with an interface to received access information (e.g., account information and credential information) for the account to determine whether to unlock the account. The access management system can deny access to an account upon determining that the credential information is not correct for the account.

Abstract: Techniques are disclosed to modify the authentication level of a session providing access to resources. In some embodiments, an access management system is configurable to enable voluntary (e.g., request by a user) or involuntary (e.g., by the access management system) reduce, or “step-down” the authentication level for a session if a lower authentication level exists. For example, an access management system may be configured to enable a user to request a step-down of the authentication level of a session to prevent access to resources at a higher authentication level. By reducing the authentication level to a lower authentication level, a user may be prompted to provide credentials for authentication according to the authentication schemes defined for higher authentication levels. These techniques can reduce, if not prevent, unauthorized access to protected resources by challenging a user for credentials to authenticate to higher authentication levels.

Abstract: Techniques are disclosed for facilitating impersonation for accessing resources through an access management system. When a user (“impersonator”) requests access to impersonate another user (“impersonatee”), the access management system may generate security data having two parts. One part may include a first security key that is sent to the impersonator and a second part may include a second security key that is sent to the impersonatee. Receipt of the second security key notifies the impersonatee about a request for impersonation to access a resource according to access permitted to the impersonatee. The impersonatee, if consenting to impersonation, may provide the security key received to the impersonator, thereby implicitly providing the impersonator with trust at run-time to access the resource. Upon verification of both security keys, by the access management system, access to a resource is provided to the impersonator based on access to the resource permitted to the impersonatee.

Abstract: Techniques are disclosed for managing session information stored by an access management system. Certain techniques are disclosed for updating session information based characteristics of the session information to be updated. The disclose techniques disclose how session information is updated and the frequency in which the session information is updated. Certain embodiments may enable a descrease in computing performance overhead and/or memory usage overhead caused by managing session information (e.g., performing authentication or determining authorization to access a resource) for a session.

Abstract: Techniques are disclosed for enabling a user to validate the authenticity of a computing system (e.g., an access management system) such as one which controls access to one or more resources. A user can determine the authenticity of an access management system before the user provides credential information to the access management system. A user can be presented at a client system with an interface to request authentication of an access management system. The access management system may provide the user at the client system with temporary access information to submit back to the access management system. The access management system may provide recent personal information to the user at the client system to verify the access management system. Upon verification of the personal information, the access management system may prompt the user for credential information to establish a session.

Abstract: Techniques are disclosed for using a global unified session identifier across data centers. Upon creating an initial session in the data center for a user first accessing the data center, a session identifier is generated for the user session. Because the initial session is the first session created for that user, the initial session identifier is designated as the global unified session identifier for all sessions that may be created for the user in other data centers within the enterprise network. Data centers may then map the global unified session identifiers to locally generated session identifiers for the user. A global unified session identifier enables various user session actions to be performed globally across the data centers, including global logout, global session termination, global session updates, and/or the like. A global unified session identifier prevents the risk of collision that can occur between randomly generated numbers of different data centers.

Abstract: Techniques are disclosed for restricting access to resources accessible in a SSO session. An access management system may provide access one or more resources by implementing an SSO system to provide a SSO session. An SSO session may provide an authenticated user with access to protected resources to which the user is entitled to access. In some instances, a user sharing a computer with other users may want to access a particular protected resource so as to restrict other users sharing the computer from accessing other protected resources accessible to the user in an SSO session. The access management system may enable the user to dynamically choose, such as during login, the protected resources which to restrict and/or permit. Upon successful authentication, a session may be established for only those protected resources that are permitted based on the user's selection, while the other resources are restricted.

Abstract: Systems and methods are disclosed for using a global unified session identifier across data centers. When a user first accesses a data center and an initial session is created for the user in the data center, a session identifier is generated for the user session. Because the initial session is the first session created for that user, the initial session identifier is designated as the global unified session identifier for all sessions that may be created for the user in other data centers within the enterprise network. Other data centers may then map the global unified session identifiers to locally generated session identifiers for the user. Using a global unified session identifier enables various user session actions to be performed globally across the data centers, including global logout, global session termination, global session updates, and/or the like.

Abstract: Techniques are disclosed for managing session activity of SSO access across multiple data centers. Session activity of SSO access is managed across multiple geographically disperse computing systems clustered together to form a multi-data center (MDC) system. A first data center in the MDC system may implement session adoption to manage an SSO session of the user in the MDC system. Information about subsequent sessions established by other data centers may be adopted by the first data center. The first data center may obtain session activity data from each session that is adopted for the user. The session activity may be used to determine whether SSO session is active for the user across data centers in the MDC system. Authorization to access a resource at any data center in the MDC system may be granted based on the status of the SSO session using session adoption among the data centers.

Abstract: Techniques are disclosed for a single sign-on (SSO) enterprise system with multiple data centers that can use a lightweight cookie on a user's client device. The lightweight cookie can include a reference to a data center in which the user is already authenticated, and a new data center can contact the old data center for creating a session for the user on the new data center. If the old data center is unavailable, then the new data center may fall back to accessing a local security store, a backup of keys, security tokens, and/or other security data, in order to create a local session for the user on the new data center.

Abstract: Systems and methods are disclosed for a single sign-on (SSO) enterprise system with multiple data centers that use a lightweight cookie on a user's client device. The lightweight cookie includes a reference to a data center in which the user is already authenticated, and a new data center contacts the old data center for creating a session for the user on the new data center. If the old data center is unavailable, then the new data center may fall back to accessing a local security store, a backup of keys, security tokens, and/or other security data, in order to create a local session for the user on the new data center.

Abstract: Systems and methods are disclosed for a single sign-on (SSO) enterprise system with multiple data centers that use a lightweight cookie on a user's client device. The lightweight cookie includes a reference to a data center in which the user is already authenticated, and a new data center contacts the old data center for creating a session for the user on the new data center. If the old data center is unavailable, then the new data center may fall back to accessing a local security store, a backup of keys, security tokens, and/or other security data, in order to create a local session for the user on the new data center.

Abstract: A method of dynamically communicating a parameter during runtime may include providing a script to a command-line scripting module that uses the parameter, where the parameter is to be provided during runtime by a user and the script is configured to generate an exception including an identifier associated with the parameter. The method may also include generating byte code based on the script, executing the byte code on a virtual machine until the exception is generated, passing the exception to the command-line scripting module, causing, by the command-line scripting module, receiving a parameter value from the user through an input device, passing the parameter value to the virtual machine, and continuing execution of the byte code on the virtual machine.