Abstract: An access analysis system obtains data about user requests to access particular applications, such as identifiers of the particular user and application involved, the time of the request, and (optionally) additional contextual data, and uses that data to generate user access distributions that quantify the distribution of a given user's requests to access applications over time. After one or more distributions have been generated for a particular user, when that user submits a new access request for an application, the access analysis system can compare the request to the previously-generated access distributions to determine whether (or to what degree) the request is anomalous. If the request is sufficiently non-anomalous, it can be granted with little or no additional actions required by the user or the user's device; if, however, the request is sufficiently anomalous, it can be denied, or additional information—such as additional user authentication factors—can be required.

Abstract: An authentication system facilitates a transfer of enrollment in authentication services between client devices. The authentication system enrolls a client device in authentication services to enable the client device to be used for authenticating requests to access one or more services. As part of enrolling the client device, the authentication system receives authentication enrollment information for the client device that is associated with one or more authentication credentials securely stored on the client device (e.g., a multi-factor authentication (MFA) certificate). The authentication system facilitates one or more processes for transferring the enrollment from an enrolled client device to a non-enrolled client device that limit the number and complexity of actions performed by the user.

Abstract: A multitenant infrastructure server (MTIS) is configured to provide an environment to execute a computer routine of an arbitrary application. The MTIS receives a request from a webtask server to execute the computer routine in a webtask container. The computer routine is executed in the webtask container at the MTIS. Upon successful execution of the computer routine, a result set is returned to the webtask server. If the execution of the computer routine is unsuccessful, an error notification is returned to the webtask server. The resources consumed during the execution of the computer routine are determined. The webtask container is destroyed to prevent persistent storage of the computer routine on the MTIS.

Abstract: A process running on client devices intercepts requests destined for an identity provider (“IdP”) system and injects a digital signature corresponding to a user associated with the request. In order to reduce or eliminate the burden on providers of the applications or other resources used by the users, the organization providing the IdP system may also provide components that run locally on the client devices of users and integrate with the users' applications. For example, in one embodiment code of the IdP system is run within a container of an application to handle communication with the IdP system. Additionally, code of the IdP system is run as a local process that handles request interception and digital signature injection. For client devices not supporting the use of the local process, a separate verifier application of the IdP can be run locally and allow interactively performing authentication via a user interface.

Abstract: A system stores resources such as text articles, videos, and so forth for an organization. During operation, the system receives a query and provides a response. During initial use of the system, there is little or no historical data available to help determine which resource is most relevant to a particular query. In this “cold-start” situation, the system determines attributes associated with a user account of the user making the query. The query is used to search a data store and retrieve a set of resources based on a term match with the query and to find the resources which correspond to the attributes of the user account. This allows the system to provide simplified output that is more likely to be relevant to that particular user in the “cold-start” situation.

Abstract: An identity provider (“IdP”) system maintains a framework of authentication methods and security targets that enables flexible authentication policy authoring and analysis of authentication performed by users of an organization. The IdP system generates authentication method profiles that include authentication factors and attributes, which may be further classified as required or optional. The IdP system also generates security target profiles that indicate security requirements needed to satisfy the corresponding security targets. The IdP system uses the generated profiles to determine relationships between authentication methods and security targets (e.g., a list of authentication methods that satisfy a given security target). Using these relationships, the IdP system may enable users to author policies and analyze how users' authentication behaviors comply with security targets.

Abstract: Systems for processing queries may first determine correspondence between the parameters of the query and a set of existing data entries, a set of previous queries that have been received, or both the existing data entries and the previous queries. If the query parameters do not correspond to the data entries or pervious queries, correspondence is determined between the query parameters and group data that associates at least a subset the query parameters with a particular group that may generate a response to the query. The same group or the generated response may be used when similar queries are received. If the group transmits the query to a different group or if negative user feedback is received, the group data may be modified to indicate the different group or to remove the association with the initial group that received the query.

Abstract: An authentication system determines a risk level for a client device impersonating a client device enrolled in authentication services by comparing device metadata for the impersonating client device to device metadata for the enrolled client device. As part of enrolling the enrolled client device, the authentication system associates one or more authentication credentials with the enrolled client device. In order to authenticate access requests associated with a client device identified as the enrolled client device, the authentication system obtains an authentication token from the client device generated using the authentication credentials and also obtains device metadata corresponding to the client device. Based on the device metadata comparison during authentication, the authentication system detects device metadata anomalies and uses detected device metadata anomalies to determine a risk level for the client device.

Abstract: An authentication system facilitates efficient generation of authentication integrations with third-party identity providers for client systems. The authentication system provides one or more interfaces configured to receive requests to make authentication integrations available for a third-party identity provider. The requests to make authentication integrations available include integration information for the relevant identity provider. Based on the request to make authentication integrations available, the authentication system generates an identity provider profile for the identity provider that can be used to generate authentication integrations with the identity provider for one or more client systems. Once the identity provider profile is generated, the authentication system uses the identity provider profile to generate authentication integrations for one or more client systems that request authentication through the third-party identity provider.

Abstract: A risk management system deploys an anomaly detection method for a target data instance without explicitly storing data processing architectures in memory. The anomaly detection method determines whether the target data instance is an anomaly with respect to a reference set of data instances. In one embodiment, the anomaly detection method mimics traversal through one or more trees in an isolation forest without explicitly constructing or storing the trees of the isolation forest in memory. This allows the risk management system to avoid unnecessary storage and retrieval of parts of each tree that would not be traversed if the tree were constructed. Moreover, the anomaly detection method allows anomaly detection to be efficiently performed within memory-constrained systems.

Abstract: Users of organizations use many different third-party applications. The organizations use the services of a server to manage and interact with the third-party applications. In particular, the server provides a user lifecycle API that defines a set of user lifecycle events corresponding to changes of the users with respect to their organizations and/or the third-party applications that they use within the organizations. The server further has access to lifecycle code modules corresponding to the different third-party applications and defining how those third-party applications will respond to the user lifecycle events. When a user lifecycle event occurs for a particular user of a particular organization, the server determines the third-party applications to which the organization has given the user access uses the appropriate functionality of the lifecycle code modules of the corresponding third-party applications to implement the appropriate user changes for those applications.

Abstract: In response to detected attempts to gain unauthorized access to user accounts of an online system, a security module of an online system applies an attack response policy to take actions in response to the attempts. Possible responses of the policy include reordering credential types requested by the online system during multi-factor authentication-enabled login, switching to a mode in which login requests are accepted but login is not permitted for the requesting user, and logging information about the login requests. Logged information may be applied to enhance the ability to prevent future unauthorized accesses, such as adding credential values to a list of common credential values and prohibiting users from associating those values with their accounts, or training a model based on the logged information to predict a probability that a given login request is unauthorized.

Abstract: A verification server provides certificate verification services to users of third-party application sites. In some embodiments, a verifier component of a user's client device provides the verification server with a certificate of a third-party application site, and the verification server indicates whether the certificate is successfully verified. In response to successful verification, the verifier component of the user's client device takes an action such as permitting the user's credentials to be provided to the third-party application site. In some embodiments, verifier components of numerous client devices provide certificates to the verification server, based on which the verification server learns which certificates are valid for a given third-party application site.

Abstract: An identity management system detects the occurrence of a trigger event, such as a time period expiration, or an action on the identity management system. The identity management system accordingly generates a new password for an account of a user on a third-party service and causes the account of the user on the third-party service to use the new password. The identity management system can also detect a manual user change of a password for a third-party service and cause configuration of client devices of the user to reflect the new password.

Abstract: An identity management system prevents users' credential information from being harvested by phishing attackers. The identity management system can installed as a plug in on users' devices. Destinations that solicit users' credential information are verified. For example, web addresses or registered names of websites that receive users' credential information can be verified against known web addresses or registered names to verify their authenticity. When verification of the authenticity of a destination fails, a user is alerted and submission of credential information needs to be confirmed.

Abstract: After an initial user sign-on with an identity provider, and in response to an intention of the user to use a third-party application executing on a client device of the user and requiring user sign-on, the identity provider provides a client script to the third-party application. The client script facilitates user and application authentication and invokes a trusted broker application that interacts with the identity provider to enable the user to use the third-party application. The use of the trusted broker application provided by the identity provider frees the authors of third-party applications from the need to modify their applications to explicitly sign in with the identify provider. For enhanced security, conformance to an organizational security policy is verified at time of sign-on, and an authenticatable link is used to invoke the third-party application to foil attempts by malicious software to substitute another application.

Abstract: Users of organizations use many different third-party applications. The organizations use the services of a server to manage and interact with the third-party applications. In particular, the server provides a remote login service that interacts with auto-login components executing within the domains of the organizations. The auto-login components intercept (e.g., at networking devices of the organization) the requests to login to, or otherwise use, the third-party applications, and sends them to the remote login service. The remote login service handles transparent login of the users to the third-party applications, capturing resulting URLs and session cookies of the third-party applications and providing them to the user browsers so that the user is automatically provided with access to the applications without requiring manual login interactions.

Abstract: An identity management system detects the occurrence of a trigger event, such as a time period expiration, or an action on the identity management system. The identity management system accordingly generates a new password for an account of a user on a third-party service and causes the account of the user on the third-party service to use the new password. The identity management system can also detect a manual user change of a password for a third-party service and cause configuration of client devices of the user to reflect the new password.

Abstract: An identity management system provides single sign-on (SSO) services to clients, logging the clients into a variety of third-party services for which the clients have accounts. An SSO integration is stored for each of the third-party services, the SSO integration including information that allows the identity management system to automate the login for the corresponding third-party service, such as locations of the login pages, and/or identities of username and password fields. The identity management system uses different techniques in different embodiments to detect that a given SSO integration is broken (i.e., no longer permits login for its corresponding third-party service) and/or to repair the SSO integration.

Abstract: An identity management system detects the occurrence of a trigger event, such as a time period expiration, or an action on the identity management system. The identity management system accordingly generates a new password for an account of a user on a third-party service and causes the account of the user on the third-party service to use the new password. The identity management system can also detect a manual user change of a password for a third-party service and cause configuration of client devices of the user to reflect the new password.