Пользовательская .NET-аутентификация, членство, профиль провайдера для портлетов? - PullRequest
3 голосов
/ 03 февраля 2009

Мне интересно, можно ли использовать функции провайдера аутентификации, членства и / или профиля в .NET, чтобы помочь интегрировать веб-приложения .NET в корпоративный портал моей компании. Короче говоря, портал отправляет настраиваемые значения заголовков в любое приложение, которое находится «за» порталом, для таких полей, как имя пользователя, данные профиля пользователя и некоторые права доступа. Одна из проблем, с которыми мы сталкиваемся в работе с порталом, заключается в том, что мы не можем использовать многие из приложений .NET, доступных в Интернете, поскольку они не были предназначены для «поддержки портала», в первую очередь для того, чтобы доверять тому, что пользователь уже прошел аутентификацию.

Можно ли было бы как-то написать собственного провайдера аутентификации (или, может быть, каким-то образом использовать аутентификацию форм), чтобы просто посмотреть на заголовок (плюс IP) и автоматически "аутентифицировать" этого пользователя? Я думаю, что, написав поставщика профилей, возможно, поставщика членства, и каким-то образом добавив аутентификацию, я смогу загрузить классные компоненты, такие как блог Oxite (демо .net mvc, которое я нашел), переключить провайдеров на свой собственный и использовать рычаги это за порталом моей компании с минимальными изменениями кода.

Имеет ли это какой-то смысл? Мне кажется, что я не понимаю, как эти компоненты вписываются в головоломку.

Ответы [ 3 ]

3 голосов
/ 06 июля 2009

Я не думаю, что вы можете сделать это с нулевыми изменениями в приложении .Net, но я думаю, что вы могли бы сделать это с минимальными изменениями. Обратите внимание, что я предполагаю, что портал шлюз все, что идет в веб-приложение .Net. Таким образом, портал получает каждый HTTP-запрос от браузера, добавляет к нему свои собственные заголовки, отправляет запрос в приложение .Net, получает ответ от приложения .Net, переписывает что-то еще, а затем возвращает информацию в браузер. .

Я предполагаю, что сейчас происходит (причина, по которой вы написали этот вопрос), - вы встраиваете это приложение .Net в портлет на своем портале, но когда кто-то пытается перейти к нему, даже если они зарегистрированы на вашем портале они видят внешний экран входа в систему .Net внутри окна портлета. Не очень приятно.

Здесь необходимо выполнить два шага:

  1. Повторно выполните страницу входа для приложения .Net для автоматического входа пользователей портлета
  2. Создайте пользовательский поставщик членства, который работает вместе с # 1

1. Повторно выполните страницу входа в приложение .Net для автоматического входа пользователей портлета

Найдите страницу входа в приложение .Net. Вероятно, это будет что-то вроде login.aspx. Скопируйте его (и все связанные с ним файлы кода) в portallogin.aspx и portallogin.cs. Откройте файлы portallogin.aspx и portallogin.cs. Избавьтесь от всех элементов управления и кода там. Замените его чем-то вроде того, что вы видите ниже. Обратите внимание, что везде, где вы видите PORTAL_SomeFunctionName, вам нужно будет заменить его кодом из SDK вашего портала, который выполняет соответствующий вызов функции.

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");
  }
}

Затем отредактируйте файл web.config для приложения .Net и скажите ему, что страница входа - это portallogin.aspx, а не login.aspx.

Это должно обеспечить автоматическую попытку входа пользователя в систему.

2. Создайте пользовательский поставщик членства, который работает вместе с # 1

Здесь вам нужно будет создать собственного провайдера членства. Чтобы это работало, приложение .Net, с которым вы работаете, должно использовать поставщиков членства и разрешить использование настраиваемого поставщика членства.

Создать нового провайдера членства. Вам нужно создать класс и наследовать от System.Web.Security.MembershipProvider. Как минимум, я думаю, вам нужно реализовать функции GetUser и ValidateUser и свойство ApplicationName. Ниже приведены некоторые идеи о том, как они могут выглядеть. Существует множество других функций, которые необходимо переопределить, но заглушки (с сопровождающими исключениями NotImplementedException), вероятно, можно оставить в покое.

    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;
    }

Вы также можете сделать аналогичные реализации для .Net RoleProvider и ProfileProvider, если эти функции будут полезны при интеграции с этим приложением .Net. (Поставщик ролей предоставит информацию о членстве в группе, а ProfileProvider предоставит дополнительные биты информации профиля, такой как адрес электронной почты, почтовый индекс или любые другие свойства, которые вы хотите, чтобы он предоставлял для каждого пользователя. Эту информацию нужно искать из базы данных или из информации HTTP заголовка портала.

Другие соображения

Поскольку вы используете стороннего поставщика аутентификации для этого внешнего приложения .Net, вам необходимо выяснить, как вы можете сообщить этому приложению .Net, какие пользователи / группы являются администраторами. Я не могу вам этого сказать - вам придется это выяснить из стороннего приложения .Net. Это необходимо, если есть какие-либо разрешения, необходимые для выполнения каких-либо действий в этом приложении .Net, помимо наличия учетной записи.

Поскольку вы используете это на портале, есть несколько способов его использования. У вас может быть только один большой портлет, отображающий все веб-приложение .Net. У вас также может быть много маленьких портлетов, которые показывают кусочки веб-приложения .Net. В любом случае, вы должны учитывать, что портал может отображать или не отображать объекты должным образом, когда он помещает полное приложение .Net в маленькое поле с портлетами на странице портала. Если вы получаете HTML, который выглядит или работает странно, это будет неприятно исправить. Вы можете попытаться исправить исходное веб-приложение .Net, чтобы он выдавал другой HTML, или вы можете добавить модуль в IIS, чтобы переписать HTML на лету (я не совсем уверен, что это модуль ... у вас будет чтобы покопаться в IIS, чтобы понять, как это можно сделать).

Уф!

Я знаю, что это еще не все, но я работал над настройкой портала Plumtree (теперь BEA Aqualogic User Interaction) в качестве источника аутентификации для служб отчетов Microsoft SQL Server, и я реализовал пользовательский провайдер аутентификации для IIS на основе членства пользователя, хранящегося в таблице Dynamics NAV. Надеюсь, мой опыт работы с этими проектами поможет вам в интеграции этого внешнего приложения .Net с вашим порталом.

Tim
1 голос
/ 03 февраля 2009

Я думаю, что это отличная идея. Вы определенно нуждаетесь в поставщике членства и убедитесь, что для всех загружаемых веб-приложений .Net установлена ​​аутентификация «формы».

Также ознакомьтесь с IIS7, поскольку его недавно созданный конвейер означает, что вы можете использовать типы аутентификации на основе .Net в любом обработчике (CGI и т. Д.). Например, вы можете использовать аутентификацию Windows для ваших PHP-приложений.

0 голосов
/ 30 августа 2012

Один незначительный момент, который отсутствуют в других ответах, заключается в том, что проверка подлинности в asp.net поддерживает перекрестную проверку подлинности.

Тег проверки подлинности форм имеет свойства имени домена и cookie.

совпадение с этим и использование одного и того же ключа компьютера, позволит перекрестную аутентификацию между приложениями.

Ваш поставщик членства для каждого сайта должен будет указывать на одно и то же хранилище данных.

...