To put a bit of a finer point on this topic, we should describe the type of solutions that integrate easily with the pre-authenticated SSO provider in Knox.
There are a number of solutions in the enterprise that follow a particular pattern for integration. This pattern requires all traffic to resources that participate in the SSO to be routed through a proxy or gateway to access those services. What this enables is the ability to inject headers into the request as it flows through the network to represent the authenticated user and in some cases the groups associated with that user.
Apache Knox has the ability to flow-in the identity of the end user through the use of these HTTP headers by using the header based pre-authenticated SSO provider. It defaults to header names that are often used for SiteMinder integration - SM_USER and SM_GROUPS. The header names can be overridden to match those used in different environments. Tivoli Access Manager and other solutions follow this same pattern.
The provider can also be configured to only accept requests from specific (or a range) of ip addresses as well as to require mutual authentication with SSL client certificates. These helps to mitigate risk of some other party circumventing the SSO solution and asserting an arbitrary identity for resource access.
It is important to understand that the SSO solution and network security provisions need to ensure that there is no way to circumvent the SSO provider's proxy and go directly to Knox.
