[acs-wg] Security

[Keisuke Fukui]

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)
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: SAML.ppt
Type: application/vnd.ms-powerpoint
Size: 131584 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/acs-wg/attachments/20050810/f593bd28/attachment.ppt