RE: [ebxml-dev] ebXML security

["Ahmed, Zahid" <zahid.ahmed@commerceone.com>]

Actually, w.r.t. SAML based security infrastructure being exposed
in a J2EE Web services environment, there is a JSR-155 effort
taking place to integrate SAML semantivs with Java authentication
and auhorization model and to expose SAML request/response
protocols via Java SAML extensions.
 
This work, when completed, would be a good addition to a web 
services package - infact, I expect that one day critical building 
blocks of SAML would become part of Java SDK.
 
Is there any software specification for the "trustbridge" solution or
is it merely marketing-ware currently? I know Microsoft has also
announced that they are interested in employing basic SAML
components.
 
ebXML will have to eventually support use of SAML and WS-Security 
extensions ultimately. 
 
thanks,
Zahid

-----Original Message-----
From: Ranjeet Sonone [mailto:ranjeet@ipedo.com]
Sent: Friday, August 09, 2002 1:13 PM
To: Douglas Nelson; ebxml-dev@lists.ebxml.org
<mailto:ebxml-dev@lists.ebxml.org> 
Subject: RE: [ebxml-dev] ebXML security


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