ID 관련 용어 익히기

학습 목표

이 모듈을 완료하면 다음을 수행할 수 있습니다.

• ID 및 액세스 관리에 사용되는 업계 표준을 식별할 수 있습니다.
  
• SAML이 XML과 어떤 관련이 있는지 이해할 수 있습니다.
  
• ID 공급자와 서비스 공급자의 차이점을 이해할 수 있습니다.
  

ID 표준 및 프로토콜

사용자가 외부 웹사이트나 앱에 로그인할 필요가 없을 때 사용자의 ID를 안전하게 유지할 수 있다는 사실이 믿어지지 않나요? 수많은 기업과 경쟁업체의 제품들은 서로 어떻게 연동이 가능한 걸까요?

ID 및 액세스 관리를 위한 업계 표준 및 프로토콜이 있기 때문입니다. 다소 어렵게 들릴 수도 있지만, 전혀 그렇지 않습니다. 표준은 업계 구성원들이 따르는 광범위하게 동의된 관행 집합입니다. 표준에는 시스템이 정보를 교환하는 방식을 지정하는 프로토콜이 포함될 수 있습니다.

다음은 Salesforce 및 기타 ID 공급자가 ID 솔루션을 구현하기 위해 따르는 세 가지 프로토콜입니다.

• SAML
  
• OAuth 2.0
  
• OpenID Connect
  

SAML 프로토콜

사용자가 반복적으로 로그인하지 않고 Salesforce 조직과 애플리케이션 간에 원활하게 전환하도록 지원하려면 싱글사인온을 설정하세요. 이를 위해서는 SAML(Security Assertion Markup Language) 프로토콜이 필요합니다.

다음은 실제 동작하는 SAML의 몇 가지 예입니다.

• Salesforce에 로그인한 후 앱 시작 관리자를 클릭하여 Gmail 받은 편지함으로 바로 이동합니다.
  
• 다른 앱에 이미 로그인한 사용자가 다시 로그인하지 않고도 Salesforce 조직에 액세스할 수 있습니다.
  

SAML 어설션

SAML 동작 방식은 다음과 같습니다. 사용자가 서비스에 액세스하려고 시도합니다. 서비스 공급자는 기본적으로 "이 사용자가 내 서비스에 액세스해도 괜찮나요?"라고 묻는 요청을 ID 공급자에게 전송합니다. ID 공급자는 데이터베이스를 확인한 후 "예, 이 사용자는 승인되었습니다. 여기에 사용자에 대한 몇 가지 정보가 있습니다."라는 응답(어설션)을 반환하여 사용자가 올바른지 확인합니다.

그렇다면 ID 공급자와 서비스 공급자의 차이점은 무엇일까요? 기본적으로 ID 공급자는 사용자를 인증하고, 서비스 공급자는 인증된 ID를 요청합니다. ID 공급자와 서비스 공급자는 이 유닛의 뒷부분에서 자세히 설명하겠습니다.

어설션은 전송되는 정보입니다. 어설션은 사용자에 대한 상세 정보를 전달할 수 있습니다. 또한 이름과 성, 연락처 정보, 직급과 같은 사용자에 대한 속성도 포함할 수 있습니다.

SAML은 백그라운드에서 동작하므로 사용자는 동작 모습을 볼 수 없습니다. 추가 정보를 제공하거나 다시 로그인할 필요 없이, 아이콘이나 링크를 클릭하고 다른 앱을 열기만 하면 됩니다. 때때로 목적지는 사용자 속성이 도착할 때 그에 대한 정보를 이미 알고 있습니다.

SAML 및 XML

SAML은 XML 기반 프로토콜입니다. 즉 교환되는 정보 패키지가 XML로 작성됩니다. XML은 사람이 어느 정도는 판독할 수 있어서 무슨 일이 진행 중인지 파악할 수 있습니다. 제대로 작동하는지 확인하려고 한다면 이는 분명 좋은 소식입니다.

다음 다이어그램에는 SAML 어설션의 일부가 나와 있습니다. 무슨 의미인지 하나도 모르시겠나요? 다시 한 번 보시면, 전혀 이해를 못할 정도는 아닙니다. 여기에는 사용자의 사용자 이름, 전화번호, 이름이 포함되어 있습니다.

이 예시에서 Salesforce 조직은 사용자의 정보를 다른 애플리케이션에 전달합니다. 이 애플리케이션은 해당 정보를 사용하여 사용자에게 권한을 부여하고 사용자 경험을 개인화할 수 있습니다 하지만 가장 중요한 것은 사용자가 애플리케이션에 액세스하기 위해 다시 로그인할 필요가 없다는 사실입니다.

OAuth 2.0 프로토콜

OAuth(Open Authorization) 2.0은 애플리케이션 간의 안전한 데이터 공유를 위해 사용되는 개방형 프로토콜입니다. 사용자는 한 앱에서 작업하지만 다른 앱의 데이터를 볼 수 있습니다. Salesforce 모바일 앱에 로그인해서 Salesforce 조직의 데이터를 보는 경우가 그 예입니다.

보이지 않는 곳에서 앱은 서로 통신한 후 사용자에게 이 데이터 공유를 승인하도록 요청합니다. 개발자는 앱을 Salesforce와 통합할 때 OAuth API를 사용합니다.

다음은 몇 가지 예입니다.

• Salesforce 조직에서 연락처를 가져오는 모바일 앱은 OAuth를 사용합니다.
  
• 다른 서비스로부터 연락처를 받는 Salesforce 조직도 OAuth를 사용합니다.
  

다음은 OAuth 2.0을 사용하여 사용자에게 정보 액세스 권한을 요청하는 앱의 예입니다.

OpenID Connect 프로토콜

OpenID Connect 프로토콜은 OAuth 2.0에 인증 계층을 추가하여 사용자 정보의 안전한 교환을 지원합니다. SAML과 마찬가지로 OpenID Connect는 한 서비스에서 다른 서비스로 ID 정보를 전송합니다. 단, SAML과 달리 OpenID Connect는 오늘날의 소셜 네트워크를 위해 개발되었습니다. 새 앱을 설치하고서 'Google 계정으로 로그인하세요'와 같은 메시지를 본 적이 있나요? 해당 앱은 OpenID Connect 프로토콜을 사용하고 있습니다. Google로 로그인하는 경우 계정과 다른 비밀번호를 생성하는 것이 아닙니다. Google만이 해당 정보를 보유합니다.

앱 개발자는 OpenID Connect 프로토콜을 사용하여 소셜사인온을 활성화합니다.

예를 들어 Google이 다른 서비스를 대신하여 사용자의 ID를 확인하는 것은 사용자를 인증하는 것입니다. 이런 면에서 Google은 ID 공급자입니다.

Salesforce는 Google, Facebook, LinkedIn을 비롯한 여러 주요 소셜 ID 공급자를 지원합니다. 특정 ID 공급자가 기본적으로 지원되지 않더라도 OpenID Connect 프로토콜을 구현하면 계속 사용할 수 있습니다(예: Amazon, PayPal).

OpenID Connect 프로토콜이 사용자에게 제공하는 이점은 별도의 계정, 사용자 이름, 비밀번호의 수를 줄일 수 있다는 것입니다. 한편, 개발자는 비밀번호 파일을 소유하고 관리할 필요 없이 웹사이트와 앱에서 사용자를 인증할 수 있습니다. 이러한 프로세스로 인해 해커가 사용자 계정에 침입하기가 매우 어렵습니다.

서비스 공급자와 ID 공급자

사용자를 인증하는 과정에서 SAML은 ID 공급자(IdP)라고 불리는 정보 소유자와 서비스 공급자라고 불리는 원하는 서비스 간에 ID 정보를 교환합니다.

사용자가 Salesforce에 로그인한 후 Gmail에 액세스하는 경우 Salesforce가 ID 공급자이고 Google이 서비스 공급자입니다. Salesforce는 서비스 공급자인 동시에 ID 공급자가 될 수 있습니다.

서비스 공급자로서의 Salesforce

인증된 사용자는 외부 ID 공급자에서 Salesforce로 이동할 수 있습니다. 이 경우 Salesforce는 서비스 공급자입니다. 사용자는 이 서비스에 액세스하기를 원하고 해당 ID 공급자에서 해당 행동을 허용합니다. 회사에서 이미 ID 공급자를 이용하는 경우가 많기 때문에 이러한 Salesforce 구성은 일반적입니다. ID 공급자는 Microsoft의 ADFS(Active Directory Federation Services), Ping Identity의 PingFederate, 오픈 소스 Shibboleth 또는 ForgeRock의 OpenAM과 같이 시장에서 활동 중인 여러 회사 중 하나일 수 있습니다.

사용자는 ID 공급자에서 로그인한 후 Salesforce(서비스 공급자)로 리디렉션됩니다. 또 다른 모듈에서 여러분은 Salesforce를 서비스 공급자로 지정하고 타사 애플리케이션을 외부 ID 공급자로 지정하는 싱글사인온을 설정할 예정입니다.

ID 공급자로서의 Salesforce

인증된 사용자는 Salesforce에서 다른 클라우드 및 앱으로 이동할 수도 있습니다. 이 경우 Salesforce는 ID 공급자 역할을 하고, 사용자가 다른 서비스 공급자에 연결할 수 있도록 싱글사인온을 제공합니다.

싱글사인온에 대한 SAML 플로

다음 다이어그램은 싱글사인온 프로세스 동안 SAML 통신이 진행되는 방향을 보여줍니다. 이러한 동작은 보이지 않는 곳에서 수행됩니다. 이러한 내용에 관심이 없더라도 걱정하지 마세요. 테스트에 포함되지 않습니다.

싱글사인온 프로세스는 모두 매우 빠르게 진행되지만, 다음과 같은 몇 가지 단계를 거칩니다.

1. 사용자가 Salesforce에 액세스하려고 시도합니다.
   
2. Salesforce가 싱글사인온 요청을 인식하고 SAML 요청을 생성합니다.
   
3. Salesforce가 SAML 요청을 브라우저로 다시 리디렉션합니다.
   
4. 브라우저가 SAML 요청을 외부 ID 공급자로 리디렉션합니다.
   
5. ID 공급자가 사용자의 ID를 확인하고 사용자 인증이 포함된 SAML 어설션을 패키징합니다.
   
6. ID 공급자가 SAML 어설션을 브라우저에 전송합니다.
   
7. 브라우저가 어설션을 Salesforce로 리디렉션합니다.
   
8. Salesforce가 어설션을 확인합니다.
   
9. 이제 사용자가 로그인하여 Salesforce에 액세스할 수 있습니다.
   

ID 용어 학습 테이블

ID 프로토콜 주제에 대한 집중 과정이 어떠셨나요? 단어가 유사하게 들리고 차이가 미묘하면 혼동스러울 수 있습니다. 그래서 학습 테이블을 준비했습니다. 도움이 되기를 바랍니다!

다음 단계

ID 액세스 및 관리에 대한 업계 표준을 간략하게 살펴보았습니다 혼동스럽게 느껴지더라도 걱정하지 마세요. 지금은 Salesforce Identity가 프로토콜을 사용하여 기능을 구현한다는 점만 기억하세요.

이제부터 진짜 재미가 시작됩니다! 개념과 정의를 충분히 이해하셨나요? 오늘 배운 내용 중 일부를 실습해보겠습니다. 이 트레일의 뒷부분에서 Salesforce 개발 조직의 보안 기능을 설정할 예정입니다.

리소스

• Salesforce 도움말: SAML SSO 플로
  
• Salesforce 도움말: 사용자 식별 및 액세스 관리