المحتويات

المقدمة

المتطلبات الأساسية

المتطلبات

المكونات المستخدمة

تثبيت

متطلبات النظام

التكوين

التكامل مع خادم LDAP

نموذج ملف التكوين

السماح بالطلبات من جميع العملاء

تكوين Shibboleth للتكامل مع المعرفات

خوارزمية التجزئة الآمنة (SHA1) وتكوين التشفير في المعرفات

تكوين UID و user_PRINCIPAL إلى إستجابة SAML

بيانات تعريف IDp

تكوين موفري بيانات التعريف

مزيد من التكوين ل SSO

المقدمة

يصف هذا المستند التكوين الموجود على موفر هوية OpenAM (IDp) لتمكين تسجيل الدخول الأحادي (SSO).

نماذج نشر معرفات Cisco

المنتج

النشر

UCCX

مقيم مشارك

PCCE

مقيم مشترك مع CUIC (Cisco Unified Intelligence Center) و LD (بيانات مباشرة)

UCCE

مشارك مقيم مع CUIC و LD لعمليات نشر 2k.

مستقلة لعمليات النشر التي تبلغ 4 آلاف و 12 ألف عملية.

المتطلبات الأساسية

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

- Cisco Unified Contact Center Express (UCCX) الإصدار 11.6 أو Cisco Unified Contact Center Enterprise الإصدار 11.6 أو Packaged Contact Center Enterprise (PCCE) الإصدار 11.6 حسب الاقتضاء.

ملاحظة: يشير هذا المستند إلى التكوين المرتبط بخدمة تعريف Cisco (المعرفات) ومزود الهوية (IDp). يشير المستند إلى UCCX في لقطات الشاشة والأمثلة، ومع ذلك فإن التكوين يكون مماثلا فيما يتعلق بخدمة تعريف Cisco (UCCX/UCCE/PCCE) ومعرف IDp.

المكونات المستخدمة

لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.

تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.

تثبيت

Shibboleth هو مشروع مفتوح المصدر يوفر إمكانيات تسجيل دخول فردي ويسمح للمواقع باتخاذ قرارات تفويض مستنيرة للوصول الفردي لموارد الإنترنت المحمية بطريقة تحفظ الخصوصية. وهو يدعم لغة ترميز تأكيد الأمان (SAML2). IDs هو عميل SAML2 ومن المتوقع أن يدعم Shibboleth بأقل تغييرات أو بدون تغييرات في المعرفات. في 11.6، تعتبر بطاقات الهوية مؤهلة للعمل مع Shibboleth IdP.

ملاحظة: يشير هذا المستند إلى الإصدار 3.3.0 من Shibboleth كجزء من التأهيل مع SSO

متطلبات النظام

مكون

التفاصيل

إصدار شيبولت

v3.3.0

موقع التنزيل

http://shibboleth.net/downloads/identity-provider/

تثبيت النظام الأساسي

Ubuntu 14.0.4

إصدار Java "1.8.0_121"

إصدار البروتوكول الخفيف للوصول للدليل (LDAP)

Active Directory 2.0

خادم ويب Shibboleth

أباتشي تومكات/8.5.12

يرجى الرجوع إلى الويكي للاطلاع على تركيب شبولت

https://wiki.shibboleth.net/confluence/display/IDP30/Installation

التكوين

التكامل مع خادم LDAP

لدمج خادم LDAP مع Shibboleth، يلزم تحديث الحقول في $shibboleth_home/conf/ldap.properties حيث يشير$shibboleth_home(الإعداد الافتراضي هو /opt/shibboleth-idp) إلى دليل التثبيت المستخدم عند تثبيت Shibboleth.

الحقل

القيمة المتوقعة

الوصف

idp.authn.ldap.trustCertificates

مورد لتحميل إرتباطات الثقة منه، عادة ملف محلي في ${idp.home}/بيانات الاعتماد

حيث إن idp.home هو متغير بيئي يتم تصديره على أنه java_opts في setenv.sh

٪{idp.home}/credentials/ldap-server.crt

idp.authn.ldap.trustStore

مورد لتحميل مخزن مفاتيح Java يحتوي على نقاط ربط ثقة، عادة ملف محلي في ٪{idp.home}/بيانات الاعتماد

٪{idp.home}/credentials/ldap-server.truststore

idp.authn.ldap.returnAttributes

قائمة LDAPAttributes المقسمة بفاصلة التي يلزم إرجاعها. إذا أردت إرجاع كافة السمات، فقم بإضافة "*".

*

idp.authn.ldap.baseDN

BaseDN التي يلزم إجراء بحث LDAP عندها

CN=المستخدمون،DC=Cisco،DC=com

idp.authn.ldap.subtreeSearch

ما إذا كنت تريد البحث بشكل متكرر

صحيح

idp.authn.ldap.userFilter

عامل تصفية البحث ل LDAP

(sAMAccountName={user})*

idp.authn.ldap.bindDN

DN للربط به عند إجراء البحث

administrator@cisco.com

idp.authn.ldap.bindDNCredential

كلمة المرور للربط بها عند إجراء البحث

idp.authn.ldap.dnFormat

سلسلة تنسيق لإنشاء DNs للمستخدم للمصادقة

٪s@adfsserver.cisco.com

(٪s@domainname)

idp.authn.ldap.authenticator

يتحكم في سير العمل لمعرفة كيفية حدوث المصادقة مقابل LDAP

BindSearchAuthenticator

idp.authn.ldap.ldapURL

URI للاتصال لدليل LDAP

لمزيد من التفاصيل، ارجع إلى:

https://wiki.shibboleth.net/confluence/display/IDP30/LDAPAuthnConfiguration

نموذج ملف التكوين

# الوقت بالمللي ثانية للانتظار من أجلاستجابات

#idp.authn.LDAP.responseTimeout = PT3S

## تكوين SSL، إما jvmTrust أو certificateTrust أو keyStoreTrust

#idp.authn.LDAP.sslConfig = certificateTrust

## في حالة إستخدام CertificateTrust أعلاه، قم بالتعيين إلى مسار الشهادة الموثوق بها

idp.authn.ldap.trustCertificates = ٪{idp.home}/credentials/ldap-server.crt

## في حالة إستخدام keyStoreTrust أعلاه، قم بالتعيين إلى مسار TrustStore

idp.authn.ldap.trustStore = ٪{idp.home}/credentials/ldap-server.truststore

## إرجاع السمات أثناء المصادقة

#idp.authn.LDAP.ReturnAttributes = userPrincipalName، sAMAccountName

idp.authn.ldap.returnAttributes = *

## خصائص دقة DN ##

# دقة DN للبحث، يتم إستخدامها من قبل anonSearchAuthenticator، bindSearchAuthenticator

# من أجلAD: CN=Users،DC=example،DC=org

idp.authn.ldap.baseDN = CN=users،DC=cisco،DC=com

idp.authn.ldap.subtreeSearch = صحيح

*idp.authn.ldap.userFilter = (sAMAccountName={user})*

# ربط تكوين البحث

# من أجلAD: idp.authn.ldap.bindDN=adminuser@domain.com

idp.authn.ldap.bindDN = مسؤول@cisco.com

idp.authn.ldap.bindDNCredential = Cisco@123

# تنسيق دقة DN، مستخدم من قبل DirectAuthenticator و adAuthenticator

# من أجلAD إستخدام idp.authn.ldap.dnFormat=٪s@domain.com

#idp.authn.LDAP.dnFormat = ٪s@adfsserver.cisco.com

# تكوين سمة LDAP، راجع attribute-resolver.xml

# ملاحظة، هذامن المحتمل ألا يتم تطبيق هذا على إستخدام تكوينات محلل V2 القديمة

idp.attribute.resolver.ldap.ldapURL = ٪{idp.authn.ldap.ldapURL}

idp.attribute.resolver.ldap.connectTimeout = ٪{idp.authn.ldap.connectTimeout:PT3S}

idp.attribute.resolver.ldap.responseTimeout = ٪{idp.authn.ldap.responseTimeout:PT3S}

idp.attribute.resolver.ldap.baseDN = ٪{idp.authn.ldap.baseDN:undefined}

idp.attribute.resolver.ldap.bindDN = ٪{idp.authn.ldap.bindDN:undefined}

idp.attribute.resolver.ldap.bindDNCredential = ٪{idp.authn.ldap.bindDNCredential:undefined}

idp.attribute.resolver.ldap.useStartTLS = ٪{idp.authn.ldap.useStartTLS:صحيح}

idp.attribute.resolver.ldap.trustCertificates = ٪{idp.authn.ldap.trustCertificates:undefined}

idp.attribute.resolver.ldap.searchFilter = (sAMAccountName=$resolutionContext.principal)

السماح بالطلبات من جميع العملاء

ولضمان وصول الطلبات الواردة من جميع العملاء، يلزم إدخال تغييرات على "$shibboleth_home/conf/access-control.xml"

<entry key="AccessByIPAddress">

<bean id="AccessByIPAddress" parent="shibboleth.IPRangeAccessControl"

p:allowedRange="#{ {'127.0.0.1/32'،'0.0.0.0/0'، ':1/128'، '10.78.93.103/32'} }" />

</entry>

أضف '0.0.0.0/0' إلى النطاقات المسموح بها. وهذا يسمح بالطلبات من أي نطاق IP.

تكوين Shibboleth للتكامل مع المعرفات

خوارزمية التجزئة الآمنة (SHA1) وتكوين التشفير في المعرفات

لتكوين المعرفات بشكل افتراضي إلى SHA1، افتح "$shibboleth_home/conf/idp.properties" واضبط:

idp.signature.config = shibboleth.SignatureConfiguration.SHA1

هذا تشكيل يستطيع أيضا كنت غيرت:

IDP.Encryption.إختياري = true

إذا قمت بتعيينه إلى true، فلن يؤدي الفشل في تحديد موقع مفتاح تشفير لاستخدامه، عند تمكينه، إلى فشل الطلب. هذا hيتيح إجراء التشفير "بشكل انتهازي"، أي للتشفير كلما أمكن (يتم العثور على مفتاح متوافق في بيانات تعريف النظير للتشفير به) ولكن لتخطي التشفير بطريقة أخرى.

تكوين UID و user_PRINCIPAL إلى إستجابة SAML

تتم إضافة AttributeDefinition في "$shibboleth_home/conf/attribute-resolver.xml" لتعيين sAMAccountName و userPrincipalName إلى المعرف و user_principal في إستجابة SAML.

بالإضافة إلى ذلك، أضف إعدادات موصل ldap باستخدام العلامة <DataConnector>.

ملاحظة: يلزم تحديد ReturnAttributes بالقيمة sAMAccountName userPrincipalName".

ملاحظة: تعد LDAPProperty إلزامية في حالة وجود تكامل مع Active Directory (AD).

%{idp.attribute.resolver.LDAP.searchFilter}

sAMAccountName userPrincipalName

دمج التغييرات في $shibboleth_home/conf/attribute-filter.xml"

تغيير $shibboleth_home/conf/saml-nameid.xml لتضمين

بيانات تعريف IDp

تتوفر بيانات تعريف IDp في المجلد $shibboleth_home/metadata" . يمكن تحميل ملف idp-metadata.xml إلى المعرفات من خلال واجهة برمجة التطبيقات (API)

وضع https://<idshost>:<idsport>/ids/v1/config/idpmetadata

حيث IDSPORT ليست كيانا قابلا للتكوين والقيمة هي "8553"

تحذير: يمكن أن تحتوي بيانات تعريف Shibbolth على شهادتي توقيع، وشهادة توقيع عامة والقناة الخلفية. انتقل إلى الملف idp-backchannel.crt in "$shibboleth_home/credentials" للتعرف على شهادة القناة الخلفية. إذا كانت شهادة القناة الخلفية متاحة في البيانات الأولية، يجب عليك إزالة شهادة القناة الخلفية من بيانات التعريف xml قبل التحميل إلى المعرفات. وذلك لأن مكتبة Fedlet 12.0 التي تستخدمها المعرفات تدعم شهادة واحدة فقط في بيانات التعريف. في حالة توفر أكثر من شهادة توقيع واحدة، يستخدم المفتاح أول شهادة متاحة.

تكوين موفري بيانات التعريف

نحتاج إلى تكوين موفري بيانات التعريف مع إدخال في $shibboleth_home/metadata-providers.xml.

<MetadataProvider id="smart-86"  xsi:type="FilesystemMetadataProvider" metadataFile="/opt/shibboleth-idp/SP/sp.xml"/>

حيث يمكن أن تكون سمة "id" أي اسم فريد.

يشير هذا الإدخال إلى أن موفر بيانات التعريف مسجل بالمعرف المحدد وأن بيانات التعريف متوفرة في الملف المحدد /opt/shibboleth-idp/SP/sp.xml.

يجب نسخ بيانات تعريف موفر الخدمة (SP) الخاصة بالمعرفات إلى MetadataFile المحدد في الإدخال.

ملاحظة: يمكن إسترداد بيانات تعريف SP الخاصة بالمعرفات عبر GET https://<idshost>:<idSport>/ids/v1/config/spmetadata، حيثIDsport ليست كيانا قابلا للتكوين والقيمة هي "8553".

مزيد من التكوين ل SSO

يصف هذا وثيقة التشكيل من ال idP جانب ل SSO أن يتكامل مع cisco هوية خدمة. لمزيد من التفاصيل، ارجع إلى أدلة تكوين المنتج الفردي:

- UCCX

- UCCE

- PCCE