Autenticação .NET personalizada, associação, provedor de perfil para portlets?

Question

Gostaria de saber se é possível aproveitar os recursos de autenticação, associação e/ou provedor de perfil no .NET para ajudar a integrar aplicativos da Web .NET no portal corporativo da minha empresa. Em poucas palavras, o portal envia valores de cabeçalho personalizados para qualquer aplicativo que esteja 'por trás' do portal para campos como o nome de usuário, os dados do perfil do usuário e alguns direitos de acesso. Uma questão que temos com o portal é que não conseguimos aproveitar muitos dos aplicativos .NET disponíveis na Web porque eles não foram projetados para ter "ciente do portal", principalmente para confiar que o usuário já se autenticou.

Seria possível escrever um provedor de autenticação personalizado (ou talvez alavancar os formulários de alguma forma) para apenas olhar para o cabeçalho (mais o IP) e automaticamente "autenticar" como esse usuário? Meu pensamento é que, ao escrever um provedor de perfil, possivelmente um provedor de associação e, de alguma forma, adicionando autenticação, seria capaz de baixar componentes legais como o Oxite Blog (Demoção .NET MVC que eu encontrei), Switch Fornesters to My Custom e alavancar Por trás do portal da minha empresa com alterações mínimas de código.

Isto faz algum sentido? Sinto que talvez não esteja entendendo como esses componentes se encaixam no quebra -cabeça.

Answer 1

Eu não acho que você possa fazer isso com zero alterações no aplicativo .NET, mas acho que você pode fazer isso com alterações mínimas. Observe que estou assumindo que o Portal Gateways tudo o que está indo para o aplicativo .NET Web. Ou seja, o portal recebe todas as solicitações HTTP do navegador, adiciona seus próprios cabeçalhos, envia a solicitação ao aplicativo .NET, recebe uma resposta do aplicativo .NET, reescreve as coisas um pouco mais e depois retorna informações ao navegador .

Suponho que o que acontece agora (a razão pela qual você escreveu essa pergunta) é que você incorpore esse aplicativo .NET em um portlet em seu portal, mas quando alguém tenta navegar nele, mesmo que esteja conectado ao seu portal, eles vêem A tela de login .NET externa dentro da caixa Portlet. Não é muito bom.

Há duas etapas que precisam ser tomadas aqui:

1. Re-Doe a página de login do aplicativo .NET para usuários de portlet de login automaticamente
2. Crie um provedor de associação personalizado que funcione junto com #1

1. Re-Doe a página de login do aplicativo .NET para usuários de portlet de login automaticamente

Encontre a página de login para o aplicativo .NET. Provavelmente será algo como login.aspx. Copie -o (e quaisquer arquivos CodeBehind associados) para portallogin.aspx e portalogin.cs. Abra os arquivos Portallogin.aspx e Portalogin.cs. Livre -se de todos os controles e código lá. Substitua -o por algo como o que você vê abaixo. Observe que em todos os lugares que você vê Portal_womeFunctionName, você precisará substituí -lo pelo código do SDK do seu portal que faz a chamada de função apropriada.

const string specialpassword = "ThisPasswordTellsTheBackendSystemThisUserIsOK";

Page_Load()
{
  if (PORTAL_IsLoggedInToPortal())
  {
    string username = PORTAL_GetCurrentUserName();
    // Authenticate the user behind the scenes
    System.Web.Security.FormsAuthentication.SetAuthCookie(username, false);
    System.Web.Security.FormsAuthentication.Authenticate(username, specialpassword);
  }
  else
  {
    throw new Exception ("User isn't coming from the Portal");
  }
}

Em seguida, edite web.config para o aplicativo .NET e diga que a página de login é portallogin.aspx em vez de login.aspx.

Isso deve cuidar automaticamente tentando registrar o usuário.

2. Crie um provedor de associação personalizado que funcione junto com #1

É aqui que você precisará criar um provedor de associação personalizado. Para que isso funcione, o aplicativo .NET com o qual você está trabalhando deve fazer uso de provedores de associação e permitir que um provedor de associação personalizado seja usado.

Crie um novo provedor de membros. Você precisa criar uma classe e herdar a partir de system.web.security.membershipprovider. No mínimo, acho que você precisará implementar as funções GetUser e ValidateSer e a propriedade ApplicationName. Abaixo estão algumas idéias de como elas poderiam parecer. São muitas mais funções que precisam ser substituídas, mas os stubs (com o NotImplementException (s) que acompanham) provavelmente podem ser deixados em paz.

    public override string ApplicationName
    {
        get
        {
            return "Portal";
        }
        set
        {
            ;
        }
    }

    private const string specialpassword = 
       "ThisPasswordTellsTheBackendSystemThisUserIsOK";

    public override bool ValidateUser(string username, string password)
    {
        // If the password being passed in is the right secret key (same  
        // for all users), then we will say that the password matches the
        // username, thus allowing the user to login 
        return (password == specialpassword);
    }

    public override MembershipUser GetUser(string username, bool userIsOnline)
    {
       string email = PORTAL_getemailfromusername(username);

       System.Web.Security.MembershipUser u = new MembershipUser(
         this.name, username, username, email, "", "", true, false, 
         DateTime.Now(), DateTime.Now(), DateTime.Now(), 
         DateTime.Now(), DateTime.Now(), DateTime.Now()
       );
       return u;
    }

Você também pode fazer implementações semelhantes para o .Net RoleProvider e o ProfileProvider se essa funcionalidade fosse útil na integração com este aplicativo .NET. (O provedor de função fornecerá informações de associação ao grupo, e o perfilprovider fornecerá bits extras de informações de perfil, como endereço de e -mail, ZipCode ou quaisquer outras propriedades que você deseja fornecer para cada usuário. Essas informações teriam que ser procuradas de um Banco de dados ou a partir das informações do cabeçalho HTTP do portal.

outras considerações

Como você está usando um provedor de autenticação de terceiros para esse aplicativo .NET externo, você precisa descobrir como pode dizer a isso .NET Aplicativo Quais usuários/grupos são administradores. Não posso lhe dizer isso - você terá que descobrir isso do aplicativo .NET de terceiros. Isso é necessário se houver alguma permissões necessárias para fazer qualquer coisa neste aplicativo .NET além de ter uma conta.

Como você está usando isso em um portal, existem algumas maneiras de ser usadas. Você pode ter apenas um grande portlet que mostra todo o aplicativo .NET da Web. Você também pode ter muitos pequenos portlets que mostram bits e peças do aplicativo .NET Web. De qualquer forma, você terá que considerar que o portal pode ou não renderizar as coisas corretamente quando colocar um aplicativo .NET completo dentro de uma pequena caixa de portlet em uma página de portal. Se você receber o HTML que parece ou funcionar estranho, será irritante consertá -lo. Você pode tentar corrigir o aplicativo .NET Web original para cuspir HTML diferente, ou pode adicionar um módulo ao IIS para reescrever o HTML em tempo real (não tenho certeza de que é um módulo ... você terá Para cavar alguns no IIS para descobrir como você pode fazer isso).

Ufa!

Sei que isso não cobre tudo, mas trabalhei com a criação do portal Plumtree (agora a interação do usuário aqualógico da BEA) como a fonte de autenticação dos serviços de relatórios do SQL Server da Microsoft, e implementei um provedor de autenticação personalizado para o IIS baseado em IIS. na associação do usuário armazenada em uma tabela de navegação dinâmica. Espero que minha experiência com esses projetos seja útil para você na integração deste aplicativo .NET externo com seu portal.

Tim

Answer 2

Eu acho que é uma ótima ideia. Você definitivamente deseja o provedor de membros e garante que a autenticação esteja definida como 'Formulários' para todos os aplicativos da Web .NET que você baixar.

Confira também o IIS7 porque seu pipeline recém -construído significa que você pode aproveitar os tipos de autenticação baseados em .NET em qualquer manipulador (CGI, etc). Por exemplo, você pode usar a autenticação do Windows para seus aplicativos PHP.

Answer 3

Um ponto menor que as outras respostas estão faltando é que forma a autenticação no ASP.NET suporta autenticação cruzada.

A tag de autenticação de formulários possui propriedades de nome de domínio e cookie.

Combiná -los e usar a mesma chave da máquina, permitirá a autenticação cruzada entre os aplicativos.

Seu provedor de associação para cada site precisará apontar para o mesmo armazenamento de dados.