5:50 a.m.
It seems that openid is moving along. Maybe f9 can integrate openid as an
SSO solution?
http://lwn.net/Articles/255774/
10:01 a.m.
On Thu, 2007-11-08 at 06:50 -0500, Neal Becker wrote:
It seems that openid is moving along. Maybe f9 can integrate openid
as an
SSO solution?
http://lwn.net/Articles/255774/
Certainly an interesting concept, but that would pull us way too far
into the Internet space (as opposed to local or even private domain
space). How would an openid user map to Linux in terms of UID? Would a
uid be assigned on a local machine? On the domain (if the machine the
person is logging into happens to be a part of a bigger network)? Does
the OpenID spec have provisions for account authorization and
information? There are still some UNIX-y things needed by current
distributions that we have to find solutions for.
OTOH, it ties well with the Gnome Online Desktop idea, once you get past
(or provide for) the things that traditional Unix accounts need. It
would do well on truly public kiosks where authorization can be some
public default and accounting based in OpenID.
I was going to try my hand at writing an OpenID PAM module, but found a
project already started on google
(http://code.google.com/p/pam-openid/ ) It's linked to from these blogs:
http://kveton.com/blog/2006/12/10/openid-pam/ and
http://yablog-gary.blogspot.com/2007/10/openid-pam-and-apache.html .
According to one site, they had some discussion going, but the posts
were lost or yanked.
At any rate, I'll play around with the idea and post results there.
--
Richi Plana
10:42 a.m.
A question for the fedora folks: in terms of libraries, what should I
use in pam modules for:
a) string processing & manipulation support (glib?)
b) Network access (specifically HTTP and HTTPS)
c) Diffie-Hellman Key Exchange
Some have multiple implementations and I'm wondering if there are any
that are considered a "core" part of any Fedora installation. By
"core",
I really just mean something that's most likely to be installed by even
the most stripped-down version of Fedora.
--
Richi Plana
On Thu, 2007-11-08 at 09:01 -0700, Richi Plana wrote:
On Thu, 2007-11-08 at 06:50 -0500, Neal Becker wrote:
> It seems that openid is moving along. Maybe f9 can integrate openid as an
> SSO solution?
>
> http://lwn.net/Articles/255774/
Certainly an interesting concept, but that would pull us way too far
into the Internet space (as opposed to local or even private domain
space). How would an openid user map to Linux in terms of UID? Would a
uid be assigned on a local machine? On the domain (if the machine the
person is logging into happens to be a part of a bigger network)? Does
the OpenID spec have provisions for account authorization and
information? There are still some UNIX-y things needed by current
distributions that we have to find solutions for.
OTOH, it ties well with the Gnome Online Desktop idea, once you get past
(or provide for) the things that traditional Unix accounts need. It
would do well on truly public kiosks where authorization can be some
public default and accounting based in OpenID.
I was going to try my hand at writing an OpenID PAM module, but found a
project already started on google
(http://code.google.com/p/pam-openid/ ) It's linked to from these blogs:
http://kveton.com/blog/2006/12/10/openid-pam/ and
http://yablog-gary.blogspot.com/2007/10/openid-pam-and-apache.html .
According to one site, they had some discussion going, but the posts
were lost or yanked.
At any rate, I'll play around with the idea and post results there.
--
Richi Plana
11:54 a.m.
On Thu, 2007-11-08 at 09:01 -0700, Richi Plana wrote:
Certainly an interesting concept, but that would pull us way too far
into the Internet space (as opposed to local or even private domain
space). How would an openid user map to Linux in terms of UID? Would a
uid be assigned on a local machine? On the domain (if the machine the
person is logging into happens to be a part of a bigger network)? Does
the OpenID spec have provisions for account authorization and
information? There are still some UNIX-y things needed by current
distributions that we have to find solutions for.
We have the problem of UIDs in the enterprise space right now even
without OpenID in the mix.
The problem being Posix and Linux/UNIX really are not "network-aware"
when it comes to identity.
The UID/GID are *local* by nature. All tricks used up today like NIS and
LDAP to sync UIDs/GIDs all over, are just *bad* hacks.
There are only 2 solutions that have a long term breath.
1. move to 128bit UID/GIDs that are really UUIDs
problem is, most apps wont work, need changes in the kernel, in a
word:
unachievable
2. Make UIDs/GIDs *only* a local thing.
this mean changes in the vfs only, you need a mapping facility so that
you can translate them for (network) file systems.
For network file systems it is probably easier.
I expect preconcept opposition for normal filesystems tho. But that is
needed too, because if you want to use an USB pen drive or external
disk, or even an iSCSI partition you need to be able to map a UUID
stored on the filesystem to the local UID that make sense for the kernel
and all existing applications, or you are back requiring all machines in
the world synchronize with your own machines UIDs and GIDs.
/Simo "I do not except anything but a flame from this email" sadly.
12:03 p.m.
On Thu, 2007-11-08 at 12:54 -0500, Simo Sorce wrote:
1. move to 128bit UID/GIDs that are really UUIDs
problem is, most apps wont work, need changes in the kernel, in a
word:
unachievable
2. Make UIDs/GIDs *only* a local thing.
this mean changes in the vfs only, you need a mapping facility so that
you can translate them for (network) file systems.
3. Ignore UIDs as an implementation detail of the local OS, and use
situation-specific logic to Do The Right Thing.
For example, if I copy/restore my /home directory on a remote server and
then sync it back to a new install, and the current UID happens to be
different because Fedora changes UIDs to start with 700 in Fedora 10
because we need more for system services, the clearly right thing here
is to just change the UID of all the files downloaded to 700, not keep
500 and fail.
If you frame the problem too generally, then yes, it becomes impossible
to solve. But for most of them, I think the right answer is to not try
to push all logic into the OS (filesystem/kernel/libc), but apply
situation-specific logic to do the right thing.
12:09 p.m.
On Thu, Nov 08, 2007 at 12:54:12PM -0500, Simo Sorce wrote:
The problem being Posix and Linux/UNIX really are not
"network-aware"
when it comes to identity.
They make certain assumptions about what a uid or gid is, and also about
the way they can be manipulated. However that is a *solved* problem.
The UID/GID are *local* by nature. All tricks used up today like NIS
and
LDAP to sync UIDs/GIDs all over, are just *bad* hacks.
They work, they solve the problem for local users and they make it easy
locally to solve the "who owns this" problem, as opposed to the "can I
..."
problem.
1. move to 128bit UID/GIDs that are really UUIDs
problem is, most apps wont work, need changes in the kernel, in a
word:
unachievable
This doesn't work anyway - a UUID is intended to avoid collisions, it is
not intended to be securely unique.
2. Make UIDs/GIDs *only* a local thing.
this mean changes in the vfs only, you need a mapping facility so that
you can translate them for (network) file systems.
Yes - which unfsd supported in 1994 or so.
I expect preconcept opposition for normal filesystems tho. But that
is
needed too, because if you want to use an USB pen drive or external
disk, or even an iSCSI partition you need to be able to map a UUID
stored on the filesystem to the local UID that make sense for the kernel
and all existing applications, or you are back requiring all machines in
the world synchronize with your own machines UIDs and GIDs.
For remote access to data you need to stop thinking in terms of "if I say
I am number 6 you say yes" and instead move to managing key chains via
kerberos and similar systems - exactly as AFS has dealt with the problem
and NFSv4 has the framework to handle it.
Short of having a DNS like global "phonebook" for UIDs the solvable problem
is "can I have access to xyz"
Not co-incidentally the kernel has a key management service now, which is
ideal for such purposes.
Alan
12:53 p.m.
On Thu, 2007-11-08 at 13:09 -0500, Alan Cox wrote:
On Thu, Nov 08, 2007 at 12:54:12PM -0500, Simo Sorce wrote:
> The problem being Posix and Linux/UNIX really are not "network-aware"
> when it comes to identity.
They make certain assumptions about what a uid or gid is, and also about
the way they can be manipulated. However that is a *solved* problem.
Alan, I think we live on diffrent planets then :-)
I deal with ID mappings problems since ever in the Samba world, and I
rewrote the idmap subsystem twice, please trust me when I say the
problem is *far* from being solved, for anything but ideal cases which
do not exist on real networks.
> The UID/GID are *local* by nature. All tricks used up today like
NIS and
> LDAP to sync UIDs/GIDs all over, are just *bad* hacks.
They work, they solve the problem for local users and they make it easy
locally to solve the "who owns this" problem, as opposed to the "can I
..."
problem.
They are a hack that can be made to work, but to me this is not a good
definition of "work", and they definitely do not "just work".
> 1. move to 128bit UID/GIDs that are really UUIDs
> problem is, most apps wont work, need changes in the kernel, in a
> word:
> unachievable
This doesn't work anyway - a UUID is intended to avoid collisions, it is
not intended to be securely unique.
True, but there is almost no way to get something securely unique, and
anyway that's absolutely not the point. What we need is exactly to
avoiding collisions, not securely unique IDs.
> 2. Make UIDs/GIDs *only* a local thing.
> this mean changes in the vfs only, you need a mapping facility so that
> you can translate them for (network) file systems.
Yes - which unfsd supported in 1994 or so.
I know, there have been experiments that's why I am somewhat confident
we can easily do this.
> I expect preconcept opposition for normal filesystems tho. But
that is
> needed too, because if you want to use an USB pen drive or external
> disk, or even an iSCSI partition you need to be able to map a UUID
> stored on the filesystem to the local UID that make sense for the kernel
> and all existing applications, or you are back requiring all machines in
> the world synchronize with your own machines UIDs and GIDs.
For remote access to data you need to stop thinking in terms of "if I say
I am number 6 you say yes" and instead move to managing key chains via
kerberos and similar systems - exactly as AFS has dealt with the problem
and NFSv4 has the framework to handle it.
I think in CIFS terms, and there the problem was solved from scratch
basically. NFSv4 is ok too, as they finally moved from trusting the
client to not trusting it. But we have to do mapping for NFSv3.
Short of having a DNS like global "phonebook" for UIDs the
solvable problem
is "can I have access to xyz"
Exactly, but yet you need to represent identity in term of UIDs and GIDs
in the POSIX world, hence why I am slowly advocating for *local* mapping
tables. Network mapping tables simply do not work.
Not co-incidentally the kernel has a key management service now,
which is
ideal for such purposes.
Not sure what the key management thing wins you, if you mean to store
the mapping in there, yes it can be a huge help, but the mechanism we
use to store the temporary mappings is not important, what matter is
having filesystem (and not just netwrok ones) drivers support mapping,
with a way to store mappings on removable drivers when needed. Think
agaion of a USB pen drive formatted ext2, you need at least a file where
you map the UID used on the disk to the identity used (be it an email or
a kerberos principal or whatever you can think of to represent an
identity) and for groups too.
1:38 p.m.
On Thu, Nov 08, 2007 at 01:53:54PM -0500, Simo Sorce wrote:
Alan, I think we live on diffrent planets then :-)
Quite possibly. I make mine one, two, third one out unless we missed one.
I deal with ID mappings problems since ever in the Samba world, and
I
rewrote the idmap subsystem twice, please trust me when I say the
problem is *far* from being solved, for anything but ideal cases which
do not exist on real networks.
Its a solved problem - I'm not saying its solved in RHEL or for our customerbase
thats a different thing.
> This doesn't work anyway - a UUID is intended to avoid
collisions, it is
> not intended to be securely unique.
True, but there is almost no way to get something securely unique, and
anyway that's absolutely not the point. What we need is exactly to
avoiding collisions, not securely unique IDs.
You cannot avoid collisions using ids that are defacto publically visible.
I will choose to clash with your ID because I'm bad.
> Short of having a DNS like global "phonebook" for UIDs
the solvable problem
> is "can I have access to xyz"
Exactly, but yet you need to represent identity in term of UIDs and GIDs
in the POSIX world, hence why I am slowly advocating for *local* mapping
tables. Network mapping tables simply do not work.
They work very well when the authetication domain and the user domain and
the set of systems overlap - thats actually not that uncomoon. When they don't
you need mapping at that level - be it group or system.
with a way to store mappings on removable drivers when needed. Think
agaion of a USB pen drive formatted ext2, you need at least a file where
you map the UID used on the disk to the identity used (be it an email or
a kerberos principal or whatever you can think of to represent an
identity) and for groups too.
That makes a lot of sense for deciding who is who, its absolutely useless
for authentication purposes. Having a key which says "please sir I'm root"
doesn't solve the trust problem on a network.
How you do the uid mapping is I think not too important. You would want
to load a table of [disk uid][local uid] into a stacking fs or similar and
that can be done by parsing the fs in user space (with a default 'root only'
rights set until its parsed and loaded). Its not quite that simple because
you need to add new user mappings and know what is free. Thats not a trivial
excercise on GFS2 I suspect.
Truth be told however what most people want for removable storage is blanket
ownership by themself.
Alan
2:41 p.m.
On Thu, 2007-11-08 at 14:38 -0500, Alan Cox wrote:
Its a solved problem - I'm not saying its solved in RHEL or for
our customerbase
thats a different thing.
Ok put this way I can agree, it's vague enough I can attach my meaning
of 'solved' :-)
> > This doesn't work anyway - a UUID is intended to avoid
collisions, it is
> > not intended to be securely unique.
>
> True, but there is almost no way to get something securely unique, and
> anyway that's absolutely not the point. What we need is exactly to
> avoiding collisions, not securely unique IDs.
You cannot avoid collisions using ids that are defacto publically visible.
I will choose to clash with your ID because I'm bad.
Ok I think we are mixing things here, it seem we are mixing the need to
uniquely represent identities with the need to authenticate them.
Please let's not mix the two, they are connected but separate problems.
> > Short of having a DNS like global "phonebook" for
UIDs the solvable problem
> > is "can I have access to xyz"
>
> Exactly, but yet you need to represent identity in term of UIDs and GIDs
> in the POSIX world, hence why I am slowly advocating for *local* mapping
> tables. Network mapping tables simply do not work.
They work very well when the authetication domain and the user domain and
the set of systems overlap - thats actually not that uncomoon. When they don't
you need mapping at that level - be it group or system.
It's not about it being common or uncommon, it is about the pain when
you have to merge 2 or more domains (thin the mess in small shops when
you have >10 machines which have never been synchronized).
Right now it is a huge pain. If you make mapping the default an make
UIDs/GIDs make sense only locally, you are in a position to remove the
pain completely.
> with a way to store mappings on removable drivers when needed.
Think
> agaion of a USB pen drive formatted ext2, you need at least a file where
> you map the UID used on the disk to the identity used (be it an email or
> a kerberos principal or whatever you can think of to represent an
> identity) and for groups too.
That makes a lot of sense for deciding who is who, its absolutely useless
for authentication purposes. Having a key which says "please sir I'm root"
doesn't solve the trust problem on a network.
Again I am not sure why you are mixing authentication with
authorization.
Authentication is absolutely necessary, but it is a different problem.
Once you are authenticated you need an ID to represent you. I am not
advocating the UUID to be a blanket credential by itself.
This is solved in the most modern network file systems like CIFS and
NFSv4, for others we will still suffer the "trust the whole remote
machine" problem, but that is no different from what we have today.
How you do the uid mapping is I think not too important.
True, in fact I didn't propose a mechanism, I am trying to find out how
well or bad people can receive the message we need something like that
first.
You would want
to load a table of [disk uid][local uid] into a stacking fs or similar and
that can be done by parsing the fs in user space (with a default 'root only'
rights set until its parsed and loaded).
Exactly!
Its not quite that simple because
you need to add new user mappings and know what is free. Thats not a trivial
excercise on GFS2 I suspect.
Yes, it is not in some complex cases, the worst when networked apps
transmit a Posix UID/GID over the network (like NFSv2/3 does), in that
case the app need to be changed or you need to go back to use a shared
table until the app is fixed.
The nice thing is that allowing mapping at the system level does not
preclude sharing existing maps at a group/domain level.
Truth be told however what most people want for removable storage is
blanket
ownership by themself.
Sometimes they do, sometimes they don't.
If I have a drive I connect to a multi-user system (maybe a once a week
backup drive or something) I want to keep the ownership clean.
Clearly, ownership in this case is not meant to protect data when the
disk is moved to an untrusted machine, but it is still useful inside a
trusted group.
Ideally a "portable drive file system" would allow to make "everyone"
or
even a group owner of a file, a concept that, unfortunately is not
allowed by the posix semantics :-( but can be nonetheless made to work
with a mapping system probably.
Simo.
3:54 p.m.
On Thu, 2007-11-08 at 15:41 -0500, Simo Sorce wrote:
Authentication is absolutely necessary, but it is a different
problem.
Once you are authenticated you need an ID to represent you. I am not
advocating the UUID to be a blanket credential by itself.
Replying myself just to be clear, when I say UUID I do not mean the RFC
definition of it, just the english one: Unique User IDentifier.
It can be anything, even an email address for what I care.
Any string that can be unique will do, it only needs to be abstract as
it should be made possible to represent anything as an Identity: A user,
a group, a machine, a service, a process, an abstract concept like
"Authenticated user", or "everyone" too in theory.
Simo.
8:51 a.m.
tor 2007-11-08 klockan 13:53 -0500 skrev Simo Sorce:
Exactly, but yet you need to represent identity in term of UIDs and
GIDs
in the POSIX world, hence why I am slowly advocating for *local* mapping
tables. Network mapping tables simply do not work.
I totally agree with you here.
Think
agaion of a USB pen drive formatted ext2, you need at least a file where
you map the UID used on the disk to the identity used (be it an email or
a kerberos principal or whatever you can think of to represent an
identity) and for groups too.
Yes, the design problem is how to store the mapping database for
different types of file systems and what to use as global identities
(unless the file system has support for them natively). Probably you'd
want to support a number of different schemes. OpenID would be one,
Kerberos another, Mugshot account, PKI and GPG key IDs, uuids, and so
on.
You'd need to think about policies and who to trust, but it's hard to
see how it could come out any worse than the current non-system.
/abo
12:13 p.m.
On Thu, 2007-11-08 at 12:54 -0500, Simo Sorce wrote:
On Thu, 2007-11-08 at 09:01 -0700, Richi Plana wrote:
> Certainly an interesting concept, but that would pull us way too far
> into the Internet space (as opposed to local or even private domain
> space). How would an openid user map to Linux in terms of UID? Would a
> uid be assigned on a local machine? On the domain (if the machine the
> person is logging into happens to be a part of a bigger network)? Does
> the OpenID spec have provisions for account authorization and
> information? There are still some UNIX-y things needed by current
> distributions that we have to find solutions for.
We have the problem of UIDs in the enterprise space right now even
without OpenID in the mix.
The problem being Posix and Linux/UNIX really are not "network-aware"
when it comes to identity.
This seems like an excellent occasion to point to the freeIPA project
(wwww.freeeipa.org), which we will hopefully start to appear in Fedora
fairly soon.
12:21 p.m.
tor, 08 11 2007 kl. 13:13 -0500, skrev Matthias Clasen:
On Thu, 2007-11-08 at 12:54 -0500, Simo Sorce wrote:
> On Thu, 2007-11-08 at 09:01 -0700, Richi Plana wrote:
> > Certainly an interesting concept, but that would pull us way too far
> > into the Internet space (as opposed to local or even private domain
> > space). How would an openid user map to Linux in terms of UID? Would a
> > uid be assigned on a local machine? On the domain (if the machine the
> > person is logging into happens to be a part of a bigger network)? Does
> > the OpenID spec have provisions for account authorization and
> > information? There are still some UNIX-y things needed by current
> > distributions that we have to find solutions for.
>
> We have the problem of UIDs in the enterprise space right now even
> without OpenID in the mix.
>
> The problem being Posix and Linux/UNIX really are not "network-aware"
> when it comes to identity.
This seems like an excellent occasion to point to the freeIPA project
(wwww.freeeipa.org), which we will hopefully start to appear in Fedora
fairly soon.
http://freeipa.org/page/Main_Page
12:58 p.m.
On Thu, 2007-11-08 at 13:13 -0500, Matthias Clasen wrote:
On Thu, 2007-11-08 at 12:54 -0500, Simo Sorce wrote:
> On Thu, 2007-11-08 at 09:01 -0700, Richi Plana wrote:
> > Certainly an interesting concept, but that would pull us way too far
> > into the Internet space (as opposed to local or even private domain
> > space). How would an openid user map to Linux in terms of UID? Would a
> > uid be assigned on a local machine? On the domain (if the machine the
> > person is logging into happens to be a part of a bigger network)? Does
> > the OpenID spec have provisions for account authorization and
> > information? There are still some UNIX-y things needed by current
> > distributions that we have to find solutions for.
>
> We have the problem of UIDs in the enterprise space right now even
> without OpenID in the mix.
>
> The problem being Posix and Linux/UNIX really are not "network-aware"
> when it comes to identity.
This seems like an excellent occasion to point to the freeIPA project
(wwww.freeeipa.org), which we will hopefully start to appear in Fedora
fairly soon.
Yes actually I will try to pursue my plan as part of FreeIPA as well.
Right now freeipa still uses the classic approach (all uids need to be
consolidated), because the other plan needs kernel and userland support,
and anyway other Unices will need it for long.
But if you are interested in Identity management problems, be sure to
follow that project as I am willing to tackle one of them at a a time
there.
/Simo not afraid of trying to fight with the Mills.
3:45 p.m.
On Thu, 2007-11-08 at 12:54 -0500, Simo Sorce wrote:
On Thu, 2007-11-08 at 09:01 -0700, Richi Plana wrote:
> Certainly an interesting concept, but that would pull us way too far
> into the Internet space (as opposed to local or even private domain
> space). How would an openid user map to Linux in terms of UID? Would a
> uid be assigned on a local machine? On the domain (if the machine the
> person is logging into happens to be a part of a bigger network)? Does
> the OpenID spec have provisions for account authorization and
> information? There are still some UNIX-y things needed by current
> distributions that we have to find solutions for.
1. move to 128bit UID/GIDs that are really UUIDs
problem is, most apps wont work, need changes in the kernel, in a
word:
unachievable
Not to worry, gentlefolk. I've already had a word with the OpenID
Foundation and they've agreed that it is a problem that they'll address
with OpenID 2.1. In fact, they've already conferred with IANA and now
they're coming up with a scheme for allowing the distributed
registration and authentication of OpenID to be given, for each account
created, a 128-bit unique IP address that's portable (you can take it
with you to a different OpenID Provider). A private space is said to be
reserved for use by system resources and daemons.
Microsoft has uncharacteristically agreed that the convenience this
brings outweighs the usual technical arguments (read: laziness). This
was better than their original idea: having UTF-16 encoded OpenID
strings as process UIDs w/ BOM. They have agreed to ship a 128-bit UID
capable kernel in their next release of Windows entitled "Leghorn".
NEC has decided to get on the bandwagon, predicting that banks will soon
switch to OpenID, by coming out with ATMs that allow processes to run
using this universal ID system. The new ATMs will have Gnome as its
graphical environment and users automatically get their preferred
settings including background and screensaver if available from the
Internet.
Oh, and yes, flying pig.
Seriously, though, thanks for the various insights. I'll look into the
various means by which arbitrary accounts are mapped into local space.
--
Richi Plana
9 a.m.
tor 2007-11-08 klockan 06:50 -0500 skrev Neal Becker:
It seems that openid is moving along. Maybe f9 can integrate openid
as an
SSO solution?
Stuff to do:
* Browser support/plugin to help with managing them.
* Help with signing up to an OpenID identity provider, integrated
with above. (Mugshot, Online Desktop?)
* Support in packaged web apps.
Uhm... What else?
As always, the mantra is work upstream, making sure it can be packaged
well.
/abo
6051
days inactive
6052
days old
15 comments
8 participants
participants (8)
-
Alan Cox -
Alexander Boström -
Colin Walters -
David Nielsen -
Matthias Clasen -
Neal Becker -
Richi Plana -
Simo Sorce