Information Technology Reference
In-Depth Information
relieves the application from having to implement these aspects of security,
it can be treated as part of the enterprise security framework and is also a
more easily auditable control point. This is illustrated in the following
diagram.
Fig 13: Comprehensive SSO
Note that we need the extra steps 9, 10 and 11 to make this fool-proof. The
interceptor has to perform a further level of validation against the SSO
engine to ensure that the security token is genuine. The SSO server needs to
confirm the authenticity of the token. It may also send back extra user
attributes along with this confirmation. The interceptor uses these attributes
to enforce access control rules (authorisation). And with this, the access
management model is complete.
There are some details that need to be understood about this essentially
simple model. There are two types of security tokens required to make this
system work. The first is related to authentication and the second is an
“application access token” that is loosely related to authorisation. In fact,
because authentication is for the user but access relates to the user and an
application, only one authentication token is generated per user but there
passed in, but authentication and
coarse-grained
authorisation (i.e., “Can
the user access this application at all?”) are done by the SSO server and
interceptor, respectively.
