[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] CA will be participating in the SPML v2 Interoperability Event - A few question (Looking for Responses) are inline in the message
|
Comments below…
-----Original Message-----
** Posting on behalf of CA Development Team** - Look for some responses…
Thank you very much for explaining, Jeff. Could you please see inline for my further comments? Regards,
Van Bui eTrust, Computer Associates Melbourne, Australia
-----Original Message-----
CA will be participating in the SPML v2 Interoperability Event
** Posting on behalf of CA Development Team** - Look for some responses…
Hi all,
Our team recently began working on migrating some of the components in the Computer Associates eTrust IAM Suite from SPML V1 to supporting the V2 of the specification. We would be very interested in participating in the upcoming Interop event by providing both an RA and PSP.
I have some questions from beginning to work with the V2 specification that do not seem especially clear at this stage. Is anyone able to shed some light on them? 1. I gather that with the open content model, a requestor or a provider can specify additional operational attributes when issuing and responding to SPML requests via the “any” elements. Similarly, we can store any implementation specific metadata information about the DSML attributes, assuming that the provisioning schema is represented in the DSMLv2 Profile schema, in the “any” elements. But IMHO, the “permission” metadata, which can be set to either read-only, write-only, or read-write, is a common and useful metadata information that can be included as an optional attribute of an <dsmlprofile:attributeDefinitionReference> element. What do you think?
[JSB] The problem is that in some cases the “permission” is not part of the metadata but is part of policies with respect to the identity of the requestor. In other words an attribute may be read-only to a client with one set of permissions but be read-write to a client is a different set.
[Van] I wasn’t thinking about those attributes that were access-controlled by some policy. I was thinking about the scenarios where the “permission” is a static metadata, for example: · The “password”, or “biometrics” attributes is generally write-only; · ‘Virtual’ attributes are always read-only. These are attributes are computed (by the PST/PSP) from other attributes. · Attributes that are only set by the PST/PSP such as lastLoginTime, badPasswordCount, or creationTime, etc... are also read-only. If this information is made available in the provisioning schema then each client won’t need to have local knowledge about how to deal with the data. However, as I said, “permission” and other metadata information can always be set via the open content model – so this issue can now be closed.
2. Is there a way for a provider to declare that it only supports a selected number of operations in one of the standard capabilities?
[JSB] No. It is assumed such cases are handled by exception rather than declaration.
3. Why does an AddRequest have a separated “targetID” and “containerID” field while these fields are capable of being set as part of the “psoID”?
[JSB] SPML 2.0 supports both flat and hierarchical data models. If a hierarchical data model is used, then a new PSO can be added to the root target or to an existing container. Since the container specifies the target it exists on, the add request can specify either the target or the container.
[Van] Section 3.2.3 of the draft 10 of the specification states that a "PSO Identifier must be unique [snip] within the namespace of the provider", which I've interpreted as "A valid PSO Identifier must uniquely identify an object managed by the provider". For hierarchical targets, this is achieved by combining the targetID, containerID, and the object's ID in a PSO Identifier. This leads me to think that the targetID and containerID in an AddRequest are extraneous. For the same reason, it is not necessary to include a separate targetID field in a SearchQueryType because this can be set as part of the basePsoID.
If I've misunderstood and there is indeed a need for being able to specify targetID, containerID, as well as psoID in an AddRequest then shouldn't this also be applied for the Modify, Delete, Lookup requests, and all the different request types of the Suspend, Active capabilities? (As of draft 24 of the XSDs, one can only set the psoID fields for these requests).
[JSB] Add requests can be made in the following manner:
1) A new PSO can be created without a container (flat mode or creation of a root node under a target). In this case the target ID is required. The PSO ID may be passed instead of the ID if the service allows the client to specify the PSO. 2) A new PSO can be created with a container. The containing PSO ID is required, but the target is not. The PSO ID may be passed instead of the ID if the service allows the client to specify the PSO.
4. The “modificationMode” attribute of an <spmlcore:modification> element at the moment doesn’t have a default value. Should the default it to “replace”-mode to make things clearer?
[JSB] There should be a default. Replace would seem to be the logical choice.
5. Do you think that there should be a standard way for the requestor to request the provider to return the list of affected PSO’s when performing a bulkModify or a bulkDelete operation? The Add and Modify operations already support this.
[JSB] Such a mechanism already exists. Simply supply the same search query in a search request, specifying that only the PSO ID should be returned. That would return the list of PSO IDs that would be affected by the appropriate bulk operation. This of course assumes the service that supports the bulk capability also supports the search capability.
[Van] After the search request was performed and before the bulk operation is processed, there is always the possibility that the target (system) might be modified externally by a different requestor, therefore, the list of PSOs returned from the search request might not reflect accurately what would actually be affected by the bulk operation.
[JSB] Yes, that’s true. It would be true with any approach that attempts to solve the problem. What a client asks the question “what would be affected if I do X” that always means “what would be affected if I do X at this moment”. There is no other way it could work.
6. How do I store the list of sub-requests in a BatchRequest? I can’t see it in the new Schema.
[JSB] The sub-request for a batch operation are included via the open content model. See the SPML 2.0 Specification document for examples.
[Van] Do you think it is more restrictive and is at the same time easier to use (compared with using the open content model) if it was explicitly specified that a BatchRequest can contain: <element name="batchRequests" type="spml:RequestType" minOccurs="1" maxOccurs="unbounded"/> …and a BatchResponse can contain: <element name="batchResponses" type="spml:ResponseType" minOccurs="1" maxOccurs="unbounded"/>
[JSB] This alternative was considered and rejected. There is no advantage to doing this way and it is more complicated. Also there was the concern that the type=”spml:RequestType” syntax may not be as widely supported by XML schema tools.
The reason that there is no advantage to that approach is the because the Open Content Model is used (for other reasons), there is no way to restrict what elements can be sub elements of a BatchRequest, regardless of how you structured the XSDs.
There is one important point here. The SPML specification is NOT defined by the XSDs. The XSDs are merely a convenience. The SPML specification is defined by the specification document. If the type=”spml:RequestType” syntax is preferable to you, go ahead and modify your local copy of the XSDs to do it that way. The spec won’t change.
7. The Updates Capability seems like a useful operation, and there is an XSD for it, but there is no mention about it in the draft 9 of the specifications, can someone please explain why?
[JSB] That is an oversight. Thank you for pointing it out. I will touch base with Gary about this.
By the way, we are using draft 24 of the XSD. Thanks for your help.
Van Bui eTrust, Computer Associates Melbourne, Australia
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]