Blackboard Learn은 3단계 OAuth 2.0 인증을 지원합니다.

3LO(3단계 OAuth)

개발자는 보다 안전한 방식으로 사용자를 대신하여 역할을 하는 REST API를 사용하여 애플리케이션을 만들 수 있습니다. 3LO를 사용하여 인증되면 애플리케이션이 사용자를 대신하여 역할을 할 수 있으므로 해당 사용자의 접근 권한이 Blackboard Learn의 일부로 제한됩니다.

3단계 OAuth에 대해 자세히 알아보기

학생 및 교수자는 통합 애플리케이션이 Learn에서 자신의 개인 정보에 접근할 수 있도록 허용해야 합니다. 인증에 대한 자세한 내용은 통합 앱에 대한 접근 권한 부여를 참조하십시오.

타사 통합 등록

Blackboard Learn는 Blackboard Learn REST API를 사용하여 빌드된 외부 애플리케이션의 통합을 지원합니다. Blackboard Learn와의 통합을 사용하려면 먼저 관리자가 등록해야 합니다.

애플리케이션 등록을 시작하기 전에 애플리케이션 ID를 얻어야 합니다. 개발자가 관리자에게 직접 ID를 제공하거나 애플리케이션에 대한 지원 설명서와 함께 번들로 제공할 수 있습니다.

  1. 관리자 도구의 통합에서 REST API 통합을 선택합니다.
  2. REST API 통합 페이지에서 통합 생성을 선택합니다.

  3. 애플리케이션 ID에 통합 개발자가 증명한 애플리케이션 ID를 입력합니다.

    통합 개발자가 ID를 제공해야 합니다. 사용자만을 위한 사용자 지정 소프트웨어를 만들지 않는 한 통합 개발자가 Anthology 개발자 포털에서 애플리케이션 등록을 생성하도록 요청할 수는 없습니다. 상용 규격 소프트웨어 공급업체가 이를 요청하는 경우 당사에 연락하여 도움을 받도록 하십시오.

  4. Learn 사용자에서 통합이 역할을 할 사용자를 찾습니다. 일반적으로 공급업체가 애플리케이션에 필요하다고 표시한 권한만 있는 사용자 지정된 역할을 사용하여 애플리케이션당 한 명의 사용자를 생성해야 합니다.

    Anthology는 REST API 애플리케이션에 대해 시스템 역할이 '시스템 관리자'인 사용자를 선택하지 않도록 권장합니다. 애플리케이션이 아무 제한 없이 정보에 접근할 수 있기 때문입니다. 공급업체에서 '시스템 관리자'를 사용하도록 요청하는 경우 당사에 문의하여 도움을 받도록 하십시오.

  5. 애플리케이션이 최종 사용자 '역할을 해야' 하는 경우 최종 사용자 접근을 예로 설정합니다. 사용자가 이 앱에 처음 접근할 때 타사 동의 워크플로가 표시됩니다. 
    1. 최종 사용자 접근에 대해 예를 선택하는 경우 동의 워크플로를 건너뛰도록 선택할 수도 있습니다. 이렇게 하려면 사용자 역할을 수행할 권한 있음을 예로 설정합니다. 이 선택의 개인 정보 보호, 법적인 의미 및 기타 의미를 신중하게 고려해야 합니다. 자세한 내용은 아래의 신뢰할 수 있는 서비스 섹션을 참조하십시오.
  6. 최종 사용자 접근을 아니요로 설정하면 통합은 항상 Learn 사용자에서 선택한 Blackboard Learn 사용자인 것처럼 Learn에 접근할 수 있습니다. 선택한 사용자가 사용자 개인 데이터에 접근할 수 있는 경우 통합 애플리케이션도 접근할 수 있습니다.
  7. 제출을 선택하여 통합에 대한 설정을 저장합니다.

신뢰할 수 있는 서비스

신뢰할 수 있는 서비스는 타사에서 개발한 애플리케이션이 Blackboard Learn과 통신하는 것과 매우 유사한 방식으로 Blackboard Learn과 통신합니다. 신뢰할 수 있는 서비스에 대한 애플리케이션은 개발자 포털에서 작성해야 하며, 신뢰할 수 있는 서비스는 해당 자격 증명을 사용하여 Learn과 상호 작용합니다.

신뢰할 수 있는 서비스는 다음을 수행할 수 있습니다.

  • Blackboard Learn 사이트가 해당 신뢰할 수 있는 서비스와 통합된 것으로 자동으로 등록하고 사이트 관리자가 해당 통합을 제거하지 못하도록 합니다.
  • 애플리케이션 통합에 일반적으로 적용되는 속도 제한 및 사이트 할당량을 무시합니다.
  • Blackboard Learn 최종 사용자에게 허용/거부 통합 UI를 표시할 필요 없이 3단계 OAuth를 활용합니다.

신뢰할 수 있는 서비스가 아닌 타사 애플리케이션은 수정 및 선택 가능한 상태로 유지되지만 신뢰할 수 있는 서비스 애플리케이션은 선택할 수 없습니다. 신뢰할 수 있는 서비스의 동작 메뉴에도 보기 버튼만 표시됩니다.

최종 사용자 접근을 허용해야 합니까?

통합 애플리케이션의 공급업체는 애플리케이션에 최종 사용자 접근이 필요한지 여부를 알려줄 수 있어야 합니다. 접근이 필요한 경우의 일반적인 예로는 코스에서 활동을 생성하는 애플리케이션을 들 수 있습니다. 예를 들어 토론 게시판 애플리케이션에서 로그인한 사용자로 게시글을 작성하려면 최종 사용자 접근 권한이 필요합니다. 그렇지 않으면 토론 게시판 게시글이 모두 하나의 일반 계정에서 온 것처럼 보일 수 있습니다.

최종 사용자 접근이 필요하지 않은 애플리케이션의 예로는 코스, 사용자 또는 등록을 생성/관리하기 위해 SIS와 통합되는 애플리케이션을 들 수 있습니다. 이 시나리오에서 애플리케이션에는 자체 사용자만 있어야 하며 해당 사용자에게는 필요한 권한만 부여된 역할이 있어야 합니다. 앱이 기능을 수행하기 위해 특정 사용자 '역할을 할' 필요가 없습니다.