Providing Client Authorization: Approach and Configuration
Step 1: Login
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();
Step 2: SAML Token Acquisition and Parsing
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;
}
...
}
Step 3: Combine SAML Token Group Principals with an Existing a JAAS Subject
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.
Step 4: Enable RBAC for Web service Invocations
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:
- LocalAuthorizer, used to provide RBAC for Java client invoked application objects and to provision Group Principals into the JAAS Subject.
- DomParser, used to parse Active Directory Groups from the SAML token.
- ADFSPrincipal implements the JAAS Principal and is used to store a users identity, including what groups he is a member of.
- ADFSGroup implements the JAAS Group and is used to add members to a group.
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);
}
Implications
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.
