Abstract: A cross-tenant authentication system is described. The system receives a user token from a client device that is registered with a first tenant of a service application of a server. The system receives a request, from the client device, to access a second feature of a second tenant of the service application. The second feature of the second tenant of the service application is separate from a first feature of the first tenant of the service application. The second feature is only accessible to devices registered with the second tenant of the service application. The system authenticates the request by validating the user token from the client device and determines a cross-tenant policy of the second tenant of the service application based on the user token. The system forms an identity object based on the cross-tenant policy.

Abstract: Techniques of service to service authentication in distributed computing systems are disclosed herein. One example technique includes identifying a token type of a security token and an authentication scheme indicated in an access request for authenticating the access request. The example technique also includes using a combination of the identified token type of the security token and the authentication scheme indicated in the access request as a key to locate an authentication pattern in a mapping table and identifying an authentication policy corresponding to the authentication pattern. The example technique can then include applying the identified authentication policy to the received data package to authenticate the access request based on the security token and conditionally providing the client service access to the platform service.

Abstract: An authorization policy defines permissions that are exposed by a microservice. When a call is made to the microservice, it includes an access token. An application identifier uniquely identifying the calling application is extracted from the token. An access pattern, used by the calling application to obtain the access token and make the call to the microservice, is identified. Permissions that may be granted to the calling application are identified in the authorization policy based upon the application identifier and the access pattern that is identified. An authorization decision is made as to whether to authorize the call, based upon the granted permissions.

Abstract: Systems and methods for enabling cross-tenant access are provided. In particular, a computing device may receive an access request, from a user of a first tenant, requesting access to a resource of a plurality of resources on a shared collaborative channel of a second tenant. The computing device may further evaluate cross-tenant access policies of the first and second tenants to determine that access to the plurality of resources is authorized by the first and second tenants, validate that the user is a member of the shared collaborative channel, and generate a validation token indicating the user is validated to access the plurality of resources. Based on the validation token, the computing device may further validate that the user is in compliance with the cross-tenant access policies for accessing the resource and grant the user a set of permissions to access the resource.

Abstract: A routing plane includes an authentication packaging system that receives client authentication information, as part of a request from a requesting client that is to be routed to a target service. The authentication packaging system combines the authentication information with assertion information indicative of an assertion as to the identity of the routing plane, using an entropy, such as a signing key. The authentication package is attached to the request and is sent to the target service. The target service validates the authentication package based on the entropy and authenticates the routing plane based on the assertion information and performs authentication processing based on the authentication information.

Abstract: A routing plane includes an authentication packaging system that receives client authentication information, as part of a request from a requesting client that is to be routed to a target service. The authentication packaging system combines the authentication information with assertion information indicative of an assertion as to the identity of the routing plane, using an entropy, such as a signing key. The authentication package is attached to the request and is sent to the target service. The target service validates the authentication package based on the entropy and authenticates the routing plane based on the assertion information and performs authentication processing based on the authentication information.

Abstract: A routing plane includes an authentication packaging system that receives client authentication information, as part of a request from a requesting client that is to be routed to a target service. The authentication packaging system combines the authentication information with assertion information indicative of an assertion as to the identity of the routing plane, using an entropy, such as a signing key. The authentication package is attached to the request and is sent to the target service. The target service validates the authentication package based on the entropy and authenticates the routing plane based on the assertion information and performs authentication processing based on the authentication information.

Abstract: A routing plane includes an authentication packaging system that receives client authentication information, as part of a request from a requesting client that is to be routed to a target service. The authentication packaging system combines the authentication information with assertion information indicative of an assertion as to the identity of the routing plane, using an entropy, such as a signing key. The authentication package is attached to the request and is sent to the target service. The target service validates the authentication package based on the entropy and authenticates the routing plane based on the assertion information and performs authentication processing based on the authentication information.

Abstract: An authorization policy defines permissions that are exposed by a microservice. When a call is made to the microservice, it includes an access token. An application identifier uniquely identifying the calling application is extracted from the token. An access pattern, used by the calling application to obtain the access token and make the call to the microservice, is identified. Permissions that may be granted to the calling application are identified in the authorization policy based upon the application identifier and the access pattern that is identified. An authorization decision is made as to whether to authorize the call, based upon the granted permissions.

Abstract: Calendar repair may be provided. Calendar events, such as appointments and meetings, may be created and copied to a plurality of attendee calendars. A first copy of the event may be compared to a second copy of the event, and an event property of the second event may be updated to match a corresponding event property of the first event.

Abstract: A computing system controls access between components. A token issuer issues an access token to a requesting component, that is requesting access to a requested service component, based at least in part on an access policy. The requesting component sends the token to the requested service component, which includes a token authentication module that validates the access token and authorizes the requesting component to access a requested service component, and receives the authorization to access the requested service component.

Abstract: Calendar repair may be provided. Calendar events, such as appointments and meetings, may be created and copied to a plurality of attendee calendars. A first copy of the event may be compared to a second copy of the event, and an event property of the second event may be updated to match a corresponding event property of the first event.

Abstract: Calendar repair may be provided. Calendar events, such as appointments and meetings, may be created and copied to a plurality of attendee calendars. A first copy of the event may be compared to a second copy of the event, and an event property of the second event may be updated to match a corresponding event property of the first event.

Abstract: A computing system controls access between components. A token issuer issues an access token to a requesting component, that is requesting access to a requested service component, based at least in part on an access policy. The requesting component sends the token to the requested service component, which includes a token authentication module that validates the access token and authorizes the requesting component to access a requested service component, and receives the authorization to access the requested service component.

Abstract: Calendar repair may be provided. Calendar events, such as appointments and meetings, may be created and copied to a plurality of attendee calendars. A first copy of the event may be compared to a second copy of the event, and an event property of the second event may be updated to match a corresponding event property of the first event.

Abstract: Calendar repair may be provided. Calendar events, such as appointments and meetings, may be created and copied to a plurality of attendee calendars. A first copy of the event may be compared to a second copy of the event, and an event property of the second event may be updated to match a corresponding event property of the first event.

Abstract: A web extension authenticates a user using a token based authentication scheme. A token is retrieved from a client application to authenticate the user. The web extension transmits the token to a server component to have the server component authenticate the user. The server component validates the token using a validation library. The user is mapped to the token and authenticated upon validating the token.

Abstract: Online and on-premise applications identify trusted authentication providers. The applications are configured with a list of trusted issuers of authentication credentials. When an application receives a request requiring authentication, the application returns a 401 response that includes the trusted issuer list. The requesting application compares the trusted issuer list from the 401 response to its own list of authentication providers. If there is a match between the two lists, then the requesting application creates a self-issued token for the authentication provider. The authentication provider uses the self-issued token to generate an authentication token for the requesting application. The requesting application may also directly create a token for a target partner application, without an authentication provider, if there is a direct trust between the two applications.

Abstract: Dynamic time rebasing may be provided. After receiving a request to view a calendar item, a base time associated with the calendar item may be retrieved. A local bias associated with the request to view the calendar item may be identified. The base time may be converted to a local time according to the local bias. The calendar item may then be displayed according to the converted local time.

Abstract: Certificate remoting and recovery may be provided. A computer may identify required security certificates and determine whether at least one required security certificate is not available. If the certificate is not available, the computer may identify a peer server and request the missing certificate from the peer server. The computer may also be operative to receive certificate management instructions from other computers.