[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [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** Jeff, Thank you very much for
answering my questions. I have to confess that I haven’t read the specs
carefully so in question 3 I did not think of the situation where the Requestor
is not allowed to provide a full psoID in an Add Request. But things are much
clearer now. As for question 5, I was
asking if a bulk response can return the list of PSO’s that WERE affected
by the bulk operation, which is essential for client-side auditing and
monitoring. If the answer is ‘no’, then I guess that we will just
add a custom operation for this functionality. Thanks again for your
help. I really appreciate it. Van Bui eTrust, Computer
Associates -----Original 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 -----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 By the way, we are using draft 24 of the
XSD. Thanks for your help. Van Bui eTrust, Computer Associates |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]