Next in thread →
Next in month →
RE: [provision] PSO/Account/ProvisionedState
Title: Message "enableDate" and "disableDate" are much more complicated issues that just suspend and restore. Some resources, like Solaris, only support an "expirationDate", working on the assumption that if the account exists it is enabled. Others, like our UIdP accounts, have the equivalent of "enableDate" and "disableDate". Still others support richer notions of controlling repeated "periods of enablement" which reflect a schedule of when an account can be accessed. It's hard to say how much of this should be put in a standard schema. But regardless of how detailed you want to make it, the approach would be the same. A standard base class would be defined that included a logically related set of attributes for which normative behavior would assigned. For instance a "schedulable" base class could be defined that a schedule of when the account is enabled. Jeff Bohren Product Architect OpenNetwork Technologies, Inc Try the industry's only 100% .NET-enabled identity management software. Download your free copy of Universal IdP Standard Edition today. Go to www.opennetwork.com/eval. -----Original Message----- From: Gary Cole [mailto:] Sent: Friday, April 16, 2004 5:54 AM To: Jeff Bohren Cc: Subject: Re: [provision] PSO/Account/ProvisionedState Jeff, did you get this? I keep getting postmaster notifications that my email deliveries to your address failed. I still very much want to understand your approach. Gary ----- Original Message ----- From: Gary Cole To: Jeff Bohren Cc: Sent: Tuesday, April 06, 2004 9:47 AM Subject: RE: [provision] PSO/Account/ProvisionedState Okay so far.... Wouldn't we call the attribute something more specific than "state" (since we've already agreed that there are several kinds of state)? This feels like the "disabled" attribute in PrOM. (Or are you perhaps suggesting that there is only a single "state" attribute, and that the set of interfaces that an object class supports determines the valid set of values for "state"?) Suppose that Win2K supports immediate disablement and Solaris does not. Further suppose that RACF supports *scheduled* enablement and disablement, but that Win2K does not. In PrOM, I proposed three attributes to represent these: "disabled", "enableDate" and "disableDate". How would RACF advertise its support for immediate disablement/enablement AND scheduled disablement/enablement? Gary -----Original Message----- From: Jeff Bohren [mailto:] Sent: Tuesday, April 06, 2004 6:49 AM To: Subject: RE: [provision] PSO/Account/ProvisionedState Take for example two kinds of accounts; Win2K and Solaris accounts. Assuming that both are a kind of account, but Win2K accounts can be suspended and restored, where as Solaris accounts can not (some provisioning system support suspending Solaris accounts via passwords, but for the purpose of this discussion I will assume that is not the case for this PSP). A standard schema might define an object class for account which has the typical uid/password attributes and it might also define an object class for anything (account or otherwise) that can be suspended and restored. For instance the following could be object classes in a standard schema: Account uid password Suspendable state Then a PSP may publish a schema that defines Win2K and Solaris accounts: Win2KAccount : Account, Suspendable SolarisAccount : Account Thus the RA could know a prior what PSOs support suspend and restore semantics. It would be those PSOs that inherit the Suspendable class. BTW, this is all supportable in the SPML 1.0 standard. Jeff Bohren Product Architect OpenNetwork Technologies, Inc -----Original Message----- From: Gary Cole [mailto:] Sent: Monday, April 05, 2004 5:44 PM To: Jeff Bohren Cc: Subject: Re: [provision] PSO/Account/ProvisionedState Jeff, I think the ball's in your court on this one. I'm ready to agree, but I need help imagining what a standard schema for state might look like, and how provisioned object classes would declare the features they support. (Of course, I realize you've been busy writing the Use Cases.) Gary ----- Original Message ----- From: Gary Cole To: Jeff Bohren Cc: Sent: Tuesday, March 30, 2004 10:36 AM Subject: RE: [provision] PSO/Account/ProvisionedState I'm convinced. I see the complexities of "program by exception", I see the elegance of making this schema-dependent, and I see that this kind of elegance has practical value in a network protocol. So what would a "standard" state schema look like? I just need a little help imagining this. Would the standard state schema contain elements or attributes to represent the multiple facets of provisioned object state? How would the schema for each object class specify which facets of provisioned object state it supports? Would the schema for each object class be target-specific? Gary -----Original Message----- From: Jeff Bohren [mailto:] Sent: Tuesday, March 30, 2004 9:09 AM To: Subject: RE: [provision] PSO/Account/ProvisionedState This is essentially the same as the "program by exception" approach that is sometimes used in software development. In most cases the arguments for and against it are more stylistic and philosophical that practical. However since this is a network protocol, not a software API, there a several practical issues that must be addressed: 1) A PSP could legitimately consider setting unsupported status attributes to be an error. In the case of batch requests, this could result in the RA needing to resubmit all or part of the original batch request (if "continue on error" is not specified). 2) From the standpoint of minimizing network traffic, the RA must have a way to determine if a specific PSO supports a specific state attribute. This is a must because if the RA is going to present a set of state options for an authorized user of the RA system, it must be able to present the supported state options for each PSO, not all of them. Fortunately this is easily supported via standard schema. 3) This approach will make status logic more complex. How does the RA differentiate between a successful attempt to change an unsupported attribute versus a failed attempt to change a supported attribute? This all requires extra complexity that is frankly unnecessary. So far no one has brought up any state issues that could not be easily supported in SPML 1.0 with the additional of standard schemas. If we created a standard schema that only addresses account state, the SPML 1.0 could start addressing this issue immediately without even needing SPML 2.0 to be in place. By using SPML 1.0 with a standard "state" schema, the state management would be explicit, efficient, standards based, and available immediately. What more do you want in a network protocol? Jeff Bohren Product Architect OpenNetwork Technologies, Inc -----Original Message----- From: Gary Cole [mailto:] Sent: Tuesday, March 30, 2004 7:02 AM To: Jeff Bohren; Gearard Woods Cc: Subject: Re: [provision] PSO/Account/ProvisionedState Could we discuss the identification attributes for a minute, because I think that sets the stage for the discussion of state attributes? In the email that teed this all up, I wrote: > > To identify the account, Account has "target", "name", > and "guid" attributes. The account is usually associated > with some target, has a name that is changeable, and > may have an internal identifier > that is not supposed to change. > When I say "Account", I think of this as roughly equivalent to "ProvisionedObject". (I realize that not all features of Account apply to every provisioned object, but this doesn't bother me too much because not all features of Account apply to every account. Target accounts all different, but there are also common features.) Not every target supports "guid", but it's common enough (especially among the modern targets) that it's reasonable to model this as a common feature. We can simply leave "guid" null or empty where it is unknown or unsupported. I don't want to leave this "open" (i.e., an entirely arbitrary attribute) because guid is pretty common and very useful in managing the account. Where guid is supported, it is the preferred identifier. It is *very* handy to keep a guid as a native identifier, since this helps in detecting native renames (and distinguishing a 'move' from a 'delete' and an 'add'). Where the target supports some kind of guid, I want to map that value to an attribute that my management code recognizes. I'm guessing that everybody basically buys this premise, because the discussion has centered on the state-related attributes. Here's the part where I step off the ledge... I think of the state-related attributes we've been discussing in the same way: common and useful where supported, harmless and empty if unsupported. For example, it doesn't bother me at all if a particular class of provisioned object doesn't support "disabled", as long as the value that comes back is harmless (e.g., empty or "NOT_SUPPORTED"). It's common enough (not just for accounts, but also for policies and other objects) to add objects disabled and then enable them at a later date. This is such a common aspect of management that I'd prefer to model this explictly as a well-known aspect of state. I'm interested to know what everyone thinks. I'm not sure everyone will agree with this line of reasoning, but if this explains where I'm coming from, then maybe you all can use it to explain things to me. Gary ----- Original Message ----- From: Gary Cole To: Jeff Bohren Cc: Sent: Friday, March 26, 2004 9:32 AM Subject: Re: [provision] PSO/Account/ProvisionedState This sounds interesting. Defining multiple interfaces (as Gerry suggests) sounds like a reasonable way to tease apart the facets that interest some (but not necessarily all) of us. Tying these to a common schema (as Jeff B suggests) seems like a reasonable way to keep the whole thing from flying apart. I need a little more help imagining how we'd structure this. I wanted to define a bunch of common state-related attributes, but Jeff B and others point out that not all of these apply to all types of accounts. Perhaps none of these state-related attributes (beyond "exists") apply to some kinds of provisioned object. I had imagined calling a method like: State getProvisionedState(PSO-ID); For an Account, I'd get back all the attributes that apply: <State psoId='ID' exists='true' disabled='false' disableDate='NONE' enableDate='NONE' expired='false' expireDate='DATE' /> For a provisioned object that supports only "exists", I'd get back only "exists": <State psoId='ID' exists='true'/> But it sounds to me from the discussion above, that I might have to define a different schema for each combination of attributes. Am I right about that, or could 'Stateful' contain our "starter kit" of common state-related attributes? Would each kind of provisioned object have to define in its schema which state-related attributes it supports? Or would I just call a different method (e.g., #listSupportedStateAttributes)? Or could I figure this out just from the set of attributes returned by #getProvisionedState(PSO-ID)? Sorry if I'm misunderstanding your suggestion. If so, perhaps we should talk offline (rather than email everyone). Gary ----- Original Message ----- From: Jeff Bohren To: Gearard Woods ; Jeff Larson Cc: Gary Cole ; Sent: Thursday, March 25, 2004 7:51 PM Subject: RE: [provision] PSO/Account/ProvisionedState I would not be opposed to having mulitple provisioning interfaces, provided it was tied to a standard schema that normatively defined what interfaces where appropriate for what object classes. The clients still need to know what interfaces would apply to what PSOs. For example the SPML core operations could apply to all object classes but the SPML state operations may only apply to an object class that inherits from a "Stateful" object class in a standard schema (note that SPML 1.0 supports multiple inheritance so this is easy). This way the schema for the resource does not even need to extend an abitrary "Account" schema, it merely needs to extend the "Stateful" schema. Jeff Bohren OpenNetwork -----Original Message----- From: Gearard Woods [mailto:] Sent: Thu 3/25/2004 6:01 PM To: Jeff Larson Cc: Gary Cole; Jeff Bohren; Subject: RE: [provision] PSO/Account/ProvisionedState I agree that granularity of the calls is important and it really shouldn't take 42 calls to determine the state of an object - a single call should suffice. I think we can model state effectively and still minimize the traffic needed to manage it. Jeff (Jeff B) has also raised the slippery slope argument, and my take on it is that we should provide an interoperable way to do the things we feel are a core part of the provisioning process. There is a line here between what is horizontal to provisioning and what is resource-specific. State management is obviously important and passwords have come up before, although Jeff B would argue that state is not even relevant to most resources and is only applicable to accounts. The provisioning process is obviously not the same thing to all people. We have disagreement even down to the fundamentals of the provisioning model. Perhaps a way to tackle these different viewpoints is to divide and conquer. Imagine that we split up the problem into a number of interfaces: SPML core - Basic provision (add), deprovision (delete), modify, list/search SPML state - An interface and schema representing state management (lifecycle included or separate?) SPML events - An interface and schema for event notifications SPML password - Password management perhaps SPML relationships - TBD Implementors must publish core to be SPML compliant. They may then in turn overlay any of the other interfaces to offer enhanced provisioning capabilities. These would be simple interfaces with minimal schema but would be complementary and all take advantage of the core schema. Vendors who deal with directory-style interfaces need go no further than the core interface while others may wish to offer the full suite. Obviously these categories are just off the top of my head but does this sound like an approach that has promise? Gerry ' src="gif00034.gif" width=16>"Jeff Larson" <> "Jeff Larson" <> 03/25/2004 02:20 PM To: Gearard Woods/Irvine/IBM@IBMUS, "Jeff Bohren" <> cc: "Gary Cole" <>, <> Subject: RE: [provision] PSO/Account/ProvisionedState I haven't been following this that closely, but I like aspects of both approaches. I like the notion that you can carry out near-universal operations like disable, enable, and expire, in a schema independent way. But I also like the notion that I can at least obtain the current state from the model so I don't have to make 42 web services calls to get everything I want to display. I guess as long as the schema is arbitrary we can have it both ways. If I choose to use fine grained standard operations I can. If the PSP exposes the same functionality through the model, I can use that too, though I will be outside of the SPML spec. But we're on a slippery slope here. Almost every account will have an associated password, email address, and full name. Do we then provide individual operations to get and set those so we can access them in an standard way without having to be bothered with PSP specific schema? How far does this go? Jeff -----Original Message----- From: Gearard Woods [mailto:] Sent: Thursday, March 25, 2004 3:35 PM To: Jeff Bohren Cc: Gary Cole; Subject: RE: [provision] PSO/Account/ProvisionedState I think there's a fundamental difference here even though the intent may be the same. Basically, we're all trying to model state and provide some kind of standardized view of it to the outside world so that we can offer interoperability. By placing state in the resource schema you have immediately abandoned the possibility that arbitrary resource schema may be supported, which I believe to be important. You are also now requiring a mapping from the "standard" schema to the real resource schema. On the other hand, by placing the emphasis on the service provider and providing an operational interface to effect state changes, the provider can now apply its knowledge of the resource to make the state change however it wishes to do so and places no restrictions on the resource schema. Gerry
Next in thread →
Next in month →