[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D302113914-30032004><FONT face=3DArial color=3D#0000ff =
size=3D2>3)=20
This approach will make status logic more complex. How does the RA =
differentiate=20
between a successful attempt to change an unsupported attribute versus a =
failed=20
attempt to change a supported attribute?</FONT></SPAN></DIV>
<DIV><SPAN class=3D302113914-30032004><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D302113914-30032004><FONT face=3DArial color=3D#0000ff =
size=3D2>This=20
all requires extra complexity that is frankly unnecessary. So far no one =
has=20
brought up any state issues that could not be easily supported in SPML =
1.0 with=20
the additional of standard schemas. If we created a standard schema that =
only=20
addresses account state, the SPML 1.0 could start addressing this issue=20
immediately without even needing SPML 2.0 to be in place. =
</FONT></SPAN></DIV>
<DIV><SPAN class=3D302113914-30032004><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D302113914-30032004><FONT face=3DArial color=3D#0000ff =
size=3D2>By=20
using SPML 1.0 with a standard "state" schema, the state management =
would be=20
explicit, efficient, standards based, and available immediately. What =
more do=20
you want in a network protocol?</FONT></SPAN></DIV>
<DIV> </DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Jeff Bohren</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Product =
Architect</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>OpenNetwork Technologies,=20
Inc</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV align=3Dleft>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D666091017-20102003><STRONG>Try the=20
industry's only 100% .NET-enabled identity management software.=20
Download your free copy of Universal IdP Standard Edition today. Go =
to=20
</STRONG><A=20
href=3D"http://www.opennetwork.com/eval";><STRONG>www.opennetwork.com/eval=
</STRONG></A><STRONG>.</STRONG></SPAN></FONT></DIV></DIV>
<DIV align=3Dleft> </DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> Gary =
Cole=20
[mailto:gary.cole@waveset.com] <BR><B>Sent:</B> Tuesday, March 30, =
2004 7:02=20
AM<BR><B>To:</B> Jeff Bohren; Gearard Woods<BR><B>Cc:</B>=20
provision@lists.oasis-open.org<BR><B>Subject:</B> Re: [provision]=20
PSO/Account/ProvisionedState<BR><BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Could we discuss the identification =
attributes=20
for a minute, because I think that sets the stage for the discussion =
of state=20
attributes?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>In the email that teed this all up, I =
wrote:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3>> To=20
identify the account, Account has "target", =
"name",</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3>> and=20
"guid" attributes. The account is usually =
associated</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman"=20
size=3D3>> with some target, has a name that is changeable,=20
and</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3>> may=20
have an internal identifier </FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3>> that is=20
not supposed to change. </FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman"=20
size=3D3>></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial=20
size=3D2></FONT></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>When I say "Account", I think of this =
as roughly=20
equivalent to "ProvisionedObject". (I realize that not all =
features=20
of Account apply to every provisioned object, but this doesn't =
bother me=20
too much because not all features of Account apply to every =
account. =20
Target accounts all different, but there are also common=20
features.)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Not every target supports "guid", but =
it's common=20
enough (especially among the modern targets) that it's reasonable to =
model=20
this as a common feature. We can simply leave "guid" null or =
empty where=20
it is unknown or unsupported.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I don't want to leave this=20
"open" (i.e., an entirely arbitrary=20
attribute) because guid is pretty common and very =
useful in=20
managing the account. Where guid is supported, it is the =
preferred=20
identifier. It is *very* handy to keep a guid as a native =
identifier,=20
since this helps in detecting native renames (and distinguishing a =
'move' from=20
a 'delete' and an 'add'). Where the target supports some kind of =
guid, I=20
want to map that value to an attribute that my management code=20
recognizes.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial=20
size=3D2></FONT></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I'm guessing that everybody basically =
buys this=20
premise, because the discussion has centered on the state-related=20
attributes. Here's the part where I step off the =
ledge...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I think of the state-related =
attributes we've=20
been discussing in the same way: common and useful where supported, =
harmless=20
and empty if unsupported. </FONT><FONT face=3DArial size=3D2>For =
example, it=20
doesn't bother me at all if a particular class of provisioned object =
doesn't=20
support "disabled", as long as the value that comes back is harmless =
(e.g.,=20
empty or "NOT_SUPPORTED"). </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>It's common enough (not just for =
accounts,=20
but also for policies and other objects) to add =
objects disabled and=20
then enable them at a later date. This is such a common aspect =
of=20
management that I'd prefer to model this explictly as a well-known =
aspect of=20
state.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I'm interested to know what =
everyone=20
thinks. I'm not sure everyone will agree with this line of =
reasoning,=20
but if this explains where I'm coming from, then maybe you all can use =
it to=20
explain things to me.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Gary<BR></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV=20
style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
<A title=3Dgary.cole@waveset.com =
href=3D"mailto:gary.cole@waveset.com";>Gary=20
Cole</A> </DIV>
<DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Djbohren@opennetwork.com=20
href=3D"mailto:jbohren@opennetwork.com";>Jeff Bohren</A> </DIV>
<DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A=20
title=3Dprovision@lists.oasis-open.org=20
=
href=3D"mailto:provision@lists.oasis-open.org";>provision@lists.oasis-open=
.org</A>=20
</DIV>
<DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, March 26, 2004 =
9:32=20
AM</DIV>
<DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: [provision]=20
PSO/Account/ProvisionedState</DIV>
<DIV><BR></DIV>
<DIV><FONT face=3DArial size=3D2>This sounds =
interesting. Defining=20
multiple interfaces (as Gerry suggests) sounds like a reasonable way =
to=20
tease apart the facets that interest some (but not necessarily all) =
of=20
us. Tying these to a common schema (as Jeff B suggests) seems =
like a=20
reasonable way to keep the whole thing from flying =
apart.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I need a little more help =
imagining how=20
we'd structure this. I wanted to define a bunch of common=20
state-related attributes, but Jeff B and others point out that not =
all of=20
these apply to all types of accounts. Perhaps none of these=20
state-related attributes (beyond "exists") apply to some kinds of=20
provisioned object.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I had imagined calling a method=20
like:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> State=20
getProvisionedState(PSO-ID);</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>For an Account, I'd get back all =
the attributes=20
that apply:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> <State =
psoId=3D'ID'=20
exists=3D'true' disabled=3D'false' disableDate=3D'NONE' =
enableDate=3D'NONE'=20
expired=3D'false' expireDate=3D'DATE' /></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>For a provisioned object that =
supports only=20
"exists", I'd get back only "exists":</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> <State =
psoId=3D'ID'=20
exists=3D'true'/></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>But it sounds to me from the =
discussion above,=20
that I might have to define a different schema for each combination =
of=20
attributes. Am I right about that, or could 'Stateful' contain =
our=20
"starter kit" of common state-related attributes?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Would each kind of provisioned =
object have=20
to define in its schema which state-related attributes it supports?=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Or would I just call a different =
method (e.g.,=20
#listSupportedStateAttributes)? </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Or could I figure this out =
just from=20
the set of attributes returned by=20
#getProvisionedState(PSO-ID)?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Sorry if I'm misunderstanding=20
your suggestion.</FONT> <FONT face=3DArial size=3D2> If =
so,=20
perhaps we should talk offline (rather than email=20
everyone).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Gary</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style=3D"FONT: 10pt arial">----- Original Message ----- =
</DIV>
<DIV=20
style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
<A title=3Djbohren@opennetwork.com=20
href=3D"mailto:jbohren@opennetwork.com";>Jeff Bohren</A> </DIV>
<DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dgewoods@us.ibm.com=20
href=3D"mailto:gewoods@us.ibm.com";>Gearard Woods</A> ; <A=20
title=3DJeff.Larson@waveset.com =
href=3D"mailto:Jeff.Larson@waveset.com";>Jeff=20
Larson</A> </DIV>
<DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=3DGary.Cole@waveset.com=20
href=3D"mailto:Gary.Cole@waveset.com";>Gary Cole</A> ; <A=20
title=3Dprovision@lists.oasis-open.org=20
=
href=3D"mailto:provision@lists.oasis-open.org";>provision@lists.oasis-open=
.org</A>=20
</DIV>
<DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Thursday, March 25, =
2004 7:51=20
PM</DIV>
<DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: [provision]=20
PSO/Account/ProvisionedState</DIV>
<DIV><BR></DIV>
<DIV>I would not be opposed to having mulitple provisioning =
interfaces,=20
provided it was tied to a standard schema that normatively defined =
what=20
interfaces where appropriate for what object classes. The clients =
still=20
need to know what interfaces would apply to what PSOs.</DIV>
<DIV> </DIV>
<DIV>For example the SPML core operations could apply to all =
object=20
classes but the SPML state operations may only apply to an object =
class=20
that inherits from a "Stateful" object class in a standard schema =
(note=20
that SPML 1.0 supports multiple inheritance so this is easy). This =
way the=20
schema for the resource does not even need to extend an abitrary =
"Account"=20
schema, it merely needs to extend the "Stateful" schema. =
</DIV>
<DIV> </DIV>
<DIV>Jeff Bohren</DIV>
<DIV>OpenNetwork</DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV><FONT size=3D2>-----Original Message----- <BR><B>From:</B> =
Gearard=20
Woods [mailto:gewoods@us.ibm.com] <BR><B>Sent:</B> Thu 3/25/2004 =
6:01 PM=20
<BR><B>To:</B> Jeff Larson <BR><B>Cc:</B> Gary Cole; Jeff =
Bohren;=20
provision@lists.oasis-open.org <BR><B>Subject:</B> RE: =
[provision]=20
PSO/Account/ProvisionedState<BR><BR></FONT></DIV>
<P>I agree that granularity of the calls is important and it =
really=20
shouldn't take 42 calls to determine the state of an object - a =
single=20
call should suffice. I think we can model state effectively and =
still=20
minimize the traffic needed to manage it. <BR><BR>Jeff (Jeff B) =
has also=20
raised the slippery slope argument, and my take on it is that we =
should=20
provide an interoperable way to do the things we feel are a core =
part of=20
the provisioning process. There is a line here between what is=20
horizontal to provisioning and what is resource-specific. State=20
management is obviously important and passwords have come up =
before,=20
although Jeff B would argue that state is not even relevant to =
most=20
resources and is only applicable to accounts. <BR><BR>The =
provisioning=20
process is obviously not the same thing to all people. We have=20
disagreement even down to the fundamentals of the provisioning =
model.=20
Perhaps a way to tackle these different viewpoints is to divide =
and=20
conquer. Imagine that we split up the problem into a number of=20
interfaces:<BR><BR>SPML core - Basic provision (add), =
deprovision=20
(delete), modify, list/search<BR>SPML state - An interface and =
schema=20
representing state management (lifecycle included or =
separate?)<BR>SPML=20
events - An interface and schema for event notifications<BR>SPML =
password - Password management perhaps<BR>SPML relationships -=20
TBD<BR><BR>Implementors must publish core to be SPML compliant. =
They may=20
then in turn overlay any of the other interfaces to offer =
enhanced=20
provisioning capabilities. These would be simple interfaces with =
minimal=20
schema but would be complementary and all take advantage of the =
core=20
schema. Vendors who deal with directory-style interfaces need go =
no=20
further than the core interface while others may wish to offer =
the full=20
suite. Obviously these categories are just off the top of my =
head but=20
does this sound like an approach that has=20
promise?<BR>Gerry<BR><BR><BR><IMG height=3D16=20
alt=3D'Inactive hide details for "Jeff Larson" =
<Jeff.Larson@waveset.com>'=20
src=3D"cid:302113914@30032004-095F"; width=3D16>"Jeff Larson"=20
<Jeff.Larson@waveset.com><BR><BR><BR>
<TABLE cellSpacing=3D0 cellPadding=3D0 width=3D"100%" =
border=3D0>
<TBODY>
<TR vAlign=3Dtop>
<TD width=3D"1%"><IMG height=3D1 alt=3D""=20
src=3D"cid:302113914@30032004-0966"; width=3D72 =
border=3D0><BR></TD>
<TD style=3D"BACKGROUND-REPEAT: no-repeat" width=3D"1%"><IMG =
height=3D1=20
alt=3D"" src=3D"cid:007e01c41347$89877c20$1559aacf@col"; =
width=3D225=20
border=3D0><BR>
<UL>
<UL>
<UL>
<UL><B><FONT size=3D2>"Jeff Larson"=20
<Jeff.Larson@waveset.com></FONT></B>=20
<P><FONT size=3D2>03/25/2004 02:20=20
PM</FONT></P></UL></UL></UL></UL></TD>
<TD width=3D"100%"><IMG height=3D1 alt=3D""=20
src=3D"cid:007e01c41347$89877c20$1559aacf@col"; width=3D1=20
border=3D0><BR><FONT face=3DArial =
size=3D1></FONT><BR><FONT size=3D2>To:=20
</FONT><FONT size=3D2>Gearard Woods/Irvine/IBM@IBMUS, =
"Jeff Bohren"=20
<jbohren@opennetwork.com></FONT><BR><FONT =
size=3D2>cc:=20
</FONT><FONT size=3D2>"Gary Cole" =
<Gary.Cole@waveset.com>,=20
<provision@lists.oasis-open.org></FONT><BR><FONT=20
size=3D2>Subject: </FONT><FONT size=3D2>RE: [provision]=20
=
PSO/Account/ProvisionedState</FONT></TD></TR></TBODY></TABLE><BR><BR><FON=
T=20
face=3DArial color=3D#0000ff>I haven't been following this that =
closely, but=20
I like aspects of both approaches. I like</FONT><BR><FONT =
face=3DArial=20
color=3D#0000ff>the notion that you can carry out near-universal =
operations like disable, enable, and expire, </FONT><BR><FONT =
face=3DArial=20
color=3D#0000ff>in a schema independent way. But I also like the =
notion=20
that I can at least obtain the current state</FONT><BR><FONT =
face=3DArial=20
color=3D#0000ff>from the model so I don't have to make 42 web =
services=20
calls to get everything I want to display.</FONT><BR><FONT=20
size=3D4></FONT><BR><FONT face=3DArial color=3D#0000ff>I guess =
as long as the=20
schema is arbitrary we can have it both ways. If I=20
choose</FONT><BR><FONT face=3DArial color=3D#0000ff>to use fine =
grained=20
standard operations I can. If the PSP exposes the same=20
functionality</FONT><BR><FONT face=3DArial =
color=3D#0000ff>through the=20
model, I can use that too, though I will be outside of the SPML=20
spec.</FONT><BR><FONT size=3D4></FONT><BR><FONT face=3DArial=20
color=3D#0000ff>But we're on a slippery slope here. Almost every =
account=20
will have an associated</FONT><BR><FONT face=3DArial=20
color=3D#0000ff>password, email address, and full name. Do we =
then provide=20
individual operations</FONT><BR><FONT face=3DArial =
color=3D#0000ff>to get=20
and set those so we can access them in an standard way without =
having to=20
be</FONT><BR><FONT face=3DArial color=3D#0000ff>bothered with =
PSP specific=20
schema? How far does this go?</FONT><BR><FONT =
size=3D4></FONT><BR><FONT=20
face=3DArial color=3D#0000ff>Jeff</FONT><BR><FONT =
size=3D4></FONT><BR><FONT=20
size=3D4></FONT><BR><FONT size=3D4></FONT><BR><FONT=20
face=3DTahoma>-----Original Message-----</FONT><B><FONT=20
face=3DTahoma><BR>From:</FONT></B><FONT face=3DTahoma> Gearard =
Woods [<A=20
=
href=3D"mailto:gewoods@us.ibm.com";>mailto:gewoods@us.ibm.com</A>]=20
</FONT><B><FONT face=3DTahoma><BR>Sent:</FONT></B><FONT =
face=3DTahoma>=20
Thursday, March 25, 2004 3:35 PM</FONT><B><FONT=20
face=3DTahoma><BR>To:</FONT></B><FONT face=3DTahoma> Jeff=20
Bohren</FONT><B><FONT face=3DTahoma><BR>Cc:</FONT></B><FONT =
face=3DTahoma>=20
Gary Cole; provision@lists.oasis-open.org</FONT><B><FONT=20
face=3DTahoma><BR>Subject:</FONT></B><FONT face=3DTahoma> RE: =
[provision]=20
PSO/Account/ProvisionedState<BR></FONT>
<P><FONT size=3D4>I think there's a fundamental difference here =
even=20
though the intent may be the same. Basically, we're all trying =
to model=20
state and provide some kind of standardized view of it to the =
outside=20
world so that we can offer interoperability. By placing state in =
the=20
resource schema you have immediately abandoned the possibility =
that=20
arbitrary resource schema may be supported, which I believe to =
be=20
important. You are also now requiring a mapping from the =
"standard"=20
schema to the real resource schema. On the other hand, by =
placing the=20
emphasis on the service provider and providing an operational =
interface=20
to effect state changes, the provider can now apply its =
knowledge of the=20
resource to make the state change however it wishes to do so and =
places=20
no restrictions on the resource schema. <BR>Gerry<BR></FONT>
<HR>
<P><<pic13953.gif>>=20
</P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
=00
------_=_NextPart_002_01C41668.EC166689--
------_=_NextPart_001_01C41668.EC166689
Content-Type: image/gif;
name="graycol.gif"
Content-Transfer-Encoding: base64
Content-ID: <302113914@30032004-095F>
Content-Description: graycol.gif
Content-Location: graycol.gif
R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu
ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7
------_=_NextPart_001_01C41668.EC166689
Content-Type: image/gif;
name="ecblank.gif"
Content-Transfer-Encoding: base64
Content-ID: <302113914@30032004-0966>
Content-Description: ecblank.gif
Content-Location: ecblank.gif
R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7
------_=_NextPart_001_01C41668.EC166689--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]