Re: [soa-rm] Security

[Matthew MacKenzie <mattm@adobe.com>]

Exactly.

-Matt

Metz Rebekah wrote:

>By approaching security as a primitive 'constraints', it fits nicely
>into the construct of policy, where policy may address security
>constraints, performance constraints, reliability constraints, etc.
>
>Rebekah
>
>Rebekah Metz
>Associate
>Booz Allen Hamilton
>Voice:  (703) 377-1471
>Fax:     (703) 902-3457
>
>
>  
>
>>-----Original Message-----
>>From: Matthew MacKenzie [mailto:mattm@adobe.com]
>>Sent: Wednesday, April 13, 2005 9:44 AM
>>To: soa-rm@lists.oasis-open.org
>>Subject: Re: [soa-rm] Security (Re: [soa-rm] Definition of "Service
>>Consumer")
>>
>>I'd prefer to stick to the highest level primitive: "Security
>>constraints".  I really don't think we need to get down into all of
>>    
>>
>the
>  
>
>>functional areas of information security in the RM.
>>
>>-matt
>>
>>Anders W. Tell wrote:
>>
>>    
>>
>>>Ken Laskey wrote:
>>>
>>>      
>>>
>>>>Is there a difference between a contract requiring security and the
>>>>RM  including (abstract) mechanisms needed to enforce security?  I
>>>>think  so.  I certainly do not want us to get into the details of
>>>>security  policies or implementations but we need to consider what
>>>>are the  abstract concepts related to security.  From past efforts,
>>>>        
>>>>
>I
>  
>
>>>>can  remember four:
>>>>- authentication (the service provider can unambiguously identify
>>>>the  service requester)
>>>>- authorization (the service provider can unambiguously determine
>>>>that  the service requester has the right to use the service)
>>>>- integrity (the service provider, possibly through the
>>>>communication  mechanism, can be unambiguously assured that the
>>>>request has not been  modified from what was sent by the service
>>>>requester (except possibly  as otherwise authorized))
>>>>- nonrepudiation (neither the service requester nor the service
>>>>provider can later claim they were not part of the request and
>>>>response)
>>>>
>>>>Note, I described this in the context of request/response but I
>>>>believe  it can be generalized to other MEPs.
>>>>
>>>>Is this abstract enough to at least consider?
>>>>        
>>>>
>>>IMO This functional level is most likelly the right one, to include
>>>"primitive" categories such as authentication. However the levels of
>>>granularity need to be discussed since all above mentioned concepts
>>>are categories of functions. A more detailed level includes
>>>      
>>>
>functions
>  
>
>>>such as:
>>>
>>>*addAuthentication of sender/requestor
>>>*addAuthentication of intended addresse
>>>* verifyAuthentication of sender * etc.
>>>
>>>The enactment of these more detailed functions could be delegated to
>>>another service, an authentication service provider.
>>>
>>>
>>>/anders
>>>
>>>
>>>
>>>
>>>
>>>
>>>      
>>>
>
>  
>