На работе у нас есть веб-приложение, с которым мы должны будем соединить интерфейсом с веб-приложением другой компании с помощью Единой точки входа, проверенной SAML. Наши веб-приложения записаны в PHP, и это очевидно не важно, какой выбор языка другая компания использует. Тем не менее, я должен был записать простой API, к которому эта другая компания может отправить запросы SOAP с запросами SAML, и генерировать назад ответ SAML. Я писал это с нуля по трем причинам: 1) действительно кажется, нет многих опций для взаимодействий SAML, записанных в PHP, даже если я хотел один, 2) это ограничивает издержки, которые были бы связаны с добавлением другого стороннего компонента и 3) создание вещей с нуля обычно оставляет меня со значительно лучшим пониманием и делает меня намного более способным для адаптации вещи в будущем в случае необходимости.
Так или иначе я довольно плохо знаком с SAML, SOAP и стандартами XML в целом, таким образом, я отчасти самостоятельно учился, когда я иду. У меня есть API, в значительной степени завершаются в наших целях, за одним исключением, что другая компания указала, что наш ответ потребуется, чтобы быть снабженным цифровой подписью с сертификатом (и запрос, который мы получаем, будет так же снабжен цифровой подписью). Таким образом, я пытался выяснить, как обработать/генерировать XML-подписи, но честно это все немного сбивает с толку, поскольку спецификации W3C не являются точно легким чтением.
Разделите 5.4.8 из Утверждений и Протокола для Языка разметки безопасности ОАЗИСА (SAML) документ V1.1 (документ, я уходил, поскольку другая компания заявила, что они будут использовать v1.1), включает пример ответа со знаком, содержащего утверждение со знаком, которое я собираюсь включать здесь в ссылку:
TCDVSuG6grhyHbzhQFWFzGrxIPE=
x/GyPbzmFEe85pGD3c1aXG4Vspb9V9jGCjwcRCKrtwPS6vdVNCcY5rHaFPYWkf+5EIYcPzx+pX1h43SmwviCqXRjRtMANWbHLhWAptaK1ywS7gFgsD01qjyen3CP+m3Dw6vKhaq1ed10BYyrIzb4KkHO4ahNyBVXbJwqv5pUaE4=
MIICyjCCAjOgAwIBAgICAnUwDQYJKoZIhvcNAQEEBQAwgakxCzAJBgNVBAYTA1VT ... 8I3bsbmRAUg4UP9hH6ABVq4KQKMknxu1xQxLhpR1y1GPdiowMNTrEG8cCx3w/w==
http://www.opensaml.org
scott@example.org
urn:oasis:names:tc:SAML:1.0:cm:bearer
Kclet6XcaOgOWXM4gty6/UNdviI=
hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iyzixBvKXX8P53BTCT4VghPBWhFTSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMWuL/cBUj2OtBZOQMFn7jQ9YB7k1Iz3RqVL+wNmeWI4=
MIICyjCCAjOgAwIBAgICAnUwDQYJKoZIhvcNAQEEBQAwgakxCzAJBgNVBAYTA1VT ... 8I3bsbmRAUg4UP9hH6ABVq4KQKMknxu1xQxLhpR1y1GPdiowMNTrEG8cCx3w/w==
Таким образом, как я генерирую что-то вроде этого? И если я получаю что-то вроде этого, как я проверяю его? Кроме того, может любой предлагать просто основной концептуальный обзор какой
теги здесь? Кажется, что существует два
теги, один в основном
и один в
, каждый содержащий их собственное
,
, и
(и каждый отличный). Как они сгенерированы? Любой свет, который можно пролить на это, будет очень цениться. Учебные руководства или примеры кода еще более ценились бы! Но в этой точке, если можно просто получить меня на правильном пути, это - все, что я действительно прошу. Прямо сейчас все это все еще походит на большой черный квадрат мне.
Между прочим, если это помогает, это говорит в другом месте в спецификации SAML 1.1, что реализации SAML должны использовать "Эксклюзивную Канонизацию" метод только (Excl-C14N) и должны использовать "окутанный, преобразовывают" только. Я все еще не абсолютно уверен, что это означает.
Обработка XML сигнатур на самом деле не слишком сложна, если вы хорошо знакомы с XML, но есть много деталей, которые должны быть абсолютно правильными, или что-то не работает, так что я, наверное, не стал бы пытаться написать свою собственную реализацию в этой ситуации (однажды я реализовал ее частично, но это было для другого и специального назначения, и в любом случае это была не полная реализация).
В любом случае, я мало что знаю о SAML, но я знаю о XML и подписях XML, так что, возможно, я смогу найти для вас какой-нибудь способ, попытавшись ответить на ваши вопросы.
Элемент Signature
относится к определенной части XML-документа, которая была подписана цифровой подписью, в его SignedInfo
дочернем элементе. Дочерний элемент Reference
(думаю, может быть много Reference
элементов, которые соединяются при формировании подписываемых байтов, но я уже не помню наверняка) указывает на содержимое через атрибут URI
. Элементы Transform
описывают преобразования, выполняемые по ссылке на содержимое до его хэширования; для того, чтобы понять, как определены алгоритмы преобразования, необходимо посмотреть спецификации. Элемент DigestMethod
дает хэш-алгоритм для применения к байтам, которые являются результатом этих алгоритмов преобразования (обратите внимание, что одним из них всегда является канонизация, которая преобразует XML в байты), а элемент DigestValue
дает результат этого алгоритма дайджеста.
Фактическая подпись находится в элементе SignatureValue
и производится путем канонизации элемента КанонизацияМетод
для получения байтов, а затем подписывания этих байтов с помощью SignatureMethod
. Элемент KeyInfo KeyInfo
рассказывает, как найти ключ для использования.
Канонизация, которая появляется пару раз выше, это просто способ преобразовать XML документ в байты таким образом, чтобы "эквивалентные" XML документы выдавали одну и ту же последовательность байтов. Это требуется в цифровой подписи, поскольку алгоритмы работают с байтами, а XML может проходить через ряд посредников, которые, вероятно, нарушат работу исходных байтов, но сохранят эквивалентность. И разные методы канонизации необходимы в разных ситуациях: если элементы извлекаются из документов и помещаются в другие, вам нужна эксклюзивная канонизация, которая отсекает ненужные определения пространств имен, но в других случаях, которые могут работать неправильно, поэтому вместо этого вам нужна инклюзивная канонизация, которая сохраняет все пространства имен в пространстве имен.
Это только основы. Есть несколько различных вариантов, как создать XML сигнатуру, и если вы хотите реализовать работающий верификатор, вам нужно рассмотреть все из них. Так как вы новичок в XML в целом, я просто повторю свой совет по использованию того, что уже существует. Реализация спецификации - это интересный обучающий опыт, но часто это пустая трата времени, если реализации уже есть.
Существует документация W3C о подписях .
.Пример в xmlseclibs.php в SimpleSAML. Он полагается на модуль openssl для выполнения crypto.
Я бы честно использовал эту lib или мост к java/tomcat, просто потому что могут возникнуть проблемы с Interop, которые потенциально должны быть отлажены,
.