Comments below…
-----Original Message-----
From: Sodhi, Gavenraj S
[mailto:]
Sent: Sunday, June 26, 2005 11:51
PM
To:
Cc: Bui, Van A
Subject: RE: [provision] CA will
be participating in the SPML v2 Interoperability Event - A few question
(Looking for Responses) are inline in the 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-----
From: Sodhi, Gavenraj S
[mailto:]
Sent: Friday, June 24, 2005 7:01
PM
To:
Subject: [provision] CA will be
participating in the SPML v2 Interoperability Event - A few question (Looking
for Responses) are inline in the 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
