The Access Control Service is an easily configurable, cloud-based Security Token Service (STS) that supports the authentication of user name/password, Windows CardSpace, certificate, and third-party STS-issued SAML tokens and provides an authorization framework that uses flexible, claims-based rules. The Access Control Service uses the same basic architectural model for Web applications, Web services, and smart clients. In the basic scenario, there are three participants:
- The Access Control Service STS.
- An application that trusts the virtual Access Control Service STS (Relying Party).
- The application that uses the Relying Party (Requester).
These participants interact with one another in the following manner, discussed in more detail in this section:
- A trust relationship is established between the relying party and the Access Control Service STS. The owner of the relying party provides the Access Control Service STS with its certificate. This certificate is used by the Access Control Service STS to encrypt tokens that the relying party will accept.
- Before the requester can use the relying party, the owner of the relying party application defines access control rules in the STS. These rules logically grant the requester access to the relying party.
- The requester sends a WS-Trust 1.3-compliant Request for Security Token (RST) to the Access Control STS.
- The Access Control STS receives the RST, and uses the input claims in the RST to initiate processing of the Access Control rules defined in that STS.
- After Access Control rule processing, the Access Control STS packages the output into a SAML security token, signs the token, encrypts that token with the certificate provided in step 1, and sends the token back to the Requestor.
- Upon receipt of the token, the requester sends the token to the relying party along with any other relying party-specific payload.
- When the relying party receives the token, it verifies the claims in the token and decides whether the requester can access the application.
Federated Security Primer
An STS issues tokens asserting claims to a requester that wants access to resources on direction of and for consumption by a relying party that provides access to these resources.
In the Web services realm, token is commonly used as a generic term for a container that holds security information. A token is typically issued for a particular purpose and for a particular receiver. For all other parties involved in a federated security scenario, the tokens are fully or partially opaque entities. The way in which tokens are issued makes it possible to detect whether their contents have been tampered with (they are signed). Additionally, the issuer of the token can encrypt them so that only a particular party can access the token contents.
A claim is a statement that a participant in a security relationship makes about itself. A user might claim possession of certain properties, such as being a member of a particular group, being of a certain age, or having a particular e-mail address. With an identity claim, the user claims to be who the other participants believe the user is.
By themselves, claims are unverified statements. To be trustworthy, a claim needs to be verified and corroborated by an authority that all participants in the security relationships trust, which is a role commonly taken on by an STS. Corroborated claims are transferred between the participants in the security relationship inside of tokens.
A credential is an information set that contains a claim about the identity of a service or an individual and also contains some supporting evidence for the truthfulness of that claim. A credential is commonly submitted to a security service for purposes of authentication; that is, for a security service to verify and certify that the identity claim is trustworthy.
The most common example for a credential is a user name/password pair. The user name is a claim made about the identity of the party seeking authentication. The password is the supporting evidence that the authenticating service uses to verify that identity. It is assumed that only the party seeking authentication knows about the password and therefore, presentation of the correct password (or some value derived from the password based on an agreed-upon algorithm) is sufficient evidence to prove the identity. Examples of other forms of credentials are digital signatures that prove possession of a particular certificate, or tokens issued by third-party security services.
A relying party (or relying service) provides access to resources or capabilities that are secured and for which access is granted only to authorized requestors. The service therefore relies on an STS to validate the credentials of the requestor and directs the requestor through its policy to obtain an assertion (carried in a token) for a particular set of claims from the STS that the relying service might then use for further authorization.
In federated scenarios, STSs collaborate by trading tokens for other tokens if and only if the collaborating STS have a mutual trust relationship that allows them to believe assertions made by the respective other STS. More precisely, an STS will look at and validate claims asserted by some other STS and will, upon successful validation, either reaffirm those claims to its relying parties and/or assert additional or even different claims in the token it issues.
Access Control Service Basics
The Access Control Service is a hosted security token service infrastructure that authenticates credentials and issues tokens. Each .NET Services solution has a private, isolated STS at its disposal.
The Access Control service supports a SOAP-based WS-Trust protocol that accepts four different types of credentials: User name/Password, Windows CardSpace, Certificate, and third-party STS-issued SAML Token. In addition, the Access Control Service also supports two HTTP-based mechanisms:
- A simple REST HTTP protocol for programmatic access.
- A passive requestor mode (which will be WS-Federation-compliant in an upcoming release) through which interactive users are presented with a choice of supplying Windows CardSpace or user name/password credentials when accessing a relayed HTTP service using a browser.
For all protocols, the authentication of credentials is based on a validation of supplied credentials against the .NET Services store that holds validation information for Windows CardSpace or user name/password credentials for each .NET Services Solution account. Somewhat special are third-party STS-issued token credentials that are associated with an account through a trust relationship with the respective STS.
Upon successful authentication of credentials, the Access Control Service can issue a token that either asserts the immediate claims made by the requestor or issues a set of asserted claims otherwise associated with the requestor. Whether the Access Control Service issues a token is, however, subject to rules configured on the Access Control Service by the account holder. In other words, even though a credential might be successfully authenticated, the Access Control Service does not issue a token if the service does not have a rule that explicitly permits the token to be issued.
The Access Control Service rule language consists of claim mappings. A claim mapping maps an authenticated claim (from a user's credentials or a third-party-issued token) to a claim or a set of claims that the relying party wants the STS to include in the token.
Did you find this information useful? Please send your suggestions and comments about the documentation.