컨트롤 허브에서 Shibboleth로 싱글 사인온 구성하세요

싱글 사인온 및 컨트롤 허브

싱글 사인온 (SSO) 은 사용자가 하나 이상의 애플리케이션에 액세스하기 위해 자격 증명을 제공하도록 허용하는 세션 또는 사용자 인증 프로세스예요. 프로세스는 권한이 부여된 모든 애플리케이션에 대해 사용자를 인증해요. 그러면 사용자가 특정 세션 중에 응용 프로그램을 전환할 때 더 이상 메시지가 나타나지 않아요.

보안 주장 마크업 언어 (SAML 2.0) 페더레이션 프로토콜은 Webex 클라우드와 ID 공급자 (IdP) 간의 SSO 인증을 제공하는 데 사용돼요.

프로필

웹엑스 앱은 웹 브라우저 SSO 프로필만 지원해요. 웹 브라우저 SSO 프로필에서, Webex App은 다음 바인딩을 지원해요.

SP 시작 POST -> POST 바인딩
SP에서 리디렉션 시작 -> POST 바인딩

이름ID 포맷

SAML 2.0 프로토콜은 특정 사용자에 대한 통신을 위한 여러 NameID 형식을 지원해요. 웹엑스 앱은 다음 NameID 포맷을 지원해요.

urn:oasis:names:tc:SAML:2.0:nameid-format:transient
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

IdP에서 로드하는 메타데이터에서 첫 번째 항목은 Webex에서 사용하도록 구성되어 있어요.

싱글 로그아웃

웹엑스 앱은 단일 로그아웃 프로필을 지원해요. Webex 앱에서 사용자는 SAML 단일 로그아웃 프로토콜을 사용하여 세션을 종료하고 IdP로 로그아웃을 확인하는 애플리케이션에서 로그아웃할 수 있어요. 당신의 IdP가 단일 로그아웃으로 구성되어 있는지 확인하세요.

컨트롤 허브와 쉬볼레스를 통합하세요

구성 가이드는 SSO 통합의 구체적인 예를 보여 주지만 모든 가능성에 대한 완전한 구성을 제공하지는 않아요. 예를 들어, 의 통합 단계가 nameid-format urn:oasis:names:tc:SAML:2.0:nameid-format:transient문서화되어 있어요. 와 같은 기타 urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified or urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress형식은 SSO 통합에는 적합하지만 설명서 범위를 벗어납니다.

Webex 조직의 사용자를 위해 이 통합을 설정하세요 (Webex 앱 및 제어 Webex Meetings 허브에서 관리하는 기타 서비스 포함). 웹엑스 사이트가 컨트롤 허브에 통합된 경우, 웹엑스 사이트는 사용자 관리를 상속해요. 컨트롤 Webex Meetings 허브에서 관리되지 않고 이런 방식으로 접속할 수 없다면 별도의 통합을 해서 SSO를 활성화해야 해요. Webex Meetings

통합 단계에서는 CentOS 7의 쉬볼레스 2.4.5를 참조하고 톰캣 7을 웹 서버로 사용해요.

시작하기 전에

SSO와 컨트롤 허브의 경우 IdP는 SAML 2.0 사양을 준수해야 해요. 또한 IdP는 다음과 같은 방식으로 구성해야 해요.

Webex 메타데이터를 로컬 시스템에 다운로드하세요

1	컨트롤 허브에 로그인해요.
2	관리 > 보안 > 인증으로 가세요.
3	ID 공급자 탭으로 가서 SSO 활성화를 클릭해요.
4	IdP를 선택해 주세요.
5	조직의 인증서 유형을 선택하세요. Cisco 자체 서명—이 선택 추천해요. 5년에 한 번만 갱신하면 되도록 인증서에 서명하겠습니다. 공공 인증 기관에서 서명함 —더 안전하지만 메타데이터를 자주 업데이트해야 해요 (IdP 공급업체가 신뢰 앵커를 지원하지 않는 한). 신뢰 앵커는 디지털 서명 인증서를 확인하는 기관 역할을 하는 공개 키예요. 자세한 내용은 IdP 설명서를 참조하세요.
6	메타데이터 파일 다운로드해요. 웹엑스 메타데이터 파일 이름은 idb-meta- -SP.xml 예요. <org-ID>

쉬볼레스 파일에서 승인 구성하세요

Shibboleth를 설치하면 예제가 포함된 구성 파일이 제공돼요.

1	예제 파일에 액세스하려면 /opt/shibboleth-idp/conf 디렉토리로 가세요.
2	어떤 인증 방법을 사용할지 결정하세요. 예를 들면, LDAP 바인딩이에요. Active Directory
3	handler.xml 파일을 다음과 같이 편집하세요. 코멘트 없이요 `<!-- Username/password login handler --> <ph:LoginHandler xsi:type="ph:UsernamePassword" jaasConfigurationLocation="file:///opt/shibboleth-idp/conf/login.config"> <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </ph:AuthenticationMethod> </ph:LoginHandler>` 코멘트 `<ph:LoginHandler xsi:type="ph:RemoteUser"> <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</ph:AuthenticationMethod> </ph:LoginHandler>`
4	인증을 Active Directory 허용하려면 당신의 세부 정보를 입력하세요. login.config 파일에 구성을 입력하세요. `ShibUserPassAuth { edu.vt.middleware.ldap.jaas.LdapLoginModule required ldapUrl="ldap://ad0a.cisco.net:389" ssl="false" tls="false" baseDn="cn=Users,dc=cisco,dc=net" subtreeSearch="true" userFilter="sAMAccountName={0}" bindDn="cn=Administrator,cn=Users,dc=cisco,dc=net" bindCredential="ThePassword"; };`

SAML 어설션을 위한 쉬볼레스 서비스 프로바이더 구성 요소를 구성하세요

Webex SP에서 다운로드한 파일을 /opt/shibboleth-idp/metadata 디렉터리에 추가해요.

relying-party.xml 파일을 편집하세요. 기본 RelyingParty 태그 뒤에 웹엑스의 SAML 어설션 세부 정보를 추가하세요.

 <rp:RelyingParty id="https://idbroker.webex.com/ea7c1420-711d-4916-95f8-
22de53230d1e"
              provider="https://shib9a.cisco.net/idp/shibboleth"
              defaultSigningCredentialRef="IdPCredential">
            <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile"
                includeAttributeStatement="true"
                assertionLifetime="PT5M" assertionProxyCount="0"
                signResponses="never" signAssertions="always"
                encryptAssertions="conditional" encryptNameIds="never"
                includeConditionsNotBefore="true"/>
        </rp:RelyingParty>

ID의 경우, 웹엑스 메타데이터 파일의 EntityID 값을 사용해야 해요. 예제의 ID를 조직의 EntityID로 바꿔요.

메타데이터:메타데이터 프로바이더 태그 안에 파일 위치를 추가하세요.

 <metadata:MetadataProvider id="ShibbolethMetadata" xsi:type="metadata:Chaini
ngMetadataProvider">
        <metadata:MetadataProvider id="IdPMD" xsi:type="metadata:FilesystemMetad
ataProvider" metadataFile="/opt/shibboleth-idp/metadata/idp-metadata.xml" maxRefreshDelay="P1D" />
    <!--     Cisco UCXN Configuration               -->
   <metadata:MetadataProvider xsi:type="FilesystemMetadataProvider" xmlns="urn:m
ace:shibboleth:2.0:metadata" id="ucxn9a" metadataFile="/opt/shibboleth-idp/metad
ata/ucxn9a-single-agreement.xml" />
    <!--     Cisco CUCM Configuration               -->
   <metadata:MetadataProvider xsi:type="FilesystemMetadataProvider" xmlns="urn:m
ace:shibboleth:2.0:metadata" id="cucm9a" metadataFile="/opt/shibboleth-idp/metad
ata/cucm9a.cisco.net-single-agreement.xml" />
    <!--     Cisco CI Configuration               
   <metadata:MetadataProvider xsi:type="FilesystemMetadataProvider" xmlns="urn:m
ace:shibboleth:2.0:metadata" id="CI" metadataFile="/opt/shibboleth-idp/metadata/
idb-meta-ea7c1420-711d-4916-95f8-22de53230d1e-SP.xml" />
    </metadata:MetadataProvider>

SP 메타데이터는 Webex 조직의 메타데이터를 업로드한 위치에 있는 Shibboleth 파일 시스템의 파일에서 가져와요.

어설션 속성 구성해요

1	데이터 커넥터 섹션에서 사용자에 대한 속성을 검색할 위치를 지정하세요. Active Directory, MyLDAP 아이디로. `<resolver:DataConnector id="MyLDAP" xsi:type="dc:LDAPDirectory" ldapURL="ldap://ad0a.cisco.net:389" baseDN="cn=Users,dc=cisco,dc=net" principal="Administrator@cisco.net" principalCredential="ThePassword"> <dc:FilterTemplate> <![CDATA[ (sAMAccountName=$requestContext.principalName) ]]> </dc:FilterTemplate> </resolver:DataConnector>`
2	속성 정의 섹션에서 TransientID 구성에 이미 있는 것을 유지하세요.
3	SP가 예상하는 추가 속성을 추가하고 속성 소스에서 매핑할 대상을 정의하세요. 메일 (이메일 주소 속성) 속성을 uid (웹엑스의 사용자 IDActive Directory) 에 매핑해요. `<resolver:AttributeDefinition id="mail-attr" xsi:type="ad:Simple" sourceAttributeID="mail"> <resolver:Dependency ref="MyLDAP" /> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="uid" /> </resolver:AttributeDefinition>`
4	각 SP 계약에 제공할 속성을 attribute-filter.xml 파일에서 정의하세요. 사용자의 이메일 주소에 매핑되는 uid 속성을 Webex에 제공하세요. Webex와의 SP 계약에 대한 속성 UID를 릴리즈하세요. `<!-- Release the attributes to cisco CI Cloud --> <afp:AttributeFilterPolicy id="ReleaseToCI"> <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="https://idbroker.webex.com/ea7c1420-711d-4916-95f8-22de53230d1e" /> <afp:AttributeRule attributeID="transientId"> <afp:PermitValueRule xsi:type="basic:ANY"/> </afp:AttributeRule> <afp:AttributeRule attributeID="mail-attr"> <afp:PermitValueRule xsi:type="basic:ANY" /> </afp:AttributeRule> </afp:AttributeFilterPolicy>` attribute-resolver.xml 에서 만든 규칙에는 mail-attr 속성을 웹엑스와 일치하는 EntityID로 릴리스하는 정책이 있어야 해요.
5	쉬볼레스 서버에서 /opt/shibboleth-idp/metadata 내 메타데이터 파일을 다운로드해요. 파일 이름은 idp-metadata.xml 예요.

IdP 메타데이터를 가져오고 테스트 후 싱글 사인온 활성화해요

Webex 메타데이터를 내보내고, IdP를 구성하고, IdP 메타데이터를 로컬 시스템에 다운로드하면, Control Hub에서 Webex 조직으로 가져올 준비가 되었습니다.

시작하기 전에

ID 공급자 (IdP) 인터페이스에서 SSO 통합을 테스트하지 마세요. 우리는 서비스 제공자가 시작한 (SP에서 시작한) 플로우만 지원해요. 따라서 이 통합에는 컨트롤 허브 SSO 테스트를 사용해야 해요.

1	하나 고르세요: 브라우저의 컨트롤 허브 — 인증서 선택 페이지로 돌아가서 다음을 클릭해요. 브라우저 탭에 컨트롤 허브가 더 이상 열려 있지 않으면 다시 여세요. Control Hub의 고객 보기에서 관리 > 보안 > 인증으로 이동하고 IdP를 선택한 다음 작업 > 메타데이터 가져오기를 선택하세요.
2	IdP 메타데이터 가져오기 페이지에서 IdP 메타데이터 파일을 페이지에 드래그 앤 드롭하거나 파일 브라우저 옵션을 사용하여 메타데이터 파일을 찾아 업로드하세요. 다음을 클릭해요. 가능하면 보안 강화 옵션을 사용하세요. 당신의 IdP가 공용 CA를 사용하여 메타데이터에 서명한 경우에만 가능해요. 다른 모든 경우에는 덜 안전한 옵션을 사용해야 해요. 여기에는 메타데이터가 서명되지 않았거나, 자체 서명되거나, 사설 CA에서 서명되지 않은 경우가 포함돼요. Okta는 메타데이터에 서명하지 않으므로 Okta SSO 통합에는 '덜 보안'을 선택해야 해요.
3	SSO 설정 테스트를 선택하고 새 브라우저 탭이 열리면 로그인해서 IdP로 인증해요. 인증 오류 받으면 자격 증명에 문제가 있을 수 있어요. 사용자 이름과 비밀번호를 확인하고 다시 시도하세요. Webex 앱 오류는 보통 SSO 설정 관련 문제를 의미해요. 이 경우 단계를 다시 진행하세요. 특히 컨트롤 허브 메타데이터를 복사하여 IdP 설정에 붙여넣는 단계를 살펴보세요. SSO 로그인 경험을 직접 보려면 이 화면에서 클립보드에 URL 복사를 클릭하여 개인 브라우저 창에 붙여넣을 수도 있어요. 거기에서 SSO로 로그인하는 방법을 안내할 수 있어요. 이 단계는 기존 세션에 로그인했을 수 있는 액세스 토큰으로 인한 오탐을 막아줘요.
4	컨트롤 허브 브라우저 탭으로 돌아가세요. 테스트가 성공적이었으면, 성공 테스트를 선택해.SSO 켜고 다음 클릭해요. 테스트가 실패하면 테스트 실패를 선택해.SSO 끄고 다음 클릭해요. 첫 번째 라디오 버튼을 선택하고 SSO를 활성화하지 않으면 SSO 구성이 조직에 적용되지 않아요.