Eu tenho um aplicativo MVC (.Net Framework 4.5) que está lá nos últimos três anos e usando o mecanismo de autenticação de formulários. Este aplicativo fornece contas diferentes, como pessoal, freebie, Enterprise etc. Para uma conta corporativa, estamos lidando com tudo no mesmo aplicativo. Ou seja Suponha que uma empresa chamada "xyz" criou uma conta corporativa com o aplicativo, então estamos fornecendo uma URL personalizada como "https://application/xyz/login"E da URL estamos identificando queempreendimento. Não sei o motivo exato pelo qual eles implementaram dessa forma, pois vi aplicativos que têm contas corporativas criadas como subdomínios (por exemplo, https://xyz.okta.com). Agora o cliente pediu para integrar o Okta neste aplicativo. Então eu olhei para Okta e encontrei o SAML é o caminho certo para fazer e acaba em Authorservices KentorIT. Inicialmente, consegui integrar isso com um aplicativo MVC de amostra e a parte de autenticação estava funcionando bem. Com alguma ideia básica sobre o SSO, comecei a integrar o authsevices da kentor em meu aplicativo. Os desafios que encontrei nesta implementação são:
1) Para contas corporativas, a configuração do Oktaas configurações são diferentes para cada empresa e com a implementação atual do aplicativo, não é possível configurá-lo a partir do web.config. Então tentei configurá-lo a partir do código e consegui integrar essas configurações substituindo Configuration.Options.FromConfiguration;. Estou planejando armazenar todas as configurações relacionadascoisas (URL de logon único, URI de audiência, Emissor do provedor de identidade "etc.) no banco de dados para que eu possa obter as informações sempre que eu quiser e suponho que" O ID do emissor do provedor de identidade é único para cada conta do Okta. um fluxo iniciado pelo IdP, quando o usuário tenta acessar o aplicativo, ele redireciona para o método de ação AuthServicesAcs e, a partir disso, eu estou tentando ler as definições de configuração.A partir da solicitação há alguma maneira de identificar qual chamada da conta Okta (como o emissor do provedor de identidade)? Atualmente, eu defino o "Emissor do Provedor de Identidade"valor (e acho que deve ser único paraokta) ao campo Default RelayState na guia General SAML settings e eu consegui recuperá-lo dos métodos de ação AuthServicesAcs. Parece ser uma boa ideia? Conselho por favor.
2) As contas Enterprise são limitadas com base emo número de licenças (digamos 50). Suponha que, se o administrador do Enterprise Okta intencionalmente adicionasse 55 usuários, todos esses usuários pudessem autenticar com êxito o aplicativo com base nas configurações padrão. Existe alguma maneira que eu possa lidar com esse cenário. Preciso manter um registro da lista de usuários que veio em uma conta corporativa específica?
3) Dos documentos eu entendo que o Kentorserviço de autenticação é apenas para autenticação e parte de autorização tem que ser feito a partir do próprio aplicativo. A implementação atual do aplicativo consiste em um atributo de autorização customizado que verifica as permissões do usuário que estão armazenadas no banco de dados. Isso deve estar lá como está e temos que fazer a autorização com base nas permissões do banco de dados. Certo?
Esperando suas sugestões valiosas e por favor me corrija se eu estiver errado. Agradecemos antecipadamente.
Respostas:
4 para resposta № 1Não use o RelayState para dados confidenciaisa menos que você assine criptograficamente. Ele não é protegido por nenhuma assinatura ao usar a ligação POST, portanto, o usuário pode manipulá-lo. Para obter o idp de emissão, verifique o campo do emissor de qualquer declaração gerada pelo AuthServices.
Sim.
Sim, essa é a idéia completa com Kentor.AuthServies: Para conectar a autenticação SAML2 ao modelo de segurança do .NET para permitir que você use qualquer configuração de autorização atual / tradicional.