Resource User AAA Guide

AAA overview

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 service

Table of Contents

  1. AAA overview
  2. Acquiring an identity
  3. Authenticating to a Service Provider

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 must be done by the STS provider (instructions here in the "User administration" section). TRT has deployed an STS on the PETP, and can provide accounts. Other parties may deploy and manage their own STS (see the SENSEI system provider cookbook). 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 Service Provider

Authentication to a service provider (e.g. a REP, a Resource Directory, etc) is done by presenting a security token to the service provider. This token is supplied by the user's home STS, and may need translating at the service's STS if the two are different (e.g. 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 service provider is handled entirely transparently to the user. The user simply invokes the service interface with no special precautions, and the AAA infrastructure will handle the security steps in the background. The only explicit user input to the process will be signing in to its STS (the sign-in form will appear automatically in the browser through a redirect). This sign-in is required only once per user session.

Clients that cannot process redirects or choose to proactively acquire and provide tokens for efficiency can embed tokens in their initial service request. This is an advanced use of the AAA framework and is a developer's concern. A detailed specification for this can be provided to developers upon request.

Last modified 12 years ago Last modified on Nov 3, 2010, 4:59:19 PM