ID 서비스와 페더레이션

Red Hat OpenStack Platform 16.2

Red Hat Single Sign-On을 사용하여 ID 서비스와 통합

OpenStack Documentation Team

초록

Red Hat Single Sign-On을 사용하여 ID 서비스와 통합

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

Red Hat 문서에 관한 피드백 제공

문서 개선을 위한 의견을 보내 주십시오. Red Hat이 어떻게 이를 개선하는지 알려주십시오.

DDF(직접 문서 피드백) 기능 사용

특정 문장, 단락 또는 코드 블록에 대한 직접 주석은 피드백 추가 DDF 기능을 사용하십시오.

  1. 다중 페이지 HTML 형식으로 설명서를 봅니다.
  2. 문서 오른쪽 상단에 Feedback (피드백) 버튼이 표시되는지 확인합니다.
  3. 주석 처리하려는 텍스트 부분을 강조 표시합니다.
  4. 피드백 추가를 클릭합니다.
  5. 주석을 사용하여 Add Feedback (피드백 추가) 필드를 작성합니다.
  6. 선택 사항: 설명서 팀이 문제에 대한 자세한 내용을 문의할 수 있도록 이메일 주소를 추가하십시오.
  7. Submit(제출)을 클릭합니다.

1장. 소개

주의

Red Hat은 현재 페더레이션을 지원하지 않습니다. 이 기능은 테스트에만 사용해야 하며 프로덕션 환경에 배포해서는 안 됩니다.

고가용성 Red Hat OpenStack Platform director 환경에서 페더레이션을 구성하려면 다음을 구성해야 합니다.

  • Red Hat Identity Management
  • Red Hat Single Sign-On(RH-SSO)
  • Red Hat OpenStack Platform 오버클라우드

1.1. 개요

통합 인증은 분산된 서비스에 대한 인증을 제공하는 방법입니다. 이 인증 솔루션은 서비스 공급자(SP)인 ID 공급자(IdP)를 사용하며 SAML(Security Assertion Markup Language)을 기반으로 합니다.

OpenStack이 페더레이션 인증 솔루션의 서비스 프로바이더인 경우 Red Hat IdM(Identity Management) 그룹의 구성원 openstack-users 는 프로젝트 액세스에 대해 Member 역할을 사용하여 OpenStack Keystone 그룹 federated _users 에 매핑됩니다. 결과적으로 해당 사용자를 IdM 그룹 openstack-users 에 추가하여 OpenStack에 대한 액세스 권한을 부여할 수 있습니다.

1.2. 사전 요구 사항

통합 인증을 배포하기 전에 다음을 완료해야 합니다.

  • 다음과 같은 속성을 사용하여 Red Hat OpenStack Platform director 및 오버클라우드를 배포했습니다.

    • SSH를 사용하여 Red Hat OpenStack Platform director와 각 오버클라우드 노드에 연결할 수 있습니다.
    • 모든 노드에는 FQDN(정규화된 도메인 이름)이 있습니다.
    • TLS 암호화는 모든 외부 통신에 사용됩니다.
    • HAProxy는 TLS 프런트 엔드 연결을 종료하고 HAProxy 뒤에서 실행되는 서버는 TLS를 사용하지 않습니다.
  • RH-SSO 서버가 있고, 서버에 대한 관리 권한이 있거나 RH-SSO 관리자가 사용자에게 필요한 영역을 생성하고 해당 영역에 대한 관리 권한이 부여되었습니다. 연합된 IdP는 정의에 따라 외부에 있기 때문에 RH-SSO 서버가 Red Hat OpenStack Platform director 오버클라우드 외부로 간주됩니다. 자세한 내용은 RH-SSO 설치 및 구성영역 및 사용자 생성을 참조하십시오.
  • IdM 서버가 있으며 사용자와 그룹이 관리되는 Red Hat OpenStack Platform director 오버클라우드 외부에도 있습니다. RH-SSO는 IdM을 사용자 페더레이션 백업 저장소로 사용합니다.
  • Keystone 페더레이션 구성 가이드에 설명된 예제를 따릅니다.
  • undercloud-0 노드에서 도우미 파일을 stack 사용자의 홈 디렉터리에 설치하고 stack 사용자 홈 디렉터리에서 작업합니다.
  • controller-0 노드에서 도우미 파일을 heat-admin 사용자의 홈 디렉터리에 설치하고 heat-admin 사용자 홈 디렉터리에서 작업합니다.
  • 이전에 컨트롤러 노드에 mod_auth_mellon 이 설치된 경우 Puppet Apache 클래스에서 제어하지 않는 Apache 구성 파일이 제거되므로 이를 다시 설치해야 합니다.
참고

Red Hat OpenStack 오버클라우드만 페더레이션이 활성화되었습니다. director가 연결되지 않습니다.

1.3. Red Hat OpenStack Platform 노드에 액세스

오버클라우드 노드에 액세스하려면 기본적으로 Red Hat OpenStack Platform director에 로그인해야 합니다.

  1. SSH를 사용하여 Red Hat OpenStack director에 연결합니다.

    # ssh undercloud-0
  2. stack 사용자가 됩니다.

    $ su - stack
  3. stackrc 구성을 가져와 필요한 OpenStack 환경 변수를 활성화합니다.

    $ source stackrc
  4. stackrc 를 소싱한 후 Red Hat OpenStack Platform director에 대해 작동하는 openstack 명령줄 툴을 사용하여 명령을 실행할 수 있습니다. 오버클라우드 노드 중 하나에 직접 액세스하려면 openstack server list 를 사용하여 IP 주소를 검색한 다음 SSH를 사용하여 연결합니다.

    (undercloud) [stack@director ~]$ openstack server list -c Name -c Networks
    +----------------------+-----------------------+
    | Name                 | Networks              |
    +----------------------+-----------------------+
    | rhosp-controller-0   | ctlplane=10.94.101.11 |
    | rhosp-controller-1   | ctlplane=10.94.101.14 |
    | rhosp-controller-2   | ctlplane=10.94.101.17 |
    | rhosp-hypervisor-0   | ctlplane=10.94.101.18 |
    | rhosp-hypervisor-1   | ctlplane=10.94.101.20 |
    +----------------------+-----------------------+
    
    $ ssh heat-admin@10.94.101.11

1.4. 기술 개요

다음은 Red Hat OpenStack Platform의 일부입니다.

1.4.1. 고가용성

Red Hat OpenStack Platform director는 다양한 OpenStack 서비스의 중복 사본을 오버클라우드 배포에 배포합니다. 이러한 중복 서비스는 오버클라우드 컨트롤러 노드에 배포되며, director는 Red Hat OpenStack Platform director가 구성한 컨트롤러 노드 수에 따라 이러한 노드 controller-0, controller-1, controller-2 등이 이름을 지정합니다.

컨트롤러 노드에서 실행되는 서비스는 HAProxy 백엔드 서버이므로 컨트롤러 노드의 IP 주소는 외부에서 표시되지 않습니다. 컨트롤러 노드 집합에 공개적으로 표시되는 IP 주소가 있습니다. 이는 HAProxy의 프런트엔드입니다. 공용 IP 주소에 서비스에 대한 요청이 도착하면 HAProxy는 백엔드 서버를 선택하여 요청을 서비스합니다.

Overcloud는 고가용성 클러스터로 구성됩니다. Pacemaker 에서 클러스터를 관리하고 상태 점검을 수행하며 리소스가 작동을 중지하는 경우 다른 클러스터 리소스로 장애 조치할 수 있습니다. Pacemaker를 사용하여 이러한 리소스를 시작하고 중지합니다.

고가용성에 대한 자세한 내용은 High Availability Deployment and Usage 가이드를 참조하십시오.

1.4.1.1. Pacemaker 서비스 관리

Pacemaker에서 관리하는 포함된 서비스를 관리하기 위해 컨트롤러 노드에서 podman 명령을 사용하지 마십시오. Pacemaker pcs 명령을 사용합니다.

sudo pcs resource restart haproxy-bundle

리소스 이름을 확인하려면 Pacemaker status 명령을 사용합니다.

sudo pcs status
...
* Container bundle set: haproxy-bundle [cluster.common.tag/openstack-haproxy:pcmklatest]:
    * haproxy-bundle-podman-0   (ocf::heartbeat:podman):        Started rhosp13-controller-0
    * haproxy-bundle-podman-1   (ocf::heartbeat:podman):        Started rhosp13-controller-1
    * haproxy-bundle-podman-2   (ocf::heartbeat:podman):        Started rhosp13-controller-2
...

1.4.2. HAProxy 개요

HAProxy는 Pacemaker와 유사한 역할을 제공합니다. 백엔드 서버에서 상태 점검을 수행하고 백엔드 서버에 요청을 전달합니다. 모든 컨트롤러 노드에서 실행되는 HAProxy의 사본이 있습니다.

N 개의 HAProxy 사본이 실행 중이지만 실제로 한 번에 하나의 복사본만 요청하고 있습니다. 이 활성 HAProxy 인스턴스는 Pacemaker에서 관리합니다. 이 접근 방식을 사용하면 충돌이 발생하지 않으며 여러 HAProxy 복사본이 여러 백엔드에서 요청 배포를 조정할 수 있습니다. Pacemaker에서 HAProxy가 실패했음을 감지하면 프론트엔드 IP 주소를 다른 HAProxy 인스턴스에 다시 할당합니다. 그러면 이 HAProxy 인스턴스가 제어 HAProxy 인스턴스가 됩니다.

1.5. 구성 스크립트 사용

페더레이션 인증을 구성하려면 길고 복잡한 명령을 실행해야 합니다. 해당 작업을 쉽게 하고 반복성을 허용하기 위해 명령이 configure-federation 이라는 쉘 스크립트에 저장됩니다. 특정 단계를 실행할 수 있습니다. 단계 이름을 configure-federation 으로 전달하면 됩니다. 가능한 명령 목록을 보려면 help 옵션(-h 또는 --help)을 사용합니다.

참고

스크립트 내용에 대한 자세한 내용은 6장. configure-federation 파일 을 참조하십시오.

변수 대체 후에 실행되는 명령을 보려면 다음 옵션을 사용합니다.

-n
이 옵션은 시스템을 변경하지 않고 해당 작업을 stdout에 쓰는 시험 실행 모드를 제공합니다.
-v
이 옵션은 를 실행하기 전에 해당 작업을 stdout에 쓰는 자세한 정보 표시 모드를 제공합니다. 이는 로깅에 유용합니다.

1.6. 프록시 또는 SSL 종결자 사용

프록시 뒤의 환경에 대해서는 다음 주요 기능을 고려하십시오.

  • 백엔드 서버에는 다른 호스트 이름이 있거나, 다른 포트에서 수신 대기하거나, 클라이언트가 프록시의 프런트에서 표시되는 것과 다른 프로토콜을 사용할 수 있습니다.

    서버가 자체 참조 URL을 생성할 때 문제가 발생할 수 있습니다(예: 서버가 클라이언트를 동일한 서버의 다른 URL로 리디렉션하는 경우). 서버에서 생성하는 URL은 클라이언트에 표시된 대로 공용 주소 및 포트와 일치해야 합니다.

  • HTTP 및 HTTPS와 같은 인증 프로토콜은 특정 서버, 포트 및 보안 전송에 대한 요청이 대상으로 지정되었는지 확인해야 하므로 호스트, 포트 및 프로토콜에 민감합니다. 프록시는 이 정보를 방해할 수 있습니다.

    • 프록시는 백엔드의 비공용 서버로 디스패치하기 전에 공용 프론트엔드에서 수신된 요청을 변환합니다.
    • 비공용 백엔드 서버의 응답은 응답이 프록시의 공용 프런트 엔드에서 온 것처럼 표시되도록 조정이 필요한 경우가 있습니다.

      이 문제를 해결하기 위한 다양한 접근 방법이 있습니다. SAML은 호스트, 포트 및 프로토콜 정보에 민감하고 HAProxy(고가용성 프록시) 뒤에서 SAML을 구성하기 때문에 이러한 문제를 처리해야 합니다. 그렇지 않으면 구성이 실패할 수 있습니다.

2장. Red Hat Identity 관리 구성

다음 기능을 사용하여 연결된 사용자 관리를 사용하여 Red Hat OpenStack Platform을 구성할 수 있습니다.

  • Red Hat IdM(Identity Management)은 Red Hat OpenStack Platform 외부에 있습니다.
  • Red Hat IdM은 모든 사용자 및 그룹 정보의 소스입니다.
  • Red Hat Single Signon (RH-SSO)이 사용자 페더레이션에 Red Hat IdM을 사용하도록 구성되어 있습니다.

2.1. RH-SSO용 IdM 서비스 계정 생성

비공식 바인드를 사용하는 경우 보안상의 이유로 RH-SSO(Red Hat Single Sign-On)에 필수적인 일부 정보가 보장됩니다. 따라서 이 정보를 위해 IdM LDAP 서버를 쿼리할 전용 계정인 forma에서 RH-SSO에 적절한 권한을 제공해야 합니다.

LDAP_URL="ldaps://$FED_IPA_HOST"
DIR_MGR_DN="cn=Directory Manager"
SERVICE_NAME="rhsso"
SERVICE_DN="uid=$service_name,cn=sysaccounts,cn=etc,$FED_IPA_BASE_DN"

$ ldapmodify -H "${LDAP_URL}" -x -D "${DIR_MGR_DN}" -w <_FED_IPA_ADMIN_PASSWD_> <<EOF
dn: ${SERVICE_DN}
changetype: add
objectclass: account
objectclass: simplesecurityobject
uid: ${SERVICE_NAME}
userPassword: <_FED_IPA_RHSSO_SERVICE_PASSWD_>
passwordExpirationTime: 20380119031407Z
nsIdleTimeout: 0
EOF
참고

configure-federation 스크립트를 사용하여 위 단계를 수행할 수 있습니다. $ ./configure-federation create-ipa-service-account

2.2. 테스트 사용자 생성

테스트를 위해 IdM에 사용자 계정을 생성합니다.

절차

  1. IdM에서 사용자 jdoe 를 생성합니다.

    $ipa user-add --first John --last Doe --email jdoe@example.com jdoe
  2. 사용자에게 암호를 할당합니다.

    $ipa passwd jdoe

2.3. OpenStack 사용자를 위한 IdM 그룹 생성

Keystone 그룹 federated _ users에 매핑하려면 IdM 그룹 openstack- users 가 있어야 합니다. 테스트 사용자를 이 그룹에 매핑합니다.

Red Hat IdM(Identity Management)에서 openstack-users 그룹을 생성합니다.

절차

  1. openstack-users 그룹이 없는지 확인합니다.

    $ ipa group-show openstack-users
    ipa: ERROR: openstack-users: group not found
  2. openstack-users 그룹을 IdM에 추가합니다.

    ipa group-add openstack-users
  3. openstack-users 그룹에 테스트 사용자를 추가합니다.

    ipa group-add-member --users jdoe openstack-users
  4. openstack-users 그룹이 있으며 test 사용자가 멤버로 있는지 확인합니다.

    $ ipa group-show openstack-users
      Group name: openstack-users
      GID: 331400001
      Member users: jdoe

3장. Red Hat Single Sign-On 구성

RH-SSO(Red Hat Single Sign-On)는 멀티 테넌시를 지원하며 영역을 사용하여 테넌트를 분리할 수 있습니다. 그 결과 RH-SSO 작업이 영역 컨텍스트 내에서 항상 수행됩니다. RH-SSO 서버에 대한 관리 권한이 있는 경우 수동으로 영역을 생성하거나 keycloak-httpd-client-install 도구를 사용하여 이 영역을 생성할 수 있습니다.

사전 요구 사항

RH-SSO 서버가 설치되어 있어야 합니다. RH-SSO 설치에 대한 자세한 내용은 서버 설치 및 구성 가이드를 참조하십시오.

다음과 같이 다음 변수에 대한 정의가 필요합니다.

<_RH_RHSSO_URL_>

Red Hat Single Sign-On URL

<_FED_RHSSO_REALM_>

사용 중인 RH-SSO 영역을 식별합니다.

3.1. RH-SSO 영역 구성

RH-SSO(Single Sign-On) 영역을 사용할 수 있는 경우 RH-SSO 웹 콘솔을 사용하여 IdM에 대한 사용자 페더레이션 영역을 구성합니다.

절차

  1. 왼쪽 위에 있는 드롭다운 목록에서 RH-SSO 영역을 선택합니다.
  2. Configure (구성) 패널에서 User Federation (사용자 페더레이션)을 선택합니다.
  3. User Federation (사용자 페더레이션) 패널의 Add provider (공급업체 추가) 드롭다운 목록에서 ldap (ldap)를 선택합니다.
  4. 다음 매개 변수에 대한 값을 제공합니다. 모든 사이트별 값을 해당 환경과 관련된 값으로 바꿉니다.

    속성현재의

    콘솔 표시 이름

    Red Hat IDM

    편집 모드

    READ_ONLY

    등록 동기화

    꺼짐

    벤더

    Red Hat Directory Server

    사용자 이름 LDAP 속성

    UID

    RDN LDAP 특성

    UID

    UUID LDAP 속성

    ipaUniqueID

    사용자 객체 클래스

    inetOrgPerson, organizationalPerson

    연결 URL

    LDAPS://<_FED_IPA_HOST_>

    사용자 DN

    cn=users,cn=accounts,<_FED_IPA_BASE_DN_>

    인증 유형

    단순

    DN 바인딩

    uid=rhsso,cn=sysaccounts,cn=etc,<_FED_IPA_BASE_DN_>

    인증 정보 바인딩

    <_FED_IPA_RHSSO_SERVICE_PASSWD_>

  5. Test connection(테스트 연결) 및 Test authentication(테스트 인증) 버튼을 사용하여 사용자 페더레이션이 작동하는지 확인합니다.
  6. Save(저장 )를 클릭하여 새 사용자 페더레이션 공급업체를 저장합니다.
  7. 생성한 Red Hat IdM 사용자 페더레이션 페이지 상단에 있는 Mappers 탭을 클릭합니다.
  8. 매퍼를 만들어 사용자 그룹 정보를 검색합니다. 사용자의 그룹 멤버십은 SAM 어설션을 반환합니다. 나중에 그룹 멤버십을 사용하여 OpenStack에서 권한 부여를 제공합니다.
  9. Mappers(매퍼) 페이지에서 Create(만들기 )를 클릭합니다.
  10. Add user federation Mapper(사용자 페더 매퍼 추가) 페이지의 Mapper Type (매퍼 유형) 드롭다운 목록에서 group-ldap-mapper 를 선택하고 이름을 Group Mapper 로 지정합니다. 다음 매개 변수에 대한 값을 제공합니다. 모든 사이트별 값을 해당 환경과 관련된 값으로 바꿉니다.

    속성현재의

    LDAP Groups DN

    Cn=groups,cn=accounts"<_FED_IPA_BASE_DN_>

    그룹 이름 LDAP 속성

    cn

    그룹 오브젝트 클래스

    groupOfNames

    멤버십 LDAP 속성

    멤버

    멤버십 속성 유형

    DN

    모드

    READ_ONLY

    사용자 그룹, 전략 검색

    GET_GROUPS_FROM_USER_MEMBEROF_ATTRIBUTE

  11. 저장을 클릭합니다.

3.2. SAML 어설션을 사용하여 사용자 속성 추가

SAML(Security Assertion Markup Language)은 IdM(ID 공급자)과 서비스 공급자(SP) 간의 사용자 속성 및 권한 부여 자격 증명의 통신을 허용하는 개방형 표준입니다.

Red Hat Single Sign-On(RH-SSO)을 구성하여 어설션에 필요한 속성을 반환할 수 있습니다. OpenStack ID 서비스에서 SAML 어설션을 수신하면 이러한 속성을 OpenStack 사용자에게 매핑합니다. IdP 특성을 ID 서비스 데이터에 매핑하는 프로세스를 Federated Mapping이라고 합니다. 자세한 내용은 4.20절. “맵핑 파일 만들기 및 Keystone에 업로드”의 내용을 참조하십시오.

다음 프로세스를 사용하여 SAML에 속성을 추가합니다.

절차

  1. RH-SSO 관리 웹 콘솔의 왼쪽 상단에 있는 드롭다운 목록에서 <_FED_RHSSO_REALM_>을 선택합니다.
  2. Configure (구성) 패널에서 Clients (클라이언트)를 선택합니다.
  3. keycloak-httpd-client-install이 구성된 서비스 프로바이더 클라이언트를 선택합니다. SAML EntityId 를 사용하여 클라이언트를 식별할 수 있습니다.
  4. 탭의 수평 목록에서 매퍼 탭을 선택합니다.
  5. Mappers 패널에서 Create 또는 Add builtin 을 선택하여 프로토콜 매퍼를 클라이언트에 추가합니다.

추가 특성을 추가할 수 있지만 사용자가 멤버인 그룹 목록만 있으면 됩니다. 그룹 멤버십은 사용자를 인증하는 방법입니다.

3.3. SAML 어설션에 그룹 정보 추가

절차

  1. Mappers 패널에서 Create 단추를 클릭합니다.
  2. Create Protocol Mapper 패널의 Mapper tpe 드롭다운 목록에서 Group 목록을 선택합니다.
  3. Name(이름) 필드에 Group List를 이름으로 입력합니다.
  4. Group 특성 Name(그룹 특성 이름) 필드에 SAML 속성의 이름으로 groups를 입력합니다.

    참고

    SAML 어설션에 나타나는 특성의 이름입니다. keystone 매퍼가 매핑 선언의 Remote (원격) 섹션에서 이름을 검색하면 SAML 특성 이름을 검색합니다. 어설션에 전달할 RH-SSO에 속성을 추가할 때 SAML 특성 이름을 지정합니다. RH-SSO 프로토콜 매퍼에서 이름을 정의합니다.

  5. SAML Attribute NameFormat 매개변수에서 Basic 을 선택합니다.
  6. Single Group Attribute toggle(단일 그룹 속성 토글) 상자에서 On 을 선택합니다.
  7. 저장을 클릭합니다.
참고

keycloak-httpd-client-install 도구를 실행하면 프로세스에서 그룹 매퍼를 추가합니다.

4장. 페더레이션용 Red Hat OpenStack Platform 구성

다음 노드에는 FQDN(Fully-Qualified Domain Name)이 할당되어야 합니다.

  • 대시보드를 실행하는 호스트(horizon).
  • ID 서비스(keystone)를 실행하는 호스트로, 이 가이드에서 $FED_KEYSTONE_HOST 로 참조합니다. 둘 이상의 호스트가 고가용성 환경에서 서비스를 실행하므로 IP 주소는 호스트 주소가 아니라 서비스에 바인딩된 IP 주소입니다.
  • RH-SSO를 실행하는 호스트.
  • IdM을 실행하는 호스트입니다.

Red Hat OpenStack Platform director 배포는 DNS를 구성하거나 노드에 FQDN을 할당하지 않지만 인증 프로토콜(및 TLS)은 FQDN을 사용해야 합니다.

4.1. IP 주소 검색

Red Hat OpenStack Platform에는 포트 번호로 구분된 모든 OpenStack 서비스에 대해 하나의 일반적인 공용 IP 주소가 있습니다. 오버클라우드 서비스의 공용 IP 주소를 확인하려면 openstack endpoint list 명령을 사용합니다.

(overcloud) [stack@director ~]$ openstack endpoint list -c "Service Name" -c Interface -c URL | grep public

| swift        | public    | http://10.0.0.101:8080/v1/AUTH_%(tenant_id)s |
| panko        | public    | http://10.0.0.101:8977                       |
| nova         | public    | http://10.0.0.101:8774/v2.1                  |
| glance       | public    | http://10.0.0.101:9292                       |
| neutron      | public    | http://10.0.0.101:9696                       |
| keystone     | public    | http://10.0.0.101:5000                       |
| cinderv2     | public    | http://10.0.0.101:8776/v2/%(tenant_id)s      |
| placement    | public    | http://10.0.0.101:8778/placement             |
| cinderv3     | public    | http://10.0.0.101:8776/v3/%(tenant_id)s      |
| heat         | public    | http://10.0.0.101:8004/v1/%(tenant_id)s      |
| heat-cfn     | public    | http://10.0.0.101:8000/v1                    |
| gnocchi      | public    | http://10.0.0.101:8041                       |
| aodh         | public    | http://10.0.0.101:8042                       |
| cinderv3     | public    | http://10.0.0.101:8776/v3/%(tenant_id)s      |

4.2. 호스트 변수 설정 및 호스트 이름 지정

사용할 IP 주소와 포트를 결정해야 합니다. 이 예에서 IP 주소는 10.0.0.101이고 포트는 13000입니다.

  1. overcloudrc에서 이 값을 확인합니다.

    export OS_AUTH_URL=https://10.0.0.101:13000/v2.0
  2. IP 주소에 FQDN(정규화된 도메인 이름)을 할당하고 /etc/hosts 파일에 기록합니다. 이 예에서는 overcloud.localdomain을 사용합니다.

    10.0.0.101 overcloud.localdomain # FQDN of the external VIP
    참고

    Red Hat OpenStack Platform director는 오버클라우드 노드에 호스트 파일을 설정하지만 참여하는 모든 외부 호스트에 host 항목을 추가해야 할 수 있습니다.

  3. fed_variables 파일에서 $FED_KEYSTONE_HOST 및 $FED_KEYSTONE_HTTPS_PORT를 설정합니다. 이 예제에서는 동일한 값을 사용합니다.

    FED_KEYSTONE_HOST="overcloud.localdomain"
    FED_KEYSTONE_HTTPS_PORT=13000

Mellon는 ID 서비스(keystone)를 호스팅하는 Apache 서버에서 실행되므로 Mellon host:port 및 keystone host:port 값이 일치해야 합니다.

참고

컨트롤러 노드 중 하나에서 hostname 명령을 실행하는 경우 은 controller-0.localdomain 과 유사합니다. 이는 공용 이름이 아닌 내부 클러스터 이름입니다. 대신 공용 IP 주소를 사용합니다.

4.3. 도우미 파일 설치

구성의 일부로 도우미 파일을 설치해야 합니다.

4.4. 배포 변수 설정

fed_variables 파일에는 페더레이션 배포와 관련된 변수가 포함되어 있습니다. 이러한 변수는 이 가이드와 configure-federation 도우미 스크립트에서 참조됩니다. 각 사이트별 페더레이션 변수 앞에는 FED_ 가 있습니다. fed _variables의 모든 FED _ 변수에 값이 제공되었는지 확인합니다.

4.5. 도우미 파일 복사

계속하려면 controller-0에 구성 파일과 변수 파일이 있어야 합니다.

  • configure-federation 및 edit fed_variables를 undercloud-0의 ~/stack 홈 디렉터리에서 controller-0 ~/heat-admin 홈 디렉터리에 복사합니다.
$ scp configure-federation fed_variables heat-admin@controller-0:/home/heat-admin
참고

configure-federation 스크립트를 사용하여 위 단계를 수행할 수 있습니다. $ ./configure-federation copy-helper-to-controller

4.6. 작업 환경 초기화

  1. Undercloud 노드에서 stack 사용자로 fed_deployment 디렉터리를 만듭니다. 이 위치는 파일 stash입니다.

    $ su - stack
    $ mkdir fed_deployment
    참고

    configure-federation 스크립트를 사용하여 이전 단계를 수행할 수 있습니다.

    $ ./configure-federation initialize
  2. SSH를 사용하여 controller-0 에 연결하고 head-admin 사용자로 ~/fed_deployment 디렉터리를 만듭니다. 이 위치는 파일 stash입니다.

    $ ssh heat-admin@controller-0
    $ mkdir fed_deployment
    참고

    configure-federation 스크립트를 사용하여 이전 단계를 수행할 수 있습니다. controller-0 노드에서 다음을 수행합니다.

    $ ./configure-federation initialize

4.7. mod_auth_mellon 설치

사용자 환경의 각 컨트롤러에 mod_auth_mellon 을 설치해야 합니다.

  • 각 컨트롤러에서 다음을 실행합니다.

    $ ssh heat-admin@controller-n # replace n with controller number
    $ sudo dnf install mod_auth_mellon

4.8. 각 컨트롤러에 RH-SSO FQDN 추가

모든 컨트롤러가 FQDN(정규화된 도메인 이름)으로 연결할 수 있는지 확인합니다.

  • mellon 서비스는 각 컨트롤러 노드에서 실행되며 RH-SSO IdP에 연결합니다. DNS를 통해 RH-SSO IdP의 FQDN을 확인할 수 없는 경우 Heat 호스트 섹션 뒤의 모든 컨트롤러 노드의 /etc/hosts 파일에 FQDN을 수동으로 추가합니다.

    $ ssh heat-admin@controller-n
    $ sudo vi /etc/hosts
    
    # Add this line (substituting the variables) before this line:
    # HEAT_HOSTS_START - Do not edit manually within this section!
    ...
    # HEAT_HOSTS_END
    $FED_RHSSO_IP_ADDR $FED_RHSSO_FQDN

4.9. 컨트롤러 노드에 Mellon 설치 및 구성

keycloak-httpd-client-install 툴은 mod_auth_mellon 을 구성하는 데 필요한 여러 단계를 수행하고 RH-SSO IdP에 대해 인증합니다. mellon이 실행되는 노드에서 keycloak-httpd-client-install 툴을 실행합니다. 이 예제에서 mellon은 ID 서비스(keystone)를 보호하는 Overcloud 컨트롤러에서 실행됩니다.

참고

Red Hat OpenStack Platform은 동일한 복사본을 실행하는 여러 오버클라우드 컨트롤러 노드가 있는 고가용성 배포입니다. 결과적으로 각 컨트롤러 노드에서 mellon 구성을 복제해야 합니다. 이렇게 하려면 controller-0에 mellon을 설치 및 구성하고 keycloak-httpd-client-install 툴이 tar 파일에 생성된 구성 파일을 수집합니다. Object Storage(swift)를 사용하여 아카이브를 각 컨트롤러에 복사하고 해당 파일의 보관을 취소합니다.

  • RH-SSO 클라이언트 설치를 실행합니다.

      $ ssh heat-admin@controller-0
      $ dnf -y install keycloak-httpd-client-install
      $ sudo keycloak-httpd-client-install \
       --client-originate-method registration \
       --mellon-https-port $FED_KEYSTONE_HTTPS_PORT \
       --mellon-hostname $FED_KEYSTONE_HOST  \
       --mellon-root /v3 \
       --keycloak-server-url $FED_RHSSO_URL  \
       --keycloak-admin-password  $FED_RHSSO_ADMIN_PASSWORD \
       --app-name v3 \
       --keycloak-realm $FED_RHSSO_REALM \
       -l "/v3/auth/OS-FEDERATION/websso/mapped" \
       -l "/v3/auth/OS-FEDERATION/identity_providers/rhsso/protocols/mapped/websso" \
       -l "/v3/OS-FEDERATION/identity_providers/rhsso/protocols/mapped/auth
    참고

    configure-federation 스크립트를 사용하여 위 단계를 수행할 수 있습니다. $ ./configure-federation client-install

클라이언트 RPM 설치 후 다음과 유사한 출력이 표시됩니다.

  [Step  1] Connect to Keycloak Server
  [Step  2] Create Directories
  [Step  3] Set up template environment
  [Step  4] Set up Service Provider X509 Certificates
  [Step  5] Build Mellon httpd config file
  [Step  6] Build Mellon SP metadata file
  [Step  7] Query realms from Keycloak server
  [Step  8] Create realm on Keycloak server
  [Step  9] Query realm clients from Keycloak server
  [Step 10] Get new initial access token
  [Step 11] Creating new client using registration service
  [Step 12] Enable saml.force.post.binding
  [Step 13] Add group attribute mapper to client
  [Step 14] Add Redirect URIs to client
  [Step 15] Retrieve IdP metadata from Keycloak server
  [Step 16] Completed Successfully

4.10. Mellon 구성 편집

IdP-assertion-to-Keystone 매핑 단계에서 그룹은 세미콜론으로 구분된 목록에 있어야 합니다. 다음 절차에 따라 속성에 대해 여러 값을 수신하면 세미콜론으로 구분된 단일 값으로 결합되도록 mellon을 구성합니다.

절차

  1. 편집할 v3_mellon_keycloak_openstack.conf 구성 파일을 엽니다.
$ vi /var/lib/config-data/puppet-generated/keystone/etc/httpd/conf.d/v3_mellon_keycloak_openstack.conf
  1. MellonMergeEnvVars 매개변수를 <Location /v3> 블록에 추가합니다.

      <Location /v3>
          ...
          MellonMergeEnvVars On ";"
      </Location>

4.11. 생성된 구성 파일의 아카이브 생성

모든 컨트롤러 노드에서 mellon 구성을 복제하려면 각 컨트롤러 노드에 설치할 파일의 아카이브를 생성합니다. 아카이브를 ~/fed_deployment 하위 디렉터리에 저장합니다.

  1. 압축된 아카이브를 생성합니다.

    mkdir fed_deployment && cd fed_deployment
    tar -czvf rhsso_config.tar.gz \
      --exclude '*.orig' \
      --exclude '*~' \
      /var/lib/config-data/puppet-generated/keystone/etc/httpd/saml2 \
      /var/lib/config-data/puppet-generated/keystone/etc/httpd/conf.d/v3_mellon_keycloak_openstack.conf
참고

configure-federation 스크립트를 사용하여 이전 단계를 수행할 수 있습니다.

$ ./configure-federation create-sp-archive

4.12. Mellon 구성 아카이브 검색

  • undercloud-0 노드에서 생성한 아카이브를 검색하고 후속 단계에서 필요에 따라 데이터에 액세스할 수 있도록 파일을 추출합니다.

    $ scp heat-admin@controller-0:/home/heat-admin/fed_deployment/rhsso_config.tar.gz ~/fed_deployment
    $ tar -C fed_deployment -xvf fed_deployment/rhsso_config.tar.gz
참고

configure-federation 스크립트를 사용하여 위 단계를 수행할 수 있습니다. $ ./configure-federation fetch-sp-archive

4.13. Puppet에서 관리되지 않는 HTTPD 파일을 삭제하지 못하도록 방지

기본적으로 Puppet Apache 모듈은 관리하지 않는 Apache 구성 디렉터리에 있는 파일을 삭제합니다. 이렇게 하면 Apache가 Puppet에서 적용하는 구성에 대해 작동하지 않습니다. 그러나 HTTPD 구성 디렉터리에서 mellon의 수동 구성과 충돌합니다. Apache Puppet apache::purge_configs 플래그는 기본적으로 활성화되어 있어 Puppet에서 mod_auth_mellon RPM에 속한 파일을 삭제하도록 지시합니다. Puppet은 keycloak-httpd-client-install 이 생성하는 구성 파일도 삭제합니다. Puppet이 mellon 파일을 제어할 때까지 apache::purge_configs 플래그를 비활성화합니다.

참고

apache::purge_configs 플래그를 비활성화하면 컨트롤러 노드가 취약점에 대해 열립니다. Puppet에서 mellon 관리 지원이 추가되면 다시 활성화합니다.

apache::purge_configs 플래그를 재정의하려면 덮어쓰기가 포함된 Puppet 파일을 생성하고 overcloud_deploy.sh 스크립트를 실행할 때 사용하는 Puppet 파일 목록에 재정의 파일을 추가합니다.

  1. fed_deployment/puppet_override_apache.yaml 환경 파일을 생성하고 다음 내용을 추가합니다.

      parameter_defaults:
        ControllerExtraConfig:
          apache::purge_configs: false
  2. overcloud _deploy.sh 스크립트의 마지막 환경 파일로 puppet_override_apache.yaml 을 추가합니다.

    ...
      -e /home/stack/fed_deployment/puppet_override_apache.yaml \
      --log-file overcloud_deployment_14.log &> overcloud_install.log
참고

configure-federation 스크립트를 사용하여 위 단계를 수행할 수 있습니다. $ ./configure-federation puppet-override-apache

4.14. 통합을 위한 ID 서비스(keystone) 구성

Keystone 도메인에는 추가 구성이 필요합니다. 그러나 keystone Puppet 모듈이 활성화된 경우 이 추가 구성 단계를 수행할 수 있습니다.

  • Puppet YAML 파일에서 다음을 추가합니다.

    keystone::using_domain_config: true

/etc/keystone/keystone.conf 에서 다음 값을 설정하여 페더레이션을 활성화합니다.

auth:methods
허용된 인증 방법 목록입니다. 기본적으로 목록은 ['external', 'password', 'token', 'oauth1'] 입니다. 매핑된 방법을 사용하여 SAML을 활성화해야 합니다. 또한 외부 방법은 제외해야 합니다. password,token,oauth1,mapped 로 값을 설정합니다.
federation:trusted_dashboard
신뢰할 수 있는 대시보드 호스트 목록. 토큰을 반환하기 위해 Single Sign-On 요청을 수락하기 전에 원본 호스트가 이 목록의 멤버여야 합니다. 다른 값에 대해 이 구성 옵션을 여러 번 사용할 수 있습니다. 웹 기반 SSO 흐름을 사용하려면 이 값을 설정해야 합니다. 이 배포의 경우 값은 https://$FED_KEYSTONE_HOST/dashboard/auth/websso/ Red Hat OpenStack Platform director가 동일한 호스트에 keystone과 horizon을 모두 공동 배치하므로 $FED_KEYSTONE_HOST입니다. Horizon이 다른 호스트에서 keystone으로 실행되는 경우 그에 따라 조정해야 합니다.
federation:sso_callback_template
Single Sign-On 콜백 핸들러로 사용되는 HTML 파일의 절대 경로 이 페이지는 POST 요청에 토큰을 인코딩하여 ID 서비스에서 사용자를 신뢰할 수 있는 대시보드 호스트로 다시 리디렉션합니다. 기본값은 대부분의 배포에 충분합니다.
federation:remote_id_attribute

ID 프로바이더의 엔터티 ID를 가져오는 데 사용되는 값입니다. mod_auth_mellon 의 경우 Mellon_IDP 를 사용합니다. Mellon IDP 지시문을 사용하여 mellon 구성 파일에서 이 값을 설정합니다.

  • 다음 내용으로 fed_deployment/puppet_override_keystone.yaml 파일을 생성합니다.

    parameter_defaults:
      controllerExtraConfig:
        keystone::using_domain_config: true
        keystone::config::keystone_config:
          identity/domain_configurations_from_database:
            value: true
          auth/methods:
            value: external,password,token,oauth1,mapped
          federation/trusted_dashboard:
            value: https://$FED_KEYSTONE_HOST/dashboard/auth/websso/
          federation/sso_callback_template:
            value: /etc/keystone/sso_callback_template.html
          federation/remote_id_attribute:
            value: MELLON_IDP
  • overcloud_deploy.sh 스크립트 끝에 생성된 환경 파일을 추가합니다.

    ...
    -e /home/stack/fed_deployment/puppet_override_keystone.yaml \
    --log-file overcloud_deployment_14.log &> overcloud_install.log
참고

configure-federation 스크립트를 사용하여 위 단계를 수행할 수 있습니다. $ ./configure-federation puppet-override-keystone

4.15. Mellon 구성 아카이브 배포

  • Object Storage(swift) 아티팩트를 사용하여 각 컨트롤러 노드에 mellon 구성 파일을 설치합니다.

    $ source ~/stackrc
    $ upload-swift-artifacts -f fed_deployment/rhsso_config.tar.gz
참고

configure-federation 스크립트를 사용하여 위 단계를 수행할 수 있습니다. './configure-federation deploy-mellon-configuration'

4.16. 오버클라우드 재배포

  • Puppet YAML 구성 파일 및 오브젝트 스토리지 아티팩트의 변경 사항을 적용하려면 deploy 명령을 실행합니다.

    ./overcloud_deploy.sh

중요: Puppet을 다시 실행하여 컨트롤러 노드를 추가로 변경하면 overcloud_deploy.sh 스크립트가 이전 구성을 덮어쓸 수 있습니다. 오버클라우드 컨트롤러 노드의 구성 파일에 수행한 수동 편집 사항이 손실되지 않도록 이 절차 후에는 Puppet 구성을 적용하지 마십시오.

4.17. 각 컨트롤러에서 ID 서비스(keystone)에 프록시 지속성 사용

mod_auth_mellon 이 세션을 설정할 때 여러 서버에서 상태 정보를 공유할 수 없습니다. SAML에서 사용하는 리디렉션 수가 많은 경우 상태 정보가 필요하므로 동일한 서버에서 모든 트랜잭션을 처리해야 합니다. 따라서 각 클라이언트의 요청을 매번 동일한 서버로 전송하도록 HAProxy를 구성해야 합니다.

HAProxy에서 클라이언트를 동일한 서버에 바인딩하는 방법은 두 가지가 있습니다.

유사성
애플리케이션 계층 아래의 정보를 사용하여 클라이언트 요청을 단일 서버에 고정할 때 선호도를 사용합니다.
지속성
애플리케이션 계층 정보가 단일 서버 고정 세션에 클라이언트를 바인딩할 때 지속성을 사용합니다. 지속성은 선호도보다 훨씬 더 정확합니다. 다음 절차를 사용하여 지속성을 구현합니다.

HAProxy 쿠키 지시문은 쿠키 및 지속성을 위해 매개 변수의 이름을 지정합니다. HAProxy 서버 지시문에는 쿠키 값을 서버 이름으로 설정하는 쿠키 옵션이 있습니다. 들어오는 요청에 백엔드 서버를 식별하는 쿠키가 없으면 HAProxy는 구성된 분산 알고리즘을 기반으로 서버를 선택합니다.

절차

  1. /var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg 구성 파일의 keystone_public 블록에서 지속성을 활성화하려면 다음 행을 추가합니다.

    cookie SERVERID insert indirect nocache

    이 설정은 SERVERID 가 지속성 쿠키의 이름입니다.

  2. 서버 행을 편집하고 추가 옵션으로 cookie <server-name> 을 추가합니다.

    server controller-0 cookie controller-0
    server controller-1 cookie controller-1

4.18. 연결된 리소스 생성

IdM(ID 프로바이더)에서 사용할 ID 서비스(keystone) 대상, 사용자 및 그룹을 만듭니다.

절차

  1. stack 사용자로 언더클라우드에서 overcloudrc 파일을 가져오고 다음 명령을 실행합니다.

    $ openstack domain create federated_domain
    $ openstack project create  --domain federated_domain federated_project
    $ openstack group create federated_users --domain federated_domain
    $ openstack role add --group federated_users --group-domain federated_domain --domain federated_domain _member_
    $ openstack role add --group federated_users --group-domain federated_domain --project federated_project _member_
참고

configure-federation 스크립트를 사용하여 위 단계를 수행할 수 있습니다. $ ./configure-federation create-federated-resources

4.19. Red Hat OpenStack Platform에서 ID 공급자 생성

IdP는 ID 서비스(keystone)에 등록해야 합니다. 그러면 ID 서비스에서 SAML 어설션의 entityID 와 IdP의 이름이 바인딩됩니다.

절차

  1. IdP 메타데이터 에 있는 RH-SSO IdP의 엔터티 ID를 찾습니다. IdP 메타데이터는 /var/lib/config-data/puppet-generated/keystone/etc/httpd/sacd2/v3_keycloak_$FED_RHSSO_REALM_idp_metadata.xml 파일에 저장됩니다. fed_deployment/var/lib/config-data/puppet-generated/keystone/etc/httpd/sa ml2/v3_keycloak_$FED_RHSSO_REALM_idp_metadata.xml 파일에서 IdP 메타데이터를 찾을 수도 있습니다.
  2. <EntityDescriptor> 요소 내의 IdP 메타데이터 파일에 있는 entityID 속성의 값을 확인합니다. $FED_IDP_ENTITY_ID 변수를 이 값을 할당합니다.
  3. 변수 $FED_OPENSTACK_IDP_NAME 에 할당된 IdP rhsso 의 이름을 지정합니다.

    $ openstack identity provider create --remote-id $FED_IDP_ENTITY_ID $FED_OPENSTACK_IDP_NAME
참고

configure-federation 스크립트를 사용하여 위 단계를 수행할 수 있습니다. $ ./configure-federation openstack-create-idp

4.20. 맵핑 파일 만들기 및 Keystone에 업로드

Keystone은 keystone에서 이해할 수 있는 형식에 대한 IdP의 SAML 어설션과 일치하도록 매핑을 수행합니다. 매핑은 keystone의 매핑 엔진에서 수행하며 IdP에 바인딩된 매핑 규칙 집합을 기반으로 합니다.

  1. 이러한 규칙은 이 예에서 사용되는 매핑 규칙입니다(소개에 설명된 대로).

    [
        {
            "local": [
                {
                    "user": {
                        "name": "{0}"
                    },
                    "group": {
                        "domain": {
                            "name": "federated_domain"
                        },
                        "name": "federated_users"
                    }
                }
            ],
            "remote": [
                {
                    "type": "MELLON_NAME_ID"
                },
                {
                    "type": "MELLON_groups",
                    "any_one_of": ["openstack-users"]
                }
            ]
        }
    ]

이 매핑 파일에는 하나의 규칙만 포함되어 있습니다. 규칙은 로컬원격 의 두 부분으로 나뉩니다. 매핑 엔진은 일치할 때까지 규칙 목록을 반복한 다음 실행하여 작동합니다. 규칙은 규칙의 원격 부분에 있는 모든 조건이 일치하는 경우에만 일치하는 것으로 간주됩니다. 이 예제에서는 원격 조건을 지정합니다.

  1. 어설션에는 MELLON_NAME_ID 라는 값이 포함되어야 합니다.
  2. 어설션에는 MELLON_groups 라는 값이 포함되어야 하며 그룹 목록의 그룹 중 하나가 openstack-users 여야 합니다.

규칙이 일치하면 다음을 수행합니다.

  1. keystone 사용자 이름에 MELLON_NAME_ID 의 값이 할당됩니다.
  2. 사용자는 federated_ domain 도메인의 keystone 그룹 federated_users 에 할당됩니다.

요약하면, IdP가 사용자를 성공적으로 인증하고 IdP가 사용자가 openstack-users 그룹에 속해 있다고 주장하는 경우 keystone은 해당 사용자가 keystone의 federated _users 그룹에 바인딩된 권한을 사용하여 OpenStack에 액세스할 수 있도록 합니다.

4.20.1. 매핑 만들기

  1. keystone에서 매핑을 만들려면 매핑 규칙이 포함된 파일을 만든 다음 keystone에 업로드하여 참조 이름을 지정합니다. fed_deployment 디렉터리(예: fed_deployment /mapping_${FED_OPENSTACK_IDP_NAME}_saml2.json)에 매핑 파일을 만들고 이름 $FED_OPENSTACK_MAPPING_NAME 을 매핑 규칙에 할당합니다. 예를 들면 다음과 같습니다.

    $ openstack mapping create --rules fed_deployment/mapping_rhsso_saml2.json $FED_OPENSTACK_MAPPING_NAME
참고

configure-federation 스크립트를 사용하여 다음 두 단계로 위의 절차를 수행할 수 있습니다.

$ ./configure-federation create-mapping
$ ./configure-federation openstack-create-mapping
  • create-mapping - 매핑 파일을 만듭니다.
  • openstack-create-mapping - 파일 업로드를 수행합니다.

4.21. Keystone 페더레이션 프로토콜 만들기

  1. Keystone에서는 Mapped 프로토콜을 사용하여 IdP를 매핑에 바인딩합니다. 이 바인딩을 설정하려면 다음을 수행합니다.

    $ openstack federation protocol create \
    --identity-provider $FED_OPENSTACK_IDP_NAME \
    --mapping $FED_OPENSTACK_MAPPING_NAME \
    mapped"
참고

configure-federation 스크립트를 사용하여 위 단계를 수행할 수 있습니다. $ ./configure-federation openstack-create-protocol

4.22. Keystone 설정 완전히 검증

  1. 각 컨트롤러 노드에서 /var/lib/config-data/puppet-generated/keystone/etc/httpd/conf.d/10-keystone_wsgi_main.conf 를 편집하여 VirtualHost 블록 내의 ServerName 지시문에 HTTPS 체계, 공용 호스트 이름 및 공용 포트가 포함되어 있는지 확인합니다. UseCanonicalName 지시문도 활성화해야 합니다. 예를 들면 다음과 같습니다.

    <VirtualHost>
      ServerName https:$FED_KEYSTONE_HOST:$FED_KEYSTONE_HTTPS_PORT
      UseCanonicalName On
      ...
    </VirtualHost>
참고

$FED_ 변수를 배포에 고유한 값으로 바꿔야 합니다.

4.23. 페더레이션을 사용하도록 Horizon 설정

  1. 각 컨트롤러 노드에서 /var/lib/config-data/puppet-generated/horizon/etc/openstack-dashboard/local_settings 를 편집하고 다음 구성 값이 설정되었는지 확인합니다.

    OPENSTACK_KEYSTONE_URL = "https://$FED_KEYSTONE_HOST:$FED_KEYSTONE_HTTPS_PORT/v3"
    OPENSTACK_KEYSTONE_DEFAULT_ROLE = "_member_"
    WEBSSO_ENABLED = True
    WEBSSO_INITIAL_CHOICE = "mapped"
    WEBSSO_CHOICES = (
        ("mapped", _("RH-SSO")),
        ("credentials", _("Keystone Credentials")),
    )
참고

$FED_ 변수를 배포에 고유한 값으로 바꿔야 합니다.

4.24. X-Forwarded-Proto HTTP 헤더를 사용하도록 Horizon 구성

  1. 각 컨트롤러 노드에서 /var/lib/config-data/puppet-generated/horizon/etc/openstack-dashboard/local_settings 를 편집하고 행의 주석 처리를 해제합니다.

    #SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
참고

구성 변경 사항을 적용하려면 컨테이너를 다시 시작해야 합니다.

5장. 문제 해결

5.1. Keystone 매핑 규칙 테스트

매핑 규칙이 예상대로 작동하는지 확인하는 것이 좋습니다. keystone-manage 명령줄 도구를 사용하면 파일에서 읽은 어설션 데이터에 대해 일련의 매핑 규칙(파일에서 읽기)을 연습할 수 있습니다. 예를 들면 다음과 같습니다.

  1. mapping_rules.json 파일에는 다음 내용이 있습니다.

    [
        {
            "local": [
                {
                    "user": {
                        "name": "{0}"
                    },
                    "group": {
                        "domain": {
                            "name": "Default"
                        },
                        "name": "federated_users"
                    }
                }
            ],
            "remote": [
                {
                    "type": "MELLON_NAME_ID"
                },
                {
                    "type": "MELLON_groups",
                    "any_one_of": ["openstack-users"]
                }
            ]
        }
    ]
  2. assertion_data.txt 파일에는 다음과 같은 내용이 있습니다.

    MELLON_NAME_ID: 'G-90eb44bc-06dc-4a90-aa6e-fb2aa5d5b0de
    MELLON_groups: openstack-users;ipausers
  3. 다음 명령을 실행하면 다음을 실행합니다.

    $ keystone-manage mapping_engine --rules mapping_rules.json --input assertion_data.txt
  4. 매핑된 결과가 표시됩니다.

    {
      "group_ids": [],
      "user": {
        "domain": {
          "id": "Federated"
        },
        "type": "ephemeral",
        "name": "'G-90eb44bc-06dc-4a90-aa6e-fb2aa5d5b0de"
      },
      "group_names": [
        {
          "domain": {
            "name": "Default"
          },
          "name": "federated_users"
        }
      ]
    }
참고

매핑 규칙이 평가되는 방법을 설명하는 진단 정보를 출력하는 --engine-debug 명령줄 인수를 포함할 수도 있습니다.

5.2. Keystone에서 받은 실제 승인 값 결정

keystone에서 사용할 매핑된 어설션 값은 CGI 환경 변수로 전달됩니다. 이러한 환경 변수의 덤프를 검색하려면 다음을 수행합니다.

  1. 다음 콘텐츠를 사용하여 /var/www/cgi-bin/keystone/test 에 다음 테스트 스크립트를 만듭니다.

    import pprint
    import webob
    import webob.dec
    
    
    @webob.dec.wsgify
    def application(req):
        return webob.Response(pprint.pformat(req.environ),
                              content_type='application/json')
  2. WSGIScriptAlias 지시문을 일시적으로 수정하여 테스트 스크립트를 실행하도록 /var/lib/config-data/puppet-generated/keystone/etc/httpd/conf.d/10-keystone_wsgi_main.conf 파일을 편집합니다.

    WSGIScriptAlias "/v3/auth/OS-FEDERATION/websso/mapped" "/var/www/cgi-bin/keystone/test"
  3. 컨테이너를 다시 시작하십시오.

    podman restart keystone
  4. 로그인을 시도하고 스크립트가 덤프되는 정보를 검토합니다. 완료되면 WSGIScriptAlias 지시문을 복원하고 HTTPD 서비스를 다시 시작합니다.

5.3. SP와 IdP 간에 교환된 SAML 메시지 검토

SAMLTracer Firefox 애드온은 SP와 IdP 간에 교환된 SAML 메시지를 캡처하고 표시하는 데 유용한 도구입니다.

  1. 이 URL에서 SAMLTracer 설치: https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/
  2. Firefox 메뉴에서 SAMLTracer 를 활성화합니다. 모든 브라우저 요청이 표시되는 SAMLTracer 팝업 창이 나타납니다. 요청이 SAML 메시지로 탐지되면 특수 SAML 아이콘이 요청에 추가됩니다.
  3. Firefox 브라우저에서 SSO 로그인을 시작합니다.
  4. SAMLTracer 창에서 첫 번째 SAML 메시지를 찾아 클릭합니다. 창에서 SAML 탭을 사용하여 디코딩된 SAML 메시지를 확인합니다(참고, 도구는 메시지 본문에서 암호화된 콘텐츠를 암호 해독할 수 없습니다. 암호화된 콘텐츠를 확인해야 하는 경우 메타데이터에서 암호화를 비활성화해야 합니다). 첫 번째 SAML 메시지는 SP에서 IdP로 보낸 AuthnRequest 여야 합니다. 두 번째 SAML 메시지는 IdP에서 보낸 어설션 응답이어야 합니다. SAML HTTP-Redirect 프로필이 사용 중이므로 Assertion 응답은 POST로 래핑됩니다. SAML 탭을 클릭하여 어설션의 내용을 확인합니다.

6장. configure-federation 파일

#!/bin/sh


prog_name=`basename $0`
action=
dry_run=0
verbose=0

base_dir=$(pwd)
stage_dir="${base_dir}/fed_deployment"

mellon_root="/v3"
mellon_endpoint="mellon"
mellon_app_name="v3"

overcloud_deploy_script="overcloud_deploy.sh"
overcloudrc_file="./overcloudrc"

function cmd_template {
    local status=0
    local cmd="$1"
    if [ $verbose -ne 0 -o $dry_run -ne 0 ]; then
        echo $cmd
    fi
    if [ $dry_run -ne 0 ]; then
        return $status
    fi

    $cmd
    status=$?
    if [ $status -ne 0 ]; then
        (>&2 echo -e "ERROR cmd \"$cmd\" failed\nstatus = $status")
    fi
    return $status
}

function cmds_template {
    local return_status=0
    declare -a cmds=(
        "date"
        "ls xxx"
        "head $0"
    )

    if [ $dry_run -ne 0 ]; then
        for cmd in "${cmds[@]}"; do
            echo $cmd
        done
    else
        for cmd in "${cmds[@]}"; do
            if [ $verbose -ne 0 ]; then
                echo $cmd
            fi
            $cmd
            status=$?
            if [ $status -ne 0 ]; then
                (>&2 echo -e "ERROR cmd \"$cmd\" failed\nstatus = $status")
                return_status=$status
            fi
        done
    fi
    return $return_status
}

function show_variables {
    echo "base_dir: $base_dir"
    echo "stage_dir: $stage_dir"
    echo "config_tar_filename: $config_tar_filename"
    echo "config_tar_pathname: $config_tar_pathname"
    echo "overcloud_deploy_script: $overcloud_deploy_script"
    echo "overcloudrc_file: $overcloudrc_file"

    echo "puppet_override_apache_pathname: $puppet_override_apache_pathname"
    echo "puppet_override_keystone_pathname: $puppet_override_keystone_pathname"

    echo

    echo "FED_RHSSO_URL: $FED_RHSSO_URL"
    echo "FED_RHSSO_ADMIN_PASSWORD: $FED_RHSSO_ADMIN_PASSWORD"
    echo "FED_RHSSO_REALM: $FED_RHSSO_REALM"

    echo

    echo "FED_KEYSTONE_HOST: $FED_KEYSTONE_HOST"
    echo "FED_KEYSTONE_HTTPS_PORT: $FED_KEYSTONE_HTTPS_PORT"
    echo "mellon_http_url: $mellon_http_url"
    echo "mellon_root: $mellon_root"
    echo "mellon_endpoint: $mellon_endpoint"
    echo "mellon_app_name: $mellon_app_name"
    echo "mellon_endpoint_path: $mellon_endpoint_path"
    echo "mellon_entity_id: $mellon_entity_id"

    echo

    echo "FED_OPENSTACK_IDP_NAME: $FED_OPENSTACK_IDP_NAME"
    echo "openstack_mapping_pathname: $openstack_mapping_pathname"
    echo "FED_OPENSTACK_MAPPING_NAME: $FED_OPENSTACK_MAPPING_NAME"

    echo

    echo "idp_metadata_filename: $idp_metadata_filename"
    echo "mellon_httpd_config_filename: $mellon_httpd_config_filename"
}

function initialize {
    local return_status=0
    declare -a cmds=(
        "mkdir -p $stage_dir"
    )

    if [ $dry_run -ne 0 ]; then
        for cmd in "${cmds[@]}"; do
            echo $cmd
        done
    else
        for cmd in "${cmds[@]}"; do
            if [ $verbose -ne 0 ]; then
                echo $cmd
            fi
            $cmd
            status=$?
            if [ $status -ne 0 ]; then
                (>&2 echo -e "ERROR cmd \"$cmd\" failed\nstatus = $status")
                return_status=$status
            fi
        done
    fi
    return $return_status
}

function copy_helper_to_controller {
    local status=0
    local controller=${1:-"controller-0"}
    local cmd="scp configure-federation fed_variables heat-admin@${controller}:/home/heat-admin"
    if [ $verbose -ne 0 -o $dry_run -ne 0 ]; then
        echo $cmd
    fi
    if [ $dry_run -ne 0 ]; then
        return $status
    fi

    $cmd
    status=$?
    if [ $status -ne 0 ]; then
        (>&2 echo -e "ERROR cmd \"$cmd\" failed\nstatus = $status")
    fi
    return $status
}

function install_mod_auth_mellon {
    local status=0
    local cmd="sudo dnf -y install mod_auth_mellon"

    if [ $verbose -ne 0 -o $dry_run -ne 0 ]; then
        echo $cmd
    fi
    if [ $dry_run -ne 0 ]; then
        return $status
    fi

    $cmd
    status=$?
    if [ $status -ne 0 ]; then
        (>&2 echo -e "ERROR cmd \"$cmd\" failed\nstatus = $status")
    fi
    return $status
}

function create_ipa_service_account {
    # Note, after setting up the service account it can be tested
    # by performing a user search like this:
    # ldapsearch -H $ldap_url -x -D "$service_dn" -w "$FED_IPA_RHSSO_SERVICE_PASSWD" -b "cn=users,cn=accounts,$FED_IPA_BASE_DN"

    local status=0
    local ldap_url="ldaps://$FED_IPA_HOST"
    local dir_mgr_dn="cn=Directory Manager"
    local service_name="rhsso"
    local service_dn="uid=$service_name,cn=sysaccounts,cn=etc,$FED_IPA_BASE_DN"
    local cmd="ldapmodify -H \"$ldap_url\" -x -D \"$dir_mgr_dn\" -w \"$FED_IPA_ADMIN_PASSWD\""

    read -r -d '' contents <<EOF
dn: $service_dn
changetype: add
objectclass: account
objectclass: simplesecurityobject
uid: $service_name
userPassword: $FED_IPA_RHSSO_SERVICE_PASSWD
passwordExpirationTime: 20380119031407Z
nsIdleTimeout: 0

EOF

    if [ $verbose -ne 0 -o $dry_run -ne 0 ]; then
        echo $cmd
        echo -e "$contents"
    fi
    if [ $dry_run -ne 0 ]; then
        return $status
    fi

    sh <<< "$cmd <<< \"$contents\""
    status=$?
    if [ $status -ne 0 ]; then
        (>&2 echo -e "ERROR cmd \"$cmd\" failed\nstatus = $status")
    fi

    return $status
}



function client_install {
    local status=0
    local cmd_client_install="sudo dnf -y install keycloak-httpd-client-install"
    local cmd="sudo keycloak-httpd-client-install \
   --client-originate-method registration \
   --mellon-https-port $FED_KEYSTONE_HTTPS_PORT \
   --mellon-hostname $FED_KEYSTONE_HOST  \
   --mellon-root $mellon_root \
   --keycloak-server-url $FED_RHSSO_URL  \
   --keycloak-admin-password  $FED_RHSSO_ADMIN_PASSWORD \
   --app-name $mellon_app_name \
   --keycloak-realm $FED_RHSSO_REALM \
   -l "/v3/auth/OS-FEDERATION/websso/mapped" \
   -l "/v3/auth/OS-FEDERATION/identity_providers/rhsso/protocols/mapped/websso" \
   -l "/v3/OS-FEDERATION/identity_providers/rhsso/protocols/mapped/auth"
"
    if [ $verbose -ne 0 -o $dry_run -ne 0 ]; then
        echo $cmd_client_install
        echo $cmd
    fi
    if [ $dry_run -ne 0 ]; then
        return $status
    fi

    $cmd_client_install
    status=$?
    if [ $status -ne 0 ]; then
        (>&2 echo -e "ERROR cmd \"$cmd_client_install\" failed\nstatus = $status")
    else
        $cmd
        status=$?
        if [ $status -ne 0 ]; then
            (>&2 echo -e "ERROR cmd \"$cmd\" failed\nstatus = $status")
        fi
    fi
    return $status
}

function create_sp_archive {
    # Note, we put the exclude patterns in a file because it is
    # insanely difficult to put --exclude patttern in the $cmd shell
    # variable and get the final quoting correct.

    local status=0
    local cmd="tar -cvzf $config_tar_pathname --exclude-from $stage_dir/tar_excludes /var/lib/config-data/puppet-generated/keystone/etc/httpd/saml2 /var/lib/config-data/puppet-generated/keystone/etc/httpd/conf.d/$mellon_httpd_config_filename"
    if [ $verbose -ne 0 -o $dry_run -ne 0 ]; then
        echo $cmd
    fi
    if [ $dry_run -ne 0 ]; then
        return $status
    fi

    cat <<'EOF' > $stage_dir/tar_excludes
*.orig
*~
EOF

    $cmd
    status=$?
    if [ $status -ne 0 ]; then
        (>&2 echo -e "ERROR cmd \"$cmd\" failed\nstatus = $status")
    fi
    return $status
}

function fetch_sp_archive {
    local return_status=0
    declare -a cmds=(
        "scp heat-admin@controller-0:/home/heat-admin/fed_deployment/$config_tar_filename $stage_dir"
        "tar -C $stage_dir -xvf $config_tar_pathname"
    )

    if [ $dry_run -ne 0 ]; then
        for cmd in "${cmds[@]}"; do
            echo $cmd
        done
    else
        for cmd in "${cmds[@]}"; do
            if [ $verbose -ne 0 ]; then
                echo $cmd
            fi
            $cmd
            status=$?
            if [ $status -ne 0 ]; then
                (>&2 echo -e "ERROR cmd \"$cmd\" failed\nstatus = $status")
                return_status=$status
            fi
        done
    fi
    return $return_status
}

function deploy_mellon_configuration {
    local status=0
    local cmd="upload-swift-artifacts -f $config_tar_pathname"
    if [ $verbose -ne 0 -o $dry_run -ne 0 ]; then
        echo $cmd
    fi
    if [ $dry_run -ne 0 ]; then
        return $status
    fi

    $cmd
    status=$?
    if [ $status -ne 0 ]; then
        (>&2 echo -e "ERROR cmd \"$cmd\" failed\nstatus = $status")
    fi
    return $status
}

function idp_entity_id {
    local metadata_file=${1:-$idp_metadata_filename}

    # Extract the entitID from the metadata file, should really be parsed
    # with an XML xpath but a simple string match is probably OK

    entity_id=`sed -rne 's/^.*entityID="([^"]*)".*$/\1/p' ${metadata_file}`
    status=$?
    if [ $status -ne 0 -o "$entity_id"x = "x" ]; then
        (>&2 echo -e "ERROR search for entityID in ${metadata_file} failed\nstatus = $status")
        return 1
    fi
    echo $entity_id
    return 0
}

function append_deploy_script {
    local status=0
    local deploy_script=$1
    local extra_line=$2
    local count

    count=$(grep -c -e "$extra_line" $deploy_script)
    if [ $count -eq 1 ]; then
        echo -e "SKIP appending:\n$extra_line"
        echo "already present in $deploy_script"
        return $status
    elif [ $count -gt 1 ]; then
        status=1
        (>&2 echo -e "ERROR multiple copies of line in  ${deploy_script}\nstatus = $status\nline=$extra_line")
        return $status
    fi

    if [ $verbose -ne 0 -o $dry_run -ne 0 ]; then
        echo "appending $deploy_script with:"
        echo -e $extra_line
    fi
    if [ $dry_run -ne 0 ]; then
        return $status
    fi

    # insert line after last -e line already in script
    #
    # This is not easy with sed, we'll use tac and awk instead.  Here
    # is how this works: The logic is easier if you insert before the
    # first line rather than trying to find the last line and insert
    # after it. We use tac to reverse the lines in the file. Then the
    # awk script looks for the candidate line. If found it outputs the
    # line we're adding, sets a flag (p) to indicate it's already been
    # printed. The "; 1" pattern always output the input line. Then we
    # run the output through tac again to set things back in the
    # original order.

    local tmp_file=$(mktemp)

    tac $deploy_script | awk "!p && /^-e/{print \"${extra_line} \\\\\"; p=1}; 1" | tac > $tmp_file

    count=$(grep -c -e "${extra_line}" $tmp_file)
    if [ $count -ne 1 ]; then
        status=1
    fi
    if [ $status -ne 0 ]; then
        rm $tmp_file
        (>&2 echo -e "ERROR failed to append ${deploy_script}\nstatus = $status\nline=$extra_line")
    else
        mv $tmp_file $deploy_script
    fi


    return $status
}

function puppet_override_apache {
    local status=0
    local pathname=${1:-$puppet_override_apache_pathname}
    local deploy_cmd="-e $pathname"

    read -r -d '' contents <<'EOF'
parameter_defaults:
  ControllerExtraConfig:
    apache::purge_configs: false
EOF

    if [ $verbose -ne 0 -o $dry_run -ne 0 ]; then
        echo "writing pathname = $pathname with contents"
        echo -e "$contents"
    fi
    if [ $dry_run -ne 0 ]; then
        return $status
    fi

    echo -e "$contents" > $pathname
    status=$?
    if [ $status -ne 0 ]; then
        (>&2 echo -e "ERROR failed to write ${pathname}\nstatus = $status")
    fi

    append_deploy_script $overcloud_deploy_script "$deploy_cmd"
    status=$?

    return $status
}

function puppet_override_keystone {
    local status=0
    local pathname=${1:-$puppet_override_keystone_pathname}
    local deploy_cmd="-e $pathname"

    read -r -d '' contents <<EOF
parameter_defaults:
  controllerExtraConfig:
    keystone::using_domain_config: true
    keystone::config::keystone_config:
      identity/domain_configurations_from_database:
        value: true
      auth/methods:
        value: external,password,token,oauth1,mapped
      federation/trusted_dashboard:
        value: https://$FED_KEYSTONE_HOST/dashboard/auth/websso/
      federation/sso_callback_template:
        value: /etc/keystone/sso_callback_template.html
      federation/remote_id_attribute:
        value: MELLON_IDP

EOF

    if [ $verbose -ne 0 -o $dry_run -ne 0 ]; then
        echo "writing pathname = $pathname with contents"
        echo -e "$contents"
    fi
    if [ $dry_run -ne 0 ]; then
        return $status
    fi

    echo -e "$contents" > $pathname
    status=$?
    if [ $status -ne 0 ]; then
        (>&2 echo -e "ERROR failed to write ${pathname}\nstatus = $status")
    fi

    append_deploy_script $overcloud_deploy_script "$deploy_cmd"
    status=$?

    return $status
}

function create_federated_resources {
    # follow example in Keystone federation documentation
    # http://docs.openstack.org/developer/keystone/federation/federated_identity.html#create-keystone-groups-and-assign-roles
    local return_status=0
    declare -a cmds=(
    "openstack domain create federated_domain"
    "openstack project create  --domain federated_domain federated_project"
    "openstack group create federated_users --domain federated_domain"
    "openstack role add --group federated_users --group-domain federated_domain --domain federated_domain _member_"
    "openstack role add --group federated_users --project federated_project Member"
    )

    if [ $dry_run -ne 0 ]; then
        for cmd in "${cmds[@]}"; do
            echo $cmd
        done
    else
        for cmd in "${cmds[@]}"; do
            if [ $verbose -ne 0 ]; then
                echo $cmd
            fi
            $cmd
            status=$?
            if [ $status -ne 0 ]; then
                (>&2 echo -e "ERROR cmd \"$cmd\" failed\nstatus = $status")
                return_status=$status
            fi
        done
    fi
    return $return_status
}

function create_mapping {
    # Matches documentation
    # http://docs.openstack.org/developer/keystone/federation/federated_identity.html#create-keystone-groups-and-assign-roles
    local status=0
    local pathname=${1:-$openstack_mapping_pathname}

    read -r -d '' contents <<'EOF'
[
    {
        "local": [
            {
                "user": {
                    "name": "{0}"
                },
                "group": {
                    "domain": {
                        "name": "federated_domain"
                    },
                    "name": "federated_users"
                }
            }
        ],
        "remote": [
            {
                "type": "MELLON_NAME_ID"
            },
            {
                "type": "MELLON_groups",
                "any_one_of": ["openstack-users"]
            }
        ]
    }
]
EOF

    if [ $verbose -ne 0 -o $dry_run -ne 0 ]; then
        echo "writing pathname = $pathname with contents"
        echo -e "$contents"
    fi
    if [ $dry_run -ne 0 ]; then
        return $status
    fi


    echo -e "$contents" > $pathname
    status=$?
    if [ $status -ne 0 ]; then
        (>&2 echo -e "ERROR failed to write ${pathname}\nstatus = $status")
    fi

    return $status
}

function create_v3_rcfile {
    local status=0
    local input_file=${1:-$overcloudrc_file}
    local output_file="${input_file}.v3"

    source $input_file
    #clear the old environment
    NEW_OS_AUTH_URL=`echo $OS_AUTH_URL | sed 's!v2.0!v3!'`

    read -r -d '' contents <<EOF
for key in \$( set | sed 's!=.*!!g'  | grep -E '^OS_') ; do unset $key ; done
export OS_AUTH_URL=$NEW_OS_AUTH_URL
export OS_USERNAME=$OS_USERNAME
export OS_PASSWORD=$OS_PASSWORD
export OS_USER_DOMAIN_NAME=Default
export OS_PROJECT_DOMAIN_NAME=Default
export OS_PROJECT_NAME=$OS_TENANT_NAME
export OS_IDENTITY_API_VERSION=3
EOF

    if [ $verbose -ne 0 -o $dry_run -ne 0 ]; then
        echo "writing output_file = $output_file with contents:"
        echo -e "$contents"
    fi
    if [ $dry_run -ne 0 ]; then
        return $status
    fi

    echo -e "$contents" > $output_file
    status=$?
    if [ $status -ne 0 ]; then
        (>&2 echo -e "ERROR failed to write ${output_file}\nstatus = $status")
    fi

    return $status
}

function openstack_create_idp {
    local status=0
    local metadata_file="$stage_dir/var/lib/config-data/puppet-generated/keystone/etc/httpd/saml2/$idp_metadata_filename"
    local entity_id
    entity_id=$(idp_entity_id $metadata_file)
    status=$?
    if [ $status -ne 0 ]; then
        return $status
    fi

    local cmd="openstack identity provider create --remote-id $entity_id $FED_OPENSTACK_IDP_NAME"

    if [ $verbose -ne 0 -o $dry_run -ne 0 ]; then
        echo $cmd
    fi
    if [ $dry_run -ne 0 ]; then
        return $status
    fi

    $cmd
    status=$?
    if [ $status -ne 0 ]; then
        (>&2 echo -e "ERROR cmd \"$cmd\" failed\nstatus = $status")
    fi
    return $status
}

function openstack_create_mapping {
    local status=0
    local mapping_file=${1:-$openstack_mapping_pathname}
    local mapping_name=${2:-$FED_OPENSTACK_MAPPING_NAME}
    cmd="openstack mapping create --rules $mapping_file $mapping_name"

    if [ $verbose -ne 0 -o $dry_run -ne 0 ]; then
        echo $cmd
    fi
    if [ $dry_run -ne 0 ]; then
        return $status
    fi

    $cmd
    status=$?
    if [ $status -ne 0 ]; then
        (>&2 echo -e "ERROR cmd \"$cmd\" failed\nstatus = $status")
    fi
    return $status
}

function openstack_create_protocol {
    local status=0
    local idp_name=${1:-$FED_OPENSTACK_IDP_NAME}
    local mapping_name=${2:-$FED_OPENSTACK_MAPPING_NAME}
    cmd="openstack federation protocol create --identity-provider $idp_name --mapping $mapping_name mapped"

    if [ $verbose -ne 0 -o $dry_run -ne 0 ]; then
        echo $cmd
    fi
    if [ $dry_run -ne 0 ]; then
        return $status
    fi

    $cmd
    status=$?
    if [ $status -ne 0 ]; then
        (>&2 echo -e "ERROR cmd \"$cmd\" failed\nstatus = $status")
    fi
    return $status
}

function usage {
cat <<EOF
$prog_name action

-h --help        print usage
-n --dry-run     dry run, just print computed command
-v --verbose     be chatty

action may be one of:

show-variables
initialize
copy-helper-to-controller
install-mod-auth-mellon
create-ipa-service-account
client-install
create-sp-archive
fetch-sp-archive
deploy-mellon-configuration
puppet-override-apache
puppet-override-keystone
create-federated-resources
create-mapping
create-v3-rcfile
openstack-create-idp
openstack-create-mapping
openstack-create-protocol

EOF
}

#-----------------------------------------------------------------------------
# options may be followed by one colon to indicate they have a required argument
if ! options=$(getopt -o hnv -l help,dry-run,verbose -- "$@")
then
    # something went wrong, getopt will put out an error message for us
    exit 1
fi

eval set -- "$options"

while [ $# -gt 0 ]
do
    case $1 in
    -h|--help) usage; exit 1 ;;
    -n|--dry-run) dry_run=1 ;;
    -v|--verbose) verbose=1 ;;
    # for options with required arguments, an additional shift is required
    (--) shift; break;;
    (-*) echo "$0: error - unrecognized option $1" 1>&2; exit 1;;
    (*) break;;
    esac
    shift
done
#-----------------------------------------------------------------------------
source ./fed_variables


# Strip leading and trailing space and slash from these variables
mellon_root=`echo ${mellon_root} | perl -pe 's!^[ /]*(.*?)[ /]*$!\1!'`
mellon_endpoint=`echo ${mellon_endpoint} | perl -pe 's!^[ /]*(.*?)[ /]*$!\1!'`

mellon_root="/${mellon_root}"

mellon_endpoint_path="${mellon_root}/${mellon_endpoint}"
mellon_http_url="https://${FED_KEYSTONE_HOST}:${FED_KEYSTONE_HTTPS_PORT}"
mellon_entity_id="${mellon_http_url}${mellon_endpoint_path}/metadata"

openstack_mapping_pathname="${stage_dir}/mapping_${FED_OPENSTACK_IDP_NAME}_saml2.json"
idp_metadata_filename="${mellon_app_name}_keycloak_${FED_RHSSO_REALM}_idp_metadata.xml"
mellon_httpd_config_filename="${mellon_app_name}_mellon_keycloak_${FED_RHSSO_REALM}.conf"
config_tar_filename="rhsso_config.tar.gz"
config_tar_pathname="${stage_dir}/${config_tar_filename}"
puppet_override_apache_pathname="${stage_dir}/puppet_override_apache.yaml"
puppet_override_keystone_pathname="${stage_dir}/puppet_override_keystone.yaml"

#-----------------------------------------------------------------------------

if [ $# -lt 1 ]; then
  echo "ERROR: no action specified"
  exit 1
fi
action="$1"; shift

if [ $dry_run -ne 0 ]; then
    echo "Dry Run Enabled!"
fi

case $action in
    show-var*)
        show_variables ;;
    initialize)
        initialize ;;
    copy-helper-to-controller)
        copy_helper_to_controller "$1" ;;
    install-mod-auth-mellon)
        install_mod_auth_mellon ;;
    create-ipa-service-account)
        create_ipa_service_account ;;
    client-install)
        client_install ;;
    create-sp-archive)
        create_sp_archive ;;
    fetch-sp-archive)
        fetch_sp_archive ;;
    deploy-mellon-configuration)
        deploy_mellon_configuration ;;
    create-v3-rcfile)
        create_v3_rcfile "$1" ;;
    puppet-override-apache)
        puppet_override_apache "$1" ;;
    puppet-override-keystone)
        puppet_override_keystone "$1" ;;
    create-federated-resources)
        create_federated_resources ;;
    create-mapping)
        create_mapping "$1" ;;
    openstack-create-idp)
        openstack_create_idp "$1" ;;
    openstack-create-mapping)
        openstack_create_mapping "$1" "$2" ;;
    openstack-create-protocol)
        openstack_create_protocol "$1" "$2" ;;
    *)
        echo "unknown action: $action"
        usage
        exit 1
        ;;
esac

7장. fed_variables 파일

# FQDN of IPA server
FED_IPA_HOST="jdennis-ipa.example.com"

# Base DN of IPA server
FED_IPA_BASE_DN="dc=example,dc=com"

# IPA administrator password
FED_IPA_ADMIN_PASSWD="FreeIPA4All"

# Password used by RH-SSO service to authenticate to IPA
# when RH-SSO obtains user/group information from IPA as part of
# RH-SSO's User Federation.
FED_IPA_RHSSO_SERVICE_PASSWD="rhsso-passwd"

# RH-SSO server IP address
FED_RHSSO_IP_ADDR="10.0.0.12"

# RH-SSO server FQDN
FED_RHSSO_FQDN="jdennis-rhsso-7"

# URL used to access the RH-SSO server
FED_RHSSO_URL="https://$FED_RHSSO_FQDN"

# Administrator password for RH-SSO server
FED_RHSSO_ADMIN_PASSWORD=FreeIPA4All

# Name of the RH-SSO realm
FED_RHSSO_REALM="openstack"

# Host name of the mellon server
# Note, this is identical to the Keystone server since Keystone is
# being front by Apache which is protecting it's resources with mellon.
FED_KEYSTONE_HOST="overcloud.localdomain"

# Port number mellon is running on the FED_KEYSTONE_HOST
# Note, this is identical to the Keystone server port
FED_KEYSTONE_HTTPS_PORT=13000

# Name assigned in OpenStack to our IdP
FED_OPENSTACK_IDP_NAME="rhsso"

# Name of our Keystone mapping rules
FED_OPENSTACK_MAPPING_NAME="${FED_OPENSTACK_IDP_NAME}_mapping"

법적 공지

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.