[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
On the other hand, if the requestor is logging in to the requestor
and re-setting password, then I'd say that this is another setPasswordRequest:
<setPasswordRequest>
<psoID ID="27" targetID="Sun-Interop-DSML"/>
<password>setByUser</password>
</setPasswordRequest>
Again, the only difference in the XSD profile is the targetID.
<setPasswordRequest>
<psoID ID="27" targetID="Sun-Interop-XSD"/>
<password>setByUser</password>
</setPasswordRequest>
Again, the provider returns a minimal response (success or failure).
<setPasswordResponse status=“success"/>
|4. DA Grants Role Use Case
|--------------------------
|The DA grants a role to the previously provisioned user.
|The user then logs into the application.
|The application should somehow reflect the rights granted to the user via the new role membership.
<comment>
This use case requires the requestor to modify a reference.
I suppose that the user could actually log in to the application,
but it's not obvious how the application should reflect the rights granted
(and even less obvious how this could be reflected to a programmatic client).
Why doesn't the requestor simply use the 'lookup' operation
to verify that the role reference has been added?
(For that matter, the default value of returnData for modifyRequest
should ensure that the provider returns "everything"....)
</comment>
Before a requestor can add a reference to a role,
the requestor must make sure that the role exists.
The requestor could always add a role,
but it might be better to try a searchRequest first.
Actually, I'm not sure how to search for roles.
Would it look something like this?
<searchRequest>
<spmlsearch:query targetId="Sun-Interop-DSML" scope="spmlsearch:subTree">
<dsml:filter>
<dsml:equalityMatch name="objectClass">
<dsml:value>role</dsml:value>
</dsml:equalityMatch>
</dsml:filter>
</spmlsearch:query>
</searchRequest>
<searchResponse>
<pso>
</pso>
[...]
[<iterator id="iter01">]
</searchResponse>
I doubt we'll actually find enough roles on anyone else's provider
to require an iterator, but as a requestor
we should be prepared to iterate results.
<iterateRequest>
<iterator ID="iter01">
</iterateRequest>
The provider's response to an iterateRequest
has the same structure as a searchResponse.
<iterateResponse>
<pso>
</pso>
<iterator ID="iter02">
</iterateResponse>
We should also call closeIterator when we are done.
<closeIteratorRequest>
<iterator ID="iter02">
</closeIteratorResponse>
The provider's response is minimal:
<closeIteratorResponse status="success"/>
NOTE: For the purposes of this Interop, we don't care much
about the closeIteratorResponse (we did our best).
In real life we'd probably log any failure.
If the SearchCapability is not supported,
or if we can search but do not find a role,
a requestor can always add one:
<addRequest targetID="Sun-Interop-DSML">
<data>
<spmldsml:attr name="objectClass">
<value>role</value>
</spmldsml:attr>
<spmldsml:attr name="cn">
<value>Role1</value>
</spmldsml:attr>
<spmldsml:attr name="description">
<value>SPML2 Interop Role</value>
</spmldsml:attr>
</data>
</addRequest>
NOTE: I'm not sure exactly how you specify the objectClass
in the DSML profile. If you don't do it somehow, the provider
won't know which type of object you want to add....
In the XSD profile, that addRequest might look like:
<addRequest targetID="Sun-Interop-XSD">
<data>
<role cn="Role1">
<description>SPML2 Interop Role</description>
</role>
</data>
</addRequest>
We don't care much about the data coming back in the addResponse.
If we want, we can specify "returnData='identifier'" in the addRequest
(since that is all we really care about).
<addResponse>
<psoID ID="28" targetID="Sun-Interop-DSML"/>
<data>
<spmldsml:attr name="objectClass">
<value>role</value>
</spmldsml:attr>
<spmldsml:attr name="cn">
<value>Role1</value>
</spmldsml:attr>
<spmldsml:attr name="description">
<value>SPML2 Interop Role</value>
</spmldsml:attr>
</data>
</addResponse>
In the XSD profile, mainly the data would differ:
<addResponse>
<psoID ID="28" targetID="Sun-Interop-DSML"/>
<data>
<role cn="Role1">
<description>SPML2 Interop Role</description>
</role>
</data>
</addResponse>
Once the role exists (and we have its ID),
the requestor can add to the account a reference to that role.
<modifyRequest>
<psoID ID="27" targetID="Sun-Interop-DSML">
<modification modificationMode=”add”>
<capabilityData>
<reference typeOfReference="roles" >
<toPsoID ID="28" targetID=“Sun-Interop-DSML”/>
</reference>
</capabilityData>
</modification>
</modifyRequest>
By default, the provider's modifyResponse should return the entire PSO
(including capabilityData). The data will look different in each profile,
but the capabilityData will have the same structure in either profile.
<modifyResponse status="success">
<pso>
<psoID ID="27" targetID="Sun-Interop-DSML">
<data>
<spmldsml:attr name="objectClass">
<value>account</value>
</spmldsml:attr>
<spmldsml:attr name="cn">
<value>Joe Bob</value>
</spmldsml:attr>
<spmldsml:attr name="uid">
<value>joebob</value>
</spmldsml:attr>
</data>
<capabilityData>
<reference typeOfReference="roles"
<toPsoID ID="28" targetID="Sun-Interop-DSML"/>
</reference>
</capabilityData>
</pso>
</modifyResponse>
In the XSD profile, that modifyResponse might look like:
<modifyResponse status="success">
<pso>
<psoID ID="27" targetID="Sun-Interop-XSD">
<data>
<account cn="Joe Bob" uid="joebob" />
</data>
<capabilityData>
<reference typeOfReference="roles"
<toPsoID ID="28" targetID="Sun-Interop-XSD"/>
</reference>
</capabilityData>
</pso>
</modifyResponse>
NOTE: The modifyResponse in this case should not modify the <psoID>,
but anytime we issue a modifyRequest we should be prepared to
handle a modifyResponse that indicates the <psoID> has changed.
If we really wanted to double-check, we'd use a lookupRequest.
<lookupRequest>
<psoID ID="27" targetID="Sun-Interop-DSML">
</lookupRequest>
or
<lookupRequest>
<psoID ID="27" targetID="Sun-Interop-XSD>
</lookupRequest>
Unless we specify returnData attribute in the lookupRequest,
the provider's response will include everything.
In the DSML profile, this might look like:
<lookupResponse status="success">
<pso>
<psoID ID="27" targetID="Sun-Interop-DSML">
<data>
<spmldsml:attr name="objectClass">
<value>account</value>
</spmldsml:attr>
<spmldsml:attr name="cn">
<value>Joe Bob</value>
</spmldsml:attr>
<spmldsml:attr name="uid">
<value>joebob</value>
</spmldsml:attr>
</data>
<capabilityData>
<reference typeOfReference="roles"
<toPsoID ID="28" targetID="Sun-Interop-DSML"/>
</reference>
</capabilityData>
</pso>
</lookupResponse>
or, in the XSD profile:
<lookupResponse status="success">
<pso>
<psoID ID="27" targetID="Sun-Interop-XSD">
<data>
<account cn="Joe Bob" uid="joebob" />
</data>
<capabilityData>
<reference typeOfReference="roles"
<toPsoID ID="28" targetID="Sun-Interop-XSD"/>
</reference>
</capabilityData>
</pso>
</lookupResponse>
|5. DA Deprovision Use Case
|--------------------------
|The DA will deprovision the provisioned user.
This could be either a delete or a disable.
Disable would require the SuspendCapability.
To keep it simple, I assume this is a deleteRequest:
<deleteRequest>
<psoID ID="27" targetID="Sun-Interop-DSML"/>
</deleteRequest>
or
<deleteRequest>
<psoID ID="27" targetID="Sun-Interop-XSD"/>
</deleteRequest>
Provider's response is minimal (success/failure):
<deleteResponse status=“success"/>
|6. Administrator Reconciliation Use Case
|----------------------------------------
|A user will be locally added to the application.
|The Administrator will then invoke a reconciliation of the application.
|The recently added user will be discovered via the reconciliation.
<comment>
I don't understand the Administrator Reconciliation Use Case.
Sun's IDM has something it calls "reconciliation", but that involves
comparing the accounts that IDM *expects* to find on a resource
with what IDM *actually* finds on a resource.
In this case, if we're using the PSP as the 'application',
then a locally-added user would be expected.
When you say "reconciliation", do you mean some kind of search
(e.g., for recently-added accounts)? If it's a search for unexpected accounts,
where does the set of expected accounts come from?
Also, how would a requestor add a user to the application (but not the PSP)
without going through the PSP? If the provider is supposed to add a user
to the application locally, how will the provider know when to do this
(if not in response to some request from the requestor)?
</comment>
Orthogonal stuff
----------------
1) We should probably specify requestID on every request.
If we specify 'requestID', the provider MUST return
the same requestID in the response.
2) Error-handling. Punt on everything but status="success"
(except perhaps in a case where we *expect* a failure,
but I'm not writing test suites here, so forget it).
--Boundary_(ID_7l9nhaWrMwrgDNonLHPxRQ)--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]