AUTHENTICATION

SCWS supports two authentication configurations:
  • Users authenticated by the SDK service using IIS ASP.NET impersonation and delegation
  • User authentication handled by IIS, the application pool account is then used to authenticate with the SDK service

The features of these methods are described below:

ASP.NET IMPERSONATION AND DELEGATION

IIS runs the server side code under the security context of the calling user. This means that the calling user must have been granted rights in Operations Manager to perform the action that is being executed.
Key points to consider:
  • Actions are audited in Operations Manager using the correct calling user identity
  • Users retain any customised or restricted access to Operations Manager
  • Kerberos constrained delegation (KCD) may be used to delegate access when SCWS is installed on a different server to the RMS (using basic and Kerberos authentication)
  • Anonymous requests are not supported

APPLICATION POOL IDENTITY

IIS runs all server code under the specified application pool identity. Access to SCWS may be controlled by IIS using NTFS file permissions.
Key points to consider:
  • All audit logs on the RMS will show the application pool identity performing all of the SCWS actions
  • Granular delegation of rights is not possible, all users will receive the same rights as those granted to the application pool account
  • All IIS authentication methods are supported (including anonymous)

TRANSPORT LAYER SECURITY (SECURE SOCKETS LAYER)

Since SCWS uses HTTP, it is possible to encrypt the transport layer using the TLS (or SSL) protocol. Refer to IIS documentation for instructions on how to accomplish this.

LOCATION OF WEB SERVICE

It is recommended that the web service be installed on a server in the same Active Directory domain as the Operations Manager RMS. This guarantees that the full range of authentication schemes will be available.



Last edited Jan 31, 2011 at 9:30 PM by matthewwhite, version 2

Comments

No comments yet.