June 06, 2008
SAML, JAAS, & Role-Based Access Control: Part 1Frank Teti
Using a Java application as a Web service client for authentication and authorization
Frank Teti is a Consulting Technical Manager within Oracle's SOA practice. He can be reached at frank.teti@oracle.com.
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:
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).
[Click image to view at full size]
Figure 1: Java application acquires a SAML token for role-based access control and for subsequent secure Web service requests.
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>
Listing One: WS-Security using SAML Token, including groups.
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. 
|
 |
|
|||||||||||||||||||||||||||||
|
|
|
