RE: [provision] Question about targets and PSOs...

["Gary Cole" <Gary.Cole@waveset.com>]

Title: Message

Okay, I think I see where we are diverging.  I think of the PSO-ID, target, name, and guid as separate attributes of an Account.  A "white box" PSP would allow the RA to see any or all of these; a "black box" PSP might expose only PSO-ID. I tend to think of the PSO-ID as opaque in either case.

 

As long as PSO-ID always works (e.g., as a reference), can we let the PSP decide whether to expose the friendlier identifiers ("target" and at least one of "name" or "guid")?

 

I like IDs to be unique, opaque, and immutable.  (Along that line, a Target may need to have both an ID and a name, so that it can be renamed without invalidating references.)  An account can always be renamed, either through the PSP or natively. 

 

If an RA passes target name and account name to identify an account, either or both of those could have been renamed, so the values could be stale.  On the other hand, if an RA passes a PSO-ID that uniquely identifies an account to the PSP, that should work more reliably.  If the account was renamed through the PSP, then the PSP will be able to map the PSO-ID to the current name.  If the account was renamed natively, the PSP may be able to map the PSO-ID to guid (if the target supports it).  A PSP that injects PSO-ID into account objects may be able search for the account.  The PSP can use PSO-ID to find the account (e.g., by mapping it to target+name|guid) rather than relying on the RA to pass all the necessary identifiers.

 

Gary

-----Original Message-----
From: Jeff Bohren [mailto:jbohren@opennetwork.com]
Sent: Wednesday, March 24, 2004 1:38 PM
To: provision@lists.oasis-open.org
Subject: RE: [provision] Question about targets and PSOs...

I was not think of the Black Box case at all. Of course for a Black Box PSP, the PSO ID could be considered opaque. It is only for White Box PSPs that the PSO ID can not be opaque. Think about a White Box PSP with the following targets:

 

Target 1: Master Record, or User Account

Target 2: Resource A

Target 3: Resource B

 

No suppose that the RA presents a UI to the user that allows him to find a specific User Account and show the resources that it has been provisioned to it. The PSP may return to the user the following PSOs:

 

Target 1, User 1

    owns: Target 2, Account 1

    owns: Target 3, Account 1

Target 2, Account 1

Target 3, Account 1

 

Since Targets 1, 2, and 3 all have unique schemas, the RA needs to know that "Target 2, Account 1" means "Account 1" on "Target 2" so that it can use the Target 2 schema in intelligently render "Target 2, Account 1".

 

This is all totally idependent on how "Target 2, Account 1" is acutally implemented by the PSP.

 

 

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:Gary.Cole@waveset.com]
Sent: Wednesday, March 24, 2004 1:03 PM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Question about targets and PSOs...

I think I follow you, and I think I mostly agree, but I want to be careful.  I may be splitting hairs, or we may actually be thinking of this differently.

 

Yes, for a PSP to go find the actual account on a target, the PSP must know "target" and an identifier that is meaningful to the target.  That identifer can be "name" or "guid" (if the target supports guid).

 

I was thinking that an RA might not know "target", "name", or "guid".  I was thinking that a "black box" PSP might just return an opaque identifier (SPML-ID/PSO-ID) for an account.  The PSP could then map this opaque identifier to "target" and {"name"|"guid"} when necessary. 

 

I'm not really hung up on this; I guess it's just the way I was thinking about it (and my preference for opaque identifiers). 

 

So, how would a reference to a provisioned object (such as an account) look?

  <Account target='T' name='N' [guid='G'] />

 

That makes sense to me for a "white box" PSP, but might not a "black box" PSP prefer the following?

  <Account psoId='P' />

 

If I'm an RA and I really want to determine the target and name or guid, I'd call getProvisionedObject('P') and inspect the Account object:

  <Account target='T' name='N' guid='G' exists='true' disabled='false' ... />

 

I guess the difference was that I was thinking of the PSO-ID as meaningful primarily to the PSP, and not necessarily meaningful to the RA or to the target.  How different is this from what you were thinking?

 

Gary

-----Original Message-----
From: Jeff Bohren [mailto:jbohren@opennetwork.com]
Sent: Wednesday, March 24, 2004 11:12 AM
To: provision@lists.oasis-open.org
Subject: RE: [provision] Question about targets and PSOs...

I mostly agree with that, except for the opaque part. If you make the assumptions:

 

1) targets are explicitly represented in SPML 2.0

2) PSOs are provisioned to targets

3) references to other PSOs are explicitly represented in SPML 2.0

4) those references to other PSOs can span multiple targets

 

Then that leads to the conclusion that the reference, whether it is part of the PSO identifier or not, should not be opaque. For a variety of reasons a RA might need to know what PST that referenced PSO was provisioned to.

 

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:Gary.Cole@waveset.com]
Sent: Wednesday, March 24, 2004 11:51 AM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Question about targets and PSOs...

Fair enough; let's take this on.

 

I agree that relationships between provisioned objects should be able to span targets.  In your example, a master record refers to other ("connector-specific") provisioned objects. I would expect the master record to refer to those provisioned objects by PSO-ID, but I don't have a problem with the master record also containing target identifiers.

 

I usually prefer for identifiers (like SPML Identifier) to be immutable, so I try to think of them as opaque.  I guess that the identifier for a provisioned object *could* contain a reference to the target, but I'd probably prefer for the provisioned object to keep any reference to the target *separate*.

 

Does this make sense?

-----Original Message-----
From: Jeff Bohren [mailto:jbohren@opennetwork.com]
Sent: Wednesday, March 24, 2004 9:51 AM
To: provision@lists.oasis-open.org
Subject: RE: [provision] Question about targets and PSOs...

Gary,

 

One more bit of clarification, this is also a ramification of requirement 4.9 in version 4 of the SPML rquirements doc:

 

1.1.   SPML V2 must allow for the representation of relationships between provisioned objects for request and response data elements.  This needs to work for the data as part of the request/response and also as part of any operational attributes.

 

We have agreed to support a representation of relationships between provisioned objects. When objects are provisioned  to a specific target, can the mechanism that represents that relationship span targets, or is it limited to other provisioned objects in the same target? It seems that it should span targets.

 

This mechanism may or may not depend on the PrOM, depending on how it is accomplished. We currently have an SPML identifier that is used to identify all provisioned objects. If the SPML Identifier is extended to incldude the notion of the target that contains the provisioned object the the PrOM could use the SPML Identifier when references to other objects are needed.

 

By all means, let's start a thread on account and state issues. That should be very interesting. BTW, there has been a lot of interesting discussions of state transition on the WSDM group. I would encourage everyone to look at what that TC has done is this area.

 

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:Gary.Cole@waveset.com]
Sent: Wednesday, March 24, 2004 10:31 AM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Question about targets and PSOs...

That is an interesting question, but I'm not sure I'm ready to tackle it.  AFAIK, we do not yet define (or even recommend) any schema for a PSO.  Do we?

 

PrOM proposed some attributes for an "Account" class (and I think of Account as PSO), but PrOM is just a strawman.  The strawman also proposed some attributes for a "User" class (and I think of "User" as comparable to the "master record") that included references to Account instances.

 

I'd like to discuss PSO/Account/ProvisionedState.  Maybe it's time to tee that one up....

 

Gary

-----Original Message-----
From: Jeff Bohren [mailto:jbohren@opennetwork.com]
Sent: Wednesday, March 24, 2004 9:10 AM
To: provision@lists.oasis-open.org
Subject: [provision] Question about targets and PSOs...

 

Interesting question:

 

Can (or should) a PSO provisioned to one target be able to reference a PSO provisioned to another target? Can (or should) this reference be explict by defining the target ID and the PSO ID withen the target, or implicit by using an PSO ID naming convention that indicates what the target should be? It seems to me that this should be possible and should be explicit.

 

The specific case I am thinking about is a White Box PSP where the PSP master record (provisioning system user identity) is a PSO on a target that represents the underlying provisioning system. If the PSP wants to expose the semantics of the provisioning system user identity owning the provisioned accounts, then the PSO for the target representing the master record would need references to PSOs in targets representing the provisioned resources.

 

 

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.