Administering SAS BI Web Services

Securing SAS BI Web Services for Java

The default security configuration out-of-the box 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):

Use credentials that are passed in the UsernameToken WS-Security SOAP header.
Use credentials that are passed in the payload as properties (XMLA only).
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

Overview of Web Authentication

Alternatively 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. To configure Web authentication for XMLA Web services and generated Web services, select the Custom prompting level in the SAS Deployment Wizard and choose Web authentication during configuration. By default, when Web authentication is configured, WS-Security constraints are applied to the XMLA Web service as well as to generated Web services. However, transport-level security can be configured instead of message-level security (WS-Security) if desired. The following information describes the manual configuration steps that are necessary to enable Web authentication.

Message-level Security

By default, WS-Security security constraints are automatically configured when Web authentication is configured. In this case, Rampart security is engaged and configured in the services.xml deployment descriptor as follows:

<module ref="rampart"/>
<parameter name="InflowSecurity">
   <action>
      <items>UsernameToken</items>
      <passwordCallbackClass>
        com.sas.web.services.axis2.PwcbHandler
      </passwordCallbackClass>
   </action>
</parameter>

For more information about Axis2/Rampart configuration, see http://ws.apache.org/axis2/.

Currently, the Rampart security module is configured to require a Username Token. The Rampart module parses the Username Token credentials. Ultimately, the implementation consumes these credentials and uses them to programmatically invoke the application server's authentication provider configured for the current security realm, thereby allowing seamless integration into the container's security subsystem. The following list shows how this authentication is accomplished for the different Web containers:

JBoss	Uses the org.jboss.web.tomcat.login.WebAuthentication class to integrate with Java Authentication and Authorization Service (JAAS).
IBM WebSphere	Invokes WSLogin JAAS login configuration. To invoke a different JAAS login configuration, set the JAASLoginConfigName SAS BI Web Services for Java configuration property.
Oracle WebLogic	Uses the weblogic.security.services.Authentication class to integrate with JAAS.

Transport-level Security

HTTP transport-level security can be used instead of message-level security. Any message-level security constraints previously enabled must be disabled in order to use transport-level security. To disable generated Web services from automatically being configured with WS-Security constraints, you should set the AddWSSecurityAuthConstraint WebServiceMaker-specific configuration property to false.

The following security constraints should be applied to the web.xml deployment descriptor (sas.biws.war module with the sas.wip.services9.2.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/generatedWebServiceName/*</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>

The URL patterns in this code should include all of the Web services that should be secured by the HTTP transport. Notice that the WebServiceMaker service is not one of them because it must be configured for SAS authentication. Also, notice that the secured Web services must be invoked by a client that is in the SASWebUser role.

Update the JBoss Application Server Configuration

The name of the security domain is configured in the jboss-web.xml deployment descriptor. You must use this same name when creating a JAAS login configuration for this security domain. If for example the security domain name is SASApplicationLogin, your jboss-web.xml deployment descriptor contains the following:

<jboss-web>
   <security-domain>java:/jaas/SASApplicationLogin</security-domain>
</jboss-web>

The JAAS configuration file located in your server configuration (JBoss_Home/Server/SASServer1/conf/login-config.xml) looks like the following code:

<application-policy name="SASApplicationLogin">
   <authentication>
      <!-- place site-specific login modules here -->
      <login-module
               code="com.sas.services.security.login.TrustedLoginModule"
               flag="optional">
         <module-option name="host">SAS-metadata-serve-host</module-option>
         <module-option name="port">8561</module-option>
         <module-option name="domain">web</module-option>
         <module-option name="aliasdomain">DefaultAuth</module-option>
         <module-option name="trusteduser">sastrust@saspw</module-option>
         <module-option name="trustedpw">encoded-password</module-option>
      </login-module>
   </authentication>
</application>

You should add any site-specific login modules to the configuration. For example, if you want to use the UsersRolesLoginModule JBoss login module to authenticate users against a text file, follow these steps:

Add user names and passwords to the JBOSS_HOME/server/SASServer1/conf/props/sas-users.properties file. Format of this file is as follows: username=password.
Add user names and role to the JBOSS_HOME/server/SASServer1/conf/props/sas-roles.properties file. Format of this file is as follows: username=SASWebUser.

Add the following login module to the SASApplicationLogin JAAS login configuration:

<login-module
         code="org.jboss.security.auth.spi.UsersRolesLoginModule"
         flag="required">
   <module-option name="usersProperties">
         props/sas-users.properties
   </module-option>
   <module-option name="rolesProperties">
         props/sas-roles.properties
   </module-option>
   <module-option name="unauthenticatedIdentity">
         Anonymous
   </module-option>
</login-module>

Update the WebSphere Application Server Configuration

The type of security that is configured determines the JAAS login configuration that is enabled. For example, if message-level security (WS-Security) is configured, then the WSLogin JAAS login configuration (or the JAAS login configuration overridden with the JAASLoginConfigName property) is enabled. Otherwise, if transport-level security is configured, then the WEB_INBOUND JAAS login configuration is enabled.

After you have determined what JAAS login configuration is active for your particular environment, use the administration console to add the SAS trusted login module to that configuration. Follow these steps:

Navigate to Security Security administration, applications, and infrastructure Java Authentication and Authorization Service. Select Application logins or System logins depending on the configuration that you need to modify. Select the JAAS configuration that you need to modify, and then select JAAS login modules.

Click New and enter the following information:

Module class name: com.sas.services.security.login.websphere.WSTrustedLoginModule
Authentication strategy: OPTIONAL

Click OK.

Click the Custom Properties link and enter the following name/value pairs:
```
host: SAS-metadata-server-host 
port: 8561 
domain: web 
aliasdomain: DefaultAuth 
trusteduser: sastrust@saspw 
trustedpw: encoded-password-for-sastrust
```
where encoded-password-for-sastrust is an encoded password that can be obtained from the SAS administrator. For more information about encoding passwords, see SAS Intelligence Platform: Security Administration Guide.

In order for the SAS trusted login module to be loaded successfully by the WebSphere run-time application class loader during authentication, the following SAS JAR files need to be copied from the SAS Versioned Jar Repository to WAS_HOME/lib/ext:

sas.core.jar
sas.oma.omi.jar
sas.svc.connection.jar
sas.svc.sec.login.jar
sas.svc.sec.login.websphere.jar
sas.security.sspi.jar

Lastly, configure the user account repository from which to authenticate against. Using the administration console, follow these steps:

Navigate to Security Secure administration, applications, and infrastructure.
In the User account repository, select from the available realm definitions (such as Local operation system) and configure it and set it as the current realm definition.

Additionally, if transport-level security is configured, then map the SASWebUser role to all authenticated users. Use the administration console to enable this mapping as follows:

Navigate to Enterprise Applications SAS Web Infrastructure Platform Services Security role to user/group mappings.
Select All authenticated for the SASWebUser role.

Update the WebLogic Application Server Configuration

Install and configure the Authentication Provider for your security realm. Follow these steps:

Copy the following SAS JAR files from the SAS Versioned Jar Repository to BEA_HOME/weblogic92/server/lib/mbeantypes. These JAR files enable you to add and configure the SAS trusted login module to the list of authenticated providers for a given security realm.
```
sas.svc.sec.login.weblogic..mbean.jar
sas.svc.sec.login.weblogic.mbean.nls.jar
```
Copy the following SAS JAR files from the SAS Versioned Jar Repository to BEA_HOME/weblogic92/server/lib/mbeantypes. These JAR files need to be available to the SAS trusted login module at run time.
```
sas.svc.sec.login.weblogic.jar
sas.svc.sec.login.weblogic.nls.jar
sas.svc.sec.login.jar
sas.svc.sec.login.nls.jar
sas.svc.connection.jar
sas.oma.omi.jar
sas.core.jar
sas.security.sspi.jar
```
Start the administrating server and then connect to it as follows:
```
http://host:port/console
```
1. Navigate to Security Realms, and then to your Realm.
2. Select the Providers tab and then select Authentication within that grouping. Typically, you see the configured default authenticator providers: DefaultAuthenticator, DefaultIdentifyAsserter.
3. Click New to add the SAS trusted login module to the chain of providers. Enter the following information:
```
Name: SASTrustedAuthenticator
 Type: WLTrustedAuthenticator
```
4. Click on the newly created provider and enter the following information:
```
Common information:
    Control Flag: OPTIONAL
 Provider Specific information:
    Host: SAS-metadata-server-host
    Domain: web
    Port: 8561
    Encrypt: false
    Trusted User: sastrust@saspw
    Trusted Password: encoded-password-for-sastrust
    Debug: false
```
  where encoded-password-for-sastrust is an encoded password that can be obtained from the SAS administrator. For more information about encoding passwords, see the SAS Intelligence Platform: Security Administration Guide.
5. Click Save and Activate changes.
6. Restart the administration server.
Configure user information for the authentication provider. For example, if you are using the DefaultAuthenticator provider, you need to configure the internal WebLogic LDAP server with user and password information.

Navigate to Security Realms, select your Realm, and then select Users and Groups. Then click New to enter users.

Additionally, if transport-level security is configured, then map the SASWebUser role to individual authenticated users. You can perform this action using the administration console or you can modify the weblogic.xml deploy descriptor as follows:

<security-role-assignment>
   <role-name>SASWebUser</role-name>
   <principal-name>username</principal-name>
</security-role-assignment>
...

Update Remote Services Files

Modify the JAAS login configuration at the following location: SAS-config-dir/lev1/web/common/login.config. The following code is an example of what this configuration might look like:

  PFS {
      com.sas.services.security.login.OMILoginModule required
                "host"="SAS metadata server host"
                 "port"="8561"
                 "repository"="Foundation"
                 "domain"="DefaultAuth"
                 "aliasdomain"="web"
                 "trusteduser"="sastrust@saspw"
                 "trustedpw"="encoded password for sastrust"
                 "debug"="false";
  };

Modify the remote services script, the wrapper.conf file, or both to add the following JAR files to the SAS application classpath (-Dsas.app.class.path) so that application server-specific JAAS principle and credential classes are available:

JBoss

JBOSS_HOME/Server/SASServer1/lib/jbosssx.jar

WebSphere

WAS_HOME/lib/bootstrap.jar
WAS_HOME/lib/j2ee.jar
WAS_HOME/plugins/com.ibm.ws.runtime_6.1.0.jar
WAS_HOME/plugins/com.ibm.ws.emf_2.1.0.jar
WAS_HOME/plugins/org.eclipse.emf.ecore_2.2.1.v200609210005.jar
WAS_HOME/plugins/org.eclipse.emf.common_2.2.1.v200609210005.jar

WebLogic

WLS_HOME/server/lib/wls-ap.jar

Top of Page