[Server-devel] authentication method
Tony Anderson
tony_anderson at usa.net
Mon Oct 28 15:04:16 EDT 2013
Hi,
As usual, I am way behind the curve.
The Moodle authentication is based on the serial_number of the XO. This
is established by the 'registration' on the XO menu. Moodle, itself,
supports
authentication by virtually every mechanism you can think of since it is
used by for-pay educational institutions.
I would like to shift to a login concept to support <olpc deployments.
Actually,
I think we need a user and user's family id as separate even in olpc
deployments
since it is inevitable that a laptop taken home will be used by many
family members as well as friends and neighbors.
One strategy is define a guest login. Guests would not have any activity
recorded
in the Journal.
For login, there needs to be a 'session' which covers login to logout
(or shut down of the laptop). If a registered user logs in, the
activities in that session
would be recorded.
I also think that schools (or other deployment sites) can create a list
of users and the XOs assigned to them. What I am doing is creating a
database with two
record types: personal name record and xo record.
From this, it is easy to provide authentication as required to Moodle
and to
the Journal backup. Note: the Journal backup is currently based on a
public,
private key pair established at registration. My sense is that the
easiest thing is
to keep this to enable interaction between the XO and the school server
for backup without involving the user.
This does require a design decision. The public/private key gives access
to a
folder /library/users/shf00000001. One approach would be to identify users
by the person name record primary key and to maintain the public private
key pair by person. In this case the folder would be
/library/users/primary-key.
In the case of guests, all of this would be ignored since no
user-specific records
are being kept. This also works for Moodle since the Moodle
administrator defines access priviliges for the guest account (which is
always defined).
In short, it seems to me that Moodle should be the client of a
system-wide authentication protocol, not the provider.
Also, the purpose of authentication needs to be defined. In general,
most services do not need authentication but are open to all. However,
there are services for staff members that involve privacy considerations.
I would welcome a discussion of the requirements for this feature as
well as
alternative available implementation strategies.
Tony
Tony
On 10/28/2013 12:00 PM, server-devel-request at lists.laptop.org wrote:
> Message: 4 Date: Mon, 28 Oct 2013 11:28:02 -0400 From: George Hunt
> <georgejhunt at gmail.com> To: Miguel Gonz?lez
> <migonzalvar at activitycentral.com> Cc: XS Devel
> <server-devel at lists.laptop.org> Subject: Re: [Server-devel] extension
> of Moodle authentication mechanism Message-ID:
> <CADfCcpWTu=k3ruG+1ge6DdvmY++9RO_=2=8Kz7o=P7A_226yJA at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1" Thank you. I'll spend
> some time studying it and try to write up some documentation, and use
> cases. On Mon, Oct 28, 2013 at 5:07 AM, Miguel Gonz?lez <
> migonzalvar at activitycentral.com> wrote:
>> >
>> >
>> >On Mon, Oct 28, 2013 at 4:54 AM, George Hunt<georgejhunt at gmail.com>wrote:
>> >
>>> >>I heard that someone at activitycentral was extending, augmenting the
>>> >>authentication used by Moodle, so that other web based services can climb
>>> >>on.
>>> >>
>> >
>> >It's called xs-autherserve and is a component in DXS initiative. If you
>> >install XSCE using ansible you will find it in
>> >http://schoolserver.local:5000.
>> >
>> >
>>> >>
>>> >>Can someone point me to the code?
>>> >>
>>> >>
>> >The source code is inhttps://github.com/migonzalvar/xs-authserver.
>> >
>> >
More information about the Server-devel
mailing list