Transcription
Paper SAS102-2014An Advanced Fallback Authentication Framework for SAS 9.4 and SAS Visual AnalyticsZhiyong Li, SAS Institute; Mike Roda, SAS InstituteABSTRACTSAS 9.4 and SAS Visual Analytics (VA) support a wide list of authentication protocols such as Integrated WindowsAuthentication (IWA), client certificate, IBM WebSEAL, CA SiteMinder and SAML 2.0. However, advanced customersmay want to be able to use some of these protocols together and also have the flexibility to select which protocols touse. In this paper, we will focus on a “fallback” authentication framework that supports IWA as the primaryauthentication method. When IWA fails, it uses the X509 client certificate as the secondary authentication method,and when the client certificate fails, it uses the form-based username/password as the last option. The paper will firstintroduce the security architecture of SAS 9.4 and SAS VA. It will then review the three mentioned security protocols.Further, it will introduce the detailed “fallback” authentication framework and discuss how to configure it. Finally, wewill discuss the use of this framework in the customer scenario from implementing the “fallback” authenticationframework in a customer’s SAS 9.4 and SAS VA environment.INTRODUCTIONSAS 9.4 has changed its mid-tier infrastructure from using WebLogic, WebSphere and JBoss to SAS WebApplication Server. In addition, SAS 9.4 also pre-packages a SAS Web Server and the management componentcalled SAS Environment Manager. With this significant infrastructure change comes with the following securityarchitecture and implementation challenges: 9.4 SAS Web Application Server environment should support all third party security products and protocols thatare supported in SAS 9.3 by three Web Application Servers. Table 1 shows the security protocols that aresupported in 9.3 for different Web Application Servers and the security protocols supported by SAS 9.4.SecurityProtocols/ProductsSAS 9.4 SAS Web(Application)ServersSAS 9.3WebSphereWebLogicJBossHost AuthenticationXXXXContainer ManagedSecurityXXXXSSLXXXXFIPs complianceXXXXBrowser based IWAXXXXDesktop client basedIWAXXXXBrowser based IWAand pass credential tothe serverXDesktop client IWAand pass credential tothe serverXCA SiteMinderXXIBM WebSealXXSAML 2.0XFallback authenticationXXXTable 1. Authentication protocol / solutions supported by SAS 9.3 and SAS 9.41
SAS 9.4 security architecture should consider both SAS Web Server and SAS Web Application Server. SAS 9.4 security architecture should support customers’ advanced security requirements.SAS 9.4 has also changed its single sign-on implementation or Logon Manager to use Central Authentication Server(CAS). This will require changes from the previous SAS releases on how we can support third party security productswith the Logon Manager.This paper will give you an overview of SAS 9.4 web application security architecture, which includes a detaileddiscussion of the above two-layers of authentication: SAS web application layer and the enterprise layer.Further, some customers may have advanced requirements. They want to be able to use several authenticationproducts or protocols in one authentication flow. In other words, they want to be able to authenticate using protocol A,when that authentication fails, they want to be able to continue to authenticate using protocol B, and so on. Onetypical example is using three authentication protocols: IWA, client certificate and form-based username/password.We have developed such a framework that can support this requirement. We will use the above three protocols as anexample to demonstrate the use of the framework.SAS 9.4 AND SECURITY ARCHITECTURESAS 9.4 ARCHITECTURETo understand the security, we need to first understand SAS 9.4 architecture. SAS 9.4 enterprise platform employs amulti-tier architecture. Figure 1 shows the high-level of that architecture for the SAS 9.4 enterprise platform. Theclient tier consists of browser-based, Java desktop or MS office based applications. The middle tier has webapplications that run in the SAS Web Application Server, which in turn is behind the SAS Web Server. SAS WebServer can be used to provide the load-balance for the multiple clustered Web Application Server instances. It canalso be used as the reverse-proxy server when SAS web applications are deployed into multiple Web ApplicationServer instances. The server tier consists of SAS application servers such as SAS metadata server, SAS workspaceservers and SAS stored process servers. The data tier has SAS Web Infrastructure Platform (WIP) data server and /or third party database servers.SAS Web Application Server is SAS OEM-ed Pivotal tc Server. Pivotal tc Server is based on Apache Tomcat. Thus,in the following discussion, when we mention that a function is available for Tomcat, you can safely assume thatsame functionality is also valid for the SAS Web Application Server.2
Figure 1. High-Level Architecture for SAS 9.4 Enterprise ApplicationSAS 9.4 AND VA SECURITY ARCHITECTURESAS 9.4, VA and Solutions include over eighty web applications. We provide a single logon manager that onlyrequires an end-user sign-on to SAS web applications once and that user can access all other SAS web applicationswithout being challenged to logon again. On top of that single sign-on to all SAS web applications, we also allow SASweb applications to participate with the enterprise authentication, which may have already been implemented bycustomers. This integrated authentication or single sign-on to customer environments may be implemented usingcontainer manager security and/or using customer’s third party single sign-on products. In summary, SAS 9.4 offersthe following layers of single sign-on authentication options: SAS web applications single sign-on: Use Logon Manager and CAS to single sign-on to all SAS webapplications. Enterprise security Integration: Single sign-on to container’s realm or third party authentication domains.–Use container managed security–Integrate with enterprise Single Sign-on (SSO) solutions such as IWA, CA SiteMinder, IBM WebSEAL,SAML, etc.Figure 2 shows the high-level authentication architecture for SAS 9.4 web Applications. In that diagram, there aremultiple web application server instances; however, Logon Manager is only on SASServer1 1 (one per cluster node).All SAS web applications will use that same Logon Manager to sign-on. When using container managed security,container managed security will be implemented at the SASServer1 1 instance that SAS Logon Manager is runningon. When integrating with third party single sign-on products, the authentication will be again enforced at theSASServer1 1 instance that SAS Logon Manager is running on. Integration with the third party single sign-onproducts may use SAS Web Application Server only or use both SAS Web Server and SAS Web Application Servers.For example, to support CA SiteMinder, we need to have the Agent for SAS Web Server and the Agent for SAS WebApplication Servers.3
Figure 2. High-Level Security Architecture for SAS 9.4 Web ApplicationsSAS VA Web Application uses the same Logon Manager as the one used by other SAS web applications so that itcan participate the single sign-on with other SAS Web Applications.SAS Logon Manager and CASThe SAS Logon Manager is a web application that handles authentication requests for SAS web applications. It is the(final) entry point for all authentication requests. As a result, users see the same logon page when they access theSAS web applications and will only need to logon once. By default, SAS Logon Manager uses host basedauthentication.Logon Manager is implemented by using CAS. CAS is an open source authentication system originally created byYale University to provide a trusted way for an application to authenticate a user. CAS can provide Single Sign-On toapplications. CAS uses tickets and hence reduces the need for applications to pass credentials in order toauthenticate a user. The heart of CAS is the CAS server, a Java servlet built on the Spring Framework. The SASWeb Infrastructure Platform packages its CAS server in sas.svcs.logon.war. Servlet mappings such as "/login" directappropriate URLs to the CAS server. For example, one can logon using:http://xyz.sas.com/SASLogon/login?service http://xyz.sas.com:8080/SASHelloWorld/j spring cas security checkSAS applications engage with the CAS server by configuring the Spring SecurityFilterChain in their web.xml files, byemploying additional configuration in their Spring application context as needed, and by using REST APIs. A SASSpring namespace tag, sas-sso:http / , adds filters to the SecurityFilterChain including a CasAuthenticationFilter.Figure 3 shows the authentication process using the CAS based Logon Manager and how the tickets flow when auser logon to a SAS web application. There are four important actors in this scenario: a browser, a SAS webapplication (SASHelloWorld), the SASLogon application, and the CAS server.4
1.The user types a URL such as http://localhost/SASHelloWorld into the browser.2.Security processing in the Spring SecurityFilterChain for SASHelloWorld sends a response to the browserredirecting the request to SASLogon.3.SASLogon's security processing communicates with the CAS server.4.There is no authentication yet so SASLogon presents the SAS logon window in which the user enterscredentials.5.SASLogon uses the credentials to request a CAS Service ticket (ST) required for login and responds to thebrowser with that ticket.6.The browser resends the initial login request to SASHelloWorld with the Service ticket.7.This time the SASHelloWorld SecurityFilterChain sees the ticket, validates it with the CAS server, and loginproceeds.Figure 3. CAS and SAS Logon ManagerContainer Managed SecurityAs we have mentioned, by default, SAS web applications use the form-based authentication that is provided by theSAS Logon Manager application. When credentials are provided to SAS Logon Manager, the credentials are sent tothe SAS Metadata Server for authentication. The metadata server then authenticates the credentials against itsauthentication provider. The default provider is the host operating system.As an alternative, you can configure the SAS web applications to authenticate on the middle tier. When users logonto a SAS web application, SAS Web Application Server handles the initial authentication for container-managedsecurity. To use container managed security, we will need to make the following configuration changes:5
Configure CAS for Trusted Web Authentication: This will make CAS trust the container or third partyauthenticator for authentication. Secure SAS Logon Manager web application: This will make sure to allow the container to conduct theauthentication when authentication request is sent to the SAS Logon Manager web application. To accomplishthis, we need (1) set security constraint on /login for SAS Logon Manager web application; (2) select a Loginmethod to authenticate and also make sure credentials or tokens can be made available, the Login methodscould be a third party Login that negotiates with the user agent and collects credentials (this approach will befurther discussed in the following Enterprise SSO Integration subsection) or the Web Application Server built-insupport for BASIC, FORM, DIGEST, SPNEGO, and CLIENT-CERT methods; (3) define the security roles so thatthe user can be authorized to access the web application, for example, we can use * in conjunction withallRolesMode "authOnly“ on Realm. Realms: Realm is where the user is stored (also called the user registry) and the authentication is reallyhappening. It is also there that the security role is checked.Enterprise SSO IntegrationAs mentioned in the previous subsection, when using container managed security, the container may further beconfigured to use the third party Login. SAS 9.4 supports a wide variety of third party authentication protocols andproducts. Several popular ones are briefly discussed below.Integrated Windows AuthenticationIntegrated Windows Authentication (IWA) is a Microsoft technology that is used in an environment where users haveWindows domain accounts. With IWA, users will not be prompted for credentials; instead it will use the credentialsassociated with the user’s Windows Login account. IWA typically uses Simple and Protected GSSAPI NegotiationMechanism (SPNEGO) or Kerberos authentication protocols. On a typical environment, the key components of IWAare an Active Directory Controller machine (Windows 2000 Server or higher), a Kerberos Key Distribution Center(KDC) in a Domain Controller machine, a machine with a client browser or standalone client application, and a WebApplication Server.SAS 9.4 supports IWA in four different scenarios: Middle tier IWA: The IWA authentication happens between client and the middle tier. The middle tier and theserver tier communication do not use the client IWA credential. Based on the type of the client application, thiscan be categorized into the following two types: –Client application is a web application.–Client application is a standalone Java application.Middle tier IWA and passing the client credential to the server tier: The IWA authentication happens not onlybetween client and the middle tier, but also between the middle tier and the server tier. The middle tier will usethe client delegation token to authenticate the client against the server tier. Similarly, based on the type of theclient application, this can be categorized into the following two types:–Client application is a web application.–Client application is a standalone Java application.CA SiteMinderCA SiteMinder is used widely as the user authentication and single sign-on solution by many customers. It alsoprovides a policy-based authorization, identity federation, and auditing to the protected web applications.SAS 9.4 supports CA SiteMinder by using both SAS Web Server and SAS Web Application Server. It requiresconfiguring a Web Agent to communicate with SAS Web Server and a custom Apache Tomcat valve for SAS WebApplication Server. SAS provides this custom valve. Successful authentication results in a security token(SMSESSION) being set in the user's web browser cookies. The valve is part of the request pipeline. It receives thesecurity token in the request and communicates with the policy servers through an API to decode the user credentialsfrom the security token. This works in conjunction with web authentication to integrate with existing CA SiteMindersingle sign-on environments.6
IBM WebSEALIBM WebSEAL is an important component of IBM Tivoli Access Manager. Access Manager provides completeauthorization, network security and policy management functions and it is used for end-to-end protection of resourcesover intranets and extranets. WebSEAL is a high performance, multi-threaded Web server that applies fine-grainedsecurity policy to resources in the Tivoli Access Manager protected Web object space. WebSEAL can provide singlesign-on solutions and incorporate back-end Web application server resources into its security policy.IBM Tivoli provides a WebSEAL solution to achieve SSO between Tivoli Access Manager and Apache Tomcat. Theintegration consists of a light weight identity assertion module. This integration passes the Tivoli Access ManagerWebSEAL’s authenticated user identity to the Apache Tomcat server, where the identity is established within ApacheTomcat using a custom Valve. A Valve is a filter that is inserted into the request processing pipeline. The customValve supplied with this integration creates a Principal for the user and adds roles according to the Valve’sconfiguration.The integration uses WebSEAL as a reverse-proxy. A WebSEAL junction is created and connected to Webapplication(s) deployed on the web application server. Users access and authenticate to WebSEAL, and theirauthenticated user ID is passed through the junction. A Valve is configured on Tomcat to read the user ID and createa Principal, which is used by the Web application in order to achieve SSO.SAS uses this WebSEAL valve in its SAS Web Application Server to support WebSEAL. Customers need to firstfollow the steps in the “Web Authentication” procedure to configure SAS Web Application Server and SAS LogonManager; it then needs to make the following further updates: (1) specify AMTomcatAuthenticated for the role-nameelement in the web.xml.orig file; and (2) do not add users to tomcat-users.xml or configure a Realm in the server.xmlfile.SAMLIn SAML 2.0 there is a conceptual distinction made between the roll of Identity Provider, or IdP, and Service Provider,or SP. Conceptually, the SAS Logon Manager acts as an IdP and the applications such as SAS Visual Analytics areservice providers. In a SAML 2.0 environment, there is some external IdP, hosted by Salesforce.com for example,and the SAS Logon Manager is also a service provider, providing authentication services to the SAS webapplications.SAML 2.0 IdPs make ‘assertions’, for example asserting the identity of a user. The assertions, which are sent in XMLand contain a digital signature for verification, piggyback on the HTTP requests made by the web browser and areconsumed by the service providers. The different mechanisms of doing this are referred to as ‘bindings’, the two mostcommon being redirect and POST bindings.SAS 9.4 Maintenance release 1 can be used with SAML 2.0 authentication. Rather than work with the SAMLassertions directly, SAS has built a solution around the open source Shibboleth Native SP module, which must bedownloaded independently by the customer. The Shibboleth SP module does authentication in the Apache-basedSAS Web Server. The authenticated user information is rewritten into the HTTP headers and transmitted to the SASWeb Application Server. Inside the application server, the SAS gets those credentials and trusts them. Technicallythis could be used with any form of Apache authentication; SAS is not tied in any way to Shibboleth but that is theonly one that has been tested.AUTHENTICATION METHODS FOR FALLBACK AUTHENTICATIONBefore we discuss the fallback authentication framework, let us discuss three individual authentication methods thatare used in the fallback authentication. For the IWA, we briefly mentioned it in the previous section. It will bediscussed here again but we will focus on how it can be configured with the SAS Web Application Server and with theuse of browser as the client.INTEGRATED WINDOWS AUTHENTICATIONIntegrated Windows Authentication (IWA) allows users to transparently login to applications using their Windowscredentials without having to retype their username and password. In Internet Explorer this can be enabled by goinginto the Internet Options, Advanced, and checking the “Enable Integrated Windows Authentication” box under theSecurity settings. In Firefox you must enter about:config in the address bar, search for network.negotiateauth.trusted-uris and add the address or domain of the middle tier.For the SAS middle tier this happens over HTTP or HTTPS using the Simple and Protected GSSAPI NegotiationMechanism (SPNEGO) and requires Kerberos v5 tickets. The SAS 9.4 middle tier application server runs VMware7
vFabric tc Server, which is Apache Tomcat. Apache Tomcat has built-in support for SPNEGO. Setup requires aservice account within Active Directory, a registered Service Principal Name, and a Kerberos keytab file containingthe credentials of the service account. Configuration for IWA in the middle tier is covered in the SAS 9.4 IntelligencePlatform: Middle-Tier Administration Guide. A link is provided at the bottom of this paper in the references.When configured for IWA, normally the SAS Web Application Server is configured to protect only/SASLogon/login. When a user visits a SAS web application such as Visual Analytics and a session has not beenestablished yet, the web browser is redirected to
Dec 18, 2013 · SAML 2.0 X Fallback authentication X . 2 SAS 9.4 security architecture should consider both SAS Web Server and SAS Web Application Server. . Security processing in the Spring SecurityFilterChain for SASHelloWorld sen
