[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] SPML identifier issues for the interop ...
I'm not sure about the other vendors, but for our product the problem is two-fold. First the identifier should be unique for it to be a valid add request. Secondly, the uid (or login id) should also be unique so if the user wants to see that he can use his supplied uid/password combination to access a protected web site, or login into our User Management web application, it will work. I suppect that the other vendors would have similar problems if two add requests are made with the same uid. Would either user then be able to log into their product? Or would only one be able to log in? This would be an error in our product, even if the identifiers are unique. Jeff Bohren OpenNetwork Technologies -----Original Message----- From: Yoav Kirsch [mailto:Yoav.Kirsch@businesslayers.com] Sent: Wed 6/11/2003 6:56 PM To: 'Cohen, Doron '; Jeff Bohren; 'provision@lists.oasis-open.org ' Cc: Subject: RE: [provision] SPML identifier issues for the interop ... This should be the RA responsibity if the RA send the indentifier. For the interop we should assume that the RA will create a unique identifier either by using People Soft ID or by custom code writen on the RA Yoav -----Original Message----- From: Cohen, Doron To: Jeff Bohren; provision@lists.oasis-open.org Sent: 6/11/03 5:33 PM Subject: RE: [provision] SPML identifier issues for the interop ... Wouldn't it be fair to assume that PSFT has a unique identifier for employee that can be used (since the HR system itself needs to distinguish between two employees with the same name) ? -----Original Message----- From: Jeff Bohren [mailto:jbohren@opennetwork.com] Sent: Wednesday, June 11, 2003 11:11 PM To: provision@lists.oasis-open.org Subject: RE: [provision] SPML identifier issues for the interop ... The problem is what if two users named John Smith both use the common RA. For the first one there is no problem. For the second one, a request will be made to add a user with the GUID of an already existing user. For our system that is an error and the second add request will fail. Since we are not supporting status, the second user won't know why his user ID/password combination that he entered will not allow him to log onto our system. Now I could add special logic to make true GUID out of the GUID passed to our system to get around this, but since all of the PSPs should have similar issues, it makes sense to solve this in one place (the common RA). Can the common RA be configured to make sure that the CN is not reused? It would probably be a good idea to make sure the uid is not reused as well, if possible. We could also set the GUID id to the uid instead of the CN and just make sure that the uid is unique. BTW, if you think having two CNs the same is unlikely, what if one user wants to run through the demo twice from two different vendors? Jeff Bohren Product Architect OpenNetwork Technologies, Inc -----Original Message----- From: Kevin Boyce [mailto:kevin.boyce@entrust.com] Sent: Wednesday, June 11, 2003 3:56 PM To: Jeff Bohren; provision@lists.oasis-open.org Subject: RE: [provision] SPML identifier issues for the interop ... it would be nice if the RA generated unique ids for the duration of the demo but since we are not supporting status or any other requests for the interop, it should not functionally matter -----Original Message----- From: Jeff Bohren [mailto:jbohren@opennetwork.com] Sent: June 11, 2003 12:59 PM To: provision@lists.oasis-open.org Subject: [provision] SPML identifier issues for the interop ... For the interop we are using the SPML add request where the identifier is specified. Therefor the RA must ensure that the specified identifier is unique. In the examples in the interop spec the GUID identifier type is used with the user's CN as the guid. Obviously the CN is not guaranteed to be unique. I would suggest that we either use the email identifier (would require users to enter their real email) or we use the GUID identifier with an autogenerated GUID. Jeff Bohren Product Architect OpenNetwork Technologies, Inc You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgroup.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]