3.2.5.2 Authentication with User Information Within a Single Organization

  • Article

The following procedure shows the authentication that takes place when a client makes a call to a server in the same organization using these extensions. The client also sends user information to the server, and the server uses the information to determine whether to return the requested resource.

  1. The organization's IT administrator sets up an STS and configures it with the security principal identifiers for the client and server. The client and server each exchange public keys, carried in X.509 certificates, with the STS. The administrator also configures the client and server to trust security tokens issued by the STS.

  2. The client makes an anonymous request to the server.

  3. The server responds with an HTTP 401 challenge, as specified in [RFC2616] and [RFC2617].

  4. The client requests a security token from the STS. It does this by sending a self-issued security token that is signed with its private key. The security token contains the aud, iss, nameid, trustedfordelegation, nbf, and exp claims, as specified in section 2.2. The client request also includes a resource parameter and a realm parameter, as specified in [MS-OAUTH2EX]. The value of the resource parameter is the URI of the server. For an example of a self-issued security token, see section 4.2.

  5. The STS validates the public key of the security token provided by the client, verifies that the client is authorized to access the requested resource, and responds to the client with a server-to-server security token that is signed with a public key that the server trusts. The security token contains the aud, iss, nameid, nbf, and exp claims. For an example of a server-to-server security token issued by an STS that contains user information, see section 4.3.

  6. The client sends a self-issued security token to the server that includes the server-to-server security token it received from the STS, as well as additional claims that contain the user information. The additional claims are the aud, iss, nameid, nbf, exp, smtp, sip, msexchuid, and actort claims, as specified in section 2.2. The actort claim contains the server-to-server security token provided by the STS. Note that the server-to-server security token is signed, but the user information is not. For an example of a self-issued server-to-server security token that contains user information, see section 4.4.

  7. The server validates the request by checking the user information contained in the aud, iss, and exp claims and the public key used to sign the security token provided by the STS. Because the user information is not signed, the server validates the user information by checking that the values of the aud and iss claims in the user information match the values of the aud and iss claims in the server-to-server security token contained in the actort claim. For security considerations regarding the unsigned user information, see section 5.1.

  8. The server performs additional validation checks to ensure that the client is authorized to access the requested resource. It then responds to the client with the requested resource.