SSO 및 안전한 하이브리드 액세스를 위해 Akamai 엔터프라이즈 애플리케이션 액세스로 Azure Active Directory B2C 구성
이 샘플 자습서에서는 Azure AD B2C(Azure Active Directory B2C) 인증을 Akamai 엔터프라이즈 애플리케이션 액세스와 통합하는 방법을 알아봅니다. Akamai 엔터프라이즈 애플리케이션 액세스는 프라이빗 데이터 센터에 있는 최신 및 레거시 애플리케이션에 대한 안전한 원격 액세스를 지원하는 ZTNA(제로 트러스트 네트워크 액세스) 솔루션입니다. Akamai 엔터프라이즈 애플리케이션 액세스는 IdP(ID 공급자) Azure AD B2C와 페더레이션하여 사용자를 인증한 다음 권한 부여 정책을 사용하여 프라이빗 애플리케이션에 대한 액세스를 허용하기 전에 ID, 디바이스, 애플리케이션 및 요청 컨텍스트를 지속적으로 평가합니다.
이 기능은 사용자 지정 정책에만 사용할 수 있습니다. 설정 단계의 경우 이전 선택기의 사용자 지정 정책을 선택합니다.
필수 조건
시작하려면 다음이 필요합니다.
Akamai 엔터프라이즈 액세스 계약. 계정이 없으면 체험 계정을 얻습니다.
Azure 구독 구독이 없는 경우 무료 계정을 얻을 수 있습니다.
Azure 구독에 연결된 Azure AD B2C 테넌트입니다.
Akamai 엔터프라이즈 애플리케이션 액세스 커넥터를 배포하기 위해 데이터 센터 또는 하이브리드 클라우드 환경의 방화벽 뒤에 배포된 가상 어플라이언스
인증을 위해 헤더를 사용하는 애플리케이션입니다. 이 샘플에서는 docker header-demo-app 헤더를 표시하는 애플리케이션을 사용합니다.
또는 OIDC(OpenID Connect) 애플리케이션. 이 샘플에서는 OWIN(Open Web Interface for .NET) 미들웨어 및 Microsoft ID 플랫폼을 사용하여 사용자를 로그인하는 ASP.NET MVC 웹앱을 사용합니다.
시나리오 설명
이 시나리오에서는 최종 사용자가 Akamai 엔터프라이즈 애플리케이션 액세스로 보호되는 프라이빗 애플리케이션에 액세스하려고 시도하는 동안 Azure AD B2C 인증을 사용하도록 설정합니다.
이 통합과 관련된 구성 요소는 다음과 같습니다.
Azure AD B2C: 최종 사용자 인증을 담당하는 SAML ID 공급자입니다.
Akamai 엔터프라이즈 애플리케이션 액세스: 지속적인 ZTNA 정책 적용으로 프라이빗 애플리케이션에 대한 액세스 보안을 담당하는 ZTNA 클라우드 서비스입니다.
Akamai 엔터프라이즈 애플리케이션 액세스 커넥터: 프라이빗 데이터 센터에 배포된 가상 어플라이언스입니다. 데이터 센터 인바운드 방화벽 포트를 열지 않고도 프라이빗 앱에 안전하게 연결할 수 있습니다.
애플리케이션: 최종 사용자가 액세스해야 하는 프라이빗 데이터 센터에 배포된 서비스 또는 애플리케이션입니다.
사용자는 SAML 어설션을 사용하여 Akamai 엔터프라이즈 애플리케이션 액세스(서비스 공급자)에 응답할 Azure AD B2C(SAML IdP)에 인증합니다. Akamai 엔터프라이즈 애플리케이션 액세스는 SAML 어설션의 정보를 매핑하고 OpenID 클레임을 구성하거나 사용자에 대한 정보가 포함된 HTTP 헤더를 삽입합니다. 그런 다음 Akamai 엔터프라이즈 애플리케이션 액세스는 이를 Akamai 엔터프라이즈 애플리케이션 액세스 커넥터를 통해 액세스할 수 있는 애플리케이션으로 전달합니다. 샘플에서 애플리케이션은 이러한 헤더의 콘텐츠를 표시합니다. OIDC 애플리케이션의 사용 사례에서는 사용자의 클레임을 표시합니다.
다음 다이어그램은 Akamai EAA(엔터프라이즈 애플리케이션 액세스)가 Azure AD B2C와 통합되는 방식을 보여 줍니다.
최종 사용자가 Akamai 엔터프라이즈 애플리케이션 액세스에 등록된 애플리케이션의 외부 URL을 사용하여 프라이빗 데이터 센터에서 호스트되는 애플리케이션에 액세스하려고 합니다.
Akamai 엔터프라이즈 애플리케이션 액세스는 인증을 위해 인증되지 않은 최종 사용자를 Azure AD B2C로 리디렉션합니다.
인증에 성공한 후 SAML 어설션을 사용하여 Akamai 엔터프라이즈 애플리케이션 액세스로 Azure AD B2C는 사용자를 다시 리디렉션합니다.
Akamai 엔터프라이즈 애플리케이션 액세스는 SAML 어설션의 ID 정보를 사용하여 사용자를 식별하고 사용자가 요청된 애플리케이션에 액세스할 수 있는지 여부를 결정합니다.
Akamai 엔터프라이즈 애플리케이션 액세스는 OIDC 클레임을 구성하거나 HTTP 헤더를 삽입하여 애플리케이션으로 전송합니다.
애플리케이션은 이 정보를 사용하여 인증된 사용자를 식별하고 최종 사용자를 위한 애플리케이션 세션을 만듭니다.
Akamai 엔터프라이즈 애플리케이션 액세스로 온보딩
Akamai 엔터프라이즈 애플리케이션 액세스를 시작하려면 Akamai 엔터프라이즈 애플리케이션 액세스 시작 가이드를 참조하세요.
1단계 - Akamai 엔터프라이즈 애플리케이션 액세스에서 Azure AD B2C를 SAML IdP로 추가
Akamai 엔터프라이즈 애플리케이션 액세스는 Azure AD B2C와 같은 클라우드 IdP와의 SAML 페더레이션을 지원합니다. Akamai 엔터프라이즈 애플리케이션 액세스에서 Azure AD B2C를 타사 SAML IdP로 추가합니다.
엔터프라이즈 센터 https://control.akamai.com/에 로그인
엔터프라이즈 센터 탐색 메뉴에서 애플리케이션 액세스 > ID 및 사용자 > ID 공급자를 선택합니다.
ID 공급자 추가(+)를 선택합니다.
이름과 설명을 입력하고 공급자 형식을 타사 SAML로 선택합니다.
계속을 선택합니다. ID 공급자 구성 페이지가 나타납니다.
설정>일반에서 ID 서버의 URL을 입력합니다. Akamai 도메인 사용 또는 도메인 사용을 선택할 수 있습니다. 고유의 도메인을 사용하는 경우 자체 서명된 인증서를 사용하거나 업로드된 사용자 지정 인증서를 사용합니다.
인증에 일반의 이전 단계에서 정의한 것과 동일한 URL을 입력하고 저장을 선택합니다.
2단계 - Azure AD B2C에서 SAML 애플리케이션 등록
GitHub에서 사용자 지정 정책 스타터 팩을 가져온 다음, Azure AD B2C 테넌트 이름을 사용하여 LocalAccounts 스타터 팩의 XML 파일을 업데이트합니다.
.zip 파일을 다운로드하거나 리포지토리를 복제합니다.
git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpackLocalAccounts 디렉터리의 모든 파일에서 문자열
yourtenant를 Azure AD B2C 테넌트의 이름으로 바꿉니다. 예를 들어 B2C 테넌트의 이름이fabrikam이면yourtenant.onmicrosoft.com의 모든 인스턴스는fabrikam.onmicrosoft.com이 됩니다.
Akamai 엔터프라이즈 애플리케이션 액세스로 전송되는 SAML 응답에 서명하기 위해 Azure AD B2C용 서명 인증서를 만듭니다.
a. 인증서를 가져옵니다. 인증서가 아직 없는 경우 자체 서명된 인증서를 사용할 수 있습니다.
b. Azure AD B2C 테넌트에 인증서를 업로드합니다. 다음 단계에서 언급된
TechnicalProfile에 이름이 필요하므로 이름을 기록해 두세요.정책이 SAML 애플리케이션과 연결되도록 설정합니다.
a. 사용자 지정 정책 시작 팩에서
LocalAccounts\TrustFrameworkExtensions.xml을 엽니다. ClaimsProviders 요소를 찾습니다. 존재하지 않는 경우 루트 요소TrustFrameworkPolicy아래에 추가하고 다음 XML 코드 조각을 추가하여 SAML 응답 생성기를 구현합니다.<ClaimsProvider> <DisplayName>Akamai</DisplayName> <TechnicalProfiles> <!-- SAML Token Issuer technical profile --> <TechnicalProfile Id="AkamaiSaml2AssertionIssuer"> <DisplayName>Token Issuer</DisplayName> <Protocol Name="SAML2" /> <OutputTokenFormat>SAML2</OutputTokenFormat> <Metadata> <Item Key="IssuerUri">https://<REPLACE>.login.go.akamai-access.com/saml/sp/response</Item> </Metadata> <CryptographicKeys> <Key Id="SamlAssertionSigning" StorageReferenceId="B2C_1A_AkamaiSAMLSigningCert" /> <Key Id="SamlMessageSigning" StorageReferenceId="B2C_1A_AkamaiSAMLSigningCert" /> </CryptographicKeys> <InputClaims /> <OutputClaims /> <UseTechnicalProfileForSessionManagement ReferenceId="SM-Saml-issuerAkamai" /> </TechnicalProfile> <!-- Session management technical profile for SAML-based tokens --> <TechnicalProfile Id="SM-Saml-issuerAkamai"> <DisplayName>Session Management Provider</DisplayName> <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.SamlSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" /> <Metadata> <Item Key="IncludeSessionIndex">false</Item> <Item Key="RegisterServiceProviders">false</Item> </Metadata> </TechnicalProfile> </TechnicalProfiles> </ClaimsProvider>b. 1단계에서 Akamai 엔터프라이즈 애플리케이션 액세스 설정 > 일반에 정의된 Akamai URL로
issuerUri를 바꿉니다.예:
<Item Key="IssuerUri">https://fabrikam.login.go.akamai-access.com/saml/sp/response</Item>B2C_1A_AkamaiSAMLSigningCert를 업로드된 정책 키의 이름으로 바꿉니다.
3단계 - SAML에 대해 구성된 등록 또는 로그인 정책 만들기
시작 팩의 작업 디렉터리에
SignUpOrSignin.xml파일의 복사본을 만들고 새 이름으로 저장합니다. 이 문서에서는SignUpOrSigninSAML.xml을 예로 사용합니다. 이 파일은 신뢰 당사자에 대한 정책 파일입니다. 기본적으로 JWT 응답을 발급하도록 구성되어 있습니다.원하는 편집기에서
SignUpOrSigninSAML.xml파일을 엽니다.Azure AD B2C 테넌트의 이름으로
tenant-name을 업데이트하고 정책의PolicyId및PublicPolicyUri값을B2C_1A_signup_signin_saml및http://<tenant-name>.onmicrosoft.com/B2C_1A_signup_signin_saml로 변경합니다.<TrustFrameworkPolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.microsoft.com/online/cpim/schemas/2013/06" PolicySchemaVersion="0.3.0.0" TenantId="tenant-name.onmicrosoft.com" PolicyId="B2C_1A_signup_signin_saml" PublicPolicyUri="http://<tenant-name>.onmicrosoft.com/B2C_1A_signup_signin_saml">사용자 경험이 끝나면 Azure AD B2C에
SendClaims단계가 포함됩니다. 이 단계에서는 토큰 발급자 기술 프로필을 참조합니다. 기본 JWT 응답이 아닌 SAML 응답을 발급하려면SendClaims새 SAML 토큰 발급자 기술 프로필을 참조하는 단계를 수정Saml2AssertionIssuer합니다.<RelyingParty>요소 바로 앞에 다음 XML 코드 조각을 추가합니다. 이 XML은LocalAccount사용자 지정 정책 시작 팩을 사용한다고 가정하고SignUpOrSignIn사용자 경험의 오케스트레이션 4단계를 덮어씁니다.시작 팩의 다른 폴더에서 시작했거나 오케스트레이션 단계를 추가 또는 제거하여 사용자 경험을 사용자 지정한 경우
order요소의 번호가 토큰 발급자 단계의 사용자 경험에 지정된 번호와 일치하는지 확인합니다. 예를 들어 다른 시작 팩 폴더에서 해당 단계 번호는SocialAndLocalAccounts의 경우 7,SocialAccounts의 경우 6,SocialAndLocalAccountsWithMfa의 9입니다.<UserJourneys> <UserJourney Id="SignUpOrSignIn"> <OrchestrationSteps> <OrchestrationStep Order="4" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="AkamaiSaml2AssertionIssuer"/> </OrchestrationSteps> </UserJourney> </UserJourneys>신뢰 당사자 요소는 애플리케이션에서 사용하는 프로토콜을 결정합니다. 기본값은
OpenId입니다.Protocol요소는SAML로 변경해야 합니다. 출력 클레임은 SAML 어설션에 대한 클레임 매핑을 만듭니다.<RelyingParty>요소의 전체<TechnicalProfile>요소를 다음 기술 프로필 XML로 바꿉니다.<TechnicalProfile Id="PolicyProfile"> <DisplayName>PolicyProfile</DisplayName> <Protocol Name="SAML2"/> <OutputClaims> <OutputClaim ClaimTypeReferenceId="displayName" /> <OutputClaim ClaimTypeReferenceId="givenName" /> <OutputClaim ClaimTypeReferenceId="surname" /> <OutputClaim ClaimTypeReferenceId="email" DefaultValue="" /> <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="" /> <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="objectId"/> </OutputClaims> <SubjectNamingInfo ClaimType="objectId" ExcludeAsClaim="true"/> </TechnicalProfile>신뢰 당사자의 최종 정책 파일은 다음 XML 코드처럼 표시됩니다.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <TrustFrameworkPolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.microsoft.com/online/cpim/schemas/2013/06" PolicySchemaVersion="0.3.0.0" TenantId="fabrikam.onmicrosoft.com" PolicyId="B2C_1A_signup_signin_saml" PublicPolicyUri="http://fabrikam.onmicrosoft.com/B2C_1A_signup_signin_saml"> <BasePolicy> <TenantId>fabrikam.onmicrosoft.com</TenantId> <PolicyId>B2C_1A_TrustFrameworkExtensions</PolicyId> </BasePolicy> <UserJourneys> <UserJourney Id="SignUpOrSignIn"> <OrchestrationSteps> <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="AkamaiSaml2AssertionIssuer"/> </OrchestrationSteps> </UserJourney> </UserJourneys> <RelyingParty> <DefaultUserJourney ReferenceId="SignUpOrSignIn" /> <TechnicalProfile Id="PolicyProfile"> <DisplayName>PolicyProfile</DisplayName> <Protocol Name="SAML2"/> <OutputClaims> <OutputClaim ClaimTypeReferenceId="displayName" /> <OutputClaim ClaimTypeReferenceId="givenName" /> <OutputClaim ClaimTypeReferenceId="surname" /> <OutputClaim ClaimTypeReferenceId="email" DefaultValue="" /> <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="" /> <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="objectId"/> </OutputClaims> <SubjectNamingInfo ClaimType="objectId" ExcludeAsClaim="true"/> </TechnicalProfile> </RelyingParty> </TrustFrameworkPolicy>참고 항목
이와 동일한 프로세스에 따라 다른 형식의 흐름(예: 로그인, 암호 재설정 또는 프로필 편집 흐름)을 구현할 수 있습니다.
4단계 - 정책 업로드
변경 내용을 저장하고 TrustFrameworkBase.xml, 새 TrustFrameworkExtensions.xml 및 SignUpOrSigninSAML.xml 정책 파일을 Azure Portal에 업로드합니다.
Azure Portal에 로그인합니다.
여러 테넌트에 액세스할 수 있는 경우 상단 메뉴의 설정 아이콘을 선택하여 디렉터리 + 구독 메뉴에서 Azure AD B2C 테넌트로 전환합니다.
Azure Portal에서 Azure AD B2C를 검색하고 선택합니다.
정책에서 Identity Experience Framework를 선택합니다. 사용자 지정 정책 업로드를 선택하고 다음 순서에 따라 변경한 두 정책 파일을 업로드합니다.
- 기본 파일(예:
TrustFrameworkBase.xml) - 확장 정책(예:
TrustFrameworkExtensions.xml) - 그런 다음 신뢰 당사자 정책(예:
SignUpOrSigninSAML.xml).
- 기본 파일(예:
5단계 - Azure AD B2C IdP SAML 메타데이터 다운로드
정책 파일이 업로드된 후 Azure AD B2C는 구성 정보를 사용하여 애플리케이션에서 사용할 ID 공급자의 SAML 메타데이터 문서를 생성합니다. SAML 메타데이터 문서에는 로그인 방법, 로그아웃 방법 및 인증서 등의 서비스 위치가 포함되어 있습니다.
Azure AD B2C 정책 메타데이터는 다음 URL에서 사용할 수 있습니다.
https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/samlp/metadata<tenant-name>은 Azure AD B2C 테넌트의 이름으로 바꿉니다.<policy-name>을(를) 정책의 이름(ID)으로 바꿉니다. 예를 들어 다음과 같습니다:https://fabrikam.b2clogin.com/fabrikam.onmicrosoft.com/B2C_1A_signup_signin_saml/samlp/metadata
SAML 메타데이터를 다운로드하고 디바이스에 로컬로 저장합니다. 이는 Akamai 엔터프라이즈 애플리케이션 액세스에서 구성을 완료하기 위한 다음 단계에서 필요합니다.
6단계 - Azure AD B2C에서 Akamai 엔터프라이즈 애플리케이션 액세스 애플리케이션 등록
Azure AD B2C에서 Akamai 엔터프라이즈 애플리케이션 액세스를 신뢰하려면 Azure AD B2C 애플리케이션 등록을 만듭니다. 이 등록에는 애플리케이션의 메타데이터 엔드포인트와 같은 구성 정보가 포함됩니다.
Azure Portal에 로그인합니다.
여러 테넌트에 액세스할 수 있는 경우 상단 메뉴의 설정 아이콘을 선택하여 디렉터리 + 구독 메뉴에서 Azure AD B2C 테넌트로 전환합니다.
왼쪽 메뉴에서 Azure AD B2C를 선택합니다. 또는 전체 서비스를 선택한 다음 Azure AD B2C를 검색하여 선택합니다.
앱 등록을 선택한 다음, 새 등록을 선택합니다.
애플리케이션의 이름을 입력합니다. 예를 들어, Akamai B2C 엔터프라이즈 애플리케이션 액세스를 입력합니다.
지원되는 계정 유형에서 이 조직 디렉터리에만 있는 계정(B2C 전용 - 단일 테넌트)을 선택합니다.
리디렉션 URI에서 웹을 선택한 다음 1단계의 Akamai 엔터프라이즈 애플리케이션 액세스 설정\일반에 정의된 Akamai URL을 입력합니다. 예:
https://fabrikam.login.go.akamai-access.com/saml/sp/response.등록을 선택합니다.
7단계 - Azure AD B2C에서 Akamai 엔터프라이즈 애플리케이션 액세스 애플리케이션 구성
SAML의 경우 애플리케이션 등록 매니페스트에서 여러 속성을 구성해야 합니다.
Azure Portal에서 3단계에서 만든 애플리케이션 등록으로 이동합니다.
관리에서 매니페스트를 선택하여 매니페스트 편집기를 엽니다. 그런 다음, 다음 섹션에 설명된 속성을 수정합니다.
식별자 추가
Akamai 엔터프라이즈 애플리케이션 액세스 SAML 애플리케이션이 Azure AD B2C에 요청하면 SAML 인증 요청에 Issuer 특성이 포함됩니다. 이 특성의 값은 일반적으로 애플리케이션의 메타데이터 entityID 값과 같습니다. Azure AD B2C는 이 값을 사용하여 디렉터리에서 애플리케이션 등록을 조회하고 구성을 읽습니다. 이 조회가 성공하려면 애플리케이션 등록 매니페스트의 identifierUri가 Issuer 특성과 일치하는 값으로 채워져야 합니다.
등록 매니페스트에서 identifierURIs 매개 변수를 찾고 2단계, Azure AD B2C ClaimsProvider에 정의된 IssuerURI 값을 추가합니다.
예시:
"identifierUris": [
"https://fabrikam.login.go.akamai-access.com/saml/sp/response"
],
이 값은 애플리케이션에서 EntityId에 대해 SAML AuthN 요청에 구성된 값 및 애플리케이션의 메타데이터에 있는 entityID 값과 동일합니다. 또한 accessTokenAcceptedVersion 매개 변수를 찾아 값을 2로 설정해야 합니다.
Important
accessTokenAcceptedVersion을 2로 업데이트하지 않으면 확인된 도메인이 필요한 오류 메시지가 표시됩니다.
8단계 - Akamai 엔터프라이즈 애플리케이션 액세스에서 Azure AD B2C IdP에 대한 인증 설정 구성
신뢰 Microsoft자 URL과 같은 인증 정보로 Akamai 엔터프라이즈 애플리케이션 액세스 Azure AD B2C IdP를 업데이트합니다.
엔터프라이즈 센터 https://control.akamai.com/에 로그인
엔터프라이즈 센터 탐색 메뉴에서 애플리케이션 액세스 > ID 및 사용자 > ID 공급자를 선택합니다.
1단계에서 만든 ID 공급자 이름을 선택합니다.
5단계에서 다운로드한 Azure AD B2C SAML 메타데이터 파일을 업로드합니다.
metadata.xml 파일을 업로드하려면 파일 선택을 선택합니다.
저장 및 배포를 선택합니다.
9단계 - 프라이빗 데이터 센터에 Akamai 엔터프라이즈 애플리케이션 액세스 커넥터 배포
프라이빗 애플리케이션에 대한 액세스를 사용하도록 설정하려면 애플리케이션이 있는 프라이빗 데이터 센터에 하나 이상의 Akamai 엔터프라이즈 애플리케이션 액세스 커넥터를 배포합니다. 커넥터가 프라이빗 애플리케이션에 연결할 수 있고 Akamai 클라우드에 대한 아웃바운드 액세스 권한이 있는지 확인합니다.
10단계 - 프라이빗 애플리케이션용 Akamai 엔터프라이즈 애플리케이션 액세스에서 액세스 애플리케이션 정의
Akamai 엔터프라이즈 애플리케이션 액세스에서 액세스 애플리케이션 정의 및 배포
액세스 애플리케이션을 정의하는 경우
이전 단계에서 만든 엔터프라이즈 애플리케이션 액세스 Azure AD B2C IdP 정의에 연결합니다.
프라이빗 애플리케이션에 SSO를 사용하도록 애플리케이션 연결 인증을 구성합니다.
옵션 1: HTTP 헤더
이 샘플에서는 docker header-demo-app 헤더를 표시하는 애플리케이션을 사용합니다. 애플리케이션이 프라이빗 환경에 배포되고 커넥터가 애플리케이션에 액세스할 수 있게 되면 Akamai 설명서 액세스 애플리케이션에 대한 사용자 지정 HTTP 헤더 구성에 따라 사용자 지정 HTTP 형식 애플리케이션을 만듭니다.
- 인증에서 이전 단계에서 만든 Azure AD B2C SAML IdP를 선택합니다.
- 애플리케이션의 고급 섹션에서 인증 성공 시 SAML 응답에서 Azure AD B2C가 발급한 SAML 특성에 HTTP 헤더를 매핑합니다.
예시:
| 헤더 이름 | Attribute |
|---|---|
| ps-sso-first | http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name |
| ps-sso-last | http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname |
| ps-sso-EmailAddress | emailaddress |
| ps-sso-uid | objectId |
만든 사용자 지정 HTTP 형식 웹 애플리케이션에 대한 Akamai URL을 선택하여 애플리케이션을 테스트합니다.
옵션 2: OpenID Connect
이 샘플에서는 OWIN(Open Web Interface for .NET) 미들웨어 및 Microsoft ID 플랫폼을 사용하여 사용자를 로그인하는 ASP.NET MVC 웹앱을 사용합니다.
이전 단계에서 만든 Azure AD B2C SAML IdP에서 OIDC-SAML 브리징을 구성합니다.
액세스 애플리케이션에 대한 OpenID Connect 구성에 따라 사용자 지정 HTTP 형식 애플리케이션을 만듭니다.
인증에서 HTTP 헤더 애플리케이션에 따라 이전 단계에서 만든 Azure AD B2C SAML IdP를 선택합니다.
고급에서 인증 메커니즘으로 OpenID Connect 1.0을 선택한 다음 저장을 선택합니다.
새 OpenID 탭이 표시되면 애플리케이션 테스트를 위해 OWIN 구성 요소를 구성할 때 단계의 뒷부분에서 필요한 검색 URL을 복사합니다.
클레임 섹션에서 Akamai가 OIDC 애플리케이션에 대해 발급할 클레임을 정의하고 인증 성공 시 SAML 응답에서 Azure AD B2C가 제공하는 SAML 특성에 해당 값을 매핑합니다. 이러한 클레임은 Azure AD B2C SAML IdP에서 SAML 브리징에 OIDC를 구성할 때 이전 단계에서 정의한 내용을 매핑해야 합니다.
시작 클래스를 ASP.NET MVC 웹앱에서 다음 코드로 바꿉니다.
이러한 몇 가지 변경 내용은 인증 코드 흐름 허용을 구성하고, 인증 코드는 애플리케이션의 토큰 엔드포인트에서 토큰으로 교환되고, 메타데이터 주소를 도입하여 Akamai에서 메타데이터를 가져오기 위한 검색 엔드포인트를 설정합니다.
public class Startup { // The Client ID is used by the application to uniquely identify itself to Azure AD. string clientId = System.Configuration.ConfigurationManager.AppSettings["ClientId"]; //App Client Secret to redeem the code for an access token string ClientSecret = System.Configuration.ConfigurationManager.AppSettings["ClientSecret"]; // RedirectUri is the URL where the user will be redirected to after they sign in. string redirectUri = System.Configuration.ConfigurationManager.AppSettings["RedirectUri"]; // PostLogoutRedirectUri is the URL where the user will be redirected to after they sign out string PostLogoutRedirectUri = System.Configuration.ConfigurationManager.AppSettings["PostLogoutRedirectUri"]; //Authority is the URL for authority string authority = System.Configuration.ConfigurationManager.AppSettings["Authority"]; //discovery endpoint for obtaining metadata string MetadataAddress = System.Configuration.ConfigurationManager.AppSettings["MetadataAddress"]; /// <summary> /// Configure OWIN to use OpenIdConnect /// </summary> /// <param name="app"></param> public void Configuration(IAppBuilder app) { app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType); app.UseCookieAuthentication(new CookieAuthenticationOptions()); app.UseOpenIdConnectAuthentication( new OpenIdConnectAuthenticationOptions { // Sets the ClientId, authority, RedirectUri as obtained from web.config ClientId = clientId, Authority = authority, RedirectUri = redirectUri, MetadataAddress = MetadataAddress, // PostLogoutRedirectUri is the page that users will be redirected to after sign-out. In this case, it is using the home page PostLogoutRedirectUri = redirectUri, RedeemCode = true, Scope = OpenIdConnectScope.OpenIdProfile, // ResponseType is set to request the code id_token - which contains basic information about the signed-in user ResponseType = OpenIdConnectResponseType.Code, // OpenIdConnectAuthenticationNotifications configures OWIN to send notification of failed authentications to OnAuthenticationFailed method Notifications = new OpenIdConnectAuthenticationNotifications { AuthenticationFailed = OnAuthenticationFailed } } ); } /// <summary> /// Handle failed authentication requests by redirecting the user to the home page with an error in the query string /// </summary> /// <param name="context"></param> /// <returns></returns> private Task OnAuthenticationFailed(AuthenticationFailedNotification<OpenIdConnectMessage, OpenIdConnectAuthenticationOptions> context) { context.HandleResponse(); context.Response.Redirect("/?errormessage=" + context.Exception.Message); return Task.FromResult(0); } }web.config파일에서 메타데이터 주소를 추가하고 clientId, clientsecret, authority, redirectUri 및 PostLogoutRedirectUri를appSettings의 Akamai 애플리케이션 값으로 바꿉니다.Discovery URL=MetadataAddress를 만든 HTTP Akamai 애플리케이션의 OpenID 탭에서 이전 5단계에서 이러한 값을 찾을 수 있습니다.redirectUri는 Akamai 커넥터가 로컬 OIDC 애플리케이션으로 확인하기 위한 로컬 주소입니다.Authority는.well-known/openid-configuration문서에서 찾을 수 있는 authorization_endpoint입니다.검색 URL:
https://fabrikam.login.go.akamai-access.com/.well-known/openid-configuration<appSettings> <add key="ClientId" value="xxxxxxxxxxxxxxxxxx" /> <add key="ClientSecret" value="xxxxxxxxxxxxxxxxxx" /> <add key="Authority" value="https://fabrikam.login.go.akamai-access.com/oidc/oauth" /> <add key="redirectUri" value="http://oidcapp.identity.mistermik.com/" /> <add key="PostLogoutRedirectUri" value="https://oidc-test.go.akamai-access.com/" /> <add key="MetadataAddress" value="https://fabrikam.login.go.akamai-access.com/.well-known/openid-configuration" /> </appSettings>만들어진 사용자 지정 http 형식 웹 애플리케이션에 대한 Akamai URL을 선택하여 애플리케이션을 테스트합니다.
솔루션 테스트
Akamai 엔터프라이즈 애플리케이션 액세스에 지정된 외부 URL을 사용하여 애플리케이션 URL로 이동합니다.
인증되지 않은 사용자는 Azure AD B2C 로그인 페이지로 리디렉션됩니다.
페이지의 목록에서 IdP를 선택합니다.
Azure AD B2C에 연결된 자격 증명을 사용하여 최종 사용자로 로그인합니다.
인증에 성공하면 최종 사용자는 애플리케이션으로 다시 리디렉션되고 애플리케이션에 최종 사용자로 로그인됩니다.
추가 리소스
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기