| Re: [higgins-dev] CUID re-use (was something else) |
|
Sorry, I wasn't making the case for a requirement, just providing the use case :)
My guess is that eventually both will be desired. We may need to add the notion of a perma-cuid. Depending on the CP, this may be the same as the regular CUID. Some CP's may choose to throw NotImplementedException when asked for a perma-cuid.
Jim >>> Greg Byrd <gbyrd@xxxxxxxx> 8/15/06 4:42 PM >>> OK, good example. Would this application expect this same behavior from any garden-variety Context? Or is this a good reason to choose a particular Context implementation -- one that guarantees the no-reuse property? (Or perhaps this property is the responsibility of the back-end data source, which is not necessarily under the control of the context provider?) I'm still not convinced this is a required property of all Contexts. In my classroom scenario, what distinguishes a student is the fact that she's sitting in B7. But there will be a different student there an hour from now. I could use the NCSU context and attach a seat number attribute to a particular student during this class, but my application will be much more efficient if I can easily refer to B7 instead of searching the NCSU context for a particular classroom+seat number attribute. ...Greg Jim Sermersheim wrote: > >>> Greg Byrd <gbyrd@xxxxxxxx> 8/15/06 3:02 PM >>> > >In what scenario is the CUID of an IDigitalSubject used to grant > >permissions? > Here's a use case which illustrates this, as well as the need to > perform a "whoami", re-authenticate, and compare attributes at a > sub-value level (we have applications that do this kind of thing all > the time). > > Assume a DigitalSubject represents a role. That DS has an attribute > called "roleMember", and is populated with the CUIDs of other DS's > which are members of this role. Now assume an application that a > military officer uses to launch missiles. The officer logs into the > application with username and password. The application in turn > attempts to open the context containing the role using the officer's > presented name/pw. If this succeeds, the application performs calls > the (not yet agreed upon) "whoami" method to obtain the officer's > CUID. The application then re-opens the same context using it's own > identity and calls IContext.verifySubjectAttributes() asserting that > the officer's CUID is part of the "roleMember" attribute in the role > DS. If it is, the officer is allowed to launch missiles. > > Other scenarios will follow. The IdAS data model does not include an > access control model, so people will have to make up their own. one > way of doing access control is to add DS relationships like (my wife > has access to my bank account number) where "my wife" is really my > wife's CUID. > > Jim > ------------------------------------------------------------------------ > > _______________________________________________ > higgins-dev mailing list > higgins-dev@xxxxxxxxxxx > https://dev.eclipse.org/mailman/listinfo/higgins-dev > _______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev |