MITA TAC 2010 - Security as a Service (MMIS Conference)

With respect to the MITA TAC, the theme and effort we focused on for 2010 was centered on “Security as a Service” (SaaS).  SaaS has the benefit of:

1. Centralizing control of security
2. Re-using critical security functionality throughout an organization
3. Providing consistency with respect to how security is implemented
4. Leveraging standards to implement security for interoperability, plugability and extensibility 

The upshot is that the MITA TAC achieved the following:

1. Clarified what the key services are: authentication, authorization, and auditing
2. Leveraged industry standards for security to build out and deploy examples of these services
3. Exposed these web services on the internet – focusing on the 2010 MMIS Conference
4. Demoed these services at the MITA TAC interoperability booth

The following services were researched, designed and implemented:

Authentication

Authentication as a service is achieved using the OASIS WS-Trust and Secure Token Service standard.  We did not implement this in the demo, but this is a well understood and widely accepted area with respect to authentication as a service.  SAML version 2 has also being adopted by NHIN CONNECT as the standard interoperable token format for authentication.  

Authorization

OASIS also standardized authorizaton via the XACML standard.  We adhered to the XACML version 2 standard with respect to implementing authorization as a service.  We used Oracle’s Entitlement Server product (OES) to implement this service.  There are 2 ways to consume this service: one is to use the following WSDL and XSD files contained here and invoke it directly – perhaps using Java 1.6 and JAX-WS to autogenerate your code.  I want to thank Chris Carr (eServices’ software engineer extraordinaire) for implementing the client-side of this authorization service and proving it out, as well as resolving a couple XSD and WSDL issues:

WSDL Document:

https://docs.google.com/leaf?id=0B_4CVzElF_kNOTBkMmQwZmEtNGI2ZS00OThjLWE3ZWYtMWExNjYyMzAyNWU5&hl=en

XSD Files (Zipped up) that Accompany the WSDL:

https://docs.google.com/leaf?id=0B_4CVzElF_kNNjNlMDcyNWYtYWU3Yi00ODAyLTlkZDctYWE0M2I4MGMyZWQ3&hl=en

The other way to consume the OES authorization service is to wrap it with another web service that meets your needs better, and/or perhaps proxy the web service using a service bus.  The following Java source code was used to wrapper the OES Authorization web service using 3 simple (string) elements: Subject, Resource, and Action.  We recommend using WS-I compliant Document-Wrapped style of web services for implementing a service like this:

Authorization Java Code (OES client):

 https://docs.google.com/leaf?id=0B_4CVzElF_kNZmQ0ZTc0YjItYjEwOS00NDlhLWIzZTMtNWY5ODAxNzVhZWI0&hl=en

XACML JAR Files:

https://docs.google.com/leaf?id=0B_4CVzElF_kNMDIyYzBiOTAtYjQzMC00YThlLTkxMTUtM2Q5OTc4YmU3NDU0&hl=en

Note that Subject contains some value that uniquely identifies a user.  The Resource element identifies the IT resource for which you are making an authorization decision.  Some examples of a resources are: 1) a web page (URL), 2) document, 3) web service, 4) business component, or 5) business process.  Finally, the Action is the specific operation the subject/user wants to perform on the resource.  Examples of actions are “create”, “view”, “update”, “invoke”, “delete”, etc.  Anyhow, based on this Java source code, you can auto-generate a wrapper service using your favorite IDE tool.  I should also note that OES provides a Java API as well.  Finally, Oracle is serving as a catalyst to standardize an Authorization API (different than current OES API) that is XACML-oriented and ultimately will support multiple programming languages.  This new standard is called OpenAz and is located here:

http://sourceforge.net/projects/openaz/

Auditing

The MITA TAC team investigated whether there was any pre-existing standards relating to auditing – either industry-wide or healthcare-specific.  We found that IHE ATNA had already identified RFC 3881 as an auditing standard.  This RFC specifies an XML schema to represent an audit message.  However, this RFC did not specify how the audit data would be persisted or exactly what additional fields might be appropriate for post-analysis purposes.  As a result, we discovered and used the CEF (Common Event Framework).  CEF was created by ArcSight™, and it adds some additional fields and structure to the persisted audit message.   What follows is the XSD we designed to accommodate these 2 standards (AuditService.xsd) and the WSDL (AuditService.wsdl) as well as a real-world implementation of this WSDL (AuditSvc_ep.wsdl):

AuditService.xsd:  
https://docs.google.com/leaf?id=0B_4CVzElF_kNOGE4YTBlMzktNzI3Ni00MjI0LTg5NmYtYTMzYjU5YjRlODUy&hl=en

AuditService.wsdl:

https://docs.google.com/leaf?id=0B_4CVzElF_kNNTNkYmU1NTYtMWFiNS00YzIyLTliYjctMDM0YjViYmIwNmVi&hl=en

AuditSvc_ep.wsdl:

https://docs.google.com/leaf?id=0B_4CVzElF_kNZjY2ZjRiNDktOGJhNS00OTU0LTgwZmMtYjgxYjQ3NDg3NDdk&hl=en


Note that CEF also makes it easier to implement automated alerting and forensic analysis based on these fields.  Moreover, the MITA TAC recommends that you persist audit records into a database so it is easier to manage, analyze and report on the audit data.  These two URLs will provide you with more detailed information on these auditing "standards" if you want to delve deeper into auditing:

http://datatracker.ietf.org/doc/rfc3881/

http://www.arcsight.com/solutions/solutions-cef/