FIDO에 관한 간단한 소개는 [한국정보인증 FIDO 홈페이지]를 참고하세요.

FIDO 스펙에 관한 정보는 [FIDO Alliance]를 참고하세요.

FIDO는 규격이기 때문에 이것을 실제로 어플리케이션과 서버에 적용하려면 해당 규격을 충족하는 프로그램을 실제로 작성해야 한다.

이에 작년부터 삼성과 ETRI를 비롯해 많은 회사에서 자체적으로 FIDO 기반 서버와 앱을 만들어 인증을 해왔는데, eBay에서 최근에 자신들이 만든 프레임워크를 [Github]에 공개했다.

따라서 본인은 eBay에서 공개한 FIDO 프레임워크의 구조와 특징을 분석해 보기로 하였다.


FIDO UAF Demo Server

[FIDO UAF Demo Server 저장소]

FIDO UAF Demo Server는 앞에서 분석한 UAF Core의 코드를 이용해 실제로 구동 및 이용이 가능한 서버를 구현한 것이다. Java로 작성되었고 SUN의 [Jersey 서버 프레임워크]를 이용해 서버를 만들었다. 종속성은 아래와 같으며, GSON을 이용하는 것과 별개로 데모 서버에선 Jersey가 별도로 제공하는 JSON 라이브러리를 이용해 특정 작업을 수행하는 것 같다. 또한 앞서 분석한 UAF Core를 직접 참조하여 이용하는 것을 확인할 수 있다.

패키지의 구조는 아래와 같다. 구동 파트는 org.ebayopensource.fidouaf.res에 있는 Hello와 FidoUafResource에 있다. Hello는 단순 테스트용 서버이고 FidoUafResource는 실제 RP 서버와 FIDO 서버 페이지를 제공한다.

uafserver

아래는 각 서브패키지에 관한 설명이다.

  • “facets” 패키지엔 각종 FacetID를 저장하기 위해 만든 튜플들이 들어있다.
  • “RPserver.msg” 패키지엔 각종 메시지(Reg, Dereg, Auth)를 주고 받을 때 쓰기 위한 튜플(컨테이너)들이 들어있다. TokenType와 Token이 정의되어 있는 것이 특징이라 할 수 있는데, 이 TokenType은 아래와 같이 enum 자료형으로, 로그인 유형을 담는 것으로 보인다.

  • “stats” 패키지엔 Dash라는 클래스가 있는데, 이것은 명령(Auth, Reg, Dereg)이 처리된 내역을 해시맵으로 최대 100개까지 저장해주는 역할을 한다. 로그 저장용 클래스라고 보면 된다.
  • “res” 패키지가 바로 실질적으로 표면적인 서버를 구현한 것이라 보면 된다. “res.util” 패키지에는 Notary, Storage 인터페이스를 구현한 클래스가 있으며 Response 메시지를 처리하거나 Dereg Request를 처리하는 클래스가 존재한다. FetchRequest 클래스는 AppID와 AAID를 집어넣으면 특정 Request를 수행할 수 있게 도와주는 중계자 역할을 한다. 아래는 사용 예이다.

FidoUafResource.java

FidoUafResource는 FIDO Demo Server의 표면적인 부분(URL을 타고 접근할 수 있는 부분 등)과 내부적인 부분(UAF Core를 기반으로 만들어진 처리기 부분)을 실제로 이어주는 클래스이다. 아래는 FIDO Demo Server의 클래스 다이어그램인데 여기서도 FidoUafResource가 다른 클래스들을 생성하고 이용하는 것을 확인할 수 있다.

diagram

구조 자체는 단순하다. Jersey에서 웹페이지를 제공하는 방법이 JSP와 비슷하기 때문에 처음 보는 사람도 금방 이해할 수 있을것이다.

위는 등록된 유저들을 리스트로 보여주는 함수/페이지이다.

위는 특정 유저를 등록하는 함수/페이지이다. {username} 부분을 가져와 유저로 등록하는 걸 보면 중괄호로 묶어둔 부분은 동적으로 바뀔 수 있다는 뜻인 것 같다.

위는 유저 삭제 요청을 받는 함수/페이지이다. POST를 이용하는 경우엔 함수에 인자를 선언하여 POST값을 가져오는 듯 하다.

정리하자면 FIDO Demo Server는 위와 같은 방식들로 각종 페이지를 제공하고 요청을 처리하게 만들었다. 아래는 정의된 함수와 변수 목록이다.

FidoUafResource

본 데모 서버의 가장 큰 특징으로는 RP서버와 FIDO서버의 기능이 섞여있다는 것이다. 테스트 용도로 만들어졌기 때문에 그런 것으로 보이지만 일반적으론 RP 서버와 FIDO 서버는 분리하는 것이 원칙이다. 또한 DB 엔진을 이용하지 않기 때문에 신용하는 FacetID 목록, 허용한 AAID 등은 모두 클래스 내에 하드코딩되어있다. 유저 정보도 서버가 실행 중일 때에만 해시맵에 넣고 관리하는 것으로 파악된다.

만약 이 라이브러리를 기반으로 독자적인 서버를 구축하고자 한다면 DB와 연동하는 부분은 따로 구현해야 할 것이다.

지금까지 FIDO Demo Server를 살펴보았습니다. 역시 깔끔한 설계가 돋보입니다.

답글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다.