Security in myGrid

1
Security in myGrid

• Associated projects meeting
• May 18th

2
History on security work

• Security questionnaires collated and analyzed
  security policy produced
• Discussion on possibly security measures
• Stop gap sign on proposal and implementation
  authentication on the basis of username/password,
  access control directly linked to authentication
• Possible collaboration with security
  architectures in CLEF, GOLD

3
Current work on security

• Security architecture for Grimoires (formerly the
  views registry in myGrid)
• Outline of possible security architecture for
  myGrid

4
Grimoires

• Metadata enhanced registry metadata attachments
  to registry entries
• Metadata in the form of RDF triple multiple
  metadata attachments. Uses Jena triple store
• Generic metadata interface supported by UDDI,
  OWL-S and BioMoby
• Third party annotation
• To be used in conjunction with Feta
• Target deployment environments OMII container,
  Globus and standard Tomcat/Axis

5
Security in Grimoires

• Uses signatures on SOAP messages to authenticate
  incoming requests to the registry (WS-Security
  using OMII framework)
• Performs access control on a per operation basis
  on the X509DN
• To support the attachment of XACML statements in
  metadata to augment access control

6
Security architecture
OMII Tomcat/Axis container
Grimoires business logic
SOAP
OMII server side handler
Signed SOAP
X509DN
Client side handler
Authorization handler
Registry request
Jena backend
Valid operation ?
DNBob operations saveBusiness DNAlice
operations getBusiness
..
7
Additional security features necessary for myGrid

• Support for using signatures to authenticate
  (used in OMII and Globus), in addition to
  username/password
• Incorporate relevant security standards where
  possible- XACML, SAML, WS-Trust, etc.
• Support for finer grained access control
• Support for delegation of access control
• Support for user-supplied security assertions
  (expressed in XACML for example).
• Support for security generated faults
• Uniform way of determining user identities across
  LSID scheme and information model and mapping to
  appropriate X509DN.

8
Architecture features

• Components that can be deployed in a distributed,
  stand-alone fashion should ideally support both
  authentication and access control MIR, KAVE,
  enactor, Feta/Grimoires
• Authentication parts should be able to support
  credentials that are specifically associated with
  the delegation process, e.g. proxy certificates.
• Components that are accessed directly by a user
  should support the input of security credentials
  (certificates, tokens, username/password)
  Taverna, Portal.
• Option should be provided for individual access
  control lists to be centrally managed through a
  central authorization entity (possibly the MIR ?)

9
Granularity of access control

• Access control at the level of the WS operations
  exposed (e.g. all read operations permitted, all
  write operations disallowed).
• Access control at the level of the data item /
  document being read
• Identity of remote user is matched against an
  internal ACL to ascertain which collection of
  data items are accessible
• Could reuse the access control functionality of
  internal database, (e.g. RBAC in Oracle, etc)
• Might require a mapping between remote user
  identities and the identity scheme used for
  authentication to the internal database.

10
XACML architecture for access control
11
User-supplied security assertions

• User A may run a workflow and wishes the partial
  results generated to be accessible only to user B
  and C
• This access control restriction must be specified
  as part of the workflow through an appropriate
  assertion (e.g. XACML or SAML)
• At the point where results are stored into the
  MIR, the assertion is submitted with the result
• Subsequent requests for those results are
  validated against those specific assertions.
• Allows dynamic determination of access control
  rights by a user without involvement from the
  system administrator

12
Questions to be answered

• To what extent will a security architecture for
  myGrid need to be dependent on or reuse features
  from architectures of other projects (CLEF, GOLD,
  etc) ?
• Will there be any effort at security
  implementation beyond stop gap sign on ? If so
• what standards and open source software do we
  commit to developing against (e.g. WSS4J,
  openSAML, SunXACML, PERMIS, GSI, etc) ?
• which components are to be further
  security-enabled ?
• what limitations will there be on the development
  effort ?