Other concepts

Authentication concepts

In a Nevis single sign-on environment, user authentication is managed by nevisProxy/nevisAuth. The application delegates the actual authentication process to these services. Regardless of this delegation, all application servers that can be reached through the nevisProxy have to trust the proxy to forward only authenticated requests. Because an application server no longer authenticates the user directly, it must at least be able to extract the user's identity from a request.

Components

• nevisProxy: nevisProxy is the secure reverse proxy acting as a central upstream entry point for all web traffic. nevisProxy controls user access by using an IdentityCreationFilter enforcing user authentication and an optional SecurityRoleFilter enforcing access control. A DelegationFilter may be used to propagate the user identity to the application.
• nevisAuth: nevisAuth implements strong user authentication. It offers secure execution of multi-step authentication and is able to dynamically adjust authentication strengths.
• nevisLogRend The login renderer is used to provide a web frontend to the end user.
• Application: Applications no longer authenticate the user (verification of the user's credentials), but delegate this to nevisProxy/nevisAuth.

Initial authentication

For nevisProxy to grant access to protected resources, a caller needs to be identified for each request on the reverse proxy. nevisProxy uses an authentication subsystem to perform the initial identification of the user. nevisProxy then binds the authentication context to the channel the user is using to be able to automatically match any subsequent requests.

Single Sign-on

To avoid being forced to authenticate for other protected resources, the user is automatically granted access to resources residing in the same SSO domain that do not require any additional security attributes (SSO domains are also known as realms).

Stepup authentication

If a user was authenticated with a weak mechanism (e.g., by using user ID/password credentials), access to a sensitive resource may require an additional security credential (e.g. a one-time password or a challenge and response mechanism). The authentication subsystem is invoked to perform this authentication upgrade (stepup). The nevisProxy reverse proxy detects these requirements by enforcing an authorization model based on security roles. These security roles are essentially (usually coarse) grained access rights that are granted by a more powerful authentication subsystem, which may also provide authorization services.

Identity propagation

For content providers to be able to identify the sender of a request without any further authentication, nevisProxy has to propagate the user's identity (along with other information like authentication strength). Nevis, by default, uses a secure identity passing mechanism consisting of a signed security token (called Nevis SecToken), which is piggybacked on the transport protocol to the content provider. The receiver is able to verify proper authentication and deny access to clients that try to bypass nevisProxy. The SecToken is obtained from the authentication subsystem as a result of the authentication. For further information about the Nevis authentication and authorization services as well as technical details about the Nevis SecToken, see the nevisAuth documentation.

Reverse proxying

Interception

nevisProxy is designed to act as a transparent reverse proxy with authentication capabilities. Authentication is performed as an interception of the first request to a protected resource, branching the request flow to the authentication subsystem and the login application. As soon as the authentication is completed, the original request is propagated to the content provider. The mechanism is designed to work transparently for single-step authentications (e.g. web service clients or X509 client authentication) and multi-step authentications (i.e., procedures with user interaction) as well as for browser clients where a POST request needs to be intercepted.

For security reasons, the transparency may be reduced by plugging cookie caches that filter out application-specific (session) cookies of replies and read them to later requests.

Proxy awareness

Content providers sometimes emit HTML with URLs pointing to the application that is not proxy aware. If the reverse proxy does not consider this content, the client browser may:

• try to directly connect to the content provider host (if the URL contains a host and/or port information)
• try to use an invalid protocol (e.g. because the reverse proxy is using HTTPS, and the content provider does not)
• or address a resource on the reverse proxy that cannot be mapped to the content provider the URL came from (e.g. because the application resides on /some/location on the application server and on /other/location on the reverse proxy)

This problem can either be resolved by correctly implementing the content provider to use relative resource addressing and to be able to reallocate its location in the application server's URL namespace. nevisProxy supports content rewriting for HTML, which resolves this problem in cases where the content provider cannot be adapted nevisProxy 3.13.7.0 requires additional CPU resources to parse the HTML content..

Content control

Additional (custom) content control modules may be plugged anywhere in the content stream, e.g., providing security checks on links inside sensitive applications, which are pointing to foreign content or securing Java Scripts.

Cookie Manager

nevisProxy can manage the cookies sent by a content provider. They will not be sent to the client, but are stored and sent to the content provider if the same user accesses it again.

Web application firewall

nevisProxy can protect web applications from hacker attacks through the use of specialized filters. Using the filter concept allows for fine-grained protection of the URI namespace - different parts of an application may require different levels of protection. This allows to protect sensitive areas such as forms with the maximum possible security, and still achieve high performance in areas that are less critical (e.g., static content, images, style sheets, ...).

HTTP protocol validation

nevisProxy supports various HTTP protocol validation features. HTTP requests and responses are parsed, internalized and completely rebuilt during processing. This ensures that HTTP protocol violations are recognized and that appropriate action can be taken regarding the display of information and error messages.

HTTP protocol limitations

In addition to HTTP protocol validation, several limitations can be configured. Some limitations such as max request size can be configured globally "). Others have to be configured per location by using a ModsecurityFilter with the corresponding limiting rules.

Input validation/filtering

User input such as form fields or URLs can be validated by configuring a ModsecurityFilter. The most actual rules can be downloaded from http://www.modsecurity.org/rules.html. You find more information about the ModsecurityFilter in the chapter ModsecurityFilter.

URL signatures

URLs can be signed by configuring an UrlEncryptionFilter ). Signing of URLs prevents cross-site request forgery (CSRF) attacks because attackers cannot present a link with a valid signature to a victim. Also, forceful browsing can be prevented using such URL signatures.

For cases that cannot be covered by the above mentioned filtersModsecurityFilterorUrlEncryptionFilter, it is usually possible to cover the case with theLuaFilter. For more information about theLuaFilter, seeLuaFilter.

Form signatures

HTML forms can be signed by configuring an EncryptionFilter ). This can prevent attacks that inject or remove form fields or modify the values of hidden fields. As with URL signing, the attacker cannot present a valid form to a victim.

Output rewriting

Response content can be rewritten using a RewriteFilter ). This allows to detect and overwrite malicious/unwanted content in responses (like credit card numbers or exception stacks).

Generic error pages

Error pages that are sent from a backend system can be mapped to generic error pages using an ErrorFilter ). This prevents leakage of information about backend applications.

Secure session handling

The current version of nevisProxy provides secure session handling by using client identifications based on a secure random cookie or the TLS session. The session bindings are renegotiated periodically. Backend cookies are stored internally in the HttpConnectorServlet ) and not forwarded to the client.

Some of the WAF features " about using those and other security features to protect your applications.

Failsafeness and load balancing

Failsafeness relates to a situation with no session state or no ability to address stateful resources from any node in the distributed environment. Load balancing adds the ability to distribute stateless requests or sessions (i.e. subsequent requests) to multiple application instances. A failsafe nevisProxy setup (assuming that the stateful authentication pattern is the rule and caches are local) therefore consists of:

• A load balancer that performs sticky routing to a reverse proxy instance (based on the clients IP address ranges when using HTTPS, or based on the client IP or HTTP headers i.e. cookies, when using HTTP).
• A redundant setup of reverse proxy hosts.
• Failsafe connectors to nevisAuth and content providers.

The following image provides an overview of this setup:

Frontend load balancing

Load balancing in front of the reverse proxy is provided by the mechanisms of the load balancer. If the load balancer performs a failover from one reverse proxy instance to another, the user loses the session context and is prompted to authenticate again. Depending on the security level of the installation and the behavior of the authentication service, the user session may be recovered by implementing one of the following scenariosThese failover scenarios are not part of the standard Nevis distribution:

• Secure single-session recovery: The authentication service performs a full authentication of the user, but associates the user's existing session with the new login. The user therefore is able to access the existing content provider sessions.
• Handover recovery: As a result of the initial authentication, a secure cookie is generated by nevisAuth providing a key to the global session. This cookie is sent to the client. On failover, nevisAuth detects this cookie and (optionally) performs a minimal authentication (e.g. requesting a password similar to a screen saver unlock). The existing session then is associated with the new channel.

The handover recovery may also be performed by only using the mentioned cookie. In this case, no other client information is required and the user is only technically identified (this pattern is used with SUN's liberty approach.

When using cookie caching in the reverse proxy, these application cookies have to be propagated to the global nevisAuth session to be able to achieve a complete session recovery (including the content provider sessions). This content provider cookie handover is not supported in the current release, which means that the above recovery patterns and failover (by the load-balancer) are contradictory, i.e., using the security feature 'cookie caching' and providing an authentication recovery are not working when using multiple reverse proxies with a load balancing setup. The 'cookie caching' security feature is not required, when using an association check (between global Nevis session and local session cookie) in the content provider.Backend load balancing To distribute load in the backend system, connectors for details). Advanced load balancing policies are pluggable by providing a customized connector, which routes the traffic to the content provider by considering response times, error ratio, or specific content.

Vertical scaling

The other failsafeness pattern consists in using an active/standby setup, e.g. using a Nevis failover cluster as described within the nevisAdmin reference guide chapter "Failover Cluster", where only one instance of the reverse proxy is running on a larger machine. Scaling is done by adding memory and CPU to this machine, allowing it to serve more parallel requests by providing more processes or threads.