Abstract: Methods and systems are described which obtain a service token at an edge device. Embodiments obtain a device certificate from an authentication service based on a private key which is associated with a public key. The public key is further associated with a device identifier for the edge device at a directory service. Embodiments send a request for a service token to an authentication service from a directory service based on the private key where the directory service has identified the public key for the edge device. Other embodiments extract the device identifier from the device certificate and send a request for a service token to the directory service, where the request includes the device certificate and the device identifier. Embodiments receive the service token from the directory service and use the service token to access a service.

Abstract: According to examples, an apparatus may include a processor that may determine that an application was accessed through a portal. Based on a determination that the application was accessed through the portal, the processor may determine whether a first credential type or a second credential type was supplied to access the application, in which the first credential type may include a set of personal credentials of a user and the second credential type may include a set of single sign-on credentials that the user may use to access multiple applications. The processor may also output a trace that may indicate an identification of the application that was accessed and the type of the credential supplied to access the application, in which a backed entity may analyze the data included in the trace.

Abstract: According to examples, an apparatus may include a processor that may determine that an application was accessed through a portal. Based on a determination that the application was accessed through the portal, the processor may determine whether a first credential type or a second credential type was supplied to access the application, in which the first credential type may include a set of personal credentials of a user and the second credential type may include a set of single sign-on credentials that the user may use to access multiple applications. The processor may also output a trace that may indicate an identification of the application that was accessed and the type of the credential supplied to access the application, in which a backed entity may analyze the data included in the trace.

Abstract: A public-private key cryptographic scheme is described for granting authenticating a client to a remote device or service in order to access a secure resource. The client is provided the public key, but the private key is stored in a hardware security module (HSM) that the client is not able to access. The client requests a digital signature be generated from the private key from a secure vault service. The secure vault service accesses the HSM and generates the digital certificate, which is then passed to the client. The digital certificate may be added to a security token request submitted to an identity provider. The identity provider determines whether the digital signature came from the private key.

Abstract: According to examples, an apparatus may include a processor that may determine that an application was accessed through a portal. Based on a determination that the application was accessed through the portal, the processor may determine whether a first credential type or a second credential type was supplied to access the application, in which the first credential type may include a set of personal credentials of a user and the second credential type may include a set of single sign-on credentials that the user may use to access multiple applications. The processor may also output a trace that may indicate an identification of the application that was accessed and the type of the credential supplied to access the application, in which a backed entity may analyze the data included in the trace.

Abstract: A public-private key cryptographic scheme is described for granting authenticating a client to a remote device or service in order to access a secure resource. The client is provided the public key, but the private key is stored in a hardware security module (HSM) that the client is not able to access. The client requests a digital signature be generated from the private key from a secure vault service. The secure vault service accesses the HSM and generates the digital certificate, which is then passed to the client. The digital certificate may be added to a security token request submitted to an identity provider. The identity provider determines whether the digital signature came from the private key.

Abstract: According to examples, an apparatus may include a processor that may determine that an application was accessed through a portal. Based on a determination that the application was accessed through the portal, the processor may determine whether a first credential type or a second credential type was supplied to access the application, in which the first credential type may include a set of personal credentials of a user and the second credential type may include a set of single sign-on credentials that the user may use to access multiple applications. The processor may also output a trace that may indicate an identification of the application that was accessed and the type of the credential supplied to access the application, in which a backed entity may analyze the data included in the trace.

Abstract: A public-private key cryptographic scheme is described for granting authenticating a client to a remote device or service in order to access a secure resource. The client is provided the public key, but the private key is stored in a hardware security module (HSM) that the client is not able to access. The client requests a digital signature be generated from the private key from a secure vault service. The secure vault service accesses the HSM and generates the digital certificate, which is then passed to the client. The digital certificate may be added to a security token request submitted to an identity provider. The identity provider determines whether the digital signature came from the private key. If so, the identity provider provides authenticates the client and provides an access token that is usable by the client for authentication to the remote device with the secure resource.

Abstract: A public-private key cryptographic scheme is described for granting authenticating a client to a remote device or service in order to access a secure resource. The client is provided the public key, but the private key is stored in a hardware security module (HSM) that the client is not able to access. The client requests a digital signature be generated from the private key from a secure vault service. The secure vault service accesses the HSM and generates the digital certificate, which is then passed to the client. The digital certificate may be added to a security token request submitted to an identity provider. The identity provider determines whether the digital signature came from the private key.

Abstract: Protocol-agnostic configuration of an identity claim policy that is to be implemented in one or more applications according to one of multiple identity authentication protocols and verification of the protocol-agnostic claims configuration. First, one or more protocol-agnostic identity claim policies are generated and applied to one or more applications. Each of the one or more applications implement one of the multiple identity authentication protocols. For each of the one or more applications, the implemented identity authentication policy is determined. Based on the determined identity authentication protocol, one or more identity claims of the corresponding application that corresponds to the at least one identity claim policy is then construed.

Abstract: A secure password-based single sign-on process enables a user to access a web application without the authorization credentials transmitted over a distributed computing network. A network directory service system utilizes an identity management system, outside of the client device, to execute a sign-on to a web-based resource in a Hyper-V container. The browser cookie from the sign-on process is returned to the client device in a sign-on script that the client-side browser uses to transition to the web portal or home page of the target web-based resource.

Abstract: An identity provider, within a directory service, provides an automatic technique for configuring the single sign-on settings of a service provider. The directory service contains pre-configured templates for each service provider supported by the directory service which include the details of the service provider's SSO configuration settings web page. A configuration sign-on script is generated to automatically fill in the configuration settings so that the principal can perform single sign-on with the service provider's preferred authentication and authorization protocol.

Abstract: Protocol-agnostic configuration of an identity claim policy that is to be implemented in one or more applications according to one of multiple identity authentication protocols and verification of the protocol-agnostic claims configuration. First, one or more protocol-agnostic identity claim policies are generated and applied to one or more applications. Each of the one or more applications implement one of the multiple identity authentication protocols. For each of the one or more applications, the implemented identity authentication policy is determined. Based on the determined identity authentication protocol, one or more identity claims of the corresponding application that corresponds to the at least one identity claim policy is then construed.

Abstract: The automatic troubleshooting of failed single sign on attempts via an identity provider to a service provider. When an error message is encountered due to that failed single sign on attempt, that error message is used to automatically identify a root cause of the failure of the single sign on attempt. In some embodiments, a resolution of the failure is also identified, and a tool for the resolution automatically provided to the user. Such failures in single sign on attempts usually are due to improper configuration information being provided to the identity provider. The principles described herein allow a user to test ahead of time whether they have provided proper configuration information to the identity provider, and potentially correct any problems in the single sign on experience in advance, perhaps well in advance of actually needing a resource provided by the service provider.

Abstract: An identity provider, within a directory service, provides an automatic technique for configuring the single sign-on settings of a service provider. The directory service contains pre-configured templates for each service provider supported by the directory service which include the details of the service provider's SSO configuration settings web page. A configuration sign-on script is generated to automatically fill in the configuration settings so that the principal can perform single sign-on with the service provider's preferred authentication and authorization protocol.

Abstract: A secure password-based single sign-on process enables a user to access a web application without the authorization credentials transmitted over a distributed computing network. A network directory service system utilizes an identity management system, outside of the client device, to execute a sign-on to a web-based resource in a Hyper-V container. The browser cookie from the sign-on process is returned to the client device in a sign-on script that the client-side browser uses to transition to the web portal or home page of the target web-based resource.

Abstract: The automatic troubleshooting of failed single sign on attempts via an identity provider to a service provider. When an error message is encountered due to that failed single sign on attempt, that error message is used to automatically identify a root cause of the failure of the single sign on attempt. In some embodiments, a resolution of the failure is also identified, and a tool for the resolution automatically provided to the user. Such failures in single sign on attempts usually are due to improper configuration information being provided to the identity provider. The principles described herein allow a user to test ahead of time whether they have provided proper configuration information to the identity provider, and potentially correct any problems in the single sign on experience in advance, perhaps well in advance of actually needing a resource provided by the service provider.

Abstract: In non-limiting examples of the present disclosure, systems, methods and devices for transmitting data stored in a source data store to a destination data store are presented. A plurality of data chunks may be received in a first format. At least one upsert operation may be performed on each of the data chunks for converting the first format to a format compatible with a destination data store schema. A transfer of the upserted data chunks to the destination data store may be executed. A determination may be made that at least one of the upserted data chunks has failed to transfer to the destination data store. Failed data chunks may be stored in a failed chunk retry data store. The at least one upsert operation may be re-performed on failed data chunks and a re-execution of the transfer of failed data chunks to the destination data store may be made.

Abstract: Monitoring a computer system or framework via a bot integrated into a messaging application is provided herein. A bot is made available as a contact within a messaging application to receive queries on a computer system/framework via messages from users. The bot is communicated with one or more systems or machines in a monitored computing system/framework to execute those queries and return a response to the user via the messaging application or another selected application.

Abstract: In non-limiting examples of the present disclosure, systems, methods and devices for transmitting data stored in a source data store to a destination data store are presented. A plurality of data chunks may be received in a first format. At least one upsert operation may be performed on each of the data chunks for converting the first format to a format compatible with a destination data store schema. A transfer of the upserted data chunks to the destination data store may be executed. A determination may be made that at least one of the upserted data chunks has failed to transfer to the destination data store. Failed data chunks may be stored in a failed chunk retry data store. The at least one upsert operation may be re-performed on failed data chunks and a re-execution of the transfer of failed data chunks to the destination data store may be made.