On Thu, Jun 4, 2009 at 5:41 PM, Lucas Mocellin <[email protected]> wrote:
> Also I'll try to explain:
>
> I have 2 types of users: supervisors and students
>
> this system is to authenticate students to perform a "online test", BUT the
> supervisor must authorize them to do it for a given time (the test time,
> usually 1-3hours)
>
> For other reasons the systems will be: a Linux LiveCD which is booted in any
> machine with this "authenticator client".
>
> The supervisor will authenticate and get as answer a "temporary pass" (OTP
> time synchronized), so he will give that to the students in the same
> physical location, and the students have X seconds to authenticate their
> "LiveCDs" to be able to perform the test.
>
> So I'm having some problems with this second authentication (students), when
> they are authenticated (student_id, student_pass, otp_pass) I thought to
> create a VPN between the student and the server and this "online test" will
> only be available inside this VPN, so the VPN program should be responsable
> for the "certificate validation", so I don't have to worry about.
>
> is that understandable? my english is not so good.
>
> any ideas are welcome. =)
Hm, sounds like you're creating an examination system for taking
tests. There are existing solutions for that, both non-profit and
commercial. Almost always integrated as part of a larger
computer-based training system. You may wish to check them out.
Anyway, assuming you're going the DIY (do It Yourself) route.
>From what I read in your scenario, you've got everybody connected, so
you've got a network --> no problem to set up a central server which
does all the authentication, authorization and after that, the
examination, for you. See above: solutions for this exist already. DIY
means extra work.
If you go DIY, you need to be aware that you are mixing concepts here,
as Michael already pointer out.
Certificates are like passports: they're used for authentication ~
identification. I am not 'me' for 3 hours; I've been 'me' for 40 years
now and I like to remain me for another 40 if I am permitted ;-)
Nevertheless, I've traveled frequently and for a lot of countries you
need a visa, which says you're allowed to enter and MUST exit the
premises between then and then. That's authorization.
And the latter is the major section of your initial question.
Authorization is handled through access control systems; things such
as OTPs can be used there, depending on the goals of such systems.
Nobody would ever think of issuing you a /passport/ for a few hours,
right? Hence, certificates is not the way.
Let me describe this in another way:
say you've got a web server where you want to authorize a set of
individuals for a limited time (slot).
A way to approach this may be (there are other solutions):
issue everybody with proper identification. That's either
username/password (the usual); in higher security settings, folks get
issued electronic 'tags' , which contain 'client certificates' which
are, for instance, usable in the SSL realm.
Now the webserver has to be programmed / configured to request client
/authentication/ for a chosen set of web pages, i.e. when browsing
there, you'll need to have your client certificate accessible from
your browser, so it can be sent to the server. "We want to know who
you are." So far, so good.
When this works (you can test this scenario with the OpenSSL tools
s_server and s_client in a rudimentary fashion), you've got
authentication covered: your server knows who's who and who's
connected where.
Now on to the timeslot thing (the /authorization/ part): this is where
that 'access control system' stuff comes in: the web server (pages)
need to be programmed such that a chosen set of pages only 'show' (are
enabled) during a given timeslot for a given set of users. That's
outside the OpenSSL scope and definitely a job for the server system
folks (programmers, admins).
How you determine the start of that timeslot is up to you: your
scenario suggests a teacher being present initiates the timeslot;
another often seen scenario is where the timeslots are prepublished
and you thus know you can succesfully log on and do the things you
need to do between, say, 0900 and 1200 hours, june 4th. "Have your
identification with you when you enter during those hours and you're
good to go."
By following this flow, you can issue a 'client certificate' to each
participant at your leasure /before the timeslot starts/. E.g.:
certificates can be issued at the start of the school year for one
year or maybe for 6 years, thus giving a certificate lifetime spanning
a study (usually 4-5 years) with a bit of slack. Student must keep his
cert private and stored in a safe place (more on that in a sec,
because you can state this easily, but you MUST provide the facilities
to enable this, or you're just breaking your system before it even
started yet.)
That client certificate is the student's /passport/. (Identification,
can be used as authentication)
For security reasons, I'd suggest using hardware tokens for this, but
I get the weird vibe somebody (not you) is trying to pull this off on
the cheap and not well aware of the impact here. Anyway, having client
certs float around in emails, or on CDs, etc. is begging for trouble
in a multiuser environment, hence those hardware tokens.
Once all the students have those identification/authentication tokens,
you're ready with phase 1.
Then you can add the appropriate students to the access control
system's list, which determines who's getting to view page XYZ during
timeslot 123, once the timeslot has been started by teacher ABC (who,
of course, also has similar client cert/hardware token authentication;
he's just got different /authorization/ as she/he can enter other web
pages where things can be set up (timeslots, examinations, ...) and/or
enabled ("start examination CS201 now")).
That's workflow mixed with access control, taken from your scenario description.
When students access those web pages before the timeslot starts, or
after the timeslot expires, they simply get to see an appropriate
failure message, even while they sent their authenticating client cert
across the line: "we know who you are, the ACL (access control list)
system part just doesn't let you pass into this particular zone,
because it's timeslotted. Try again at 0900 hours, june 4th / the
timeslot has expired, you cannot enter this area any more."
When students access those pages when the time is right, they get to
see the pages, can fill the web forms or whatever, they can do what
they got to do.
Every access triggers a recheck of the authorization parameters (here:
within/without timeslot?)
That's the outline for a working examination system, solution #1.
When presenting this and the 'token hardware' is making someone panic
at the time the 'cost' of that pops up in the discussion -- and cost
it will, if only a small amount -- I strongly suggest to ditch the
whole client cert thing as the risk of certificate loss / theft is too
great for such an environment and go with oldfashioned
username/password systems as you won't surpass that degree of security
yet: simply code it up that users can log in anytime, they can only
view certain pages when those have been enabled through timeslot +
teacher activation.
As you mentioned the word VPN, you implicitly said you got network.
That's where the above will work.
If you don't have connectivity, things become a little different, but
the certificate versus password advice above remains as is. (And, yes,
this is a broad generalization, alas.)
If you don't want the examination itself to happen on a central
server, the above still applies, but needs an added level of
indirection, as it can be considered equivalent to a distributed
server scenario a la, for example, Domain Controllers in MS Windows
environments. Machine M sees individual X entering and sends request
about 'permissions' to central server. Central server responds to
server M with the given set of permissions and their [time]validity.
Server M's software thus determines what individual X is allowed to do
during this time on the machine.
Bottom line: one of your major tasks is finding out / setting up an
access control system which allows timeslot-enabled access to selected
areas. (authentication) Which is outside the scope of SSL.
Certificates, for servers, clients, or any other purpose/identity, are
basically to be regarded as /identification/. They also are a form of
/authentication/ as the identification may be considered secure (given
the proper context / conditions, which includes a PKI). Authorization
is an entirely different goal, which has authentication as a
[mandatory] prerequisite: after all, we need to know /who/ we're
authorizing / allowing to do X.
On a closing note: if the setting is not 'web pages', when translated
to SSL usage, it means authentication is/can be handled by SSL
(sidetrack: there's also anonymous-client connections where you
authenticate using application level protocol, such as in the case of
https:// based forums, where you log into a forum using
user+passphrase); /authorization/ is always handled in an overlay
(application layer), as SSL cannot not do this for you.
--
Met vriendelijke groeten / Best regards,
Ger Hobbelt
--------------------------------------------------
web: http://www.hobbelt.com/
http://www.hebbut.net/
mail: [email protected]
mobile: +31-6-11 120 978
--------------------------------------------------
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [email protected]
