incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Story <>
Subject Re: Logged in as multiple users, how should application deal with this new feature?
Date Thu, 19 May 2011 16:36:37 GMT
Thanks for bringing this up. I was hoping someone would push me to think
about this at some point, so that we could have a more in depth discussion.

On 19 May 2011, at 16:52, Reto Bachmann-Gmuer wrote:

> On Thu, May 19, 2011 at 4:15 PM, Henry Story <> 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.
>> 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

The point is that you need multiple principals in the current world. This
is so clear that the Java Community that has gone through a standardisation process
with the requirements of a large number of players in mind has worked this out in
detail and even written it out clearly in all their documentation. So this is a 
standardised problem.  Let's be happy that we are using such a well thought out
language and are not having to re-invent all these solutions ourselves.

And if we are going to work on the web there is just no other way to do things.
People are going to be able to login with OpenId, with passwords, or with other
means. Being able to have multiple logins can increase security.

> [...]
>> 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

Well the first thing is that you end up with is multiple Principals. What is needed
is a UI to allow users to merge those principals, or a UI to select from one or the
other. This is in fact a cool thing in that you can see that someone logged in twice 
and allow them to merge. Let's be happy when the semantic web gives us benefits for 
free. :-)

Ok more below...

>>> 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: <> .
>> @prefix zz: <> .
>> @prefix foaf: <> .
>> </user/admin/profile#me>
>>    perm:hasPermission [
>>        perm:javaPermissionEntry "( \"\" \"\")"
>>    ] ;
>>    perm:passwordSha1 "d033e22ae348aeb5660fc2140aec35850c4da997" ;
>>    zz:lastLogin "2011-05-17T18:03:48.558Z"^^<>
>>    zz:userName "admin" ;
>>    a foaf:Agent ;
>>    foaf:mbox <> .
>> 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.

You have multiple URIs and one resource. That is what owl:sameAs is for,
or what merging and smushing is for. Logging in with multiple ids is a
a proof of an owl:sameAs relation.

So then you allow people to merge. That is what the semantic web is so good
at. For the moment we have a quite simple scenario to help us think about things.
We have cookie and WebID.

>> It would be easy to extend this to allow openid by adding the relation
>> </user/admin/profile#me> foaf:openid <> .
>> 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?

I think we need to look at this case by case.

1. User has Username (only) 

We know how to deal with that

For one a user cannot login I think with one cookie and a different user name. I think 
when you login with user name the cookie is automatically set to go with it. 

So the main case we have is the user logging in with WebID and a username.

2. User logs in with WebID

(let's forget the issue of multiple WebIDs currently. We can look at that later)

Currently we don't have a satisfactory home page for the user logging in with a WebID without
a username.  As shown in CLEREZZA-515 it is something like 


That was a good thing to get something going, but is not a good solution, and we should
fix it. Especially as it would not be improved by the option of the same user then logging
with an openid, or with any of the many other options. ((Btw, I think it is because openid
people are not using the semantic web that they are having trouble solving this issue. We
are a lot further ahead here, and just need to think about it.))

I think that the user who logs in with a WebID without a username, should not have a home
page, but only a profile page that shows him what we know about him. Something like:

( I think that is what we are in fact doing - a WebId logged in user does not have an account.

If that person does something local where we wish to keep some state then we put that in the
graph for the webid. 

So if the system then wants to allow the remote user to sore local information about the user
where would he put it? Perhaps here?


But that may just be app dependent. I suppose it would be nice for the remote webid user to
able to get a quick list of all blog comments he posted. That should go there.

2.1 User then links to an account

What such a page can do is ask the user to associate that webid with an existing account 
or create an account. In either case the following relations for a user named "joe" will the

</user/joe/profile#me> zz:userName "joe";
            owl:sameAs <> .

3. User logs in with Multiple WebIDs

  This is not going to be a big issue, and I don't think we need to work hard
on it, as there will not be a big need for this. But it is good to think of it ahead
of time a bit.

3.1 without a user account

  So it's the same as with one webid. The the user graph would just be the merger of the two.
And either URL could be selected. 

3.2 with a user account

   The the user account is the main graph and the WebId principals are just tied to the user
like this.

</user/joe/profile#me> zz:userName "joe";
            owl:sameAs <>, <>


So I think the conclusion of this is just that people only have a home page if they
have asked for it. 

>> 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.

Well part of the reason I can work on this here is that this helps me work
on things over there. So I am willing to deal with the added complexity.

>> There is also  CLEREZZA-515 "ugly account name when logging into ZZ with a foreign
>> 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.

Well it is an issue I want to solve anyway. Now that you have brought this up, we
might as well tie this in, so I can work on it.

>> 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"

Does the above detailing help? 
Perhaps you can describe your needs more precisely too. 

Are you satifisfied with the one webid solution? I think that is what we have currently,
except that we need to decide what the home page of a webid only user is.


>> Henry
>>> Reto
>> Social Web Architect

Social Web Architect

View raw message