RE: Issue 2-02

["Edwards, Nigel" <Nigel_Edwards@hp.com>]

> 
> ISSUE:[UC-2-02:OutsourcedManagement] A use case scenario provided by
> Hewlett Packard illustrates using SAML enveloped in a CIM/XML
> request. Should this scenario be included in the use case document?
> 

Hi Folks,
The purpose of this scenario was to illustrate an information flow
involving multiple (more than two) entities in which intermediaries
had to enforce authorization decisions and in which multiple SAML
assertions were used to determine the decision. It has two places where
PEPs enforce authorization decisions: the firewall and end entity. 

It also illustrates the use of SAML in crossing domain boundaries
(firewalls). I believe this may turn out to be an important use.

I think it also managed to start the enveloped versus enveloping
debate, although I don't believe it makes it explicit which of these
possibilities I had intended. (In fact I was thinking enveloping.)

At the time I wrote this scenario (mid January) we did not have a
scenario in which multiple assertions are used. However, since then
ISSUE:[UC-8-02:IntermediaryAdd] was written and we voted on that
before we got to the scenario which I submitted. The two differences
between ISSUE:[UC-8-02:IntermediaryAdd] and this scenario are firewall
traversal is called out explicitly, and an intermediate PEP is called out
explicitly.

As Darren implied in the mail below, I will no longer be participating
actively in this group (or the core-assertion group). So I am
excluding myself from this ballot.

I really regret that I have to reduce my level of participation in
Oasis SSTC. As some of you may know, I changed jobs in February. The
old job had SAML as an explicit objective, the new one does not. The
new job has grown more and more demanding, and unfortunately there are
only so many hours you can work and maintain reasonable quality. I hit
the limit and indeed went over it. I will still be on the mailing
lists, and will be reading your documents with interest. I have really
enjoyed working as part of this team.

All the best,
Nigel.

> -----Original Message-----
> From: Darren Platt [mailto:dplatt@securant.com]
> Sent: 04 April 2001 19:37
> To: Edwards, Nigel
> Subject: Issue 2-02
> 
> 
> Nigel,
> 
> One more thing before you go (if you want to, of course).  On 
> the concall
> today, we reviewed the ballots for the final round of voting. 
>  There was
> some debate as to whether one of the scenarios you created a 
> while back
> (which is the basis of issue 2-02) was redundant with other use case
> scenarios already in the document.  We felt that the 
> functionality here was
> represented in Scenario 1-3 - Third Party Security Service.
> 
> The general consensus on the concall was that it was not good to have
> multiple scenarios for what is essentially the same 
> functionality.  So the
> purpose of this email is to ask that you explain to the list why it is
> different (if that is the case) and should therefore be considered.  I
> understand that you are really busy, but I thought you might like the
> opportunity to fight for this scenario.  We are voting before 
> Friday, so if
> you would like to respond, please get it to the list before then.
> 
> 
> Here's the issue from the ballot:
> 
> ISSUE:[UC-2-02:OutsourcedManagement] A use case scenario provided by
> Hewlett Packard illustrates using SAML enveloped in a CIM/XML
> request. Should this scenario be included in the use case document?
> 
> The use case would be inserted as follows (some editing for clarity):
> 
> This scenario shows an enterprise A that has outsourced the management
> of its network devices to a management service provider B. Management
> messages are exchanged using CIM/XML over HTTP. (CIM or Common
> Information Model, is a management standard being developed by the
> Distributed Management Task Force - http://www.dmtf.org/, an XML DTD
> for CIM has been defined.)
> 
> Suppose the operator, Joe, wants to invoke the StopService
> method. This will be executed by the XML/CIM agent on the managed
> device, if authorized.
> 
> [OutsourcedManagement.png] (attached here)
> 
> Fig X. Outsourced Management.
> 
> Steps:
> 
>    1. This SAML assertion has been generated by B's attribute
>       authority (or Policy Decision Point) and confers the role
>       "System Manager for A" to Joe.
> 
>    2. The CIM management console generates the XML content and
>       attaches an SAML assertion. The CIM management console signs the
>       request and sends it as an HTTP request.
> 
>    3. The request now has to traverse A's firewall or the boundary
>       into A's network. The gateway at this boundary uses its SAML
>       evaluation engine (or Policy Enforcement Point) to verify that
>       this incoming message is allowed. It does this, by verifying the
>       signature and discovering the request is from Joe. Next it uses
>       two assertions to authorize the incoming message: the assertion
>       issued by B's attribute authority that is attached to the
>       message (conferring the role "System Manager for A" on Joe); an
>       assertion issued by A's attribute authority granting "Gateway
>       Access" to any entity that has a valid "System Manager for A"
>       assertion issued by B's attribute authority. Note that the
>       second assertion can be pushed to the gateway (part of its
>       configuration), or retrieved dynamically from a repository (or
>       indeed the issuer) (the last case is shown here).
> 
>    4. The request is forwarded by the gateway to the managed device.
> 
>    5. The SAML evaluation engine on the managed device needs to
>       determine if a "StopService" request from Joe is allowed. It
>       does this by using two assertions: the "System Manager for A"
>       assertion issued by B's attribute authority; an assertion issued
>       by A's attribute authority granting "Full Management Rights" to
>       any entity with a valid "System Manager for A" assertion issued
>       by B's attribute authority.
> 
>    6. The managed device executes the "StopService" method.
> 
> Potential Resolutions:
> 
> 1. Add this use-case scenario to the document.
> 2. Do not add this use-case scenario.
> 
> 
> Regards,
> 
> Darren
>