|
Using a Java application as a Web service client for authentication and authorization
June 06, 2008
URL:http://www.drdobbs.com/web-development/saml-jaas-role-based-access-control-par/208402532
Frank Teti is a Consulting Technical Manager within Oracle's SOA practice. He can be reached at [email protected].
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.
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.
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.
The approach I discuss uses an NT login module. Login modules are identified by a name in a configuration file (see Listing Two) and then called by a LoginContext class that JAAS provides (see Listing Three).
GetNTLoginModule {
com.sun.security.auth.module.NTLoginModule required;
};
Most of these modules expect to be run from an application or on the command line, and thus to be able to interact directly with users. This argument (-D java.security.auth.login.config=jaas.conf) is required on the JVM. Essentially, this authenticates users who have already logged into NT. Authentication is defined as the act of verifying that a user is a JAAS Subject and that contains certain JAAS Principals -- "who you are."
The JAAS Subject is retrieved using the code in Listing Three. The Subject at the login contains the Principals associated with the user's login domain. A Principal is one view of the Subject. The API states that it "represents the abstract notion of a principal, which can be used to represent any entity, such as an individual, a corporation, and a login id. A Principal is used for authorization can be thought of as a role or a group, but those terms have special meaning in J2EE. Authorization is the act of verifying that users are to access a certain resource -- "what you may do."
lc = new LoginContext("GetNTLoginModule");
lc.login();
subject = lc.getSubject();
A call must be made to a SAML token provider in order to get the XML token. This example used ADFS (Active Directory Federation Services) as a SAML Authority.
// Call to get assertion to add all groups from token here. ADFSAuthenticator asserter = new ADFSAuthenticator(); assertion = asserter.getAssertion(); //instantiate a parser obj for testing DomParser dp = new DomParser(assertion); //call run parser and return list of groups from token
After the token is acquired in the form of a String object (see Listing One) it is passed to the XML parser (see Listing Four). The Group Principal name is retrieved by read the saml:AttributeValue element on the token (see Listing Five, parseDocument method).
public class DomParser {
...
/* Build a DOM with the SAML token */
private void parseXml(){
//get the factory
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setNamespaceAware(true);
dbf.setValidating(false);
dbf.setExpandEntityReferences(true);
dbf.setIgnoringComments(true);
dbf.setIgnoringElementContentWhitespace(true);
dbf.setCoalescing(true);
dbf.setExpandEntityReferences(true);
try {
//Using factory get an instance of document builder
DocumentBuilder db = dbf.newDocumentBuilder();
StringReader sr = new StringReader(assertion);
InputSource is = new InputSource(sr);
dom = db.parse(is);
}catch(ParserConfigurationException pce) {
pce.printStackTrace();
}catch(SAXException se) {
se.printStackTrace();
}catch(IOException ioe) {
ioe.printStackTrace();
}
}
/* Parse token for SAML group element */
private void parseDocument(){
//get the root elememt
Element docEle = dom.getDocumentElement();
//get a nodelist of <employee> elements
NodeList nl = docEle.getElementsByTagName("saml:AttributeValue");
if(nl != null && nl.getLength() > 0) {
for(int i = 0 ; i < nl.getLength();i++) {
// get item in node
String name = (String)nl.item(i).getTextContent();
Employee e = new Employee(name);
//add it to list
myEmpls.add(e);
}
}
}
/* Get the List of SAML groups */
public List getGroupList() {
return myEmpls;
}
...
}
A Collection List containing Group Principals from the SAML token is retrieved by calling the getGroupList method on the DomParser object (see Listing Four). With the JAAS Subject and List of Group Principals created in Step 1 and 2, respectively, the application has the necessary information required to perform authorization.
The Sequence Diagram in Figure 2 specifies a custom LocalAuthorizer object, which provisions Group Principals to the Subject and is used for RBAC.
The Sequence diagram (Figure 2) view of participating classes, roles and responsibilities includes:
The LocalAuthorizer constructor takes a List argument, which contains the Group Principals, retrieved from the SAML authority, in this case ADFS. The Group Principals are merged with the Principals already associated with the user's existing Subject acquired from the user's login domain. The JAAS Subject is essentially a local credential cache.
Using that same SAML assertion that is used by the Web service policy insures that the security model is internally consistent between client and server applications. For example, only users in the "Customer_Service" group can invoke the operation (see Listing Six) and, in turn, the Web service would be using the same token in order to administer access control on the Web service.
The application uses the LocalAuthorizer object's getName and isInRole methods, which returns the user name and whether the user is in already configures role, respectively. A JAAS role is equivalent to an Active Directory group.
if (user.isInRole(Iconstants.Customer_Service) {
//Based on group access privileges allow access to a specific Web service
client.operation(assertion);
}
With previous generation distributed technologies (DCE, for instance) using Kerberos within a DCE Cell was inextricably linked to using the DCE RPC. With Web services technologies, there is nothing in place that preempts your using a SOAP RPC call without security.
However, in the case of Web services, bindings are available for a host of programming languages. Because of the distributed nature of Web services technology, many organizations are putting Web services applications into play where sensitive information may be compromised. While the Web services programming model is flexible, the security model is austere.
The distributed nature of the Web services requires that security mechanisms also need to be multi-purpose. The security model I propose in this article deviates, to a degree, from the standard approaches dictated by the technologies. These deviations are a result of using viable approaches to implementing the technology, that is, a Web service client implemented as a Java application. However, they are not necessarily accepted as standard approaches. SAML is a server-to-server technology, or server-to-browser technology.
In short, the security models available for Web service need to be as omnipresent as the client Web services programming languages.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.