SSO с SAML 2.0 във Финансовия Сектор: Enterprise Имплементация

Финансовият сектор има структурен проблем с идентичността: десетки портали, вътрешни платформи, приложения на търговски партньори и облачни услуги, всяка със своя система за удостоверяване. Множеството идентификационни данни насърчава повторното им използване и слабите процеси за възстановяване; SSO намалява тази повърхност, но сам по себе си не премахва фишинга и отвличането на сесии: върви заедно с MFA и контроли на сесията.

SAML 2.0 и OpenID Connect: кога кое е по-подходящо

OAuth 2.0 делегира упълномощаване; OpenID Connect добавя удостоверяване. SAML 2.0 и OIDC са актуални и двата: SAML остава често срещан в корпоративни пакети и в съществуваща B2B федерация; OIDC обикновено е за предпочитане за съвременни уеб и мобилни приложения и за API. SAML 2.0 е проектиран за федерация на идентичност между организации, с подписани със сертификати X.509 XML твърдения (assertions) и сложни потребителски атрибути, и запазва значително присъствие в корпоративни среди; изборът зависи от съвместимостта, модела на интеграция, модела на заплахите и експлоатацията.

При основните (core) и наследените платформи федерацията обикновено изисква портал, шлюз или междинен слой; по продукт и версия се валидира поддържаният процес, сесията и наличните атрибути. И двата подхода може да изискват интеграционни компоненти; въздействието се измерва в конкретната архитектура.

Архитектура на реално внедряване

В портала за ваучери на Intelyvale, корпоративните му клиенти влизат с профила на собствената си компания: федерираме техния доставчик на идентичност и отделяме този достъп от локалния вход.

Проблемите, за които никой не говори

Техническото внедряване на SAML е относително лесно със зрели библиотеки. Реалните проблеми се появяват в реална експлоатация: ротация на сертификати (ако IdP смени сертификата си, без да уведоми SP, потребителите остават блокирани; с метаданни ротацията се автоматизира), непоследователни атрибути (различни SP очакват един и същ атрибут с различни имена), съпоставяне на ролите от директорията на клиента с тези на системата, създаване на потребители при първия достъп и изход от сесията в хибридни екосистеми.

Твърденията зависят от времеви условия (NotBefore / NotOnOrAfter); допустимото отклонение се определя изрично, колкото е възможно по-малко според операцията, със следена синхронизация на времето.

Доставчикът на услуга валидира строго подписа и веригата на доверие, издателя, аудиторията, местоназначението, срока на валидност, съответствието със заявката и еднократното използване на твърдението и се защитава срещу повторно възпроизвеждане и XML signature wrapping. Приемането на „подписано“ твърдение не е достатъчно.