Single Sign-On을 사용하도록 Shibboleth 구성

  • 아티클

업데이트: 2015년 6월 25일

적용 대상: Azure, Office 365, Power BI, Windows Intune

이 항목에는 SAML 2.0 프로토콜을 사용하여 하나 이상의 Microsoft 클라우드 서비스(예: Microsoft Intune 및/또는 Office 365)에 대한 Single Sign-On 액세스를 사용하도록 Azure AD 페더레이션하도록 Shibboleth ID 공급자를 구성하는 방법에 대한 자세한 지침이 포함되어 있습니다. 이 시나리오에서 사용되는 Microsoft 클라우드 서비스용 SAML 2.0 신뢰 당사자는 Azure AD입니다.

중요

다음과 같은 제한된 클라이언트 집단만 이 single sign-on 시나리오에서 지원됩니다.

  • Exchange Web Access 및 SharePoint Online과 같은 웹 기반 클라이언트

  • 기본 인증을 비롯해 IMAP, POP, Active Sync, MAPI 등(향상된 클라이언트 프로토콜 끝점이 배포되어야 함)과 같은, 지원되는 Exchange 액세스 방법을 사용하는 이메일 리치 클라이언트에는 다음이 포함됩니다.

    • Microsoft Outlook 2007

    • Microsoft Outlook 2010

    • Thunderbird 8 및 9

    • iPhone(다양한 iOS 버전)

    • Windows Phone 7

다른 모든 클라이언트는 Shibboleth ID 공급자를 사용하는 이 Single Sign-On 시나리오에서 지원되지 않습니다.  예를 들어 Lync 2010 데스크톱 클라이언트는 Single Sign-On을 위해 구성된 Shibboleth ID 공급자를 사용하여 서비스에 로그인할 수 없습니다.

중요

Single Sign-On을 위해 Shibboleth ID 공급자를 구성하기 위해 이 항목의 단계를 완료하려면 먼저 Single Sign-On 준비에 제공된 지침을 검토하고 따라야 합니다.

Single Sign-On에 대한 일반적인 내용은 Single Sign-On 로드맵을 참조하세요.

Single Sing-On을 사용하도록 Shibboleth ID 공급자를 구성하려면 다음 단계를 완료합니다.

  1. Azure AD 메타데이터 추가

  2. Azure AD를 신뢰 당사자로 추가

  3. Shibboleth 특성 확인자 구성

  4. Shibboleth 특성 필터 구성

  5. 선택 사항: Shibboleth ECP 확장 설치

  6. Shibboleth를 다시 시작하고 기능 확인

중요

이 항목 전반에서 설명하는 예에서 IDP_HOME은 c:\shibboleth2idp와 같이 Shibboleth ID 공급자를 설치한 기본 디렉터리입니다. 이 항목의 지침에 따라 Shibboleth를 구성할 때는 IDP_HOME을 실제 경로로 바꿉니다.

Azure AD 메타데이터 추가

Shibboleth ID 공급자를 사용하려면 Azure AD 신뢰 당사자에 대한 정보가 필요합니다. Azure AD는 https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml 에 메타데이터를 게시합니다. 최신 Azure AD 메타데이터가 있는지 항상 확인하는 것이 좋습니다. 메타데이터의 최신 값은 다음과 같습니다.

<?xml version="1.0" encoding="utf-8"?>
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="urn:federation:MicrosoftOnline">
  <SPSSODescriptor WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://login.microsoftonline.com/login.srf" index="0" isDefault="true"/>
    <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://login.microsoftonline.com/login.srf" index="1"/>
    <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://login.microsoftonline.com/login.srf" index="2" />
    <NameIDFormat>
      urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
    </NameIDFormat>
    <NameIDFormat>
      urn:mace:shibboleth:1.0:nameIdentifier
    </NameIDFormat>
    <NameIDFormat>
      urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
    </NameIDFormat>
    <NameIDFormat>
      urn:oasis:names:tc:SAML:2.0:nameid-format:transient
    </NameIDFormat>
    <NameIDFormat>
      urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
    </NameIDFormat>
  </SPSSODescriptor>
</EntityDescriptor>

Shibboleth ID 공급자에 Azure AD 메타데이터를 추가하려면 파일 시스템 메타데이터 공급자 방법을 사용하여 IDP_HOME/metadata 폴더의 파일에 Azure AD 메타데이터를 수동으로 다운로드 및 저장할 수 있습니다.

중요

이 항목 전반에서 설명하는 예에서 IDP_HOME은 c:\shibboleth2idp와 같이 Shibboleth ID 공급자를 설치한 기본 디렉터리입니다. 이 항목의 지침에 따라 Shibboleth를 구성할 때는 IDP_HOME을 실제 경로로 바꿉니다.

Azure AD를 신뢰 당사자로 추가

IDP_Home/conf/relying-party.xml 파일에서 새 RelyingParty 요소를 정의하여 Shibboleth ID 공급자와 Azure AD 간의 통신이 가능하도록 설정해야 합니다. Azure AD에서는 DefaultRelyingParty 요소의 기본 saml:SAML2Profile 설정을 변경해야 합니다.

DefaultRelyingParty 요소 뒤에 다음 텍스트를 삽입하고 RelyingParty ID 값이 add Azure AD 메타데이터에 지정한 entityID 값과 일치하는지 확인합니다(예: "urn:federation:MicrosoftOnline"). 또한 다음 예에 나와 있는 것처럼 provider 값이 DefaultRelyingParty 요소에 지정된 Shibboleth ID 공급자의 EntityID와 일치하는지 확인합니다.

<!-- Azure AD -->
<rp:RelyingParty id="urn:federation:MicrosoftOnline" provider="https://idp.contoso.com/idp/shibboleth" defaultSigningCredentialRef="IdPCredential">
         
     <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile"
signAssertions="conditional"
encryptAssertions="never"
encryptNameIds="never" />
             
</rp:RelyingParty>

또한 IDP_HOME/metadata/windows-azure-ad-metadata.xml과 같이 Azure AD 메타데이터가 포함된 파일을 찾을 위치를 Shibboleth ID 공급자에 대해 지정해야 합니다. 이렇게 하려면 다음 예에 나와 있는 것처럼 IDP_Home/conf/relying-party.xml 파일의 MetadataProvider 노드에 항목을 추가합니다.

<!—- Azure AD Metadata -->
<metadata:MetadataProvider id="OrgID" xsi:type="metadata:ResourceBackedMetadataProvider">
<metadata:MetadataResource xsi:type="resource:FilesystemResource" file="C:\opt\shibboleth-idp/metadata/WindowsAzureAD-metadata.xml"/>

Shibboleth 특성 확인자 구성

Azure AD에서는 인증 플랫폼의 섀도 계정을 찾기 위해 Shibboleth ID 공급자의 두 데이터를 사용해야 합니다. Shibboleth에 이러한 요구 사항을 알리려면 IDP_HOME/conf/attribute-resolver.xml 파일에 다음 항목을 추가합니다.

  • Azure AD ImmutableID

    Azure AD에서는 사용자 디렉터리의 각 사용자에 대해 고유 식별자를 선택해야 합니다. 또한 SAML 2.0 NameID 어설션에서 Azure AD에 대한 각 페더레이션 로그인에 대해 이 특성을 보내도록 Shibboleth를 구성해야 합니다. 사용자가 시스템에 존재하는 동안에는 해당 사용자에 대해 이 식별자가 변경되면 안 됩니다. Azure AD 서비스에서 해당 특성은 "ImmutableID"입니다. 고유 식별자의 값은 도메인 정보를 포함할 수 없으며 대/소문자를 구분합니다.

    예를 들어 .user@contoso.com 아래 권장 코드에서 사용된 값은 base64로 인코딩된 Active Directory objectGUID 속성입니다. 계정을 만들 때는 ImmutableID가 동일한 방식으로 처리되는지 확인해야 합니다. 그렇지 않으면 사용자가 Microsoft 클라우드 서비스에 로그인할 수 없습니다. Microsoft Azure Active Directory 동기화 도구는 ImmutableID 값에 대해 Active Directory objectGUID를 자동으로 사용하고 다음 권장 예제와 동일한 방식으로 ImmutableID를 처리합니다.

    <!-- Use AD objectGUID for ImmutableID -->
<resolver:AttributeDefinition id="ImmutableID" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
          sourceAttributeID="objectGUID">
   <resolver:Dependency ref="myLDAP" />

   <resolver:AttributeEncoder xsi:type="SAML2StringNameID" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
   nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" />
  </resolver:AttributeDefinition>

    중요

    attribute-resolver.xml에서 LDAP 데이터 커넥터를 업데이트하여 objectGUID를 바이너리로 지정합니다.

    LDAP 데이터 커넥터 항목에 다음 줄을 추가합니다. 그러면 objectGUID가 올바르게 처리되며 base64로 인코딩됩니다.

    <LDAPProperty name="java.naming.ldap.attributes.binary" value="objectGUID"/>

    예를 들어:

    <!-- ========================================== -->
<!--      Data Connectors                       -->
<!-- ========================================== -->
<!-- Live@edu LDAP Connector -->
<resolver:DataConnector id="myLDAP" xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
                   ldapURL="ldap://MyADServer:389"
                   baseDN="CN=Users,DC=MyDomain,DC=ORG"
                   principal="CN=Administrator,CN=Users,DC=MyDomain,DC=ORG"
                   principalCredential="A.useful.p!w.d">
  <FilterTemplate>
    <![CDATA[
                (uid=$requestContext.principalName)
            ]]>
  </FilterTemplate>

  <LDAPProperty name="java.naming.ldap.attributes.binary" value="objectGUID"/>

</resolver:DataConnector>

  • Azure AD 사용자 ID

    Azure AD 아래 예제에 설명된 대로 사용자 지정 항목을 사용하여 Azure AD 사용자 IDjoe@contoso.com를 보내야 합니다. 이 예에서 값은 LDAP userPrincipalName 특성에 저장됩니다.

    <!-- UserPrincipalName for Azure AD User ID -->
<resolver:AttributeDefinition id="UserId" xsi:type="ad:Simple" sourceAttributeID="userPrincipalName">
      <resolver:Dependency ref="myLDAP" />
      <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="IDPEmail" friendlyName="UserId" />
</resolver:AttributeDefinition>

Shibboleth 특성 필터 구성

Shibboleth ID 공급자는 Azure AD로 필수 특성을 릴리스하도록 구성해야 합니다. 특성을 Azure AD로 릴리스하려면 IDP_HOME/conf/attribute-filter.xml 파일에 다음 텍스트를 추가합니다.

여기에 나와 있는 설정은 Azure AD 및 Windows Live 서비스로만 필수 특성을 릴리스하며 특정 AttributeFilterPolicy ID를 사용하여 Azure AD에 필요한 특성을 표시합니다.

<!-- Attribute Filter Policy for Azure AD -->
<afp:AttributeFilterPolicy id="PolicyForWindowsAzureAD">
<afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="urn:federation:MicrosoftOnline" />

<!-- Release userPrincipalName as Azure AD User ID -->
      <afp:AttributeRule attributeID="UserId">
            <afp:PermitValueRule xsi:type="basic:ANY"/>
      </afp:AttributeRule>

<!-- Release Immutable ID to Azure AD -->
      <afp:AttributeRule attributeID="ImmutableID">
          <afp:PermitValueRule xsi:type="basic:ANY"/>
      </afp:AttributeRule>

<!-- Note: it is not recommended to send transientId to Azure AD -->
<afp:AttributeRule attributeID="transientId">
   <afp:DenyValueRule xsi:type="basic:ANY"/>
</afp:AttributeRule>

</afp:AttributeFilterPolicy>

선택 사항: Shibboleth ECP 확장 설치

이 단계는 선택 사항이지만 수행하는 것이 좋습니다. Shibboleth를 STS로 사용 중인 경우 스마트폰, Microsoft Outlook 또는 기타 클라이언트에서 Single Sign-On을 사용하려면 Shibboleth ID 공급자 ECP 확장을 설치해야 합니다.

ECP(향상된 클라이언트/프록시) 확장은 Shibboleth 2.3.3 이상 버전에 포함되어 있습니다. Shibboleth 2.x 이전 버전의 경우에는 ECP 확장을 다운로드하여 설치할 수 있습니다. 자세한 내용은 https://wiki.shibboleth.net/confluence/display/SHIB2/IdP+ECP+Extension를 참조하세요.

Shibboleth ID 공급자 ECP 확장을 사용하면 데스크톱 전자 메일 응용 프로그램과 Azure AD를 통합할 수 있습니다. 이 확장은 SAML 2.0 ECP 사양을 구현합니다. Azure AD와의 Single Sign-On을 구성할 때는 ECP 확장의 URL을 https://idp.contoso.com/idp/profile/SAML2/SOAP/ECP와 같이 지정할 수 있습니다. 현재 Shibboleth ECP 확장 인증은 기본 인증으로 제한됩니다.

Shibboleth ECP 확장을 설치하려면 다음 단계를 완료합니다.

  1. IDP_HOME/metadata에 있는 로컬 Azure AD 메타데이터 파일에 다음 코드를 추가합니다.

    <AssertionConsumerService index="2" Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://login.microsoftonline.com/login.srf"/>

  2. IDP_HOME/config에 있는 relying-party.xml의 Azure AD RelyingParty 구성 노드에 "saml:SAML2ECPProfile" 항목을 추가합니다.

    <rp:RelyingParty id="urn:federation:MicrosoftOnline" provider="https://idp.contoso.edu/idp/shibboleth" defaultSigningCredentialRef="IdPCredential">  
                <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" 
                                signAssertions="conditional" 
                                encryptAssertions="never"                          
                                encryptNameIds="never" />                                                      
                <rp:ProfileConfiguration xsi:type="saml:SAML2ECPProfile"                                                           
                                signAssertions="always"                  
                                encryptAssertions="never"                  
                                encryptNameIds="never"/>                                                             
</rp:RelyingParty>

Shibboleth를 다시 시작하고 기능 확인

Apache Tomcat을 중지했다가 시작하여 Shibboleth ID 공급자를 다시 시작한 다음 업데이트된 XML 파일이 로드되었는지 확인합니다. 하나 이상의 구성 파일에 문제가 있으면 Shibboleth가 시작되지 않을 수 있습니다. 공급자를 다시 시작한 후 Shibboleth 로그 파일에서 오류가 보고되지 않았는지를 확인합니다. 또한 네트워크에서 이전에 구성한 Shibboleth 서비스 공급자에 로그인하여 액세스해 보는 것이 좋습니다.

참고

Shibboleth 서버의 시계가 정확한 시간 원본과 동기화되는지 확인합니다. 시계 시간이 부정확하면 페더레이션 로그인이 실패하게 됩니다.

참고 항목

개념

Shibboleth Identity Provider를 사용하여 Single Sign-On 구현