Single SignOn

ÍNDICE

Controle de Versões
Versão
Data
Autor
Notas da Revisão
1
22/01/2014
Gregory Anthony

1 Motivação e Objetivos
Temos diversos sistemas internos que realizam transações complementares entre si. Desse modo, não raro, usuários de um sistema têm a necessidade de autenticarem em outra aplicação, a fim de concluírem ou darem continuidade a suas atividades.
Outro problema que enfrentamos com a proliferação de sistemas, é a falta de uma visão central de quantos são, e quais são eles. Isso gera prejuízos que vão desde a baixa performance dos processos até a construção de funções repetidas devido ao desconhecimento de sua existência.
A título de exemplo, supondo um usuário com papel de professor, ele precisará acessar pelo menos os seguintes sistemas: SAGA2, SAGAUm, SVVPI, Network e SGPI. E para acessar cada um deles será preciso repetir o procedimento de autenticação (colocar login e senha), além de ter que guardar os endereços de cada um dos sistemas.
2 Benefícios esperados
Com o Single SignOn, queremos oferecer uma tecnologia de base, segura, multi-plataforma, e que proporcione a negociação de usuários autenticados entre as aplicações.
O Single SignOn também viabiliza a criação de um ponto único de acesso ás aplicações acadêmicas, diminuindo a complexidade no gerenciamento das aplicações, e endereços, por parte dos usuários.
Outro benefício para o usuário final será a melhoria da usabilidade uma vez que, dependendo da atividade, com o clique em um link, ele poderá entrar em outro sistema, ou ainda, sem sair de um sistema onde já está autenticado poder acessar “webparts” de uma segunda aplicação.
3 Escopo
A arquitetura do Single SignOn, foi dividida em 3 estruturas: Sistema Confiável, Sistema Destino, Base de Usuários.
PARTES INTEGRANTES DO SINGLE SIGNON
Sistema confiável
Sistema onde o usuário final já estará autenticado e de onde partirá a solicitação para entrada em outro sistema.
Sistema destino
Sistema que receberá a