summaryrefslogtreecommitdiffstats
path: root/zarb-ml/mageia-sysadm/2010-November/000897.html
blob: 96fba3d08da01e624e63ce9c340777be4817bcd0 (plain)
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
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
<!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%20authentication&In-Reply-To=%3C1290621280.2069.77.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="000896.html">
   <LINK REL="Next"  HREF="000899.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%20authentication&In-Reply-To=%3C1290621280.2069.77.camel%40akroma.ephaone.org%3E"
       TITLE="[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication">misc at zarb.org
       </A><BR>
    <I>Wed Nov 24 18:54:40 CET 2010</I>
    <P><UL>
        <LI>Previous message: <A HREF="000896.html">[Mageia-sysadm] [457] add a Requires to fix bootstraping ( ie,	puppet try to do the link
</A></li>
        <LI>Next message: <A HREF="000899.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap	authentication
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#897">[ date ]</a>
              <a href="thread.html#897">[ thread ]</a>
              <a href="subject.html#897">[ subject ]</a>
              <a href="author.html#897">[ author ]</a>
         </LI>
       </UL>
    <HR>  
<!--beginarticle-->
<PRE>Hi,

as proposed during previous founders meeting, we need to be clear upon
how we want to use authentication on web applications ( and non web
too ) with regard to ldap directory.

So what I propose will apply to sympa, but could be expended on others
applications.

So the first proposal that I will expose :

- users will use their personal email address and the password from ldap
to authenticate themselves. 

While this is the easiest solution ( and the current one in svn from
what I understood ), this idea suffer from 3 issues :

- people will use a different login than the one of identity. This is
not really how a centralized login system should work, imho. And this
was a source of confusion ( at least, of my confusion ) at Mandriva.

- people will need to open a account on identity. For some applications,
this may not be desirable. For example, on a forum, having to first
register, and then log on the forum to fill the data is not good. For
mailling list, if we intend to subscribe gmane, or mail archive to the
list, this is not good either. I couldn't get in touch with rda in time,
but I think that's what he meant ( if not, romain, feel free to correct
me ). And in fact, this would also put more pressure on ldap than
intended ( if we requires this for forum, we may end with a big ldap
directory ). 

- using email as login is dangerous. Since the email is freely editable
in catdap ( and multivalued ), someone could perfectly change his email
after opening a account, and thus get access to sympa subscription of
someone else.  More ever, nothing guarantee that email are uniques
across the whole DIT, especially if email span on 2 attributes ( mail
and mailAlternateAddress ).

We could however 1) check the unicity of email on ldap 2) modify catdap
to requires a confirmation before changing anything email related.


So then a second proposal was done :
- users use their @mageia.org alias, and the password from ldap

this one fix the 3rd issue, to be replaced by a 4th and 5th ones :

- everybody who will open a account on identity will receive a alias.
I am not sure that's what we should propose, especially since a alias is
like a official acknowledgment. And we do not want to restrict ml to the
few people that would receive a alias.

- people will need to use the alias to post on the ml, or we will need
to find a way to find their emails from their subscriptions. Not sure if
sympa could do it ( but this would be great )

But issue 1 and 2 still apply.


For the sake of being complete, we could also decide to not use ldap.
Then we would lose the centralisation of password, and that's imho
something to avoid if we can. But that's still a option that we should
not forget.


So what I propose to solve this is the following scheme :

A user wanting to authenticate on sympa will provide a login, who will
be either :
- a email ( his personal email or email of choice ) + password of his
choice, stored by sympa, and using regular sympa authentication
or 
- a login ( identity login ) + password from ldap

If I understood correctly, sympa support this
( <A HREF="http://www.sympa.org/manual_6.1/authentication">http://www.sympa.org/manual_6.1/authentication</A> ).

This way : 
1) we do not force identity on anybody

2) the login is either a email ( with email verification done by sympa,
and email change also done by sympa ) or our fixed ldap login ( fixed,
ie, not under the control of any user )

3) people will use the same uid everywhere ( because having sometime the
email, sometime the uid is confusing, especially if we start to offer
email alias )

So, that's the first part of my mail. 


This issue with ldap integration will likely arise on almost every web
application we will setup. So I would like to propose the following :

we have 2 types of applications :
- some are for use of active people
  - submit packages, send something on svn
  - wiki edition ( not sure on this one )
  - transifex
  - maintainers db
  - etc 

For those applications, we would likely require be in a team first which
should IMHO require a account in identity.

- some are for the use of the enlarged community
  - forums
  - mailing lists
  - bugzilla
  - etc

Those should not requires to be in a team first, and therefore, do not
require a account in identity. 

Yet, we want to have the benefit of the central authentication as much
as possible.

So let's divide applications in 2 category :
 
The one in the 1st will use ldap authentication only. That's quite easy
to achieve most of the time. Of course, supporting ldap is not the only
thing we want when selecting a application. Being able to support
filter, show meaningful errors messages, and others are also to
consider.

The one in the 2nd will use some kind of hybrid auth, if possible. Ie,
if people give a ldap login ( uid + password ), the access is granted,
and if not, we do a fallback on some kind of native and non centralized
login system.

However this will open a can of worms :
- what about possible login conflict, ie, how can we prevent someone
from using &quot;misc&quot; ( for example ) as a login in the native users
database ? What would happen if the conflict arise ? 

Forcing people to use their email is a solution, but not everything
support that model. We can't simply check if the login is not in use
because someone could perfectly use it later.

- what people who first open a account on the software, and later change
to use a identity login ? How can we merge the 2 ( especially if there
is some authorization issue ) ?

This would likely requires hand edition by a admin of the DB or
equivalent.

- what about a software that do not support it, ie ldap or native, but
not both ? Or that do not support it as we want ?

So far, bugzilla support this ( ldap, and fallback on the DB ), maat
told me this was the proposed scheme for forum ( iirc ) and that's the
one I propose for sympa. So at least, for the example I gave, we are ok.


and the biggest problem ( imho ) :

How do we decide what category does a application belong ?

Some are quite easy, and some are more difficult ( I think ). For
example, I would be inclined to use ldap login for the wiki, or let
people be unauthenticated. Maybe not everybody agree.

What about application like mageia-app-db ? 
This one is easier since we can specifically add this as requirement. 

So to summarize :
- can someone confirm we can do this for sympa ?

- does someone see a problem with the proposed scheme for sympa, and
does it fulfill everybody need ?

- does everybody agree for the separation in 2 category of applications,
and the consequence for the application in term of authentication ?


-- 
Michael Scherer

</PRE>













<!--endarticle-->
    <HR>
    <P><UL>
        <!--threads-->
	<LI>Previous message: <A HREF="000896.html">[Mageia-sysadm] [457] add a Requires to fix bootstraping ( ie,	puppet try to do the link
</A></li>
	<LI>Next message: <A HREF="000899.html">[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap	authentication
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#897">[ date ]</a>
              <a href="thread.html#897">[ thread ]</a>
              <a href="subject.html#897">[ subject ]</a>
              <a href="author.html#897">[ 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>