Gervas Douglas wrote:

 > As Keith points out, concentrating all resources in a central server
 > cluster presents a well defined target.  On the other hand users wandering

 > around with laptops, memory sticks, iPods, mobile phones, cameras etc., all
 > with substantial storage capacity are in themselves a security nightmare.
 > I suspect that there is no simple solution to this problem.
 > Further thoughts, please!

What is at issue is non-SOA enterprise architectures.  Data oriented 
applications have historically been focused on creating high speed access to 
remote clients of that data.  There have been optimizations performed local to 
the database using stored procedures.  The database vendors have been in 
control 
by creating standards that continue to focus on their products expanded use, 
rather than standards that allow a decoupling from the vendors wares.

This is where SOAs comes into play.  If you create services which expose a 
vendor neutral interface, then you have the opportunity to move past the 
vendors' shortcommings.  SQL 'views' have been used to cast new interfaces on 
old data, or to combine data into new structures.  This mechanism highlights 
the 
power of technologies such as Java language interfaces.  The SQL view is 
accessed in the same way as the SQL table.  This is the kind of abstraction 
that 
should be used to eliminate a direct dependency on implementation details.  The 
fact that SQL is used, is another level of abstraction which may or may not be 
an advantage to export.  In general, I try desparately to make SQL invisible to 
my SOA applications.

With remote computing, you have data volume issues and data source/access 
management issues as is discussed above.  Jini technologies enhance your 
abilities to move abstractions between the client and server computing 
environment.  Through the use of mobile code, we can use client side caching in 
a changing way, as well as switch from SQL to method access. Being able to 
change the service abstractions independent of the client application is where 
Jini shines.  Mobile code is the enabling technology.

Security of data involves not exposing more data than is necessary. 
Authenticated access to data is one way to manage that.  SQL implementations 
are 
not, in general, able to provide very much control over access to limited sets 
of data in views/tables.  In particular, the 'free' SQL databases have very 
limited control at the row access level.

Through the use of SOA and appropriate security controls, we can limit access 
to 
data.  The Java security model allows you to provide a wide range of scoping of 
access through the use of the Java Security Manager.  You can create methods 
using security controls such as:

public List<DataItems> getItemsFor( String table, List<DataKeys> keys ) {
     for( DataKeys k : keys ) {
         AccessController.checkPermission(
             new DataAccessPermission( table, k ) );
     }
     ... method implementation ...
}

Typically, then you might find a static expression of a policy for access 
control in the policy file, such as:

grant Principal javax.security.auth.kerberos.KerberosPrincipal
     "[EMAIL PROTECTED]" {

     permission domain.your.DataAccessPermission( "the_table", "key1");
     permission domain.your.DataAccessPermission( "the_table", "key3");
};

The Jini toolkit includes a dynamic policy provider that can be used to create 
a 
policy from a data store or other dynamic environment.  So, it is possible to 
do 
this in a very flexible yet controlled way.

DynamicPolicyProvider pol = new DynamicPolicyProvider();
Policy.setPolicy( pol );

...

DatabaseManager mgr = SQLFactory.getManager( driver, url, user, password );
try {
     ResultSet rs = mgr.executeQuery( "select idn_prin,nme_tbl,nme_key "+
         "from tbl_data_access" );
     while( rs.next() ) {
         pol.grant( getClass(), new Principal[]{
             new KerberosPrincipal( rs.getString("idn_prin") ) },
             new DataAccessPermission( rs.getString(nme_tbl) ),
                 rs.getString(nme_key) );
     }
} finally {
     mgr.release();
}

So, it's fairly easy, to see that there is plenty of opportunity to provide a 
more controlled data access implementation.  SOA is where it all starts. 
Creating focused APIs which the REST folks will say are limiting is where the 
control comes from.

Gregg Wonderly





------------------------ Yahoo! Groups Sponsor --------------------~--> 
Everything you need is one click away.  Make Yahoo! your home page now.
http://us.click.yahoo.com/AHchtC/4FxNAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/service-orientated-architecture/

<*> To unsubscribe from this group, send an email to:
    [EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


Reply via email to