1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE> [Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication
</TITLE>
<LINK REL="Index" HREF="index.html" >
<LINK REL="made" HREF="mailto:mageia-sysadm%40mageia.org?Subject=Re%3A%20%5BMageia-sysadm%5D%20%5BLONG%5D%20sympa%20%28%20and%20web%20apps%20%29%20ldap%0A%20authentication&In-Reply-To=%3C1290732472.2069.268.camel%40akroma.ephaone.org%3E">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="000950.html">
<LINK REL="Next" HREF="000964.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication</H1>
<B>Michael Scherer</B>
<A HREF="mailto:mageia-sysadm%40mageia.org?Subject=Re%3A%20%5BMageia-sysadm%5D%20%5BLONG%5D%20sympa%20%28%20and%20web%20apps%20%29%20ldap%0A%20authentication&In-Reply-To=%3C1290732472.2069.268.camel%40akroma.ephaone.org%3E"
TITLE="[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication">misc at zarb.org
</A><BR>
<I>Fri Nov 26 01:47:52 CET 2010</I>
<P><UL>
<LI>Previous message: <A HREF="000950.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication
</A></li>
<LI>Next message: <A HREF="000964.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#963">[ date ]</a>
<a href="thread.html#963">[ thread ]</a>
<a href="subject.html#963">[ subject ]</a>
<a href="author.html#963">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>Le jeudi 25 novembre 2010 à 22:40 +0100, nicolas vigier a écrit :
><i> On Thu, 25 Nov 2010, Michael Scherer wrote:
</I>><i>
</I>><i> > > > - using email as login is dangerous. Since the email is freely editable
</I>><i> > > > in catdap ( and multivalued ), someone could perfectly change his email
</I>><i> > > > after opening a account, and thus get access to sympa subscription of
</I>><i> > > > someone else.
</I>><i> > >
</I>><i> > > And lose their account to the user whose email address was used as soon as we
</I>><i> > > allow user-initiated password reset ...
</I>><i> >
</I>><i> > Which is not a problem, since opening a account is free. If we start to
</I>><i> > have some private mls ( such as the one requested for forums ), reading
</I>><i> > archive would be a privacy issue, and so step must be taken to prevent
</I>><i> > that.
</I>><i> >
</I>><i> > But my main point is not this particular example who is quite easy to
</I>><i> > prevent. But rather that letting people freely edit the attribute they
</I>><i> > use for login is IMHO a risky operation given the wide range of
</I>><i> > application that we will have.
</I>><i> >
</I>><i> > Editing by admin should be ok.
</I>><i>
</I>><i> To avoid this, I think email should not be freely editable in catdat,
</I>><i> but should be verified first before being actually changed in ldap.
</I>><i> When changing email, the user should receive on the new email an URL
</I>><i> to open to confirm he is the owner of the email.
</I>
So to summarize, here is a updated proposal ( order matter ) :
- use username as primary login, not letting people change it for now.
Since most applications may not properly support it, I feel it would be
safer.
- make sure that catdap can take username or email when resetting
password. ie :
reset password :
- email or username :
[send the request]
this will likely be enough for people who forget their username, IMHO.
- make sure primary email is unique, by setting it in ldap as such.
( quite easy )
- allow to also use emails as login for all applications that support it
now. Ie username and primary email ( since it is easier to have it
unique ). Yet the username will still be the username showed, or the cn
if the application support it ( or displayName ).
Ie, even if I used <A HREF="https://www.mageia.org/mailman/listinfo/mageia-sysadm">michael at example.org</A>, it would show "welcome Michael
Scherer" ( or welcome misc, if the application do not support getting
the CN or DisplayName or a custom attribute ).
So far, sympa support it. Not sure for the others.
- For those that don't, try to patch them _and_ get the patch accepted
by upstream first ( because that's already enough work to write the
patch so if it is not even accepted upstream, we will have to maintain
it and that's not good from a deployment pov ). Backporting the patch
would be ok, carrying it forever is IMHO not desirable. But theses
features seems generic enough to be a welcome addition that can be
upstreamed.
Features being "using email and/or username" and/or "showing
CN/DisplayName instead of username".
- find a way to ensure unicity of email for the secondary emails that
user can enter. If possible, on the ldap level directly, but maybe doing
it on catdap level would be enough. I would feel safer to have this at
ldap level for obvious reasons of data integrity.
- once we have enabled and checked it, and ensured that this is not a
potential source of problem, enable the use of the secondary email as a
login, in addition to username and primary email
( this should not requires much patching of application, but if needed,
same rule as previously apply ).
- ensure that aliases @mageia.org can also be used without being entered
in the ldap ( may requires some black magic at ldap level ). But if we
can't, just let people add it by themself, or add it when user get their
email aliases.
- The username will be used by application as the "primary key" in their
local db. So people can change their email without trouble, and we will
not need to touch to the application too much when it happens.
( or at least I hope )
Later, if we decide this is worthwhile, and if there is demand for it
( but if we let change email and display name, username may not require
change ), we have enough ressources ( because I think that would be a
issue for the moment ), we can start to check for a way of changing
username on the whole information system.
So I think this plan of action will satisfy everybody :
- people can use their email or their username
- people can change their emails without impacting the db, and without
requiring invasive change ( and with upstreamable patchs )
- people can change the information that is displayed, and patchs could
also be sent upstream.
- we do not have much burden of maintaining it ( as we use standard
protocols )
- we can roll out the required feature one at a time, so nothing get
late, and we have the full time to work on it and properly finish the
adaptation of others softwares
Bonus points :
- we have small patchs and features to code, so we can fill the junior
job list
- we can also communicate frequently on progress
I didn't included oauth/openid/SSO/etc in the plan, as
- this seems much more like a much more distant goal
- much more invasive on all levels
- something that I still didn't grasp
So, is everybody ok with this plan ?
--
Michael Scherer
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="000950.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication
</A></li>
<LI>Next message: <A HREF="000964.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#963">[ date ]</a>
<a href="thread.html#963">[ thread ]</a>
<a href="subject.html#963">[ subject ]</a>
<a href="author.html#963">[ author ]</a>
</LI>
</UL>
<hr>
<a href="https://www.mageia.org/mailman/listinfo/mageia-sysadm">More information about the Mageia-sysadm
mailing list</a><br>
</body></html>
|
