July 17, 2008
SAML, JAAS, & Role-Based Access Control: Part 2Web service Client Security: Approach and Configuration
Step 1: NT login configuration
The approach uses a JAAS NT login module. Login modules are identified by a name in a configuration file (see Listing One).
Listing One: jaas.conf configuration file
Most of these modules expect to be run interactively by a user either from an application or on the command line. The argument -D java.security.auth.login.config=jaas.conf is required on the JVM. Essentially, this authenticates a user (who has already logged into NT) within a Java application. The LoginContext object constructor instantiates itself as an NT login (see Listing Two).
Listing Two: JAAS login within the Java application
Step 2: Token acquisition from a SAML provider
For Web services security, a remote call must be made to a SAML provider in order to get the signed, XML token. Essentially, Listing Three should be viewed as an interface method that needs to be implemented, based on the SAML provider in your architecture.
After the token is acquired, it should be stored within a String object. A cached assertion can be reused for subsequent Web service calls during the lifetime of the client session. However, for long running clients, the SAML assertion may expire, which will result in a server-side SOAP fault.
The Java application should be designed to specifically catch an expired assertion fault and force an automatic acquisition of a new token. In the vast schema of things, expiration dates could be set such that they may not expire to well into the future. In effect, though, this type of policy would represent weak management and a breach of best practices.
However, technically speaking, the SOAPMessage object provides behavior for persisting a SOAP message to a local file (see Listing Six) and the application could be designed to be reentrant from a security standpoint. Needless to be said, just because something is viable doesn't mean it is a good thing to do.
Listing Three: Storing a SAML token as a String object
While the asserter behavior is implementation-specific, the XML response needs to be well-formed XML assertion (see Listing Four). Note that this assertion is specified to use groups, which will allow the application server to secure the Web service by role.
<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 Four: SAML Assertion (Token)
Step 3: Security preprocessing steps before invoking the Web service
The "secure" operation method is a method on the Java application which is responsible for:
It is important to point out that for a production applications, handler implementation-details should be encapsulated in a set of objects outside of the programmer space.
An explanation of the processing steps is embedded as comments in Listing Five.
private void secureOperation( Service_Impl service, Hello port, Stub helloStub, String assertion) {
Listing Five: Secure Web service method
Step 4: Injecting the SAML token into the SOAP header
In real-time, the SAMLAuthenticationHandler object has completed processing before the Web service is invoked in Listing Five. The SAMLAuthenticationHandler is responsible for setting the SAML token into the SOAP header.
An explanation of the processing steps is embedded as comments in Listing Six.
public class SAMLAuthenticationHandler extends GenericHandler {
Listing Six: SAML authentication handler
Implications
In practice, most of the code in this article should be abstracted away from Java application programmers. Essentially, information contained in SOAP objects is opaque. The size and shape of opaque objects should not be directly accessible to the user. Opaque objects should be accessed via handles, which exist in user space.
Even issues such as exception handling for expired tokens are system programmer's responsibility, not application programmers. As is the case with all security-related programming, the objective is to keep the application programmer productive, while enforcing the organizations security polices.
|
|
||||||||||||||||||||||||||||||
|
|
|
|