Date: Thu, 28 Mar 2024 13:17:26 +0000 (UTC)
Message-ID: <543252025.6449.1711631846381@ip-10-10-7-29.ec2.internal>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_6448_6770600.1711631846380"
------=_Part_6448_6770600.1711631846380
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
Interim Report Items
Interim Report Items
Interim Report Notes from the OSIdM4HE Provisioning Su=
bcommittee
- Provisioning Is Critical We remain convinced that prov=
isioning is a critical capability of an effective IdM stack for higher ed, =
and that its scope extends not only to moving information between component=
s of the stack (although that may be very important to provide for) but als=
o to moving information between the stack and external, connected systems.<=
/li>
- Primary Goal Is Consistency We seem to have settled, r=
oughly, on the idea that the primary function of a provisioning facility is=
to produce and maintain, through the lifecycle of a provisionable resource=
, consistency between that resource's representation in some source facilit=
y (which we expect in this case to be a registry, although we would look to=
the Registry group to consider questions of whether a single registry or s=
ome form of logical meta-registry is appropriate). We have some commitment =
to the concept of "consistency" rather than "synchronization", largely in r=
ecognition of the possibility that a target system may represent a resource=
differently than the source system but may still need its representation t=
o reflect the same semantic content as the source system. (We are working o=
n developing a more formal definition of this notion of consistency, now).<=
/li>
- Provisioning Scope Extends Beyond Just People We seem =
convinced that a successful IdM stack will scope its provisioning mechanism=
(s) in a way that allows for provisioning not only of traditional person id=
entities but also of other classes of identity-related or identity-dependen=
t resources =E2=80=93 groups, roles, privileges, etc. As to whether actual =
delivery of provisioning features unique to non-person entities is critical=
for an initial offering or not, I don't think we're as certain, but the ge=
neral timber of our discussions seems to have led to including non-person o=
bjects and their attributes in the collection of resources a good provision=
ing system should be capable of manipulating.
- Provisioning Needs to Minimize Latency we're confident=
that a successful provisioning facility will ensure, to the extent that an=
y technology can under possibly varying conditions of performance and avail=
ability, that inconsistencies between source and target systems introduced =
when source data (again, typically in a registry) changes will be resolved =
in target systems with a minimum of latency, and that under routine circums=
tances, target systems' representations will be kept consistent far more of=
the time than they are inconsistent.
- Provisioning Needs to Include Repair We recognize that=
in pursuit of low-latency, there may be times at which "incremental" provi=
sioning fails to meet the standard for on-average consistency above, and th=
at at certain boundaries (such as the inception of a new provisioning facil=
ity, a new target facility, or a new connection between existing provisioni=
ng facilities and target facilities) there may be a need to instantiate con=
sistency between sources and targets without the aid of "triggering" change=
s in the source facilities. As such, we note that any complete provisioning=
solution must surely include support for the notion of a "full resync" or =
"reconcile and repair" process by which inconsistencies introduced through =
error or architectural change may be addressed without the introduction of =
synthetic "events" in source systems.
- Provisioning Should Embrace More Than One Mode Of Operation Items (4) and (5), I think we've determined, can be achieved in a num=
ber of different ways, each well-suited to different classes of provisionin=
g scenario (enterprise, federated, and "cloud", for example) and sometimes =
to different strategic goals ("just in time" versus "just in case") and dif=
ferent consumer strategies ("push" versus "pull", etc.). So far, I don't th=
ink we've necessarily ruled out any of the options for implementation as ei=
ther infeasible or unable to provide value under any conditions, so I don't=
know that we can identify any specific mix of options as "the" solution st=
rategy. To some extent, that may be a matter for the developers to weigh in=
on as much as for us to consider at this point in the process. That said, =
I think we have a general sense that given the possible spread of target ca=
pabilities that may be encountered, it may not be possible to select exactl=
y one collection of strategic positions (eg., to say that the provisioning =
facility need only support "just in case, push" provisioning). We are likel=
y to instead need to aim for a "spanning set" of interoperable tools and pr=
ocesses that collectively address the needs identified in the use cases we =
choose (with the wider effort) to address.
- Provisioning Facilities Must Support Multiple Sources and Targe=
ts A well-designed provisioning facility needs to have the capacit=
y to support a wide range of target or connected systems. It seems reasonab=
le that we might focus our efforts on or even limit our efforts to the OSId=
M4HE provisioning facility consuming information from OS4IdM4HE registries,=
rather than from external "authoritative" sources. The provisioning facili=
ty, however, should employ a well-documented and well-specified interface f=
or interacting with its data source(s)/registries, that should be well-impl=
emented in its initial release =E2=80=93 should other sources be deemed imp=
ortant in specific deployments, there should be support for developers' use=
of those same standard interfaces. In essence, I suspect we'd advocate pus=
hing the responsibility for supporting multiple source systems onto the reg=
istry, standardizing on a single (preferably open-standard) consumer interf=
ace for the provisioning facility that's negotiated with the registry devel=
opers, and making support for a variety of "downstream" provisioning consum=
ers the greater focus of the OSIdM4HE provisioning effort. (Note: to the ex=
tent to which the Registry effort may lead to the production of multiple so=
urce registries, and/or the access management effort may produce a separate=
source for provisionable privilege information, we would propose that all =
intended provisioning sources plan to write to an agreed upon standard inte=
rface that the provisioning facility can implement).
- Provisioning Target Flexibility Through Standardization As much as possible, I think we'd like to try and accomplish target flexi=
bility through implementation of standards-based interfaces for provisionin=
g target systems. We have reviewed a number of existing and nascent provisi=
oning standards, and would note that the SAML Change Notification work seem=
s very promising (as evidenced by Google's stated support of the effort), a=
s does SCIM (which has the advantage of a lively and actively open developm=
ent community). Where "high impact" target systems (read: GoogleApps, Sakai=
, etc.) can be identified, we'd advocate trying to negotiate support from t=
hem for standard provisioning interfaces. Likewise, where our community con=
trols high-visibility target systems (Grouper, CoManage, Kuali, etc.).
- Provisioning Should Exhibit the Pattern "Standards at the Core =
and on the Wire, Customization at the End Points" While we recogni=
ze that there are going to be intractable target cases, some of which are l=
ikely to be of critical importance to some or all of our community, we woul=
d support the notion that customization of "adapters" should be the provinc=
e of those target systems, and that their adapters should target a standard=
s-based interface provided by the provisioning facility, rather than target=
ing a specific provisioning facility implementation directly. To the extent=
that some targets may be more easily adapted to one standard for provision=
ing than another, we would support the long-term goal of providing a "spann=
ing set" of standards-based provisioning interfaces.
------=_Part_6448_6770600.1711631846380--