Автор работы: Пользователь скрыл имя, 22 Января 2013 в 20:48, дипломная работа
Исходя из этого, целью работы является разработать техногологию межсайтовой авторизации в сети интернет для портала ИМКН.
Для реализации технологии единого входа поставим перед собой следующие задачи:
Проанализировать существующие технологии единого входа (межсайтовой авторизации)
Настройка межсайтовой авторизации портала ИМКН
Тестирование настроек сайта или вопрос безопасности.
Введение 3
1.Технологии 5
1.1 1С - Битрикс 5
1.2 Технология переноса посетителей между сайтами 7
1.3 Модуль AD/LDAP 10
1.4 Схема работы модуля 13
1.5 Настройка многосайтовой конфигурации в 1С-битрикс. 14
1.6 OpenID 21
1.7 Кто контролирует OpenID? 22
1.8 Терминология OpenID 23
1.9 Simple Registration Extension 24
1.10 Применение технологии OpenID 26
1.11 Протокол Диффи-Хеллмана 27
1.12 Описание алгоритма 27
1.13 Недостатки OpenID в системе университета 35
1.14 Windows Live ID 37
1.15 SAML 38
2.Настройка межсайтовой авторизации между битриксом и удалёнными сайтами. 40
3.Безопасность при межсайтовом взаимодействии 49
Список литературы 51
Вывод это технология для университета не особо удобная так как может возникнуть путаница с логинами и подтверждением пользователей что он студен, назначение правильной группы и т.д. плюсом в OpenID не встроена защита от фишинга (для ввода пароля пользователя могут не перенаправить на страницу провайдера, а показать поддельную страницу, похожую на страницу провайдера). Однако многие провайдеры и дополнительные программы (например, расширения для Firefox) предоставляют эту защиту.
Windows Live ID — сервис идентификации и аутентификации предоставляемый системой Windows Live. Используется для единого входа на всех сетевых сервисах Microsoft, не только Windows Live. Имеет программную документацию для встраивания в собственные приложения и веб-сайты. По сути очень похоже на OpenID, только у OpenID провайдеров мног, а Windows Live ID он один.
В июле 1999 года сайты MSN Network получили систему Microsoft Passport, единый аккаунт для ряда веб-сервисов.
С развитием
система получила название .NET Passport.
Появилась возможность
Язык SAML (Security Assertion Markup Language) сможет обеспечить стандартный способ обмена аутентификационными и авторизационными данными между приложениями разных производителей. Стандарт SAML версии 1.1 — это XML-структура, разработанная организацией OASIS (Organization for the Advancement of Structured Information Standards). В версии 1.1 спецификации Liberty Alliance этот стандарт используется для поддержки единой Web-регистрации, а также служб аутентификации в соответствии со спецификацией Web Services Security. Web-службы открывают перспективу для стандарта SAML, и в ближайшем будущем такие продукты, как Nsure компании Novell и eTrust Admin компании Computer Associates, будут поддерживать SAML. Между тем ведущие производители ПО, включая компании CrossLogix, Tivoli Systems (в составе IBM), Netegrity, Novell, Oblix, RSA Security и Sun Microsystems, уже предлагают поддержку SAML в своих решениях безопасности, как и новая платформа .Net Server компании Microsoft.
Стандарт SAML поддерживает пароли, мандаты Kerberos, защищенные удаленные пароли, жетоны, открытые ключи (сертификаты X.509, SPKI, XKMS, SSL/TLS) и цифровые подписи XML.
Протоколы SAML определяют формат запросов и ответов. Обмен данными SAML предполагает наличие доверительных отношений между инициатором запроса и отвечающей стороной. Обе стороны должны ссылаться на один и тот же объект, например, существует только один объект с именем “Bruce” в домене безопасности “nwcinc.com”.
В соответствии со стандартом SAML каждый запрос и каждый ответ имеют общие заголовки, определяемые в SAML-документах пространством имен samlp. Все утверждения SAML начинаются с префикса, задающего пространство имен saml, и каждый из трех видов утверждений имеет соответствующий протокол запроса.
Помимо базовых протоколов, стандарт SAML также определяет параметры (артефакты) перенаправления браузера и единой регистрации. Артефакт ссылается на утверждение SAML, позволяя приложению или Web-серверу получить его.
Разработаем страницу с системе битрикс и назовём её auth_bix.php эта страница будет проверять с какого сайта пришел пользователь, и если он ещё не авторизирован на сайте то перенаправляем его на страницу авторизации, а если авторизирован то проверяем жива ли сессия и есть ли связка ID пользователя и то перенаправляем его на сайт с которго он пришол и подымаем там сессию.
В основу защиты я взял потокол Диффи-Хелмана который используется в технологии OpenID. Этот протокол позволяют двум сторонам сгенерировать общий ключ К, не передавая его по незащищённому каналу связи.
Как это выглядит на практике. Когда пользователь заходит на сайт происходит редирект на сайт битрикса, где с этим редиректом перенаправляются 3 сгенерированных переменных в процессе на сайте битрикса проверяется авторизирован ли пользователь (т.е. живы ли сессии и cookie) и если да то на странице битрикса вычисляется переменная и происходит редирект назад на страницу с которой пришел пользователь если есть связь в базе ID пользователя и сессии и совпадает ключ, то подымаем сессию и перенаправляем на пользовательскую страницу.
Схема генерации ключа по протоколу Дифи-Хелмана
auth_bix.php – странница на которую пересылаются пользователи с других сайтов , для авторизации в битриксе
index.php – главная странница сайта, с которой пользователи пересылаются на auth_bix.php для авторизации либо, подтвердив что автризациия уже выполнена и перенаправить назад уже авторизированным
config.php – содержит конфигурационные данные
function.php – страница с функциями к которым обращается index.php
logout.php – при переходе на эту странницу происходит закрытие сессии и уничтожение сессионных переменных
members.php – страница на которую пересылается в случае успешной авторизации на сайте
Структура файла auth_bix.php в битриксе
<?
require($_SERVER['DOCUMENT_
global $USER;
if(eregi("test1.ru",$_SERVER['
$lock = "true";
$site_k = "http://test1.ru/"; }
elseif(eregi("test2.ru",$_
$lock = "true";
$site_k = "http://test.ru/";
}
else $lock = "false";
}
if ($lock == "true") {
if ($_GET['auth'] == "qwerty") {
if ($_GET['close'] == "1") {$USER->Logout();};
if ($USER->IsAuthorized()) {
$login = $USER->GetParam("LOGIN");
$password = $USER->GetParam("PASSWORD_
header("Location:
".$site_k."index.php?auth=
}
else {
header("Location: ".$site_k."index.php?auth=1");
}
}
else {
if (isset($_GET['login'])) {
if (isset($_GET['pass'])) {
$login = trim($_GET['login']); $password = trim($_GET['pass']);
global $USER;
if (!is_object($USER)) $USER = new CUser;
$arAuthResult = $USER->Login($login, $password, "Y", "Y");
$APPLICATION->arAuthResult = $arAuthResult;
header("Location: ".$site_k."");
}
}
};
};
require($_SERVER['DOCUMENT_
?>
Структура файла config.php
<?php
include_once("functions.php");
session_register("login");
session_register("password");
session_register("loggedIn");
$messages=array();
$dbhost="localhost";
$dbuser="root";
$dbpass="";
$dbname="imkn_b";
$site = "http://sait_bitrix.ru/auth_
connectToDB();
?>
Структура файла function.php
<?php
function connectToDB() {
global $link, $dbhost, $dbuser, $dbpass, $dbname;
($link = mysql_pconnect("$dbhost", "$dbuser", "$dbpass")) || die("Couldn't connect to MySQL");
mysql_select_db("$dbname", $link) || die("Couldn't open db: $dbname. Error if any was: ".mysql_error() );
}
function displayErrors($messages) {
print("<b><small> Вы не можете войти в систему. Возможна одна из следующих причин:</small></b>\n<ul>\n");
foreach($messages as $msg){
print("<li><small>$msg</small>
}
print("</ul>\n");
}
function checkLoggedIn($status){
switch($status){
case "yes":
if(!$_SESSION["loggedIn"]){
header("Location: index.php");
exit;
}
break;
case "no":
if($_SESSION["loggedIn"]){
header("Location: members.php?".session_name()."
}
break;
}
return true;
}
function bitrix_pass($pass_baza,$
global $link,$messages;
$salt = substr($pass_baza, 0, (strlen($pass_baza) - 32));
$realPassword = substr($pass_baza, -32);
$password = md5($salt.$password);
if ($password == $realPassword) return true;
}
function checkPass($login, $password, $auth) {
global $link,$messages;
$query="SELECT * FROM b_user WHERE login='$login'";
$result=mysql_query($query, $link) or die("checkPass fatal error: ".mysql_error());
if(mysql_num_rows($result)==1) {
$userData=mysql_fetch_array($
if ($auth == "open") {
if ($userData['PASSWORD'] == $password) return $userData;
}
elseif ($auth == "1") {
if(bitrix_pass($userData['
};
}
else return false;
}
function cleanMemberSession($login, $password) {
global $link,$sid,$site;
$_SESSION["login"]=$login;
$_SESSION["password"]=$
$_SESSION["loggedIn"]=true;
header("Location:
".$site."?login=".$_SESSION["
/*
header("Location: http://imkn.ru/test1.php?
}
function cleanMemberSession2 ($login) {
global $link;
$_SESSION["login"]=$login;
$_SESSION["loggedIn"]=true;
}
function flushMemberSession() {
global $link;
unset($_SESSION["login"]);
unset($_SESSION["password"]);
unset($_SESSION["loggedIn"]);
session_destroy();
return true;
}
?>
Структура файла index.php
<?php
include_once("config.php");
checkLoggedIn("no");
global $sid,$site;
if ($_GET['auth'] == "open") {
if( !($userData = checkPass($_GET["login"], $_GET["pass"],$_GET["auth"])) ) {
$messages[]="Mejsaitovaa avtorizacia ne proshla";
}
if($messages){
doIndex();
exit;
}
cleanMemberSession2 ($_GET["login"]);
sleep(1);
header("Location: members.php?".session_name()."
}
elseif (!isset($_GET['auth'])) {
header("Location: ".$site."?auth=qwerty&id=$sid"
};
if($_GET["submit"]) {
field_validator("логин", $_GET["login"], "alphanumeric_space", "1","50");
field_validator("пароль", $_GET["password"], "alphanumeric_space"," 1", "50");
if($messages){
doIndex();
exit;
}
if( !($userData = checkPass($_GET["login"], $_GET["password"],1)) ) {
$messages[]="Вы ввели неверный логин/пароль, попробуйте снова";
}
if($messages){
doIndex();
exit;
}
cleanMemberSession($_GET["
} else {
doIndex();
}
function doIndex() {
global $messages;
global $title;
?>
<html>
<head>
<?php meta()?>
<meta content="text/html; charset=Windows-1251" http-equiv="content-type">
<title>test ::.</title>
<?php doCSS()?>
</head>
<body onLoad = document.go.login.focus(); >
<table border="0">
<tr >
<td width="347" valign="top" >
<h2 >Тестовая страница ::.</h2>
<h3 >Авторизация</h3>
<?php
if($messages) { displayErrors($messages); }
?>
<form name="go"
action="<?=$_SERVER["PHP_SELF"
<table width="224" height="107" border="0">
<tr>
<td width="81" height="31" class="wpmd">Логин:</td>
<td
width="133"><input type="text" title="логин" name="login"
onKeyUp="changeButtonStatus()" onChange="changeButtonStatus()
</tr>
<tr>
<td height="29" class="wpmd">Пароль:</td>
<td><input
type="password" title="пароль" name="password" onKeyUp="changeButtonStatus()"
onChange="changeButtonStatus()
</tr>
<tr>
<td> </td>
<td><input name="submit" title="Войти в систему" type="submit" value="Войти"></td>
</tr>
</table>
</form>
<script language="JavaScript">
<!--
var f=document.go;
function changeButtonStatus(){
f.submit.disabled=(f.login.
}
changeButtonStatus();
//-->
</script>
</td>
<td width="551" valign="top"> </td>
</tr>
</table>
</body>
</html>
<?php
}
?>
Структура файла logout.php
<?php
include_once("config.php");
global $sid,$site;
checkLoggedIn("yes");
flushMemberSession();
header("Location: ".$site."?auth=qwerty&close=1&
?>
Структура файла members.php
<?php
include_once("config.php");
checkLoggedIn("yes");
$query="SELECT * FROM b_user WHERE login='".$_SESSION["login"]."'
$result=mysql_query($query, $link) or die("checkPass fatal error: ".mysql_error());
$myrow = mysql_fetch_array($result);
?>
<head>
<?php meta()?>
<meta content="text/html; charset=Windows-1251" http-equiv="content-type">
<title>test</title>
<?php doCSS()?>
</head>
<body>
<?php welcome($myrow['NAME']); ?>
<?php
print("<table border='0' ><tr ><td height='30'>");
print("<td><img src='ris/exit.gif' width='16' height='16'><a href='logout.php?".session_
print("</tr></table>");
?>
</body>
</html>
Суть протокола Diffie-Hellman в генерации общего ключа К
двумя сторонами: А и Б. Но если у нас есть
кто-то «посередине» т.е. находится ещё
один сервер (М), кто может изменять трафик,
то может оказаться так, что А сгенерировал
общий с М ключ К1, а Б — общий с М ключ К2.
В итоге Вы (А) устанавливаете абсолютно
защищённое соединение с М, думая, что
установили соединение с Б. После этого
М устанавливает безопасное соединение
с Б и начинает передавать ему ваши запросы,
а вам — его ответы. Таким образом, М может
прослушивать взаимодействие А — Б и даже
модифицировать передаваемые сообщения.
Разумеется, подобная атака не пройдёт,
если клиент и сервер взаимодействуют
по HTTPS с полноценной проверкой сертификата.