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.
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.
More Here
Courtesy:http://asher2003.wordpress.com/2011/02/14/accesscontrolservice-architectural-model/
{ 0 comments... read them below or add one }
Post a Comment