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

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

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


Subject: Re: [provision] A Proposal for using DSML for Provisioning



That is pretty much the gist of it, as I see it. There is an implied third party, which is the party (most likely a system) that makes the request at the
protocol layer. Suppose that the RA is a provisioning system (system A) in one domain and the PSP is a provisioning system (system B) in another. There is
a supervisor user named jdoe that has rights to request a PSTD for jsmith. Now the trust relationships would be:

Systems A and B have a trust relationship.
System A has the rights to impersonate user jdoe.
jdoe has the rights to request a PSTD for user jsmith

So then the flow might be:

1) jdoe requests a PSTD for jsmith in System A.
2) System A sends a DSML addRequest to System B, using the authRequest tag to refer to jdoe.
3) System B processes the request and sends a response to System A.
4) System A sends a response to jdoe.

In this case System B has knowledge of all three parties involved in the request.

Although these are interesting questions, does anyone have any comments about the overall notion of using DSML for provisioning? Is this something that
makes sense?

Jeff B.

mpolan@ca.ibm.com wrote:

> Can I play this back to make sure I understand?
>
> The RA requests a PSTD for the principle specified in the request data.  So
> there will be authorization of
> 1) The RA as entitled to request PSTDs
> 2) the RA as entitled to act for the principle in requesting this PSTD in
> particular
> 3) The principle of being entitled to have the new account allocated
>
> Is that right?
>
> I've been wondering if a 3rd party should be added as a parameter to this
> and related requests.  The use cases support the delegation of request -
> that is a PSP or PST becoming an RA in order to complete a provisioning
> request, right?  If a request has been delegated, might it be necessary to
> also know the original RA?
>
> Mike Polan
> IBM Canada Ltd
>
> |---------+---------------------------->
> |         |           jbohren@opennetwo|
> |         |           rk.com (Jeff     |
> |         |           Bohren)          |
> |         |                            |
> |         |           07/24/2002 02:31 |
> |         |           PM               |
> |         |                            |
> |---------+---------------------------->
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
>   |                                                                                                                                                  |
>   |       To:       Tony Gullotta <TGullotta@access360.com>                                                                                          |
>   |       cc:       provision@lists.oasis-open.org                                                                                                   |
>   |       Subject:  Re: [provision] A Proposal for using DSML for Provisioning                                                                       |
>   |                                                                                                                                                  |
>   |                                                                                                                                                  |
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
>
> Tony,
>
> No, I would not say that is true in general, although it might be in some
> cases. In use case 5 the RA is the requestor that is requesting a PSTD on
> the behalf of a specific principle. The principle that is used for
> authenticating request at the protocol (i.e. SOAP) may or may not be the
> principle of the RA. If it is not, then the authRequest tag must be used to
> specificy that the principle upon which authroization decisions are to be
> made is the principle of the RA. Obviously the principle that was used for
> the protocol must have privalege to impersonate the RA.
>
> Jeff Bohren
>
> Tony Gullotta wrote:
>
> > So are you saying that the principal used for authentication of the DSML
> > request would be used to identify the end-user being provisioned when
> > communicating between the RA and PSP. In example 5 then, provisioning
> > the email account jsmith@acme.com would be linked back to the identity
> > cn=John Smith,o=acme.com for authorization of the provisioning request.
> > Or to put it another way, the PSP would authorize that cn=John
> > Smith,o=acme.com could have the email account before provisioning it.
> >
> > Tony
> >
> > -----Original Message-----
> > From: jbohren@opennetwork.com [mailto:jbohren@opennetwork.com]
> > Sent: Tuesday, July 23, 2002 9:44 AM
> > To: provision@lists.oasis-open.org
> > Subject: [provision] A Proposal for using DSML for Provisioning
> >
> > Since I keep bringing this up, it is only fair that I put forth some
> > concrete details. Attached is a rough draft I did this morning for a
> > proposal for using DSML for provisioning. Bear in mind that this is a
> > very rough draft, but I think this gives us a good starting point for a
> > discussion on the issue.
> >
> > --
> > Jeff Bohren
> > Product Architect
> > OpenNetwork Techologies
> > jbohren@opennetwork.com
> > (727) 561-9500x219
>
> --
> Jeff Bohren
> Product Architect
> OpenNetwork Techologies
> jbohren@opennetwork.com
> (727) 561-9500x219
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

--
Jeff Bohren
Product Architect
OpenNetwork Techologies
jbohren@opennetwork.com
(727) 561-9500x219




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


Powered by eList eXpress LLC