RE: [soa-rm] Security

["Metz Rebekah" <metz_rebekah@bah.com>]

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