OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [soa-rm] Identity


Identity also needs to be part of availability (authentication/authorization) because you need to be sure of who you are dealing with to be sure access is appropriately given or withheld.

Ken

At 11:30 AM 5/11/2005, Smith, Martin wrote:
Joe - -
 
Right - - that’s how I would see it. 
 
I was also trying to make the point that identity (related to security, as opposed to any unique object ID sort of issues) is one of several implementation-related sub-issues of the overall security issue.  I spend a lot of my time these days worrying with identity management systems for access control, so I’m tempted to cheer when IdM is mentioned, but I’m not sure that makes identity a first-class entity or concept in the RM.
 
Martin
 
 
-----Original Message-----
From: Chiusano Joseph [ mailto:chiusano_joseph@bah.com]
Sent: Wednesday, May 11, 2005 10:58 AM
To: SOA-RM
Subject: RE: [soa-rm] Identity
 
It does sound right - thanks Martin. So I believe that "Identity" could be part of both "confidentiality" (as Identity helps ensure that one knows who the "right people" are) and accountability (in order to know who needs to be accountable, they need to be identified).
 
Joe
 
Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
 

From: Smith, Martin [ mailto:Martin.Smith@DHS.GOV]
Sent: Tue 5/10/2005 10:02 PM
To: Chiusano Joseph; SOA-RM
Subject: RE: [soa-rm] Identity

Joe - -

For security, I think we can use the neo-classical "CIAA" set of security "values" (benefits we are seeking from security measures) as a foundational concept:
confidentiality (info not disclosed to wrong people)
integrity (info not altered or corrupted or destroyed)
availability (access not denied to legitimate users)
and accountability (any view of or change to info is traceable to the responsible person.)  (This is the "neo" part - -we used to say "authentication" but that's a "tool" not an intrisicic "value".)

To achieve these values we then enter a discussion of threat sources and technical (or administrative) countermeasures, like link encryption or PKI or separation of duties.  We translate this security strategy into a set of security policies (and the means to implement them.)

Does that sound right?

Martin


________________________________

From: Chiusano Joseph [ mailto:chiusano_joseph@bah.com]
Sent: Tue 5/10/2005 11:42 AM
To: SOA-RM
Subject: RE: [soa-rm] Identity


More potential security aspects:

- Policy (noting that this is already covered in our RM)
- Confidentiality
- Message-Level Security
- Cross-Domain Trust

Part of the question may be how much if this is specified in an RM, and how much in a Reference Architecture (RA)*

Joe

*sneaky attempt to get a response on last evening's posting on RM vs. RA ;)


Joseph Chiusano

Booz Allen Hamilton

Visit us online@ http://www.boozallen.com < https://webmail.bah.com/exchweb/bin/redir.asp?URL=http://www.boozallen.com/ >


________________________________

From: Ken Laskey [mailto:klaskey@mitre.org]
Sent: Tue 5/10/2005 11:39 AM
To: SOA-RM
Subject: Re: [soa-rm] Identity



The essentials are

authentication - I have confidence I know who you are
authorization - I know who you are and I am authorize to request things
of you and/or you are authorized to requests things of me
integrity - other communications are not being tampered
non-repudiation - neither one of us could later say this exchange did
not occur

Identity is a part of this but is not sufficient on its own.  Also, it
is not one way because there is often a need for reciprocity.

Ken

On May 10, 2005, at 11:17 AM, Duane Nickull wrote:

> What about from the Service providers point of view?  I definitely
> think that identifying service consumers is not required in all cases,
> however service providers have some form of implied identity.
>
> The expedia example however does raise the question of would you use
> the site to book a trip if you could not identify it was Expedia's
> site? If just before you were going to give them your credit card, it
> jumped to a different domain name?   Identity is implied by the URL
> resolution process, which in itself places a great deal of security
> requirements on the entire DNS process.
>
> I am not thinking so much in terms of a service consumer as I am the
> service provider.  Ajay made the point in his presentation that it
> would be mandatory to be able to ascertain to some degree that the
> service you are going to use is the one you want to use.
>
> I would at least like to mention it in the RM as an aspect (perhaps
> just in passing).  To me, the Service description is probably where a
> service provider could make a statement of claim regarding their
> identity and perhaps supply a token, even as simple as a URI, to
> provide proof.
>
> anyone else?
>
> Duane
>
> --
> ***********
> Senior Standards Strategist - Adobe Systems, Inc. -
> http://www.adobe.com
> Chair - OASIS Service Oriented Architecture Reference Model Technical
> Committee -
> http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm
> Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
> Adobe Enterprise Developer Resources  -
> http://www.adobe.com/enterprise/developer/main.html
> ***********
>
>
------------------------------------------------------------------------
------------------
Ken Laskey
MITRE Corporation, M/S H305     phone:  703-983-7934
7515 Colshire Drive                        fax:        703-983-1379
McLean VA 22102-7508

*** note change of phone extension from 883 to 983 effective 4/15/2005
***


--
     ---------------------------------------------------------------------------------
  /   Ken Laskey                                                                \
 |    MITRE Corporation, M/S H305    phone:  703-983-7934   |
 |    7515 Colshire Drive                    fax:      703-983-1379   |
  \   McLean VA 22102-7508                                              /
    ----------------------------------------------------------------------------------

*** note: phone number changed 4/15/2005 to 703-983-7934 ***



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]