Using an Access Controlled Resource

Access control is an optional service on the SENSEI test platform. Each public interface in the system can be access controlled or not, at the owner's discretion. Two basic components are required to enable access control:

• An identity provider, which in the SENSEI architecture is a Security Token Service
• An access control decision making function, which in the SENSEI architecture is a AAA block

Table of Contents

1. Using an Access Controlled Resource
2. Acquiring an identity
3. Authenticating to a REP

Acquiring an identity

All users of an access controlled interface need an identity with the system. This identity is acquired by setting up an account with a Security Token Service (STS). This identity will be recognised by all entities in the security domain of:

• The issuing STS
• Any STS which has a federation relationship with the issuing STS

Authenticating to a REP

Authentication to a REP is done by presenting a security token to the REP. This token is provided by the user's home STS, and may need translating at the REP's STS if the two are different (i.e. a user is trying to authenticate to a REP in a different security domain).

If the client is a standard web browser (or an application embedding a full web browser capability), acquiring a token and providing it to the REP is handled entirely transparently to the user.

• The sensor / actuator service request is sent to the REP
• The REP requests a redirect to the STS
• The STS requires the user to log in (first time only)
• The STS provides a token to the REP via a redirect from the client browser

The REP stores the token so future service calls (bound to the SSL session).

Clients that cannot process redirects or choose to proactively acquire and provide tokens for efficiency can embed tokens in their initial service request.