Transcript Globus Week UK e-Science Institute, Edinburgh GT4 Security Evaluation 7

GT4 Security Evaluation
7th April 2005
Anthony Stell, University of Glasgow
Globus Week UK
e-Science Institute, Edinburgh
Aims of evaluation
Testing performed on basic services
ETF evaluation and local security focused
projects
GSI authentication
Gridmap authorization
Role-Based authorization
To note:
Conclusions from results are based on
comparison against GT3.2
Have yet to implement GT4 in our big projects
Resources
GT4-Friends – useful and informative
Sotomayor tutorial – Invaluable as a starting
point.
Globus 3.9.5 – Good as a reference manual
Globus Documentation Project – resourcing the
doc efforts of the community
Security structure
Similar to 3.2 (use of proxy certs, simpleCA,
etc.) Additionally:
The use of global security descriptors to specify
credentials to run container. This is the default
state so beginners must do some work to switch
it off – this is good…
New GT4 code base allows authz to be
controlled at service-level and/or resource-level.
Allows more flexibility in implementing policies.
And more…
The learning curve (small issues)
Nothing really security-specific. All issues involved
getting used to the WS-Addressing features:
Have to set stub properties twice – once on
creation of a resource then once before
operations on that resource.
Using resources (epr.xml) instead of instance
variables in a service.
Understanding terms like “EndpointReference”
etc.
Unresolved Issues
CAS still only talks to GridFTP and doesn’t work
with Java WS Core grid services. This needs
some kind of integrative module developed – can
we help with this?
SAML security language that calls out to the
third-party authz applications has a Globusspecific wrapper therefore need to refactor those
third-party applications like PERMIS. This is
being addressed on both sides.
SAML Callout
Security Assertion Markup Language (SAML)
Conversion
Ease of conversion depends on what you’re trying
to convert…
Easy enough for small test services.
Security conversion *should* be fairly straightforward for our big projects (BRIDGES just now).
More major issues will probably involve the
structure of the code itself (implementing three
classes for a service instead of just one).
Overall Impressions
Documentation is the big win – structured, logical
and invaluable as a reference manual. Plus the
central availability of docs at the GDP website:
http://gdp.globus.org. All this means learning
curve is minimised.
Security features themselves seem to be slightly
more rigorous but with more options to
implement trade-offs between flexibility and
privacy/integrity. Performance benefits to be
investigated…