Securing SAS BI Web Services for Java

SAS Authentication

The default security configuration for SAS BI Web Services for Java is SAS authentication. In this mode the Web application server does not perform any authentication on behalf of the application. Instead, SAS BI Web Services for Java authenticates client credentials against the configured SAS Metadata Server. Client credentials are obtained by one of the following ways (in this order):
  1. Use credentials that are passed in the UsernameToken WS-Security SOAP header. For RESTful invocation, use the credentials passed in the Authorization HTTP header.
  2. Use credentials that are passed in the payload as properties (XMLA only).
  3. Use anonymous credentials that are configured with the Webanon SAS metadata login account (XMLA and generated Web services).
Typically, the WebServiceMaker service is invoked via the Deploy As Web Service wizard in SAS Management Console. Therefore, this service must be able to process SAS one-time passwords. For this reason the WebServiceMaker service functions only in SAS authentication mode.

Web Authentication

As an alternative to SAS authentication, the application server can be configured to perform the authentication on behalf of the SAS BI Web Services for Java application. This is known as Web authentication. Beginning with SAS 9.3, Web authentication can also be used with RESTful Web services.

Editing the web.xml File for Third-Party Authentication

If you configure third-party authentication with products such as CA SiteMinder, and use the JavaScript Objects Notation (JSON) and REST Web services, edit the web.xml file. This file is located in the SAS-Installation-Directory \SASWebInfrastructurePlatform\9.3\Configurable\wars\sas.wip.services9.3ear\sas.biws.war\WEB-INF directory. Remove or comment out the following configuration section in the web.xml file (within the SAS BI Web Services WAR file):
<filter>
     <filter-name>SecurityFilter</filter-name>
     <filter-class>org.springframework.web.filter.DelegatingFilterProxy
     </filter-class>
     <init-param>
          <param-name>targetBeanName</param-name>
          <param-value>basicAuthFilter</param-value>
     </init-param>
     <init-param>
          <param-name>targetFilterLifecycle</param-name>
          <param-value>true</param-value>
     </init-param>
</filter>
<filter-mapping>
          <filter-name>SecurityFilter</filter-name>
          <url-pattern>/rest/*</url-pattern>
</filter-mapping>
<filter-mapping>
          <filter-name>SecurityFilter</filter-name>
          <url-pattern>/json/*</url-pattern>
</filter-mapping> 

Transport-level Security

HTTP transport-level security can be used instead of message-level security. The following security constraints should be applied to the web.xml deployment descriptor (sas.biws.war module with the sas.wip.services9.3.ear application) as follows:
<security-constraint>
   <web-resource-collection>
      <web-resource-name>All-resources</web-resource-name>
      <url-pattern>/services/XMLA/*</url-pattern>
      <url-pattern>/services/dynamicServicePath/*</url-pattern>
      <http-method>GET</http-method>
      <http-method>POST</http-method>
   </web-resource-collection>

   <auth-constraint>
      <role-name>SASWebUser</role-name>
   </auth-constraint>
</security-constraint>

<login-config>
   <auth-method>BASIC</auth-method>
</login-config>

<security-role>
   <role-name>SASWebUser</role-name>
</security-role>