تثبيت موفر هوية Shibboleth (IDp) وتكوينه لخدمة تعريف Cisco (IDs) لتمكين SSO

خيارات التنزيل

  • PDF     (288.5 KB)
    عرض باستخدام Adobe Reader على مجموعة متنوعة من الأجهزة
  • ePub     (88.2 KB)
    العرض في تطبيقات مختلفة على iPhone أو iPad أو نظام تشغيل Android أو قارئ Sony أو نظام التشغيل Windows Phone
  • Mobi (Kindle)     (78.1 KB)
    عرض على جهاز Kindle أو تطبيق Kindle على أجهزة متعددة
تم التحديث:١٣ أغسطس ٢٠١٧
معرّف المستند:211578

لغة خالية من التحيز

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

حول هذه الترجمة

ترجمت Cisco هذا المستند باستخدام مجموعة من التقنيات الآلية والبشرية لتقديم محتوى دعم للمستخدمين في جميع أنحاء العالم بلغتهم الخاصة. يُرجى ملاحظة أن أفضل ترجمة آلية لن تكون دقيقة كما هو الحال مع الترجمة الاحترافية التي يقدمها مترجم محترف. تخلي Cisco Systems مسئوليتها عن دقة هذه الترجمات وتُوصي بالرجوع دائمًا إلى المستند الإنجليزي الأصلي (الرابط متوفر).

    المقدمة

    يصف هذا المستند التكوين الموجود على موفر هوية 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 هوية خدمة. لمزيد من التفاصيل، ارجع إلى أدلة تكوين المنتج الفردي:

    TAC Authored

    تمت المساهمة بواسطة مهندسو Cisco

    • Arundeep Nagaraj
      TAC من Cisco
    • Balakrishnan Doraisamy
      الهندسة من Cisco
    • Venkatesh Vedurumudi
      الهندسة من Cisco

    هل كان هذا المستند مفيدًا؟

    Feedbackالتعليقات

    اتصل بنا

    ينطبق هذا المستند على هذه المنتجات