1. Un protocollo aperto e ben documentato;
2. SSO non solo WEB; Supporta anche la proxy autentication che permette per esempio anche a intere applicazioni di autenticarsi e non solo a client web.- Compliant con il procollo SAML per l’iterazione con altri sistemi SSO;
3. Una componente server open source; E’ possibile scaricarselo e installarselo in casa per testare l’ambiente. Funziona sia con apache 1 che apache 2.
4. Una vasta libreria di client per Java, Net, PHP, Perl, Apache, uPortal e altri ancora;
5. Integrato con uPortal, BlueSocket, TikiWiki, Mule, Liferay, ExO, Moodle e altri ancora
6. Vengono forniti molti esempi pronti all'uso.
7. Si tratta di un software con una comunità abbastanza robusta e attiva.
8. Rilasciato con aggiornamenti abbastanza cadenzati.
9. Scritto in java e open source.

Funzionamento

E' basato su cookie di sessione (come la maggior parte dei SSO).

CAS richiede SSL.

CAS usa LDAP per memorizzare le informazioni degli utenti connessi.

Quando un utente accede ad un sito CASizzato il sito lo reinderizza al server CAS. In questa fase un cookie viene salvato sulla macchina dell'utente. Questo cookie contiene un ticket univoco che lo identifica. Dopo che CAS ha verificato la sua identità lo rimanda indietro al sito di partenza. CAS aggancia un ticket unico alla URL del sito protetto.

Il sito protetto vede il ticket e manda tale ticket al CAS server. CAS chiede al servizio protetto se il ticket è buono. Se si l’accesso è garantito.

Client per CAS

Net Cas Client

.Net Http module

Acegi as CAS Client

ASP.NET Forms Authentication

AuthCAS

CAS + Seam Web Applications

CAS and JSR-168

CAS Client for Java 3.0

CAS Client for Java 3.1

CAS Proxying with ASP.Net Forms Authentication

CASBar- Toolbar for Firefox 2

CASP — CASP is an ASP .NET CAS client implementation in C #.

ColdFusion client script

Copy of CAS Client for Java 3.0

ISAPI Filter

Java Client

JSP Client

mod_auth_cas

MOD_CAS

mod_python auth module

PAM Module

Perl Client

phpCAS

CAS e Java

Per quanto riguarda la configurazione. Si mette un jar nel web-inf. Si configura un filtro (CAS in Java è gestito mediante Filter) e dovrebbe essere tutto a posto.

http://www.ja-sig.org/wiki/display/CAS/CASifying+Tomcat+Manager

CAS e .NET

http://www.ja-sig.org/wiki/display/CASC/ASP.NET+Forms+Authentication

In .NET viene usato un HTTPModule.

Esempio in DotNET

HTTPModule Filter Process

Il filtro HTTPModule è un programma C# che intercetta tutte le URL verso IIS 6.0 ed esegue le seguenti azioni:

il filtro controlla se si tratta di un utente valido guardando il cookie di sessione.

se un utente valido esiste (l'utente si è già autenticato all'applicazione corrente), lo USER ID è registrato nella collection degli elementi di contesto alla voce HTTP_USER e il controllo viene redirezionato alla URL richiesta. l'utente può essere prelevato in questo modo: string user = (string)Context.Items["HTTP_USER"];

Se non esiste un utente valido nel cookie di sesisone allora il filtro controlla il Ticket nel SSO Server.

se il ticket esiste (l'utente è stato già autenticato) il filtro inizia con il SSOServer il processo di validazione, uno user ID viene generato e salvato e crittato nel cookie di sessione e memorizzato nella collection di contesto alla voce HTTP_USER.

se la validazione fallisce viene generato un errore e il filtro torna un eccezione.

se nè esiste un utente valido, nè un ticket esiste (l'utente non si è autenticato) allora il filtro inizia un processo di login redirezionando il controllo al processo di SSO Login.

il filtro HTTPModule usa 2 files di configurazione per gestire questa fase:

il primo definisce i nomi di directory file e le directory del file di configurazione principale, se viene richiesta SSL, se e dove loggare le informazioni sul processo di filtro.

Il filtro HTTPModule è installato in ogni directory in cui si vuole intercettare la URL.

Se il filtro valido l'utente l'applicazione può leggere lo userID nella server variable HTTP_user.

Se il server SSO non valida l'utente l'applicazione non accederà mai alla URL richiesta.

Conclusioni

In buona sostanza CAS è un sistema di autenticazione puro e non di autorizzazione.

In altre parole consente di propagare l'identità dell'utente tra diverse applicazioni eventualmente istallate su server o in domini differenti mediante dei ticket crittografati. La determinazione dell'autorizzazioni assegnate ad un utente e l'enforcing delle policy di sicurezza sono compiti che spettano all'applicazione.

In effetti, è prassi utilizzare CAS in combinazione con un directory server in cui sono censite sia le identità degli utenti che i ruoli assegnati, tuttavia è responsabilità di ogni singola applicazione connettersi alla directory per accedere al profilo dell'utente e quindi applicare le dovute policy. Una possibile soluzione potrebbe essere quella di inserire nel ticket / cookie informazioni supplementari. Essendo il ticket scambiato di frequente non è una procedura consigliabile dato che il profilo di un utente può essere molto articolato mentre tale ticket deve essere il più snello possibile.

Riferimenti

http://www.ja-sig.org/products/cas/

http://wiki.case.edu/Central_Authentication_Service

http://www.ja-sig.org/wiki/display/CASC/.Net+Http+module
http://www.ja-sig.org/wiki/display/CASC/ASP.NET+Forms+Authentication
http://www.ja-sig.org/wiki/display/CASC/CAS+Proxying+with+ASP.Net+Forms+Authentication
http://www.ja-sig.org/wiki/display/CASC/ASP.NET+Forms+Authentication+with+Role+Provider

]]> http://paolosblog.wordpress.com/?p=162 Tue, 22 Jul 2008 08:38:32 +0000 P@olo http://paolosblog.it.wordpress.com/2008/07/22/autenticazione-tramite-public-key-in-linux/ Un ulteriore modo per rafforzare la sicurezza di un sistema Linux contro accessi non autorizzati è l'utilizzo della chiave pubblica (public key) durante la fase di login.

Vantaggi

• Elevato grado di sicurezza nel processo di autenticazione.
• Solo gli utenti con la chiave corretta possono autenticarsi nel sistema.
• Ogni chiave può essere protetta da password (ulteriore protezione).

Svantaggi

• Senza la giusta chiave non c'è modo di autenticarsi e quindi di accedere al sistema.
• La gestione delle chiavi può risultare laboriosa.

PROCEDURA

- generare la coppia di chiavi pubblica e privata.
ssh-keygen -t rsa

La chiave privata viene salvata nel file id_rsa.
La chiave pubblica viene salvata nel file id_rsa.pub.

- creare la directory nascosta .ssh nella home user.
mkdir ~/.ssh

- copiare la chiave pubblica nel file authorized_keys.
cat id.rsa.pub > ~/.ssh/authorized_keys

- impostare i permessi sul file per evitare che altri utenti possano leggere i dati della chiave.
chmod go-w ~/
chmod 700 ~/.ssh
chmod go-rwx ~/.ssh

- editare il file sshd_conf (deve essere effettuato come root).
su -
vi /ets/ssh/sshd_conf

- identificare e modificare i parametri come indicato.

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no

- riavviare il servizio ssh per attivare la nuova configurazione
service sshd restart

Una volta effettuato il restart del servizio ssh, l'unico modo per effettuare un login remoto è tramite l'utilizzo delle chiavi generate.

Per generare la chiave pubblica e privata è possibile utilizzare anche altri tools come ad esempio puttygen, membro della famiglia puTTY e soggetto a licenza MIT compatibile con la GNU GPL.

- p@olo

In un precedente tutorial abbiamo visto come usufruire degli strumenti che Tomcat ci mette a disposizione per gestire l'autenticazione degli utenti del nostro sistema.

In questa breve guida, invece, vedremo come "istruire" Tomcat a leggere i dati degli utenti (user name, password e ruoli) da un database.

I prerequisiti necessari sono essenzialmente due:

1. Apache Tomcat 5.x
2. MySQL 5.0 (anche se la configurazione per altri DBMS è molto simile)

Poiché sia Tomcat e MySQL sono multi-piattaforma, le istruzioni riportate di seguito saranno valide per diversi sistemi operativi (Linux, Windows, Mac, ... ).

Per prima cosa dobbiamo scaricare i driver JDBC che MySQL ci mette a disposizione qui, scompattare l'archivio e copiare il file mysql-connector-java-x.x.x.x-ga-bin.jar nella directory $CATALINA_HOME/common/lib , dove per $CATALINA_HOME si intende il path della vostra installazione di Tomcat .

Dopo di che dobbiamo inserire nel database le tabelle che conterranno rispettivamente gli utenti e i ruoli delgi utenti del nostro sistema:

[sourcecode language='sql']
create table users (
user_name varchar(15) not null primary key,
user_pass varchar(15) not null
);

create table user_roles (
user_name varchar(15) not null,
role_name varchar(15) not null,
primary key (user_name, role_name)
);[/sourcecode]
Ovviamente questo è solo un esempio, possiamo rinominare a piacimento tabelle e attributi, o aggiungerne altri.
Vi faccio notare inoltre che le password degli utenti verranno memorizzate in chiaro; sarebbe meglio fare un digest delle password (md5, etc ...), ma questo esula gli scopi di questa guida.Fatto ciò, ci basta modificare il file $CATALINA_HOME/conf/server.xml nel seguente modo:
[sourcecode language='xml']

...

driverName="org.gjt.mm.mysql.Driver"
connectionURL="jdbc:mysql://localhost/nome_db"
connectionName="test" connectionPassword="test"
userTable="users" userNameCol="user_name" userCredCol="user_pass"
userRoleTable="user_roles" roleNameCol="role_name" />

...

[/sourcecode]
Non abbiamo fatto altro che commentare il Realm di default (righe 3-6) e inserire un nuovo Realm (righe 8-13) , lasciando inalterato il resto del file.Per ulteriore chiarezza descriverò i principali attributi del nuovo Realm:

• connectionURL indica il percorso del nostro database; al posto di nome_db dovete inserire il nome del vostro database dove avete creato le due tabelle
• in connectionName e connectionPassword dovrete inserire le credenziali per l'accesso al suddetto db
• in userTable e userRoleTable inserire rispettivamente il nome della tabella degli utenti e della tabella dei ruoli
• intuitivamente in userNameCol, userCredCol e roleNameCol è necessario inserire i nomi delle rispettive colonne

Ora non ci resta che riavviare Tomcat e verificare se tutto è andato per il verso giusto.

Implementare ex novo un sistema di autenticazione per il nostro portale web è un processo lungo e faticoso. Per fortuna molti servlet container ci mettono a disposizione dei sistemi di autenticazione belli e pronti.

Se il vostro servlet container è Apache Tomcat questa guida può fare al caso vostro.

Procederò dando per scontato che abbiate installato Tomcat 5.x o superiore sulla vostra macchina; inoltre tutte le modifiche proposte saranno piattaforma indipendenti ( Linux, Mac, Windows ... ).

Tomcat ci offre ben cinque tipi diversi di autenticazione:

• HTTP basic authentication
• Form-based login authentication
• Client certificate authentication
• Mutual authentication
• Digest authentication

In questo breve tutorial mi concentrerò sulla "Form-Based Authentication".

Essa permette di gestire il login da una form da noi creata ma non prevede alcun tipo di crittografia su dati, che viaggeranno in chiaro sulla rete.

Il comportamento di questo meccanismo può essere facilmente compreso dando uno sguardo alla seguente immagine

Per utilizzare la Form-based login authentication dobbiamo innanzi tutto creare un file contenente la form per l'autenticazione che chiameremo per coerenza con l'immagine precedente "login.jsp".

Questo file per assolvere al suo compito deve contenere necessariamente al suo interno una form così strutturata:
[sourcecode language='html']

[/sourcecode]
Dopo di che si dovrà modificare il file "web.xml" in tre passi :

1. Diciamo a Tomcat che vogliamo utlizzare la Form-based login authentication, dove si trova il file contenente la form e come si chiama:
   [sourcecode language='xml']
   

   FORM

   Richiesta Autenticazione

   /login.jsp /login.jsp

   [/sourcecode]
   In questo esempio abbiamo indicato la pagina "login.jsp" anche come error page, sarebbe una buona cosa distinguere i due casi di modo che l'utente si accorga di avere inserito delle credenziali errate nella form.

2. Creiamo i security roles:
   [sourcecode language='xml']
   

   Amministratore del sistema
   admin

   Utente generico
   user
   [/sourcecode]
   In questo caso abbiamo creato due ruoli che poi verranno assegnati a uno o più utenti, come descriverò in seguito.

3. Delimitiamo le aree che vogliamo riservare inserendo le seguenti righe:
   [sourcecode language='xml']
   

   Area Riservata 1

   /

   user

   Area Riservata 2

   /admin

   admin

   [/sourcecode]
   Abbiamo creato due aree riservate con path "/admin" e "/" a cui possono accedere rispettivamente solo gli utenti con ruolo admin e con ruolo user.

Fatto ciò non ci resta che creare gli utenti e assegnare loro dei ruoli.

Esistono diversi modi per fare ciò.

In questa guida illustrerò il più semplice, che consiste nell'editare il file "$CATALINA_HOME/conf/tomcat-users.xml", dove per "$CATALINA_HOME" si intende il path della vostra installazione di Tomcat.

Un esempio di file "tomcat-users.xml" può essere il seguente:

[sourcecode language='xml']

[/sourcecode]
In questo breve tutorial spiego come interfacciare Tomcat a un database in modo che esso, invece di leggere dal file "tomcat-users.xml", esegua delle query al DB per autenticare gli utenti.

Dopo tutte queste modifiche, neanche a dirlo, è necessario RIAVVIARE Tomcat.

(Via Punto Informatico)

Roma - S'è cucinata una piccola grande rivoluzione nelle scorse ore: il ministero dell'Interno ha dichiarato in modo ufficiale e definitivo che è accettabile autenticare gli utenti delle reti WiFi anche tramite SMS, il che significa dare un calcio al grosso di quella burocrazia che sta frenando, insieme a molte altre cose, lo sviluppo del wireless italiota. [continua a leggere]

Autenticazione, Wireless

gcc -lcrypt -o eseguibile codice.c

per entrambi i programmi.

[sourcecode lang='cpp']
#include
#include
#include
#include
#include
#include

void insert(char*,char*);
int main(int argc,char* argv[])
{
if(argc != 2){
printf("Usage: %s username\n",argv[0]);
return 0;
}

if(strlen(argv[1])>34){
fprintf(stderr,"L'username contiene troppi caratteri,ridurne la dimensione\n");
return 1;
}

unsigned long seed[2];
char salt[] = "$1$........";
const char *const seedchars =
"./0123456789ABCDEFGHIJKLMNOPQRST"
"UVWXYZabcdefghijklmnopqrstuvwxyz";
char *password;
int i;

/* Genera dei seeds (non troppo) casuali. */
seed[0] = time(NULL);
seed[1] = getpid() ^ (seed[0] >> 14 & 0x30000); //usiamo il pid del processo per rendere il seme abbastanza casuale

/*A partire dai due numeri pseudocasuali in seed[0] e seed[1] è possibile costruire un vettore di 10 caratteri ascii salt,da dare in pasto alla funzione crypt,grazie ad esso l'algoritmo basato su md5 può partorire la password */
for (i = 0; i < 8; i++)
salt[3+i] = seedchars[(seed[i/5] >> (i%5)*6) & 0x3f];
/* getpass riceve la password dell'utente e crypt effettua il calcolo dell'hash */
password = crypt(getpass("Password:"), salt);
insert(argv[1],password); //Inserisce la entry con nomeutente e pass sul file shadow
return 0;
}

void insert(char* user,char* pwd){
FILE *fd;
char buffer[35];
char *old;
char *passwd=malloc(strlen(pwd));
/*il puntatore pwd punta ad un'area di memoria dove la funzione getpass precedentemente invocata ha allocato la password immessa dall'utente.Se get pass deve essere invocato per l'immissione di una nuova password è necessario spostare il contenuto di quella precedente in un'altra area di memoria.*/
strcpy(passwd,pwd);
if(!(fd = fopen("shadow","r+"))){ //routine standard di apertura del file in lettura
fprintf(stderr,"Errore nell'apertura del file\n");
exit(0);
}
while(!feof(fd) && strcmp(buffer,user)) //scansione del file shadow
fscanf(fd,"%s",buffer);

if(feof(fd)){ //se il puntatore al file è arrivato alla terminazione senza trovare l'utente...
fclose(fd);
char *entry=malloc(strlen(user)+2+strlen(passwd));
strcpy(entry,user);
strcat(entry," ");
strcat(entry,passwd);
strcat(entry,"\n");
fd = fopen("shadow","a"); //routine standard di apertura del file in lettura
/* scrivi la nuova entry su shadow nella directory corrente con lo username,uno spazio e l'hash */
if(fprintf(fd,"%s",entry) < strlen(entry))
fprintf(stderr,"Errore di scrittura sul file\n");
fclose(fd); //chiudi lo stream
exit(0);
}

fscanf(fd,"%s",buffer); //se l'utente invece è stato trovato,la stringa successiva è la sua password
printf("Procedura di sostituzione password per l'utente %s\n",user);
old=crypt(getpass("Password Vecchia:"), buffer);
if(strcmp (buffer,old) == 0){
fseek(fd,-34,SEEK_CUR);
char *entry=malloc(strlen(passwd)+1);
strcpy(entry,passwd);
strcat(entry,"\n");
if(fprintf(fd,"%s",entry) < strlen(entry)){
fprintf(fd,"Errore di scrittura sul file\n");
fclose(fd);
}
}
else{
fprintf(stderr,"Spiacente,password Errata\n");
fclose(fd);
}
}[/sourcecode]
[sourcecode lang='cpp']

#include
#include
#include
#include

void check(int);
void usr_in();
void pwd_r(char*,char*);
int main(int argc,char* argv[])

/* Il primo e unico argomento è il nome utente*/
{
if(argc != 2){
printf("Usage: %s username\n",argv[0]);
return 0;
}

char pass[35]; //utilizziamo un buffer di 35 bytes per la password criptata

/*la funzione pwd_r legge il file delle password e carica sul buffer l'hash della password per quell'utente*/
pwd_r(argv[1],pass);

char *result;
int ok;

/* Leggi la password dell'utente e calcolane l'hash,immettendo anche la pass attesa*/
result = crypt(getpass("Password:"), pass); //getpass è una funzione di unistd che prompta la password

/* Testa il risultato confrontando il buffer con l'hash della frase immessa dall'utente. */
ok = strcmp (result, pass) == 0;

check(ok); //ok è 1 se l'hash della password immessa è uguale a quella reale presente nel file
}

void check(int p_chk){ //se le due hash corridpondono il processo di login procede con l'accesso dell'utente
p_chk ? usr_in() : printf("Authentication Failure\nSpiacente.\n");
}

void pwd_r(char* user, char *buffer){
FILE *fd;
if(!(fd = fopen("shadow","r"))){ //routine standard di apertura del file in lettura
fprintf(stderr,"Errore nell'apertura del file\n");
exit(0);
}

/*stringa per stringa si effettua la ricerca dell'utente scelto fino alla terminazione del file*/
while(!feof(fd) && strcmp(buffer,user))
fscanf(fd,"%s",buffer);

if(feof(fd)){
printf("L'utente non esiste\n");
exit(0);
}

fscanf(fd,"%s",buffer); //se l'utente è stato trovato la stringa successiva è la sua password
fclose(fd);
}

void usr_in(){
printf("Accesso effettuato\n");
}[/sourcecode]

Mi sono reso conto ricercando documentazioni in rete che le guide disponibili sul web su come installare il protocollo sono un pò confusionarie ed incomplete (o per lo meno quelle che ho trovato io lo erano)...diciamo che per mettere su il sistema ho dovuto prendere indicazioni da più tutorials. Come se non bastasse per superare alcuni problemi che ho trovato in fase di configurazione ho comunicato direttamente (via chat e mail) con alcuni membri del MIT (Massachusetts Institute of Technology)...i creatori di Kerberos, per intenderci.

Tutte queste informazioni le ho naturalmente organizzate ed inserite nella tesina realizzata; ora...visto che alcuni di voi potrebbero averne bisogno ho deciso di estrarre una parte della tesina e metterla a disposizione, in modo che abbiate un chiaro riferimento per riuscire installare il sistema Kerberos sulle vostre macchine.

Per scaricare il documento in formato PDF vi basta cliccare su questo link: Guida Kerberos.

Per chi non conosce ancora Kerberos allego anche una breve descrizione presa da Wikipedia: "Kerberos è un protocollo di rete per l'autenticazione tramite crittografia che permette a diversi terminali di comunicare su una rete informatica insicura provando la propria identità e cifrando i dati. Kerberos previene l'intercettazione e i replay attack, e assicura l'integrità dei dati. I suoi progettisti mirarono soprattutto ad un modello client-server, e fornisce una mutua autenticazione — sia l'utente che il fornitore del servizio possono verificare l'identità dell'altro. Kerberos si basa sulla crittografia simmetrica e richiede una terza parte affidabile."

Spero che queste informazioni possano esservi utili.