SSO 종류와 OKTA의 이해

<<아이디 인증 관리>>

 

OAuth - OKTA 기술 개발 순서

Context 확인 - 맥락. 예를 들어 사용자의 컨텍스트가  서울에서 부산으로 휙휙 바뀐다던지, 브라우저 종류가 휙휙 바뀐다던지 하는 컨텍스트를 파악해서 수상한지 확인

 

Single - sign -on - 통합ID 관리시스템 ( 한 아이디로 여러 플렛폼 로그인 가능)

MFA (멀티펙터 엑세스) - 로그인 화면에서 여러 인증 수단이 가능하게 하는 기능 (권장수단으로 파이어로가 있다)

 

 

 

인증 순서

Identification - Verification - Register - Authentication(인증) - Authorization(인가)

 

아이덴티피케이션은 클럽 입장이나 담배살때 민증 잠깐 확인하는것 같은 레벨 ( 행안부에 직접 민증을 대조해서 오리지날을 확인하지는 않는다)

버리피케이션은 행안부에 직접 대조해 보는 것, 이메일이나 SMS 인증 등의 방법 사용

레지스터는 인증 정보를 생성하는것

어썬티케이션은 저장된 인증정보를 제시하는 것 ( 비번이나 생체인증 등)

에쏘라이제이션은 인가. 인가는 옵셔한 부분 권한부여.

 

인증 vs 인가

인증(authentication)은 자신이 누구라고 주장하는 사람을 확인하는 절차이다. 권한부여(authorization)는 가고 싶은 곳으로 가도록 혹은 원하는 정보를 얻도록 허용하는 과정이다.

 

 

<< SSO >>

 

1. OIDC (OpenID Connect)

OAuth2 (인가)를 id 인증용으로 규격화 한것이 oicd.

sso 목적으로 json 형식을 이용한 개발.

OIDC는 OAuth 2.0을 기반으로 인증(Authentication)을 수행하는 인증 Protocol이다. OIDC는 SSO (Single Sign On)을 구성하는데 많이 이용되고 있다. OAuth 2.0는 인가(Authorization)만을 수행하는 Protocol이기 때문에 OAuth 2.0 환경에서 인증 시스템도 필요한 경우에는 OIDC를 도입하여 해결할 수 있다.

 

OIDC는 OAuth 2.0을 기반으로 하기 때문에, OIDC의 Component는 OAuth 2.0 Component와 거의 동일하다. OIDC에서는 App에게 인증 정보를 제공하는 구성 요소를 Identity (OIDC) Provider라고 명칭한다. Identity Provider는 OAuth 2.0 관점에서는 인증에 필요한 User 정보를 저장하고 있는 Resource Server와 Authorization Server의 조합으로 구성된다. 여기서 Authorization Server는 App에게 Access Token을 통한 인가 정보뿐만 아니라, User의 정보를 저장하고 있는 ID Token이라고 불리는 Token을 App에게 전달하여 인증 Server의 역활도 수행한다.

 

예시) 게임에서 페이스북 주소록을 접근 후 페이스북 친구를 게임에 초대

 

대략 전체 구성

 

1.1. ID Token

OIDC는 App에게 User의 인증 정보를 전달하기 위해서 ID Token을 이용한다. ID Token은 JWT로 구성되어 있다. App은 JWT를 통해서 ID Token이 Identity Provider가 생성한 Token이라는 사실과, ID Token의 내용이 변조되지 않았다는 사실을 보장 받을 수 있다. ID Token(JWT)의 Signature 생성은 일반적으로 Identity Provider의 비공개키로 이루어진다. 따라서 ID Token을 검증은 Identity Provider의 공개키를 통해서 이루어진다.

ID Token에는 일반적으로 다음과 같은 Claim을 포함하고 있다.

(예를 들어 페이스북 내에서 유저 정보를 식별할 수 있는 식별자를 따로 이런식으로 지정할 수 있다)

• iss (Issuer) : ID Token의 발급자를 의미한다.
• sub (Subject) : ID Token에 저장된 User의 식별자를 의미한다.
• aud (Audience) : ID Token을 수신하고 이용하는 주체를 의미힌다. 일반적으로 Identity Provider에게 전달하는 Client ID가 Audience Claim에 설정된다.
• exp (Expiration): : ID Token의 만료 시간을 의미한다.

 

 

세부적인 통신사항

OIDC의 ID Token 발급 과정을 나타내고 있다. ID Token의 발급 과정은 OAuth 2.0의 Access Token을 발급받는 과정과 거의 동일하다. 단 마지막 12번 과정에서 Authorization Server로부터 Access Token 대신 ID Token이 App에게 전달된다는 점이 다르다. 필요에 따라서는 App은 ID Token 뿐만 아니라 OAuth 2.0의 Access Token, Refresh Token도 같이 전달받을 수 있다.

 

 

 

 

 

2. SAML (Security Assertion Markup Language) 2.0

 

서비스 프로바이더( aws나 페이스북 같은)와 아이덴티티 프로바이더가 직접 둘이 통신하지 않는다는 점이 포인트.

유저가 서비스 프로바이더에 따라 다른 xml 코드를 서비스 프로바이더에서 받아서 직접 아이덴티티 프로바이더에 스크립트를 붙여넣으면 발동.

 

SAML 2.0은 SSO(Single Sign On)을 구성하기 위해서 많이 이용되는 인증 (Authentication) 및 인가 (Authorization) Protocol이다. 큰 조직의 경우 일반적으로 조직 전용 인증/인가 서버를 구축하며, 조직에 소속되어 있는 User가 조직 내부의 Service를 이용하기 위해서는 자체 구축된 인증/인가 서버와의 인증/인가 과정이 필요하다. 문제는 User가 Google, Facebook과 같은 Service Provider의 Service를 이용하기 위해서는 해당 Service Provider와의 별도의 인증/인가 과정이 필요하다는 점이다.

 

SAML 2.0을 이용하여 SSO가 구축이되면 User는 Service Provider와의 인증/인가 과정없이 조직 전용 서버와의 인증/인과 과정만을 통해서 Service Provider의 Service도 이용할 수 있게 된다. 이러한 SAML 2.0 기반 SSO 과정은 인증/인가 정보를 저장하고 있는 Assertion 발급을 통해서 이루어진다. Assertion은 XML 형태로 인증/인가 정보를 저정하고 있다.

 

Web 환경에서 SAML 2.0를 이용하여 인증/인가 기능을 구성했을때 SAML 2.0의 구성요소를 나타내고 있다. User는 Service 이용자를 의미한다. User Agent는 User의 입력을 받아 Service/Identity Provider에게 전달하거나, Service/Identity Provider으로부터 받은 내용을 User에게 보여주는 역할을 수행한다. 일반적으로는 Web Brower를 의미한다.

 

Service Provider는 의미 그대로 User가 이용하고자 하는 Service를 제공하는 제공자를 나타낸다. 일반적으로 Google, Facebook과 같은 IT 기업에서 제공하는 API Server로 이해해도 된다. Identity Provider는 User의 인증/인가 정보를 저장하고 있으며 Service Provider에게 인증/인가 정보를 제공한다. 일반적으로 특정 조직에서 내부적으로 이용하는 인증/인가 Server로 이해해도 된다. Service Provider와 Identity Provider는 일반적으로 서로 다른 기업/조직으로 구성된다.

 

1.2. Process

SAML 2.0 Component 사이에는 다음의 Request, Response를 주고 받는다.

• SAML Request : Service Provider가 Identity Provider에게 전달하는 인증 요청이다. XML Format을 이용한다.
• SAML Response : Identity Provider가 Service Provider에게 전달하는 인증 결과이다. XML Format을 이용한다. Assertion 정보가 SAML Response에 포함되어 있다.
• Relay State : Service Provider가 Identity Provider에게 SAML Request를 전송할때 같이 전송되며 Identity Provider가 저장하고 있다가, Identity Provider가 Service Provider에게 SAML Response를 전송할때 같이 전송하는 값이다. Service Provider는 SAML Response를 수신한 후 Relay State를 어떠한 동작을 이어서 진행할지 결정한다. Relay State는 주로 User가 가장 먼저 접근을 시도한 Service Provider의 URL을 저장하는 용도로 이용된다. 따라서 Service Provider는 SAML Response를 수신한 이후에 같이 전송되는 Relay State를 통해서 User를 다시 Redirect 시킨다. Relay State의 Format은 SAML 2.0에 정의되어 있지 않다. 따라서 Service Provider마다 다른 Format의 Relay State를 갖게된다.

SAML Request, SAML Response, Relay State를 Service Provider와 Identity Provider 사이에 주고 받기 위해서는, Identity Provider에 Service Provider가 이전에 등록되어 있어야 한다. SAML 2.0은 SAML Request, SAML Response, Relay State를 주고 받는 방식은 HTTP Redirect (URL Query) 또는 HTTP Post 이용하는 방식중에 선택할 수 있다.

 

Service Provider의 경우 HTTP Redirect를 통해서 SAML Request와 Relay State를 Identity Provider에게 전송하고, Identity Provider는 HTTP Post Method의 Body를 통해서 SAML Response와 Relay State를 Service Provider에게 전송하는 과정을 나타내고 있다. SAML 2.0에서 가장 많이 이용되는 형태이다.

• 1,2 : User는 User Agent를 통해서 Service Provider의 URL에 접근하여 Service를 요청한다.
• 3 : Service Provider는 User Agent로부터 받은 요청에 인증/인가 정보가 없기 때문에, User Agent가 인증/인가 정보를 얻을 수 있도록 SAML Request, Relay State와 함께 Identitiy Provider로 HTTP Redirect 명령을 User Agent에게 전달한다. SAML Request와 Relay State는 Redirect되는 URL의 Query 형태로 전달된다.
• 4,5 : User Agent는 Identity Provider에 SAML Request, Relay State에 접근한다. Identity Provider는 URL Query에 존재하는 SAML Request와 Relay State를 바탕으로 인증 UI 구성하여 User Agent에게 전송한다.
• 6,7,8,9 : User가 Login을 수행하면 Identity Provider는 인증 이후에 User Agent가 SAML Response, Relay State를 Service Provider의 ACS (Assertion Consumer Service) URL로 HTTP Post 요청을 통해서 전달하도록 만든다. SAML Response, Relay State는 Post 요청의 Body로 전송된다.
• 10, 11 : User Agent는 HTTP Post 요청을 통해서 ACS URL로 접근한다. Service Provider의 ACS는 HTTP Post 요청의 Body에 존재하는 SAML Response의 Assertion 정보를 통해서 Session을 설정한다. 또한 HTTP Post 요청의 Body에 존재하는 Relay State를 통해서 User가 처음 접근을 시도했던 Service Provider의 URL을 찾아내고 다시 Redirect 시킨다.
• 12, 13 : User Agent는 Service Provider의 ACS가 설정한 Session을 통해서 Service Provider의 Service에 접근한다.

 

 

 

 

의문1? : ACS url은 요청마다 다른가? 같은곳을 리스폰스 하는가?

의문2? :  ACS url의 역할은 뭔가? 마지막에 왜 바로 Relay state에 있는 처음의 url로 연결시켜주지 않고 acs url을 들르는가? -> SAML Response의 어설션 정보를 통해서 세션을 설정하는 변화가 있다. 그 세션으로 처음의  Relay state url 주소로 접속하는듯

 

 

 

3. SCIM

랜덤 환경변수로 계정 생성 (프로비저닝)

 

프로비저닝이란? 유저가 스스로 안만들어도 자동으로 환경을 생성해주는 것을 의미.

Modern App

IDP

 

 

 

 

 

 

4. 해당 솔루션에서 갖출 수 있는 경쟁력 있는 아이디어

 

모니터링. 사용자 관리툴

공공기관에 적용