You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@clerezza.apache.org by Reto Bachmann-Gmuer <re...@apache.org> on 2011/05/19 14:36:30 UTC
Logged in as multiple users, how should application deal with this
new feature?
Hello
I've noticed that with the change to principals one can be logged in
as multiple users. 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.
The same difficulty occurs with the displayed username in the menu,
and where the menu-item "control-panel" shall point to.
Reto
Re: Logged in as multiple users, how should application deal with this new feature?
Posted by Henry Story <he...@bblfish.net>.
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 <he...@bblfish.net> 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
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: <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 <ma...@clerezza.org> .
>>
>>
>> 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 <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?
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
/user/http___bblfish.net_people_henry_card_me/...
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 in
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:
/remote?webid=
( 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?
urn:x-localinstance:/remote?webid={webid}
But that may just be app dependent. I suppose it would be nice for the remote webid user to be
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
appear.
</user/joe/profile#me> zz:userName "joe";
owl:sameAs <http://joe.name/#me> .
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 <http://joe.name/#me>, <http://apache.org/people/joe#me> .
Conclusion
----------
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 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.
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
>
>
>>
>> Henry
>>
>>>
>>> Reto
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>>
Social Web Architect
http://bblfish.net/
Re: Logged in as multiple users, how should application deal with
this new feature?
Posted by Reto Bachmann-Gmuer <re...@trialox.org>.
On Thu, May 19, 2011 at 4:15 PM, Henry Story <he...@bblfish.net> 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 <ma...@clerezza.org> .
>
>
> 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/
>
>
Re: Logged in as multiple users, how should application deal with this new feature?
Posted by Henry Story <he...@bblfish.net>.
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.
From the documentation
[[
A Subject represents a grouping of related information for a single entity, such as a person. Such information includes the Subject's identities as well as its security-related attributes (passwords and cryptographic keys, for example).
Subjects may potentially have multiple identities. Each identity is represented as a Principal within the Subject. Principals simply bind names to aSubject. For example, a Subject that happens to be a person, Alice, might have two Principals: one which binds "Alice Bar", the name on her driver license, to the Subject, and another which binds, "999-99-9999", the number on her student identification card, to the Subject. Both Principals refer to the same Subject even though each has a different name.
]]
So this is not that different from Foaf. We can have multiple identifiers: social security number, webid, username... These are all inverse functional properties.
> 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 <ma...@clerezza.org> .
so here the user has already two identities
- the WebID </user/admin/profile#me>
- the zz:userName "admin"
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.
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.
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 can work on the core auth code change if someone can help me with the UI piece from there.
Henry
>
> Reto
Social Web Architect
http://bblfish.net/