On Thu, May 19, 2011 at 4:15 PM, Henry Story <[email protected]> wrote: > > On 19 May 2011, at 14:36, Reto Bachmann-Gmuer wrote: > >> Hello >> >> I've noticed that with the change to principals one can be logged in >> as multiple users. > > To be precise the changes made use of the flexibility of Java's Subject class. > > http://download.oracle.com/javase/6/docs/api/javax/security/auth/Subject.html > > The subject class is designed to allow one to have multiple Principals.
We shouldn't do things just because its possible, we should only implementing things with a beneficial addition to useful possibilities in relation to the added complexity [...] > > So this is not that different from Foaf. We can have multiple identifiers: > social security number, webid, username... These are all inverse functional > properties. That's not as its currently implemented by your code, if one logs in with multiple webids (and the maybe additionally with cookie login) multiple users are created in the system graphs > >> How are applications supposed to deal with this? In >> my wall-applcation and blogging engine I assumes a request originating >> from exactly one user (which can be user anonymous). I know wanted to >> updated my apps and was wondering how to do this. > > What we need is to improve the ways to identify the user so that he can log in > various ways (including openid in the future or facebook connect). > > I think we should do the following. Currently the user is identified in the > graph <http://tpf.localhost/system.graph> > > @prefix perm: <http://clerezza.org/2008/10/permission#> . > @prefix zz: <http://clerezza.org/2009/08/platform#> . > @prefix foaf: <http://xmlns.com/foaf/0.1/> . > > </user/admin/profile#me> > perm:hasPermission [ > perm:javaPermissionEntry "(java.security.AllPermission \"\" \"\")" > ] ; > perm:passwordSha1 "d033e22ae348aeb5660fc2140aec35850c4da997" ; > zz:lastLogin > "2011-05-17T18:03:48.558Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> ; > zz:userName "admin" ; > a foaf:Agent ; > foaf:mbox <mailto:[email protected]> . > > > so here the user has already two identities > - the WebID </user/admin/profile#me> > - the zz:userName "admin" yes, but we used to have just one resource, we now potentially have multiple resources created by the foafssl login module. > > It would be easy to extend this to allow openid by adding the relation > > </user/admin/profile#me> foaf:openid <http://bblfish.net/> . > > The principal can therefore be either: > - the webid > - the openid > - the account name ("admin", "joe",...) > - facebook account, ... > it does not matter. > > What we should do is to create subclasses of Principal (which anyway is just > an interface) > to allow one to distinguish these different types of principals. > > Each principal can then be used to get the resource (bnode or uri) that is the > foaf:Agent, and the zz:userName should be shown if it exists, or some > zz:preferredUserName, which could be set automatically. > > >> The same difficulty occurs with the displayed username in the menu, >> and where the menu-item "control-panel" shall point to. > > It should point to the home page, as now. yes, but what is the "home page" if one can log in as more than one user simultaneously? > > If there are two non fused identities, the user should be asked if he wants > to fuse them, and which he prefers to have as his new home. I suppose one > could also give him the opportunity to log in as one or the other, by > changing a menu. seems a great increase of complexity, what legimitates this? Talking about certs with multiple webids in the specificatioon group is one thing, making thing complex to support this (imho quite exotic) feature is another. > > There is also CLEREZZA-515 "ugly account name when logging into ZZ with a > foreign WebID" > though this would be just as valid for OpenIDs. I don't think this relates two my question, having more than one user logged in is difficult both with nice and with ugly account names. > > I can work on the core auth code change if someone can help me with the UI > piece from there. So the short answer to my question "How are applications supposed to deal with this?" is "you currently can take a user randomly or let the user choose who he wants to be, but in future thing might go back again to one user, as this is handled like inverse functional poperties in foaf" > > Henry > >> >> Reto > > Social Web Architect > http://bblfish.net/ > >
