88
resulted in ID services in the Cloud, which can be enterprise‐compliant as
soon as the in‐house LDAP, for instance, is used as the ID provider.
40
Whether an enterprise uses a centralised access control service (which
outsources the authentication function or performs it itself) or its own
Cloud‐based or in‐house authentication centre, it will require either one or
the other in order to achieve single sign‐on capability and thus a high degree
of service usability. If the user is authenticated one time per session only,
access control must contain this information and furnish it when prompted
by an application, without the user being prompted to log in again (either as
a user token or suitable prompting interface, which the application itself will
still need to implement).
Federation
Today, Cloud services come complete with their own authentication and
authorisation systems. Secure access to services has become something that
everyone expects of their Cloud providers. Yet apart from single sign‐on, the
transparent use of an enterprise's own employee data still has a long way to
go. The magic words in this case are “directory services federation”.
As federation generally requires open access (at least for outgoing
connections) to its directory, an enterprise needs to have a lot of trust in the
Cloud provider.
This access can, however, be limited to dedicated, special‐purpose
connections by setting up a proper service for secure access control; this will
generally reduce the chances of the user data being compromised. Only
time will tell which will win in the end: convenient reuse of carefully
managed enterprise data or 'safety first' at the expense of easier access for
users of enterprise Cloud services.
40
Cf. Microsoft Windows Azure Access Control Service:
‐
us/library/hh446535.aspx
