Os requisitos são frequentemente formulados em termos de autenticação (mútua), integridade e confidencialidade, deixando a escolha do mecanismo de segurança a cargo dos implementadores e implantadores. O principal caso de uso do SAML é chamado de Login Único (SSO) em Navegador Web. Um usuário utiliza um agente de usuário (geralmente um navegador web) e solicita um recurso web protegido por um provedor de serviços SAML. O provedor de serviços, desejando saber a identidade do usuário solicitante, emite uma solicitação de autenticação a um provedor de identidade SAML por meio do agente de usuário.
Segurança SAML geral
As seções a seguir analisam os riscos de segurança no uso e implementação do SAML e descrevem as contramedidas usadas pelo plug-in/módulo miniOrange SAML SSO para mitigar os riscos.
- Asserções SAML:
No nível da asserção SAML em si, pouco há a ser dito sobre questões de segurança — a maioria das preocupações surge durante as comunicações no protocolo de solicitação/resposta ou durante a tentativa de usar SAML por meio de uma das vinculações. É claro que se espera sempre que o consumidor respeite o intervalo de validade da asserção e quaisquer elementos presentes na asserção. No entanto, uma questão no nível da asserção merece análise: uma asserção, uma vez emitida, está fora do controle do emissor. Esse fato tem várias ramificações. Por exemplo, o emissor não tem controle sobre por quanto tempo a asserção será persistida nos sistemas do consumidor; nem o emissor tem controle sobre as partes com as quais o consumidor/provedor de serviços compartilhará as informações da asserção. Essas preocupações vão além das preocupações com um invasor malicioso que pode ver o conteúdo das asserções que passam pela rede sem criptografia (ou com criptografia insuficiente). Embora esforços tenham sido feitos para resolver muitas dessas questões dentro da especificação SAML, nada contido na especificação eliminará a necessidade de consideração cuidadosa sobre o que incluir em uma asserção. Em todos os momentos, os emissores devem considerar as possíveis consequências caso as informações contidas na declaração sejam armazenadas em um local remoto, onde possam ser diretamente utilizadas indevidamente, ou expostas a potenciais hackers, ou possivelmente armazenadas para usos fraudulentos mais criativos. Os emissores também devem considerar a possibilidade de que as informações contidas na declaração possam ser compartilhadas com outras partes, ou mesmo tornadas públicas, intencionalmente ou inadvertidamente.
1.1. Protocolo SAML:
As seções a seguir descrevem considerações de segurança para o próprio protocolo de solicitação-resposta SAML, além de quaisquer ameaças decorrentes do uso de uma associação de protocolo específica.
1.1.1. Negação de serviço:
O protocolo SAML é suscetível a ataques de negação de serviço (DOS). Lidar com uma solicitação SAML é potencialmente uma operação muito custosa, incluindo a análise da mensagem de solicitação (normalmente envolvendo a construção de uma árvore DOM), consulta ao banco de dados/armazenamento de asserções (potencialmente em uma chave não indexada), construção de uma mensagem de resposta e, potencialmente, uma ou mais operações de assinatura digital. Portanto, o esforço exigido por um invasor para gerar solicitações é muito menor do que o necessário para lidar com essas solicitações.
1.1.2. Exigindo solicitações assinadas
O plugin/módulo miniOrange SAML SSO assina a solicitação, o que também reduz a ordem da assimetria entre o trabalho realizado pelo plugin SAML e pelo respondedor. O trabalho adicional exigido do respondedor para verificar a assinatura é uma porcentagem relativamente pequena do trabalho total exigido do respondedor, enquanto o processo de cálculo da assinatura digital representa uma quantidade relativamente grande de trabalho para o solicitante. Reduzir essa assimetria diminui o risco associado a um ataque DOS. Observe, no entanto, que um invasor pode, teoricamente, capturar uma mensagem assinada e reproduzi-la continuamente, contornando esse requisito. Essa situação pode ser evitada exigindo o uso do elemento de assinatura XML. contendo um registro de data e hora; o registro de data e hora pode então ser usado para determinar se a assinatura é recente. Portanto, quanto menor a janela de validade da assinatura após a emissão da resposta, maior a segurança contra ataques de negação de serviço de repetição.
2. Segurança de ligações SAML:
As considerações de segurança no design do protocolo de solicitação-resposta SAML dependem, em grande parte, da vinculação de protocolo específica (conforme definido na especificação de vinculações SAML [SAMLBind]) utilizada. As vinculações aprovadas pelo Comitê Técnico de Serviços de Segurança do OASIS são a vinculação SOAP, a vinculação SOAP Reversa (PAOS), a vinculação de redirecionamento HTTP, a vinculação de redirecionamento HTTP/POST, a vinculação de artefato HTTP e as vinculações de URI SAML. Os plug-ins SAML SSO do miniOrange suportam vinculações HTTP-Redirect e HTTP-POST.
2.1. Ligação de redirecionamento HTTP
2.1.2. Denial of Service
Ameaça: Redirecionamentos maliciosos para alvos de Provedor de Identidade ou Provedor de Serviço.
Descrição: Uma entidade espúria poderia emitir um redirecionamento para um agente de usuário para que este acessasse um recurso que interrompesse o Single Sign-On. Por exemplo, um invasor poderia redirecionar o agente de usuário para um recurso de logout de um provedor de serviços, fazendo com que o Principal fosse desconectado de todas as sessões de autenticação existentes.
Contramedidas: O acesso a recursos que produzem efeitos colaterais é especificado com um qualificador transitório que deve corresponder à sessão de autenticação atual. Alternativamente, uma caixa de diálogo de confirmação pode ser interposta, baseada em um qualificador transitório com semântica semelhante.
2.2. Ligação HTTP POST
2.2.1. Afirmação roubada
Ameaça: Se um intruso puder copiar a resposta SAML do usuário real e as asserções incluídas, ele poderá construir um corpo POST apropriado e ser capaz de representar o usuário no site de destino.
Contramedidas: Mantemos a confidencialidade sempre que uma resposta é comunicada entre o plugin SAML SSO e o navegador do usuário. Isso fornece proteção contra a possibilidade de um espião obter a resposta SAML e as asserções de um usuário real. Caso um espião descumpra as medidas utilizadas para garantir a confidencialidade, contramedidas adicionais estão disponíveis:
● Os sites do Provedor de Identidade e do Provedor de Serviços DEVEM envidar esforços razoáveis para garantir que as configurações de relógio em ambos os sites sejam diferentes em, no máximo, alguns minutos. Diversas formas de serviço de sincronização de tempo estão disponíveis, tanto pela internet quanto por meio de fontes proprietárias.
● Quando um perfil SAML não SSO utiliza a vinculação POST, ele deve garantir que o destinatário possa realizar a confirmação do assunto em tempo hábil. Para isso, uma asserção de autenticação SAML para o principal DEVE ser incluída na resposta do formulário POST.
● Os valores dos atributos NotBefore e NotOnOrAfter das asserções SSO DEVEM ter o menor período de validade possível, consistente com a comunicação bem-sucedida da asserção do Provedor de Identidade para o site do Provedor de Serviço. Isso normalmente é da ordem de alguns minutos. Isso garante que uma asserção roubada só possa ser usada com sucesso dentro de um curto período de tempo.
● O plugin miniOrange SAML SSO verifica o período de validade de todas as asserções obtidas do site do Provedor de Identidade e rejeita asserções expiradas. Optamos por implementar um teste de validade mais rigoroso para asserções SSO, como exigir que o valor do atributo IssueInstant ou AuthnInstant da asserção esteja dentro de alguns minutos do momento em que a asserção é recebida no site do Provedor de Serviço.
● Se uma declaração de autenticação recebida incluir um elemento com o endereço IP do usuário, o site do Provedor de Serviços PODE verificar o endereço IP do navegador em relação ao endereço IP contido na declaração de autenticação.
2.2.2. Afirmação Forjada
Ameaça: Um usuário mal-intencionado, ou o usuário do navegador, pode falsificar ou alterar uma asserção SAML.
Contramedidas: O perfil navegador/POST exige que a resposta SAML contendo as asserções SAML seja assinada, garantindo assim a integridade da mensagem e a autenticação. O plugin miniOrange SAML SSO verifica a assinatura e autentica o emissor.
2.2.3. Exposição do estado do navegador
Ameaça: O perfil navegador/POST envolve o upload de asserções do navegador para o site de um Provedor de Serviços. Essas informações estão disponíveis como parte do estado do navegador e geralmente são armazenadas em um armazenamento persistente no sistema do usuário de forma totalmente desprotegida. O risco aqui é que a asserção possa ser "reutilizada" posteriormente.
Contramedidas: As afirmações comunicadas usando este perfil devem sempre ter uma vida útil curta e devem ter uma Asserção SAML elemento. Espera-se que os sites dos provedores de serviços garantam que as asserções não sejam reutilizadas.
2.2.4. Responder
Ameaça: Ataques de repetição equivalem ao reenvio do formulário para acessar um recurso protegido de forma fraudulenta.
Contramedidas: O plugin miniOrange SAML SSO exige que as asserções transferidas tenham a propriedade de uso único, impedindo que ataques de repetição sejam bem-sucedidos.
2.2.5. Modificação ou Exposição de informações de estado
Ameaça: Adulteração ou fabricação do estado do relé. Algumas das mensagens podem conter uma elemento, cuja integridade é recomendada pelo produtor e, opcionalmente, a confidencialidade. Se essas práticas não forem seguidas, um adversário poderá desencadear efeitos colaterais indesejados. Além disso, ao não proteger a confidencialidade do valor desse elemento, uma entidade legítima do sistema pode inadvertidamente expor informações ao Provedor de Identidade ou a um invasor passivo.
Contramedida: Siga a prática recomendada de proteger a confidencialidade e a integridade dos dados do RelayState. Observação: como o valor deste elemento é produzido e consumido pela mesma entidade do sistema, primitivas criptográficas simétricas podem ser utilizadas.
3. Segurança de perfil SAML
A especificação de perfis SAML [SAMLProf] define perfis de SAML, que são conjuntos de regras que descrevem como incorporar asserções SAML e extraí-las de uma estrutura ou protocolo.
3.1. Perfis de logon único (SSO) do navegador da Web
Observe que a autenticação do usuário no site de origem está explicitamente fora do escopo, assim como questões relacionadas à autenticação deste site de origem. A ideia principal é que a entidade do sistema de origem deve ser capaz de verificar se a entidade do sistema cliente autenticada com a qual está interagindo é a mesma da próxima etapa de interação. Uma maneira de conseguir isso é executar essas etapas iniciais usando TLS como camada de sessão abaixo do protocolo usado para essa interação inicial (provavelmente HTTP).
3.1.1. Perfil SSO
3.1.1.1. Modificação de mensagem
Ameaça: Existe a possibilidade de alteração das mensagens no fluxo para este conjunto de perfis. Alguns resultados potencialmente indesejados são os seguintes:
● A alteração da solicitação inicial pode resultar na rejeição pelo emissor do SAML, ou
criação de um artefato direcionado a um recurso diferente do solicitado
● A alteração do artefato pode resultar em negação de serviço no consumidor SAML.
● A alteração das próprias afirmações durante o trânsito pode resultar em todos os tipos de
de maus resultados (se não forem assinados) ou negação de serviço (se forem assinados e
o consumidor os rejeita).
Contramedidas: Para evitar a modificação da mensagem, o tráfego precisa ser transportado por meio de um sistema que garanta a integridade da mensagem de ponta a ponta. Para perfis baseados em navegadores da web, o método recomendado para garantir a integridade da mensagem em trânsito é o uso de HTTP sobre TLS/SSL com um conjunto de cifras que forneça verificação da integridade dos dados.
3.1.2. Perfil de logout único
Ameaça: Um invasor passivo pode coletar o identificador de nome de um Principal. Durante as etapas iniciais, um invasor passivo pode coletar o informações quando são emitidas no redirecionamento. Expor esses dados representa uma ameaça à privacidade.
Contramedidas: Todas as trocas devem ser conduzidas por meio de um transporte seguro, como SSL ou TLS.
Ameaça: Um não assinado poderia ser injetado por uma entidade de sistema espúria, negando assim o serviço ao Principal. Supondo que o NameID possa ser deduzido ou derivado, é concebível que o agente do usuário possa ser direcionado para entregar um ID fabricado. mensagem.
Contramedidas: O plugin/módulo miniOrange SAML SSO assina o mensagem. O Provedor de Identidade também pode verificar a identidade de um Principal na ausência de uma solicitação assinada.
3.2. Perfis de gerenciamento de identificadores de nome
Ameaça: Permitir que entidades do sistema correlacionem informações ou exponham informações de identidade de forma inadequada, prejudicando a privacidade.
Contramedidas: O IDP deve ter o cuidado de usar identificadores de nome diferentes com diferentes provedores de serviço para o mesmo principal. O IDP deve criptografar o identificador de nome que retorna ao provedor de serviço, permitindo que interações subsequentes usem um identificador opaco.
3.2.1. Perfis de Atributos
Ameaças relacionadas a vinculações associadas a perfis de atributos foram discutidas acima. Não são conhecidas ameaças adicionais específicas a perfis.
4. Resumo
Segurança e privacidade devem ser abordadas de forma sistemática, considerando questões humanas como ataques de engenharia social, questões de política, gerenciamento de chaves e gerenciamento de confiança, implementação segura e outros fatores que estão fora do escopo deste documento. Soluções técnicas de segurança têm um custo, portanto, requisitos e alternativas de política também devem ser considerados como requisitos legais e regulatórios "obrigatórios". Este documento não normativo resume questões e abordagens gerais de segurança, bem como ameaças e contramedidas específicas para o uso de asserções, protocolos, vinculações e perfis SAML de forma segura e que mantenha a privacidade. Os requisitos normativos são especificados nas especificações normativas SAML.
