Azure AD Graph API vs. Microsoft Graph

Office 365를 쓰고 관리하다 보면 꼭 접하게 되고 알아야 하는 것이 바로

Windows Azure에다가 Windows Azure Active Directory(AAD)라는 녀석인데,

그 개념이나 정의 등등에 관한 것을 얘기하려는 것은 아니니 넘어가고...

여기선 "관리"에 주안점을 두고 얘기해 본다면,

그동안은 Windows PowerShell용 Windows Azure Active Directory 모듈을 설치해서

원격 PowerShell로 Office 365에 연결해서 계정 생성부터 도메인 관리 등등 이것저것 할 수 있었다.

(이것 역시 과도기 서비스인 것이, 연결하는 방법만도 내가 아는 것만 벌써 3번이나 바뀌었다.)

그런데, PowerShell은 콘솔창으로 연결해서 이것저것 작업하기에는 간편하고(?) 아주 강력한데

프로그램으로 만들어서 자동화하려면 아주 골치 아파진다.

대표적인 것이 동시 연결 세션 수 제한인데,

PowerShell로는 한 계정으로 동시에 5개인가(?)까지밖에 연결을 할 수 없는 치명적인 제한이 있다.

그래서 멀티쓰레딩이 필요한 작업 또는 동시에 다수가 연결되는 작업 등에 사용하면

반드시 피(?!)를 보게 된다.

이것을 극복하려면, 그 동안은 Queue를 이용해서 순차적으로 처리하거나,

연결하는 계정 숫자를 충분히 늘려서 적절하게 동시 처리가 되도록 하는 방법 외에는 없었다.

이런 단점을 극복하기 위해 만들어진(것은 아닐 지도 모르겠지만) 서비스가 바로

Azure AD Graph API와 Office 365 Unified API이다.

(Office 365 Unified API가 최근에는 Microsoft Graph로 이름이 바뀌었다.)

>> 참조1: Azure AD Graph API (https://msdn.microsoft.com/en-us/library/azure/ad/graph/howto/azure-ad-graph-api-operations-overview)

>> 참조2: Microsoft Graph (https://graph.microsoft.io/en-us/)

그 동안 PowerShell로만 할 수 있던 작업을 HTTP REST API 방식의 통신으로 처리할 수 있게 되어

프로그램으로 Office 365 자동화를 해야 하는 경우에 아주 좋은 대안이 될 수 있어 보였다.

그래서 검토를 해 봤는데...

그런데, 나온 지는 꽤 됐지만 역시 아직 과도기 서비스이며

계속 조금씩 개념이나 서비스 내용 등이 변경되고 있는 관계로

이것이 정확한 정답이다, 라고 말할 수 있을 것 같지는 않고, 다만

지금까지 써 보고 테스트하면서 파악한 것들을 바탕으로 결정적인 차이점만 간략하게 비교해 봤다.

뭐, 길게 쓸 것 없이 핵심만 짚는다면,

1. Azure AD Graph API: Tenant Name, Tenant ID 기준 서비스

2. Microsoft Graph: 로그인 사용자 기준 서비스

이거다.

Azure AD Graph API는 일부 백그라운드로 자동화 처리가 가능하지만,

Microsoft Graph는 웹 브라우저로 Office 365에 명시적으로 로그인을 한 다음에만 동작한다.

사용하고 있는 URL만 봐도 명확하게 알 수 있다.

Azure AD Graph API가 사용하고 있는 서비스 URL은 https://graph.window.net이고,

실제 사용하는 서비스는 https://graph.window.net/{Tenant ID GUID}/ 하위 URL이 사용되는데

인증 시 사용되는 URL은 https://login.microsoftonline.com/{Tenant Name}/ 이 사용된다.

반면,

Microsoft Graph가 사용하고 있는 서비스 URL은 https://graph.microsoft.com이고,

실제 사용하는 서비스는 https://graph.microsoft.com/v1.0/ 하위 URL이 사용되는데

인증 시 사용되는 URL은 https://login.microsoftonline.com/common 이다.

로그인한 사용자 본인의 정보는 https://graph.microsoft.com/v1.0/me/ 하위 URL이 사용되고

다른 사용자 정보에 접근할 때는 https://graph.microsoft.com/v1.0/users/{Email Address}/ 가 사용된다.

따라서 이상의 두 REST API를 사용하려면

1. 기본적으로 Windows Azure 포털 사이트를 통해 앱을 등록해야 하고,

2. 등록된 앱의 Client ID, Client Secret을 알고 있어야 하며,

3. 해당 앱의 최대 사용 기간(1년 또는 2년) 내에서만 사용이 가능하며,

4. 응용 프로그램 권한 및 위임된 권한을 정확하게 지정해서 사용해야 하는 것까지는 공통인데,

Azure AD Graph API를 사용할 때는 그 외에 Tenant Name, Tenant ID 정보를 추가로 알고 있어야 하고,

Microsoft Graph를 사용할 때는 관리자 접속 계정 정보를 추가로 알고 있어야 한다(로그인해야 하니까).

프로그램으로 자동화하여 관리하려고 할 때,

관리하는 Tenant가 한두 개 정도라면 별 어려움이 없겠지만

수십 개 이상의 Tenant를 관리해야 한다면 그다지 합리적인 선택이라 보기 어렵지 않을까... 싶다.

일일이 DB화 한 다음 1년~2년마다 갱신해 주어야 간신히 관리가 될 테니 말이다.

게다가 관리자 권한 위임이 필요한 경우에는 또 명시적인 로그인도 해야 하고... 아무튼 복잡하고 어렵다.

PowerShell은 관리자 접속 계정만 알면 끝인데 말이다.

뭐, 서비스 목적에 따라 다르긴 하겠지만.

일단 여기까지.

### 참고: Azure AD Graph API로 오류 없이 사용자를 삭제하는 방법 ###

Azure AD Graph API를 이용해서 사용자 계정을 생성하거나 라이선스를 할당하는 등의 작업은 명시적인 로그인 없이 앱 권한 만으로도 가능하다. 그러나 생성된 사용자 계정을 삭제한다거나 수정하려고 하면 "Insufficient privileges to complete the operation" 오류가 발생하면서 실행이 거부된다.

이것을 정상 실행되도록 하는 방법이 있다: 앱을 회사 관리자로 지정하면 된다. 엥???? 무슨 소리냐고?

회사 관리자로 지정할 수 있는 것은 사용자뿐만이 아니라 서비스도 가능하다는 소리다.

아래 순서대로 실행하면 된다.

# 1. 앱 서비스 목록에서 AppPrincipalId를 조회한다. 또는 Client ID를 알고 있으면 그거다.

Get-MsolServicePrincipal | ft DisplayName, AppPrincipalId -AutoSize

# 2. 해당 앱을 찾는다.

$ClientIdWebApp = '6c526932-0c76-47ef-bda3-1fa5a7562ab3'

$webApp = Get-MsolServicePrincipal -AppPrincipalId $ClientIdWebApp

# 3. Add-MsolRoleMember 명령으로 “Company Administrator” 역할에 해당 앱을 등록한다.

Add-MsolRoleMember -RoleName "Company Administrator" -RoleMemberType ServicePrincipal -RoleMemberObjectId $webApp.ObjectId