✖


Jump to content

SAML 1.1

Edit links

Язык разметки утверждений безопасности (SAML) — это стандарт XML для обмена данными аутентификации и авторизации между доменами безопасности. SAML — это продукт OASIS (организации) Технического комитета служб безопасности .

SAML 1.1 был ратифицирован в качестве стандарта OASIS в сентябре 2003 года. Важнейшие аспекты SAML 1.1 подробно описаны в официальных документах SAMLCore. [ 1 ] и SAMLBind. [ 2 ] Если вы новичок в SAML, вам, вероятно, следует сначала прочитать вводную тему SAML , а затем обзор SAMLO. [ 3 ] документ из ОАЗИСа.

До SAML 1.1 SAML 1.0 в ноябре 2002 года в качестве стандарта OASIS был принят . Начиная с версии 1.0, которая сама по себе является относительно простым протоколом, SAML претерпел одну незначительную (V1.1) и одну крупную редакцию (V2.0). Однако SAML 1.0 представляет не только исторический интерес, поскольку Федеральная инициатива электронной аутентификации США приняла SAML 1.0 в качестве своей основной технологии.

Версии 1.0 и 1.1 SAML аналогичны. См. SAMLDiff [ 4 ] для конкретных различий между двумя стандартами. В этой статье основное внимание уделяется SAML 1.1, поскольку это важный стандарт, от которого зависят многие другие стандарты и реализации.

Предупреждение. Разработчикам и развертывателям следует учитывать, что все примеры кода в этой статье не являются нормативными и предназначены только для иллюстрации. см . в спецификациях OASIS SAML Нормативные требования .

Утверждения SAML 1.1

[ редактировать ]

SAML Утверждения содержат утверждения , которые поставщики услуг используют для принятия решений по управлению доступом. Например, операторы аутентификации подтверждают поставщику услуг, что принципал действительно прошел аутентификацию у поставщика удостоверений в определенное время с использованием определенного метода аутентификации. Другая информация о принципале может быть раскрыта в заявлении об аутентификации. Например, в приведенном ниже операторе аутентификации адрес электронной почты принципала передается поставщику услуг: 

  <saml:Assertion
    xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
    MajorVersion="1" MinorVersion="1"
    AssertionID="buGxcG4gILg5NlocyLccDz6iXrUa"
    Issuer="https://idp.example.org/saml"
    IssueInstant="2002-06-19T17:05:37.795Z">
    <saml:Conditions
      NotBefore="2002-06-19T17:00:37.795Z"
      NotOnOrAfter="2002-06-19T17:10:37.795Z"/>
    <saml:AuthenticationStatement
      AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"
      AuthenticationInstant="2002-06-19T17:05:17.706Z">
      <saml:Subject>
        <saml:NameIdentifier
          Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
          [email protected]
        </saml:NameIdentifier>
        <saml:SubjectConfirmation>
          <saml:ConfirmationMethod>
            urn:oasis:names:tc:SAML:1.0:cm:bearer
          </saml:ConfirmationMethod>
        </saml:SubjectConfirmation>
      </saml:Subject>
    </saml:AuthenticationStatement>
  </saml:Assertion>

Адреса электронной почты (как в приведенном выше примере) будет достаточно во многих ситуациях. Однако в некоторых случаях необходима дополнительная информация, прежде чем поставщик услуг сможет принять решение по управлению доступом. В качестве примера предположим, что студентам разрешен доступ к данным о стипендиях. В заявлении атрибута может указываться, имеет ли директор статус «студент», который поставщик услуг использует для разрешения или запрета доступа (соответственно) к заявке на стипендию: 

  <saml:Assertion
    xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
    MajorVersion="1" MinorVersion="1"
    Issuer="https://idp.example.org/saml" ...>
    <saml:Conditions NotBefore="..." NotAfter="..."/>
    <saml:AuthenticationStatement
      AuthenticationMethod="..."
      AuthenticationInstant="...">
      <saml:Subject>...</saml:Subject>
    </saml:AuthenticationStatement>
    <saml:AttributeStatement>
      <saml:Subject>...</saml:Subject>
      <saml:Attribute
        AttributeName="urn:mace:dir:attribute-def:eduPersonAffiliation"
        AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri">
        <saml:AttributeValue>member</saml:AttributeValue>
        <saml:AttributeValue>student</saml:AttributeValue>
      </saml:Attribute>
    </saml:AttributeStatement>
  </saml:Assertion>

Атрибуты часто получаются из каталога LDAP , поэтому решающее значение имеет согласованное представление атрибутов в разных доменах безопасности.

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

  <saml:Assertion
    xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
    MajorVersion="1" MinorVersion="1"
    Issuer="https://idp.example.org/saml" ...>
    <saml:Conditions .../>
    <saml:AuthorizationDecisionStatement
      Decision="Permit"
      Resource="https://sp.example.com/confidential_report.html">
      <saml:Subject>...</saml:Subject>
      <saml:Action>read</saml:Action>
    </saml:AuthorizationDecisionStatement>
  </saml:Assertion>

Эти три типа операторов не являются взаимоисключающими. Например, и операторы аутентификации, и операторы атрибутов могут быть включены в одно утверждение (как показано выше). Это исключает необходимость последующих обходов между поставщиком услуг и поставщиком удостоверений.

Протоколы SAML 1.1

[ редактировать ]

SAML Протокол — это простой протокол запроса-ответа. Запрашивающая сторона SAML отправляет SAML Request элемент для ответчика: 

  <samlp:Request
    xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
    MajorVersion="1" MinorVersion="1"
    RequestID="aaf23196-1773-2113-474a-fe114412ab72"
    IssueInstant="2006-07-17T22:26:40Z">
    <!-- insert other SAML elements here -->
  </samlp:Request>

Аналогично, ответчик SAML возвращает SAML-ответ. Response элемент запрашивающему: 

  <samlp:Response
    xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
    MajorVersion="1" MinorVersion="1"
    ResponseID="b07b804c-7c29-ea16-7300-4f3d6f7928ac"
    InResponseTo="aaf23196-1773-2113-474a-fe114412ab72"
    IssueInstant="2006-07-17T22:26:41Z">
    <!-- insert other SAML elements here, including assertions -->
  </samlp:Response>

Привязки и профили, необходимые для осуществления этого обмена сообщениями, подробно описаны в следующих разделах.

Привязки SAML 1.1

[ редактировать ]

SAML 1.1 формально определяет только одну привязку протокола — привязку SAML SOAP. Совместимая реализация SAML 1.1 должна реализовывать SAML через SOAP через HTTP (привязка синхронного протокола). Другие транспортные механизмы, помимо HTTP, разрешены при условии, что соблюдаются независимые от протокола аспекты привязки SAML SOAP (см. раздел 3.1.2 SAMLBind). [ 2 ] ).

Привязка SOAP SAML 1.1 построена на основе SOAP версии 1.1 (нумерация является случайной). Запрашивающая сторона SAML оборачивает SAML Request элемент в теле сообщения SOAP. Аналогично, ответчик SAML возвращает SAML-ответ. Response элемент в теле возвращенного сообщения SOAP. В случае ошибки ответчик вместо этого возвращает код ошибки SOAP.

Любая разметка SAML должна быть включена в тело SOAP. SAML 1.1 не определяет никаких заголовков SOAP, специфичных для SAML. Запрашивающая сторона может вставить любые заголовки SOAP, которые пожелает (хотя это и не требуется).

Напомним, что в SOAP 1.1 SOAPAction HTTP-заголовок должен быть включен в каждый HTTP-запрос (хотя его значение может быть пустым). Запрашивающая сторона SAML может указать следующее значение для SOAPAction заголовок: 

 SOAPAction: http://www.oasis-open.org/committees/security

Однако ответчик SAML не должен зависеть от этого значения.

Безопасное соединение не требуется для запросов и ответов SAML, но в тех ситуациях, когда требуется целостность и конфиденциальность сообщений , требуется HTTP через SSL 3.0 или TLS 1.0 с сертификатом на стороне сервера.

Ответчик SAML может вернуть ответ «403 Запрещено», если он отказывается отвечать запрашивающей стороне SAML. В случае ошибки SOAP ответчик должен вернуть ответ «500 Internal Server Error» (также должен быть включен элемент ошибки SOAP). В противном случае возвращается ответ «200 ОК», даже при наличии ошибки обработки SAML. Такой ответ будет включать SAML. Status элемент в теле SOAP.

Профили SAML 1.1

[ редактировать ]

В общем, профили описывают варианты использования и обмен сообщениями, необходимые для окончательной передачи утверждений от поставщика удостоверений поставщику услуг. SAML 1.1 определяет два профиля SSO веб-браузера:

  1. Профиль браузера/POST
  2. Профиль браузера/артефакта

Профиль браузера/POST основан на операции push, которая передает утверждение SSO по значению через браузер с помощью HTTP POST. Мы говорим, что поставщик удостоверений «проталкивает» утверждение поставщику услуг.

Профиль браузера/артефакта использует механизм «вытягивания». По сути, профиль передает утверждение SSO от поставщика удостоверений поставщику услуг по ссылке (через браузер с использованием HTTP Redirect), которое впоследствии разыменовывается через обмен по обратному каналу (т. е. поставщик услуг «вытягивает» утверждение из удостоверения). провайдер, использующий SAML через SOAP через HTTP).

Эти профили поддерживают междоменный единый вход (SSO). Спецификация не определяет никаких дополнительных профилей. В частности, SAML 1.1 не поддерживает профиль для защиты сообщения веб-службы и не поддерживает единый профиль выхода из системы.

Оба профиля SAML 1.1 начинаются со службы межсайтовой передачи , которой управляет поставщик удостоверений. То, как принципал прибывает в службу перевода, в первую очередь не определяется спецификацией. См. разделы 4.1 и 4.2 обзора SAMLO. [ 3 ] для возможных сценариев. На практике клиент, обращающийся к защищенному ресурсу поставщика услуг, будет перенаправлен на службу межсайтовой передачи у поставщика удостоверений, но точная последовательность шагов, необходимых для этого, не описана в SAML 1.1. (См. раздел 4.3 Обзора SAMLO). [ 3 ] для некоторых приблизительных идей в этом направлении.) Этот сценарий подробно рассмотрен в SAML 2.0.

После посещения службы межсайтовой передачи принципал передается в службу потребителя утверждений у поставщика услуг. То, как именно субъект передается из службы межсайтовой передачи в службу потребителя утверждений, зависит от используемого профиля. В случае профиля браузера/артефакта используется перенаправление; в случае профиля браузера/POST клиент отправляет запрос POST (с вмешательством пользователя или без него).

Чтобы ускорить обработку службой потребителей утверждений, указаны два отдельных URL-адреса:

  1. URL-адрес потребителя утверждений (профиль браузера/POST)
  2. URL-адрес получателя артефакта (браузер/профиль артефакта)

Эти и другие местоположения конечных точек могут быть записаны в файлах метаданных. То, как именно поставщик удостоверений получает доверенный файл метаданных или иным образом определяет расположение доверенных конечных точек конкретного поставщика услуг, выходит за рамки SAML 1.1.

Обратите внимание, что поставщик удостоверений, соответствующий стандарту SAML 1.1, должен предоставлять услугу передачи между сайтами. Аналогично, поставщик услуг SAML 1.1 должен предоставлять потребительскую службу утверждения.

Профиль браузера/POST

[ редактировать ]

Профиль браузера/POST SAML 1.1 определяет следующие четыре (4) шага. Терминология, использованная в исходной спецификации, была немного изменена, чтобы соответствовать терминологии спецификации SAML 2.0.

Поток сообщений начинается с запроса, направленного IdP.

Запросите услугу межсайтового трансфера у IdP

[ редактировать ]

Принципал (через пользовательский агент HTTP) запрашивает службу межсайтовой передачи у провайдера удостоверений: 

 https://idp.example.org/TransferService?TARGET=target

где target — это желаемый ресурс у поставщика услуг, скажем, https://sp.example.com/home. Другими словами, следующий запрос GET выдается пользовательским агентом через SSL/TLS: 

GET /TransferService?TARGET=target HTTP/1.1
Host: idp.example.org

В профиле не указано, как URL-адрес службы передачи (с TARGET параметр) получается пользовательским агентом.

Ответить с помощью HTML-формы

[ редактировать ]

Служба межсайтовой передачи возвращает HTML-документ, содержащий FORM элемент: 

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: nnnn
...
<form method="post" action="https://sp.example.com/ACS/POST" ...>
  <input type="hidden" name="TARGET" value="target" />
  <input type="hidden" name="SAMLResponse" value="''response''" />
  ...
  <input type="submit" value="Submit" />
</form>
...

где TARGET параметр сохранен с шага 1. Значение параметра SAMLResponse параметр — это кодировка base64 SAML. Response такой элемент, как следующий: 

  <samlp:Response
    xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
    MajorVersion="1" MinorVersion="1"
    ResponseID="_P1YaA+Q/wSM/t/8E3R8rNhcpPTM="
    IssueInstant="2002-06-19T17:05:37.795Z">
    <ds:Signature
      xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
    <samlp:Status>
      <samlp:StatusCode Value="samlp:Success"/>
    </samlp:Status>
    <saml:Assertion
      xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
      MajorVersion="1" MinorVersion="1"
      AssertionID="buGxcG4gILg5NlocyLccDz6iXrUa"
      Issuer="https://idp.example.org/saml"
      IssueInstant="2002-06-19T17:05:37.795Z">
      <saml:Conditions
        NotBefore="2002-06-19T17:00:37.795Z"
        NotOnOrAfter="2002-06-19T17:10:37.795Z"/>
      <saml:AuthenticationStatement
        AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"
        AuthenticationInstant="2002-06-19T17:05:17.706Z">
        <saml:Subject>
          <saml:NameIdentifier
            Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
            [email protected]
          </saml:NameIdentifier>
          <saml:SubjectConfirmation>
            <saml:ConfirmationMethod>
              urn:oasis:names:tc:SAML:1.0:cm:bearer
            </saml:ConfirmationMethod>
          </saml:SubjectConfirmation>
        </saml:Subject>
      </saml:AuthenticationStatement>
    </saml:Assertion>
  </samlp:Response>

Ответ SAML должен быть подписан цифровой подписью поставщика удостоверений.

Важно. Предполагается, что принципал уже установил контекст безопасности у провайдера удостоверений, в противном случае служба межсайтовой передачи не сможет предоставить оператор аутентификации в SAML. Response элемент.

Запросить службу поддержки утверждений у SP

[ редактировать ]

Пользовательский агент запрашивает службу Assertion Consumer у поставщика услуг: 

POST /ACS/POST HTTP/1.1
Host: sp.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: nnnn
TARGET=target&SAMLResponse=response

где значения TARGET и SAMLResponse параметры берутся из HTML-формы на шаге 2.

Примечание. Чтобы автоматизировать отправку формы, следующая строка JavaScript может появиться в любом месте страницы: 

  window.onload = function () { document.forms[0].submit(); }

Это предполагает, конечно, что страница содержит один FORM элемент ( forms[0]).

Ответ на запрос директора

[ редактировать ]

Служба потребителей утверждений использует SAML. Response элемент, создает контекст безопасности у поставщика услуг и перенаправляет пользовательский агент на целевой ресурс.

Профиль браузера/артефакта

[ редактировать ]

Профиль браузера/артефакта SAML 1.1 определяет следующие шесть (6) шагов. Терминология, использованная в исходной спецификации, была немного изменена, чтобы соответствовать терминологии спецификации SAML 2.0.

Поток сообщений начинается с запроса, направленного IdP.

Запросите услугу межсайтового трансфера у IdP

[ редактировать ]

Принципал (через пользовательский агент HTTP) запрашивает службу межсайтовой передачи у провайдера удостоверений: 

 https://idp.example.org/TransferService?TARGET=target

где target — это желаемый ресурс у поставщика услуг, скажем, https://sp.example.com/home. Другими словами, следующий запрос GET выдается пользовательским агентом через SSL/TLS: 

GET /TransferService?TARGET=target HTTP/1.1
Host: idp.example.org

В профиле не указано, как URL-адрес службы передачи (с TARGET параметр) получается пользовательским агентом.

Перенаправление в службу обработки утверждений

[ редактировать ]

Участник перенаправляется в службу Assertion Consumer Service у поставщика услуг, то есть пользовательскому агенту возвращается следующий ответ: 

HTTP/1.1 302 Found
Location: https://sp.example.com/ACS/Artifact?TARGET=target&SAMLart=artifact

где artifact — это ссылка на утверждение, которое провайдер удостоверений готов предоставить по запросу.

Важно: Предполагается, что участник уже установил контекст безопасности у провайдера удостоверений, в противном случае служба межсайтовой передачи не сможет предоставить заявление аутентификации.

Запросить службу поддержки утверждений у SP

[ редактировать ]

Пользовательский агент запрашивает службу Assertion Consumer у поставщика услуг: 

 https://sp.example.com/ACS/Artifact?TARGET=target&SAMLart=artifact

где target и artifact все как прежде. Другими словами, следующий запрос GET выдается пользовательским агентом через SSL/TLS: 

GET /ACS/Artifact?TARGET=target&SAMLart=artifact HTTP/1.1
Host: sp.example.com

Запросите услугу разрешения артефактов в IdP

[ редактировать ]

Служба обработки утверждений у поставщика услуг начинает обмен по обратному каналу со службой разрешения артефактов у поставщика удостоверений. Сообщение SAML SOAP привязано к запросу HTTP POST: 

POST /ArtifactResolutionService HTTP/1.1
Host: idp.example.org
Content-Type: text/xml
Content-Length: nnn
SOAPAction: http://www.oasis-open.org/committees/security
<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP-ENV:Header/>
  <SOAP-ENV:Body>
    <samlp:Request
      xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
      MajorVersion="1" MinorVersion="1"
      RequestID="_192.168.16.51.1024506224022"
      IssueInstant="2002-06-19T17:03:44.022Z">
      <samlp:AssertionArtifact>
        artifact
      </samlp:AssertionArtifact>
    </samlp:Request>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

где artifact ранее был отправлен от поставщика удостоверений поставщику услуг на шагах 2 и 3.

Ответьте утверждением SAML

[ редактировать ]

Поставщик удостоверений завершает обмен по обратному каналу, отвечая утверждением SAML, привязанным к сообщению SAML SOAP: 

HTTP/1.1 200 OK
Content-Type: text/xml
Content-Length: nnnn
<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP-ENV:Header/>
  <SOAP-ENV:Body>
    <samlp:Response
      xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
      MajorVersion="1" MinorVersion="1"
      ResponseID="_P1YaA+Q/wSM/t/8E3R8rNhcpPTM="
      InResponseTo="_192.168.16.51.1024506224022"
      IssueInstant="2002-06-19T17:05:37.795Z">
      <samlp:Status>
        <samlp:StatusCode Value="samlp:Success"/>
      </samlp:Status>
      <saml:Assertion
        xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
        MajorVersion="1" MinorVersion="1"
        AssertionID="buGxcG4gILg5NlocyLccDz6iXrUa"
        Issuer="https://idp.example.org/saml"
        IssueInstant="2002-06-19T17:05:37.795Z">
        <saml:Conditions
          NotBefore="2002-06-19T17:00:37.795Z"
          NotOnOrAfter="2002-06-19T17:10:37.795Z"/>
        <saml:AuthenticationStatement
          AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"
          AuthenticationInstant="2002-06-19T17:05:17.706Z">
          <saml:Subject>
            <saml:NameIdentifier
              Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
              [email protected]
            </saml:NameIdentifier>
            <saml:SubjectConfirmation>
              <saml:ConfirmationMethod>
                urn:oasis:names:tc:SAML:1.0:cm:artifact
              </saml:ConfirmationMethod>
            </saml:SubjectConfirmation>
          </saml:Subject>
        </saml:AuthenticationStatement>
      </saml:Assertion>
    </samlp:Response>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

В этом случае оператор аутентификации включает в себя NameIdentifier содержащий адрес электронной почты доверителя.

Ответ на запрос директора

[ редактировать ]

Служба обработки утверждений анализирует SAML. Response элемент, создает контекст безопасности у поставщика услуг и перенаправляет пользовательский агент на целевой ресурс.

См. также

[ редактировать ]

Ссылки

[ редактировать ]
  1. ^ Э. Малер и др., Утверждения и протоколы для языка разметки утверждений безопасности OASIS (SAML) V1.1. Стандарт OASIS, сентябрь 2003 г. Идентификатор документа oasis-sstc-saml-core-1.1 http://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf
  2. ^ Перейти обратно: а б Э. Малер и др., Привязки и профили для языка разметки утверждений безопасности OASIS (SAML) V1.1. Стандарт OASIS, сентябрь 2003 г. Идентификатор документа oasis-sstc-saml-bindings-profiles-1.1 http://www.oasis-open.org/committees/download.php/3405/oasis-sstc-saml-bindings-1.1.pdf
  3. ^ Перейти обратно: а б с Дж. Хьюз и др., Технический обзор языка разметки утверждений безопасности OASIS (SAML) V1.1. Проект комитета OASIS, май 2004 г. Идентификатор документа sstc-saml-tech-overview-1.1-cd http://www.oasis-open.org/committees/download.php/6837/sstc-saml-tech-overview-1.1- компакт-диск.pdf
  4. ^ П. Мишра и др., Различия между языком разметки утверждений безопасности OASIS (SAML) V1.1 и V1.0. Проект OASIS, май 2003 г. Идентификатор документа sstc-saml-diff-1.1-draft-01 http://www.oasis-open.org/committees/download.php/3412/sstc-saml-diff-1.1-draft-01 .pdf
Retrieved from "https://en.wikipedia.org/w/index.php?title=SAML_1.1&oldid=1003976448"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 8c9a863659d174475f5b3b7c5eda8449__1612098000
URL1:https://arc.ask3.ru/arc/aa/8c/49/8c9a863659d174475f5b3b7c5eda8449.html
Заголовок, (Title) документа по адресу, URL1:
SAML 1.1 - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)