RE: [ebxml-dev] ebXML security

[Ranjeet Sonone <ranjeet@ipedo.com>]

The list looks impressive. I am providing input on the possible existing standards/technologies

that could be plugged together in order to produce the necessary harmony between the various

actors for design and implementation of such an infrastructure. The current problem is the

existing standards are well defined within the domain they are used. E.g. The SAML specification

is focused on Single Sign-on and products (Oblix, Netegrity) that support them operate at the access layer

in a typical web service deployment. So when an organization wants to deploy such a security infrastructure, they

would already have these individual pieces (such as Single-Sign-On, Certificate Mgmt etc.) deployed and

the new security infrastructure should be able to leverage these.

 

The challenge here is to figure out which standard is offering what and can be leveraged and

then build the core layer that defines the union of these.

 

One thing surely lacking in the JAVA Web services pack and the kit is a good picture of how 

security is handled in JAVA for web services. Something like what the TrustBridge effort might do

for .NET.

thanks,

-ranjeet

-----Original Message-----
From: Douglas Nelson [mailto:douglas.nelson@sun.com]
Sent: Thursday, August 08, 2002 3:38 PM
To: ebxml-dev@lists.ebxml.org
Subject: [ebxml-dev] ebXML security

I would like to start a thread of security issues to discuss what features need to be included, interfaces, we would like to have and general discusses of each of the primary features. I am thinking the features should be available as web service and as an API possible an addition to the java core api's for web services. I would be interested in what you guys have thinking about security.  This first cut at the primary features,  you guys come up with any more, might include the following:

• Administration – An administrator shall have all the tools necessary to define and maintain roles, monitor all security aspects of the framework and to perform maintenance on any of the security modules.
  [Ranjeet Sonone] This would be pretty much specific to the solutions developed. Standardizing here would be tough, but an effort like the Microsoft Management Console, where the console framework specifies the plug-in architecture, how to register the management plug-ins and likes, would be possible.
• Auditing – The administrator shall be able to return the framework to any previous state on any given day, view logs and to track changes to the system by other authorized users and administrators.
  [Ranjeet Sonone] The standardization effort here would be focused more on the log format, events that a security system could produce, the specification for various handlers for logging and auditing. Another challenge here is to come up with log formats thatch can be consumed easily by existing reporting solutions, so thatch any reporting tool can be used for auditing.  
• Authorization – The framework shall provide a mechanism that will allow an administrator to define roles to access confidential data and resources.
  [Ranjeet Sonone] JAVA security APIs look a good candidate here. The problem is thatch they are low level provider kind of APIs. What would be needed is an API thatch defines high level objects such as Roles, Resources and then leverages existing security API to provide an implementation layer. XML Access control is more about content level access control. But what is also required is service level access control, where based on the class of users, the service would offer varying interfaces.
• Authentication – The framework will uniquely identify a user by user id and password or the acceptance credential information from a federated third party server.
  [Ranjeet Sonone] JAAS and GSS API definitley are possible candidates here. 
• Certificate Management – The administrator will have the ability to accept, delete, track certificates submitted from a trusted third party on behalf of all users registered to the framework.
  [Ranjeet Sonone] This is what a certificate management server would do. What would be required here is to clearly define an interface between the security system and the certificate management services. I am not aware of such an effort, but if it exists, there is room to leverage it.
• Encryption – The framework will provide API (Application Program Interface) to support encryption of all or part of an XML (eXtensible Markup Language) message document.
  [Ramjet Son one] This is providing a JAVA standard API for XML encryption. I am not aware if one exists. But the work would be hand-in-hand with the effort for XML encoding, again of which I am not aware.  
• Monitoring – The framework will monitor and issue alerts to administrators and support personal when errors, exceptions or general failures occurs.
• Planning for Evolution – The framework will be architected in a object oriented modular fashion to allow new open standards to be introduced without have to effect the pre- established API’s or web services.
• Privacy – The framework will provide a mechanism that will allow documents to be classified and encrypted so that the document may only be view by those to whom the document was intended.
  [Ranjeet Sonone] This would be a subset of access control for the content. 
• Redundancy – The framework will have the ability to be load balance and fail over to additional servers.
• Single Sign On - User will have the ability to log on to any of the trusted federated server and be authorized to access data and services by user id and password or any additional federated servers providing the appropriate credentials.
  [Ranjeet Sonone] SAML looks like the choice here. 
• Time Stamping – The framework will have the ability to sync its internal clock to government run time sync servers to maintain accurate logging and saving of documents for non-repudiation.

Thanks Doug