<>I was able to talk with Rebekah last week. She is not currently involved with GGF however she worked on a security issue using grids for her Masters and was involved with the OGSA-Auth-WG at that time. She is an OASIS member and has participated in the security groups. The entire WS security architecture seems overly complex to me and is focused on static definitions or rules. There are some efforts to simplify the process with a new spec called WSPL - we'll need to research that. If a "service" wants to enforce access, then SAML+XACML can be used. Some services would most likely provide their own policy enforcement point (PEP), requiring that the service provide an auxillary service which would be SAML compliant. Therefore, it seems that an ACS implemetnation might need to implement one. <> It seems that "attributes" are more important than identity and roles in the WS Security mindset. I believe the thought is that roles are just other attributes and identity is a unique set of attributes. Someone please correct me here if this is wrong or overly simplified. This contrasts with the J2EE world where roles can be declared by the web.xml and then used externally to block requests or within the authenticated request processing internally for authorization decisions (isUserInRole() method). Whether or not an ACS implementations provides a PEP service might be irrelavant as long as the provided XACML can be passed along and processed - so perhaps it can be just an implemtation detail and our spec only needs to ensure that a security policy document (using a generic term) can be supplied and updated. References: http://research.sun.com/projects/xacml/wspl_intro.pdf http://sunxacml.sourceforge.net -- Michael Behrens R2AD, LLC (571) 594-3008 (cell) *new* (703) 714-0442 (land)
Thanks Mike for an update. My comments are inserted in-line: Michael Behrens wrote:
<>I was able to talk with Rebekah last week. She is not currently involved with GGF however she worked on a security issue using grids for her Masters and was involved with the OGSA-Auth-WG at that time. She is an OASIS member and has participated in the security groups.
# To be precise, it is OGSA-Auth*z* WG, I believe.
The entire WS security architecture seems overly complex to me and is focused on static definitions or rules. There are some efforts to simplify the process with a new spec called WSPL - we'll need to research that.
If a "service" wants to enforce access, then SAML+XACML can be used. Some services would most likely provide their own policy enforcement point (PEP), requiring that the service provide an auxillary service which would be SAML compliant. Therefore, it seems that an ACS implemetnation might need to implement one.
Yes, I think it's up to the ACS implementation (or the system design that contain ACS) whether it enforce the security policy related to the repository interfaces. # Alternatively, we can state that ACS will be one of the Policy Enforcement # Point and depending on the implementation, it can have a very generous policy # that grants every permission for any of the repository interfaces. In any case, I believe we can stay away from the security impl. details, allowing the access constraint information, such as XACML doc, to be included in AAD, by real contents or reference to the separate file.
<> It seems that "attributes" are more important than identity and roles in the WS Security mindset. I believe the thought is that roles are just other attributes and identity is a unique set of attributes. Someone please correct me here if this is wrong or overly simplified. This
I believe that it is the question for security guru, though I feel I understand your point:-) I guess that roles will be described as a part of system wide security policy (which should be in a SAML doc, I believe).
contrasts with the J2EE world where roles can be declared by the web.xml and then used externally to block requests or within the authenticated request processing internally for authorization decisions (isUserInRole() method).
Whether or not an ACS implementations provides a PEP service might be irrelavant as long as the provided XACML can be passed along and processed - so perhaps it can be just an implemtation detail and our spec only needs to ensure that a security policy document (using a generic term) can be supplied and updated.
As a whole, do you think the information you collected confirms that our understanding is on the track? If so, we can focus on the simple policies toward drafting the security section in ACS spec: - We may simply specify to reserve an extension point for access constraint information, such as XACML, in AAD. Optionally, we may describe our considerations as an informational part demonstrating how this can be utilized. - We will not specify the security features for ARI (SOAP message exchange) since this should be covered by existing standard spec or profile. We will refer to the external relevant specs or profiles, such as OGSA Basic Profile. - We may include description about the *optional* AA signature, in consideration mainly for when AA Document is handled out of secured path. Though we may define the range of contents that the signature will cover, the technologies to be used for signature, such as an XML signature or signature used in Jar file, may be left unspecified or just listed as candidates. - Authentication detail is up to the security entity in the system, both for specification and for design. The implementation of ACS may have interface to it, but the ACS specification will not specify it. (example interaction may be demonstrated as an informational description.) - ACS implementation can be one of the security PEP in the system, in a sense it may accept or reject the service request to the repository, depending on the Authorization Decision Assertion returned from the Policy Decision Point, which I assume the security entity (or service) in the system is. ACS may simply match the security token presented in the request (in a SOAP header part) and the Assertion, in order to enforce the policy. Please refer the attached diagram, sample.ppt, for the terminology here. Does the above looks OK to everyone? And please point if you have any addition or subtraction from the above. We'll discuss about this in the call tomorrow. Thanks in advance! -Keisuke
References: http://research.sun.com/projects/xacml/wspl_intro.pdf _http://sunxacml.sourceforge.net_
-- Michael Behrens R2AD, LLC (571) 594-3008 (cell) *new* (703) 714-0442 (land)
participants (2)
-
Keisuke Fukui -
Michael Behrens