afirmação SAML com nome de usuário / senha - o que as mensagens realmente se parece?

Question

Eu preciso criar um algumas asserções SAML 2.0, e eu estou tendo dificuldades para encontrar o que o XML deve realmente se parecem. A maioria da documentação parece ser sobre o uso de ferramentas específicas, e não sobre as mensagens. Eu tenho os esquemas, com uma infinidade de possibilidades, mas não consigo encontrar um exemplo do que as mensagens relevantes realmente parecido na prática.

A regra de negócio diz: a fim de criar uma identidade compartilhada, o usuário informa sistema Um nome de usuário e senha no sistema B. Sistema A precisa de comunicar esta informação (juntamente com alguns dados demográficos) para o sistema B. Sistema B valida a informação e passa de volta um identificador único que pode então ser usado para se referir a este usuário.

Alguém poderia me dar um exemplo do que SAML 2.0 afirmações seria semelhante para realizar esta informação?

FWIW, eu estou usando C # e necessidade de passar o XML em torno de formas que impedem usando uma ferramenta de 3rd-party.

Answer 1

Eu não tenho certeza seu caso de uso é bem o SAML 2.0 faz.

O que você descreve como suas regras de negócios realmente se parece com um caso de uso para a identidade de provisionamento, não gerenciamento de acesso.

casos de uso SAML Standard 2.0 concentrar em uma festa de identidade afirmando (o provedor de identidade) e a outra parte (ou partes) contando com essas afirmações (a operadora). Afirmações realizar o que é chamado um identificador de nome, cuja utilização é acordado antes do tempo entre o provedor de identidade eo prestador do serviço.

Estes identificadores nome pode ser praticamente qualquer coisa, mas eles amplamente caem em duas categorias: transitória e persistente. Um identificador nome transitória só é útil no contexto da sessão atual (e, essencialmente, apenas diz: "Eu sei quem é essa pessoa") e tende a ser usado para proteger a identidade do principal, permitindo o acesso privilegiado de algum tipo. Um identificador persistente pode ser opaco (de uma forma semelhante à forma como OpenID é usado para acesso SO) onde o partido afirmando repetidamente pode verificar a identidade de um princípio sem revelar a sua identidade, mantendo uma dinâmica, mas estável compartilhada identificador entre as partes afirmando e contando ou mais substancial, como um diretório UPN ativo (que pode ser pré-acordado antes do tempo).

Quando se trata de senhas, como você menciona na sua pergunta, o prestador de serviços (contando partido) nunca vê a senha de usuários. O prestador de serviços entrega o usuário para o provedor de identidade com uma solicitação de autenticação. O provedor de identidade envia a parte de trás do usuário ao provedor de serviço com uma resposta, que no caso de autenticação bem-sucedida contém uma afirmação sobre a identidade do usuário no contexto da relação entre o provedor de identidade eo prestador do serviço.

No contexto da sua pergunta, a coisa mais importante é que SAML 2.0 não fornece uma maneira de tanto criar a conta local "aplicativo" user ou link que conta de usuário local para uma identidade federada. Isso simplesmente não é o problema SAML 2.0 tenta resolver.

Agora, de volta para o seu negócio governa ...

Parece-me que o que você está tentando fazer é qualquer conta ligando ou de registo - eu abordá-lo como este:

• visitas usuário do aplicativo, clicar em um botão para a identidade uso do provedor de identidade
• A aplicação produz uma solicitação de autenticação e direciona o usuário para o provedor de identidade, levando o pedido de autenticação
• O provedor de identidade quer logs do usuário ou reutiliza uma sessão de identidade existente se o usuário tem um. O IDP produz uma mensagem de resposta contendo uma afirmação sobre o utilizador. No seu caso esta afirmação deve, no mínimo, levar um identificador de nome persistente. O provedor de identidade dirige a parte de trás do usuário ao aplicativo, levando a mensagem de resposta.
• A aplicação processa a mensagem de resposta. Se existe uma entrada de mapeamento para o identificador persistente passou o utilizador é reconhecido de que o mapeamento e conectado como esse utilizador aplicação local. Se não houver uma entrada de mapeamento o usuário pode ser solicitado a fazer logon localmente, e em login local bem sucedida pode ser produzido a entrada de mapeamento, ou uma conta de usuário pode ser criado automaticamente e o usuário pode ser solicitado a inserir informações adicionais (nomes, endereços de e-mail , etc.) o caso de uso "corporate" seria que nenhuma conta automática ligando ou criação é permitido e que o mapeamento deve existir antes do tempo.

Quanto ao conteúdo das mensagens ...

O href="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security" rel="noreferrer"> Comitê Técnico OASIS tem um arquivo zip Download disponível com extensa documentação das peças do esquema XML, incluindo exemplos. Também é bem interessante ler a documentação do protocolo e do perfil, uma vez que estes descrevem o fluxo de mensagens entreas partes envolvidas na conversa identidade.

Há um grande número de apresentações por aí que eu achei muito útil. Especificamente, SAML v2.0 Basics por Eve Maler me ajudou a começar a perceber quais os problemas SAML v2.0 estava tentando resolver. Esta apresentação inclui exemplos de que as afirmações parecem. Existe uma apresentação atualizada e links para recursos adicionais na saml.xml.org .

Eu não tenho certeza se qualquer um isso vai ajudar, porém, como o caso de uso não parece ser o que SAML 2.0 está tentando fazer. Você pode adicionar atributos e extensões conforme necessário para solicitações e respostas, mas eu não posso ver muitos provedores de identidade fazer qualquer coisa com esses atributos e respostas.