Security Considerations
A common understanding of security and an agreement on the security model is required in order
for grid services to interoperate1. While WS-Security2 architecture provides for a secure SOAP
message exchange, complexity is increased when other required specifications are incorporated
such as SAML and policy mechanisms of XACML3.
ACS implementations MUST adhere to the OGSA™ Basic Security profiles which provide the
security foundation. Since there can be multiple levels of security, each ACS implementations
MUST also expose one or more OGSA Security conformance claims in order to advertise them.
It is RECOMMENDED that ACS implementations adhere to the OGSA Secure Channel Security
Profile. This helps clients determine the transport and security mechanisms provided by the ACS
node implementation.
Several optional and extensible mechanisms for implementing nodes are described within this
specification. The main areas of security policies and mechanisms are related to repository
access control and integrity of data.
ACS permits the creator of an archive to specify an optional security policy document which
MUST be XACML compliant. An extensibility element in the AAD can be used to specify the
policy.
In order to authorize or restrict access to an archive, an implementation of a ACS
node MAY provide its own implementation of a SAML compliant Policy Enforcement Point (PEP).
This would help to reduce the dependencies on external services and would allow an ACS node
to accept or reject service requests to the repository. An ACS implementation could therefore
have a generous policy that grants access to all interfaces and contents or strict policy which
enforces access based on the optionally provided XACML document. ACS may also may decide
to not provide a PEP, but defer to a remote or other PEP for an authorization decision. In either
situation, ACS must follow OGSA guidelines depending upon which security profile(s) it chooses
to complie to.
ACS also supports XML Digital Signatures on archive contents to enable inquirers to validate the
integrity of the data with respect to the publisher. See section <TBD> for more information.
It is highly recommended that signed checksums fore remotely referenced
jars and/or other remotely referenced content be obtainable from the AA
using the specified (….?... resource
properties/element/attribute…?...).
The level of authorization granularity which is mandatory for ACS if
complying to a non-anonymous OGSA security profile is at least at the
AA level, and must be for an identity, group, or role. This is to
insure interoperability of replication between disparate ACS servers.
1
http://www.cs.virginia.edu/~humphrey/ogsa-sec-wg/OGSA-SecArch-v1-07192002.pdf
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
3 There are some efforts to simplify the process via the Web-Service Policy language (WSPL)
specification.
2
Normative References

[WS-Security] A. Nadalin, C. Kaler, P. Hallam-Baker and R. Monzillo (ed.) Web
Services Security: SOAP Message Security 1.0 (WS-Security 2004), OASIS Standard,
200401, March 2004. http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soapmessage-security-1.0.pdf

[WS-I BP 1.1] K. Ballinger, D. Ehnebuske, C. Ferris, M. Gudgin, C.K. Liu, M. Nottingham,
and P. Yendluri (ed.) Basic Profile Version 1.1, Web Services Interoperability
Organization Final Material, 24 August 2004. http://www.ws-i.org/Profiles/BasicProfile1.1.html

[WS-I SAML 1.0] A. Barbir, M. Gudgin, M. McIntosh, and K. S. Morrison (ed.) SAML
Token Profile Version 1.0, Web Services Interoperability Organization, Working Group
Draft, 19 January 2005. http://www.ws-i.org/Profiles/SAMLTokenProfile-1.0-2005-0119.html

[OGSA WSRF Basic Profile] I. Foster, T. Maguire and D. Snelling OGSA WSRF Basic
Profile Version 1.0, Global Grid Forum OGSA-WG, GWD-R, 1 September 2005.
http://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-wsrf-basicprofile/en/36