[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [provision] A Proposal for using DSML for Provisioning
I agree with Tony. I feel that DSML might not fit in however we can use DSML attribute value convention and XML format. I took the first use case and tried to make it more SPML oriented Use Case 1: RA-PSP: Create PSU The RA generates a unique PSU-ID and adds that PSU to a PSP. This could be implemented using the DSML AddRequest (in batch mode for multiple PSUs). The PSU-ID would be the DN and all initial data for the PSU would be passed as attribute values. For example to add a user John Smith conforming to InetOrgPerson: <se:Envelope xmlns:se="http://schemas.xmlsoap.org/soap/envelope/";> <se:Body xmlns="urn:oasis:names:tc:DSML:2:0:core"> <batchRequest xmlns="urn:oasis:names:tc:DSML:2:0:core" xmlns:xsd="http://www.w3.org/2001/XMLSchema";> <addRequest dn="uid=jsmith,o=acme.com"> <attr name="objectClass"> <value>inetorgperson</value> </attr> <attr name="cn"> <value>John Smith</value> </attr> </addRequest> </batchRequest> </se:Body> </se:Envelope DSML identifies the entry using the 'dn' attribute. The 'dn' is mandatory for directories and makes sense in this arena. However we cannot force all SPML application to be directory base. We cannot assume the RA keep'dn' repositories. DSML is one transaction synchronize client server protocol. Where the client request directory operation and get Success fail result. SPML is more complicated protocol since the provisioning request is asynchronies. The SPML client side should be able to query and modify its existing request. To enable this the SPML client (RA in this scenario) should get some transaction id back from the server. I do not know if DSML support these functions. RA should ask for future provisioning for example add the user two days from today. Again I do not see how DSML naturally support this function. I suggest the following format where we use DSML as the provisioning data layers but add few more sections to the XML <se:Envelope xmlns:se="http://schemas.xmlsoap.org/soap/envelope/";> <se:Body xmlns="urn:oasis:names:tc:SPML:2:0:core"> <batchRequest xmlns="urn:oasis:names:tc:DSML:2:0:core" xmlns:xsd="http://www.w3.org/2001/XMLSchema";> <addRequest > <VirtualID> <attr name="givenname"> <value>John</value> </attr> <attr name="sn"> <value>Smith</value> </attr> </VirtualID> <TransctionInfo Id= "78776"> <attr name="TargetDate"> <value>27-Aug-2002</value> </attr> </ TransctionInfo> <ResourceInfo rescource = 'MyApplication"> <attr name="login"> <value>JSmith</value> </attr> <attr name="AccessRight"> <value>Read</value> </attr> <attr name="Disable"> <value>False</value> </attr> </ResourceInfo> </addRequest> </batchRequest> </se:Body> </se:Envelope So we basically keep the DSML attributes name value convention and add SPML specific information tags and sections. Yoav -----Original Message----- From: Tony Gullotta [mailto:TGullotta@access360.com] Sent: Friday, July 26, 2002 2:56 PM To: 'jbohren@opennetwork.com' Cc: provision@lists.oasis-open.org Subject: RE: [provision] A Proposal for using DSML for Provisioning I like DSML, but I'm afraid that all by itself, there may be some small points that won't fit in completely. For example, requesting a service passing only the type of service you are subscribing for, then in the result message sent back later, the PSP would provide the subscriber his user id, password, etc. I'm not sure if DSML accounts for an interaction like that. Do you think we can cover these fringe requirements with DSML alone? Maybe DSML can be used more as a format for payload information that we can wrap with a more provisioning flexible operational protocol? Tony -----Original Message----- From: jbohren@opennetwork.com [mailto:jbohren@opennetwork.com] Sent: Friday, July 26, 2002 10:37 AM To: mpolan@ca.ibm.com Cc: provision@lists.oasis-open.org 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 ---------------------------------------------------------------- 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC