view release on metacpan or  search on metacpan

Aut.pm  view on Meta::CPAN

=head1 ABSTRACT

Aut is an authorization framework that provides flexible backends
and flexible UIs (User Interfaces). It is build up around a combination
of backend hashing (see L<Aut::Backend::Conf|Aut::Backend::Conf> for an example) and RSA 
password encrypting and a ticket system and can be used to encrypt user 
data, while providing a secure escape to decrypt user data of a user whom 
lost his/hers password. 

=head1 DESCRIPTION

The goal of Aut is to provide a component that can be used to 
provide user authorization for applications. It's features are 
described in the following sections.

=head2 Flexible backends

Aut can be instantiated with your own backend. This could be a
backend that just uses e.g. the UNIX passwd system in combination
with some extra features. Or you could connect to LDAP, etc.

The backend provides the basis for security. A good backend should
be as secure as possible. The reference backend provided with this
package does not guarantee this security, because it's based on 
configuration files. Configuration files tend to be able to be
edited. So if someone wants to do harm, he/she could just delete
the RSA keys (explained later on) from the configuration file.

See L<Aut::Backend::Conf|Aut::Backend::Conf> for a reference interface.

=head2 Flexible UIs

Aut can be instantiated with your own User Interface. The reference
implementation is a Console Based one, that is clearly utterly simple.
There exists an other interface for wxPerl (L<Aut::UI::Wx|Aut::UI::Wx>).

E.g., when a user logs in using Aut, Aut will call the right UI functions
to establish the interaction with the user. See 
L<Aut::UI::Console|Aut::UI::Console> for a reference interface.

=head2 Ticket system

Aut works with a ticket system. If a user logs in, he/she gets a ticket.
This ticket gives the user his/hers rights in the context of an application.

Also a ticket is a container for other application specific things. So
an application can set() and get() all kinds of information that it needs
to provide context to a certain authorization level. E.g., an administrator
can have access to adminstration functionality through the ticket.

=head2 Encryption and decryption of user data

A default feature that is provided by the Aut framework is the possibility
to encrypt and decrypt data with the ticket. If a user has a valid ticket,
he/she can encrypt and decrypt his/hers data. This makes it possible to
use this ticket system with applications that store data that has to be
private. E.g. a patient document system.

There's a catch in such systems. If the user looses his/hers password,
he/she won't be able to decrypt his/hers data. This poses a problem
for helpdesks. The Aut systems provides the following  backup for this 
situation.

=head3 The backup system for lost passwords

If a user looses his/hers password, an administrator would normally
provide the user with a new password. However, this would mean that
the users looses all his/hers encrypted data, because his/hers password
is connected to the encrypted data by means of encryption/decryption keys.
This section describes the solution that Aut uses to address this problem.

=over 1

=item *

All data of a user is encrypted with a personal 'seed' value that is
stored with the user's account. 

=item *

This seed value is not world readable; it is encrypted with the user's 
password as key.

=item *

The user password must be hashed by the backend. L<Aut::backend::Conf|Aut::backend::Conf>
uses MD5 hashing, but a 'passwd' backend would use e.g. crypt() (and an unsafe
backend would probably store the password plaintext). As Hashes should be one way
functions (i.e. non invertable functions), the plaintext password cannot be retreived
from the  backend.

=item *

This is why the Aut system stores the user password also encrypted 
with a public RSA key. This RSA is part of the Aut framework.

=item *

The private key of the RSA keypair is stored encrypted with a single
password provided by the main administrator of the application. The 
password for this key could written down and be stored in on a physical
location, e.g. a safe in a trusted bank.

=item *

If the user looses his/hers password, a system administrator that knows
the password of the private key of the RSA keypair can reset the
user's password without loosing the seed value. With the private key,
the old RSA encrypted user password of the user is decrypted. The
seed is decrypted with the decrypted user password; and the new password
is used to re-encrypt the seed. 

=back

=head1 INTERFACE

=head2 Instantiating

=head3 C<new(Backend =E<gt> ..., UI =E<gt> ..., RSA_bits =E<gt> ..., Levels =E<gt> ..., Adminlevel =E<gt> ...) --E<gt> Aut>

=over 1

C<Backend> =E<gt> An C<Aut::Backend::...> object.