Web service clients can be implemented as JavaServer Pages, servlets, or Java applications, or as executables written in C++, Perl, Visual Basic, JavaScript. A truly ubiquitous protocol. In Part 1 of this article, I use a Java application as a Web service client and show how to secure that client from an authentication and authorization standpoint via Role-based Access Control (RBAC). In Part 2, I examine how to attach a SAML token to a SOAP message from within a Java application to invoke a Web service that is secured using WS-Security SAML policy file.
Basically, role-based authorization is achieved by using:
- A SAML (Security Assertion Markup Language) token provisioned as a Group Principal used within the Web service client.
- The JAAS (Java Authentication and Authorization Service) Framework to contain the Group Principal information in the JAAS Subject.
- A Custom API that is specified in a similar fashion to standard privileges management systems that provide authorization behavior.
I do not discuss configuring SAML on application servers or within a SAML provider/authority, nor injecting a SAML token into a SOAP header. However, these configurations are required for end-to-end security architectures.
SAML Application Architecture and the Security Workflow
Figure 1 is a high-level deployment of the SAML architecture for the target Java application that depicts the security model workflow. In the model, the Java (Swing) application makes an HTTP(S) call to the SAML authority inside the firewall using a .NET service that integrates with Active Directory Federation Service (AFDS). The return parameter is a signed, SAML token generated based on the user's credentials (for example, a Kerberos ticket).
Active Directory (AD) technologies are well documented, and a number of technologies (including BEA WebLogic Server) can integrate with AD to make full use of the directory services. The most common practice for integration between the BEA WebLogic Server (WLS) and AD is to configure WLS instance directly to the directory using LDAP. However, this type of configuration is not optimum from a provisioning and support perspective, since application users need to exist in the specific AD instance. This solution tightly couples the directory to the container. Additionally, this solution creates a rigid provisioning process where changes to the directory directly impact the container.
Alternatively, SAML offers a loosely coupled model, where the SAML authority can abstract away the complexities of the directory. The assertions generated by the authority can contain all the information required to authenticate and authorize activities, in a highly secure manner. The authority needs to be able to convert between the directories identities and the SAML identities.
The SAML authority is contactable using HTTPS via any calling application. The application needs to support SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism), so that the directory identity in the form of a Kerberos ticket can be submitted to the SAML authority during the call. This lets the SAML authority validate the identity of the caller and, in turn, issue a SAML assertion, so that web services protected by SAML can validate the identity. Additionally, to ensure that the assertion is secure, both Transport Level Security (for example, SSL) and Public Key Infrastructure (PKI) are needed. PKI is used by the SAML authority and the services protected by SAML to ensure that the services can validate that the SAML assertion has not been tampered with and has been generated by the SAML authority and has not expired.
The Java application parses the group membership elements on the SAML token and stores the data as a Group Principal(s) in the JAAS Subject (see Listing One). Based on this information, conditional statements in the application validate whether the user has the necessary privileges needed to invoke a particular Web service or method on a service, depending on the granularity of Web service security (i.e., OASIS WS-Security) configured.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header> <saml:Assertion AssertionID="_a1ddddfcd0e6ca80f093d9562ce26b39" ID="_a1ddddfcd0e6ca80f093d9562ce26b39" IssueInstant="2008-03-28T17:54:59.59Z" Issuer="http://xyz.abc.com" MajorVersion="1" MinorVersion="1" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"> ... <saml:Attribute AttributeName="Groups" AttributeNamespace="urn:bea:security:saml:groups"> <saml:AttributeValue>Customer_Accounting</saml:AttributeValue> </saml:Attribute> <saml:Attribute AttributeName="Groups" AttributeNamespace="urn:bea:security:saml:groups"> <saml:AttributeValue>Customer_Service</saml:AttributeValue> </saml:Attribute> ... </saml:Assertion> </soapenv:Header> ... </soapenv:Envelope>
The distributed model requires that the Web service is internally consistent with the Java application with respect to authentication and group membership policy. This consistency is achieved by both client and server applications using the same security token.
Using SAML and JAAS for Authorization
In reality, SAML and JAAS are two distinct security frameworks. SAML is an XML framework for exchanging authentication and authorization information. SAML provides a standard XML schema for specifying authentication, attribute, and authorization decision statements, and it additionally specifies a Web services-based request/reply protocol for exchanging these statements.
JAAS, on the other hand, through implementation-specific login modules receives information about the user, authenticates the user, and verifies that they are a valid subject. Sun provides default implementations for Solaris and NT. While there are many articles on authentication with JAAS, using the API for authorization is relatively undocumented. In this article I describe an approach to authorization that is modeled on vendor-based HTML tag library approaches to role-based authorization.
