* 본 포스팅은 하이퍼레저 패브릭 docs를 번역한 내용으로, 번역 과정에서 잘못된 부분이 있을 수 있습니다.

상세 내용은 하단 링크를 참조 부탁드리며, 잘못된 내용에 대한 피드백은 언제든 환영합니다 : ) 

https://hyperledger.github.io/composer/latest/tutorials/google_oauth2_rest

 

Using Google OAUTH2.0 with a Composer REST server | Hyperledger Composer

open --> Using Google OAUTH2.0 with a REST server This tutorial provides an insight into configuring the OAUTH2.0 authentication strategy (eg. for Google, Facebook, Twitter authentication providers etc) to authorize access to resources in a configured REST

hyperledger.github.io

이 튜토리얼은 구글, 페이스북, 트위터 등에서 사용하고 있는 OAUTH 2.0 인증 방식을 이용하는 방법에 대해 설명합니다. 이 방법을 이용해 REST 서버 객체의 리소스에 대한 접근 권한을 부여하거나 블록체인 네트워크의 end user가 배포된 스마트 컨트랙트나 비즈니스 네트워크와 상호작용할 수 있도록 할 수 있습니다. 개요도는 아래 그림에 나와 있고, 인증 플로우에 대해 더 자세히 나타낸 그림은 더 아래쪽에 있습니다. 튜토리얼을 진행하면서 REST 서버를 다중 사용자 모드로 실행시키고, REST API를 통해 리소스에 접근하는 여러 블록체인 id로 심플 Trade 네트워크와 상호작용하는 테스트를 진행합니다. 튜토리얼을 진행하기 위해 Google 계정 및 권한 설정을 해야 합니다. (이 작업을 진행하기 위해서는 appendix를 참고하세요. 그리 오래걸리지 않습니다.) 또 최소한 튜토리얼에 나오는 ID와 메타데이터를 사용해야 합니다. 기본 블록체인 네트워크로는 하이퍼레저 컴포저를 사용합니다.

참고: 우리는 아래 링크 내 Step 3 'Setting up your IDE'에 나온 'Development Fabric' 네트워크를 사용합니다.

https://hyperledger.github.io/composer/latest/installing/development-tools.html

불러오는 중입니다...

다양한 Passport 전략이 있습니다. 비즈니스 조직 관점에서 SAML, JSON Web Tokens (JWT), LDAP 같은 기업 전략은 확실히 적합합니다. (예: 조직 내 Active Directory server) 우리는 이 튜토리얼에서 Google+ API를 사용한 인증 방식을 제공합니다. 이 방식은 구글 계정을 가진 누구든지 쉽게 사용할 수 있으며 (어떻게 하는지는 Appendix를 참고하세요.) 서비스 환경설정을 할 수 있고, 미들웨어를 미리 설치하는 것에 대한 걱정 없이 이 튜토리얼을 진행할 수 있습니다.

 

OAUTH2.0은 실제로는 'authorization protocol' 이지만 'delegated authentication sheme' 처럼 사용됩니다. authentication은 보통 개인 credential을 이용해 신원을 확인하는 것을 의미합니다. 반면 여기서 사용되는 OAUTH2.0 authenticationdms 'delegate' authentication sheme로 사용됩니다. 백그라운드로 확장할 수 있는 다양한 '역할' 들이 있습니다. 컴포저 REST 서버의 역할은 Google+ API OAuth2.0 sheme에 의해 보호되는 비즈니스 네트워크 리소스에 대한 접근을 제공하는 것입니다. 리소스 소유자는 우리가 설정한 (appendix에 나오듯이) Google+ API 사용자 계정이며, 이 소유자의 역할은 클라이언트 애플리케이션에 동의(혹은 기타)를 부여하는 것입니다. Google+ authorization 서버는 리소스 소유자에게 동의를 요청하고 REST 클라이언트 (예: 웹 클라이언트 애플리케이션)에 access token을 발행해서 보호된 리소스에 접근할 수 있게 해줍니다. 더 작은 API 제공자도 동일한 애플리케이션이나 authorization 서버 및 리소스 서버용 Google+의 URL 공간을 사용할 수 있습니다. 이는 즉, 웹 애플리케이션 사용자 (비즈니스 네트워크에 접근하기 위해 REST API를 사용하는) 가 들어오면, 이 사용자는 사전등록을 위해 별도로 아무것도 하지 않아도 됨을 의미합니다. 애플리케이션 사용자는 구성된 클라이언트 애플리케이션에서 동의를 얻습니다. (OAUTH2.0 플로우가 구성되지 않아도) 이 튜토리얼에서 우리는 REST API를 사용하기 위해 브라우저를 사용하고 어떻게 이 authentication 플로우가 실제로 동작하는지 확인합니다.

access key는 다음 동의에 따라 부여됩니다. token이 클라이언트가 OAuth2.0에 의해 보호되고 있는 API에 접근하는 것을 허락해줍니다. OAuth2.0에서 이 access token은 "bearer tokens"라고 불리며 정보에 접근할 때 별도의 signature나 cryptography없이 단독으로 사용될 수 있습니다. 게다가 access token은 사용자 웹 브라우저의 로컬 저장소 내 쿠키에 저장됩니다. 사용자가 연속적인 요청을 수행하면 access token은 쿠키에서 검색할 수 있으며, 사용자를 reauthenticating할 필요없이 이 access token은 유효합니다. 

 

REST 서버는 MongoDB를 사용해 비즈니스 네트워크 카드 (네트워크에 연결하기 위해 필요한)를 유지하도록 구성됩니다. 보통 조직은 아래에 설명된 여러 개의 REST 서버 Docker image를 실행하고 MongoDB 사본같은 고가용성의 영구 저장소를 구성합니다. 고가용성을 위한 구성 요소들은 애플리케이션 사용자가 REST에 배포된 비즈니스 네트워크에 대한 접근 권한을 잃지 않고도 관리자가 REST 서버 객체를 중단, 재시작 혹은 제거할 수 있도록 해줍니다.

 

이 튜토리얼은 권한이 없는 사용자로 수행해야 합니다. (sudo나 그 이상의 권한이 필요하지 않습니다.)

 

Step 1: Set up the Persistent DB Credentials Data Stor using MongoDB

앞서 언급했듯이, 우리는 적절한 비즈니스 네트워크 카드가 REST wallet으로 import되면 credential을 영구저장소에 저장합니다.

 

Start the MongoDB Instance

  1. 터미널을 열어서 아래 명령어를 실행하세요.
docker run -d --name mongo --network composer_default -p 27017:27017 mongo

docker image가 다운로드되는 화면이 나오고 SHA256 메시지가 출력될 것입니다. MongoDB docker 컨테이터 객체가 시작됩니다. 여기서는 REST 서버와의 간단한 네트워크 접속을 위해 --network composer_default를 사용하는 것이 중요합니다.

 

Step 2: Build the REST Server Docker Image with OATUH2.0 module

  1. $HOME 디렉토리에서 dockettmp라는 임시 디렉토리를 생성하고 그 곳으로 이동하세요.
cd $HOME ; mkdir dockertmp
cd dockertmp
  1. 임시 폴더에서 Dockerfile이라는 docker 파일을 생성하고 아래 내용을 순차적으로 붙여넣으세요. (RUN과 npm 라인의 백슬래쉬를 포함해서 - 계속 이어진다는 문자열입니다.)
FROM hyperledger/composer-rest-server
RUN npm install --production loopback-connector-mongodb passport-google-oauth2 && \
npm cache clean --force && \
ln -s node_modules .node_modules

이 Docker 파일은 docker image를 /hyperledger/composer-rest-server에 위치시키고 두 개의 npm모듈을 추가적으로 설치합니다:

  • loopback-connector-mongodb : 이 모듈은 LoopBack 프레임워크를 위한 MongoDB 커넥터를 제공하고, REST 서버가 MongoDB를 데이터 소스로 사용할 수 있게 해줍니다. 더 자세한 설명은 다음 링크를 참고하세요. 
    https://www.npmjs.com/package/loopback-connector-mongodb
  • passport-google-oauth2 : 이 모듈은 Google+ 계정을 사용해 REST 서버에 authenticate할 수 있게 해줍니다. 더 자세한 설명은 다음 링크를 참고하세요.
    https://www.npmjs.com/package/passport-google-oauth-2 

 

  1. Dockerfile이 있는 폴더에서 커스텀 Docker REST Server 이미지를 생성하세요.
docker build -t myorg/composer-rest-server .

-t 플래그에 주어진 파라미터는 이 Docker 이미지의 이름을 지정합니다. 우리는 여기서 'myorg/composer-rest-server라고 이름을 붙입니다.

 

마지막 2줄의 'Successfuly built'를 포함해 아래와 같은 결과를 확인할 수 있습니다.

docker build -t myorg/composer-rest-server .
Sending build context to Docker daemon  4.203GB
Step 1/2 : FROM hyperledger/composer-rest-server
 ---> e682b4374837
Step 2/2 : RUN npm install --production loopback-connector-mongodb passport-google-oauth2 &&     npm cache clean  --force &&     ln -s node_modules .node_modules
 ---> Running in 7a116240be21
npm WARN saveError ENOENT: no such file or directory, open '/home/composer/package.json'
npm WARN enoent ENOENT: no such file or directory, open '/home/composer/package.json'
npm WARN composer No description
npm WARN composer No repository field.
npm WARN composer No README data
npm WARN composer No license field.

+ passport-google-oauth2@0.1.6
+ loopback-connector-mongodb@3.4.1
added 114 packages in 7.574s
npm WARN using --force I sure hope you know what you are doing.
 ---> a16cdea42dac
Removing intermediate container 7a116240be21
Successfully built a16cdea42dac
Successfully tagged myorg/composer-rest-server:latest

INFO: 위처럼 'npm warn messages'가 출력되어도 괜찮습니다. 이는 무시해도 좋습니다.

  1. 마지막으로 하나 윗 폴더로 이동합니다.
cd ..

 

Step 3: Define Environment variables for REST Server instance configuration

  1. $HOME 디렉토리에 envvars.txt파일을 생성하고 아래 환경설정 내용을 붙여넣으세요. 아래 내용 중 cliend ID와 clientSecret은 본인의 Google API+ 클라이언트 정보를 입력해야 합니다. (Appendix에 나온 것 처럼)
COMPOSER_CARD=restadmin@trade-network
COMPOSER_NAMESPACES=never
COMPOSER_AUTHENTICATION=true
COMPOSER_MULTIUSER=true
COMPOSER_PROVIDERS='{
    "google": {
        "provider": "google",
        "module": "passport-google-oauth2",
        "clientID": "312039026929-t6i81ijh35ti35jdinhcodl80e87htni.apps.googleusercontent.com",
        "clientSecret": "Q4i_CqpqChCzbE-u3Wsd_tF0",
        "authPath": "/auth/google",
        "callbackURL": "/auth/google/callback",
        "scope": "https://www.googleapis.com/auth/plus.login",
        "successRedirect": "/",
        "failureRedirect": "/"
    }
}'
COMPOSER_DATASOURCES='{
    "db": {
        "name": "db",
        "connector": "mongodb",
        "host": "mongo"
    }
}'

여기서 정의한 환경변수는 우리가 Google OAuth2와 영구 데이터 소스로 MongoDB를 사용한 authentication으로 다중 사용자 서버를 사용한다는 것을 의미합니다. 

 

첫 번째 라인은 네트워크를 시작할 비즈니스 네트워크 카드 이름, 즉 비즈니스 네트워크에 정의된 특정 REST 관리자를 의미합니다. 또한 우리는 이 환경설정에서 REST 서버가 사용할 데이터 소스와 authentication provider를 정의합니다. 이것들은 각각 COMPOSER_DATASOURCES와 COMPOSER_PROVIDERS 변수입니다.

 

Step 4: Load environment variables in current terminal and launch the persistent REST Server instance

  1. 환경 변수를 포함해 방금 생성한 envvars.txt 파일과 동일한 경로에서 아래 커맨드를 실행하세요.
source envvars.txt

INFO 커맨드의 결과물이 아무것도 출력되지 않을 것입니다. envvars.txt에 문법 오류가 발생했다면 에러 메시지가 출력될 것입니다.

  1. 아래와 같이 "echo" 커맨드를 두 번 사용해서 환경변수들이 실제로 잘 셋팅되었는지 확인합니다.
echo $COMPOSER_CARD
echo $COMPOSER_PROVIDERS

 

Step 5: Deploy the sample Commodities Trading Business network to query from REST client

  1. 아직 Trade-network를 위한 trade-network.bna 파일을 다운로드 하지 않았다면 https://composer-playground.mybluemix.net/ 에서 다운받으세요. 버전 넘버가 이 페이지에 명시된 것과 동일한지 확인하세요.
  2. 플레이그라운드에서 admin 계정으로 네트워크에 접속하고 trade-network.bna파일을 export한 다음 home 디렉토리에 복사하세요.

  1. 비즈니스 네트워크를 배포하기 위해 피어에 비즈니스 네트워크를 설치하세요.
composer network install --card PeerAdmin@hlfv1 --archiveFile trade-network.bna

위 커맨드를 실행한 후 출력되는 버전을 확인하세요. 이 버전은 다음 명령어에서 비즈니스 네트워크를 시작하기 위해 사용되는 버전입니다.

 

아래 커맨드에서 <business_network_version>을 이전 install 명령어에서 출력된 버전 번호로 변경하고 커맨들를 실행하세요.

composer network start --card PeerAdmin@hlfv1 --networkName trade-network --networkVersion <business_network_version> --networkAdmin admin --networkAdminEnrollSecret adminpw --file networkadmin.card

Commodities Trading Business Network는 admin으로 시작되어야 하며 networkadmin.card 파일이 생성되어야 합니다.

  1. 다음으로 비즈니스 네트워크 카드를 import하고 해당 카드를 wallet의 certs에 다운로드합니다.
composer card import -f networkadmin.card
composer network ping -c admin@trade-network

연결이 성공적으로 연결되었음을 확인할 수 있습니다. 이제 우리는 비즈니스 네트워크를 배포할 준비가 되었습니다.

 

Step 6: Create the REST server Administrator for the Composer REST server instance

  1. restadmin이라는 REST 관리자 id와 관련된 비즈니스 네트워크 카드 (REST 서버를 시작하는데 사용될) 를 생성하세요.
composer participant add -c admin@trade-network -d '{"$class":"org.hyperledger.composer.system.NetworkAdmin", "participantId":"restadmin"}'
composer identity issue -c admin@trade-network -f restadmin.card -u restadmin -a "resource:org.hyperledger.composer.system.NetworkAdmin#restadmin"
  1. 카드를 import하고 테스트 해보세요.
composer card import -f  restadmin.card
composer network ping -c restadmin@trade-network
  1. 우리는 특정 네트워크 IP정보를 가진 다른 위치에 REST 서버를 호스팅하기 때문에 connection.json파일을 업데이트 해야합니다. 그래야 docket hostname (영구 REST 서버 객체 내에 있는) 이 서로의 IP 주소를 확인할 수 있습니다. 

아래의 한 줄은 'localhost' 주소를 docker hostname으로 대체하고 REST 관리자 카드에 들어가는 새로운 connection.json을 생성합니다. 우리는 이 커스텀한 connection.json  파일을 튜토리얼 끝 부분에 있는 OAUTH2.0 REST authentication 을 테스트할 때 사용합니다. 빠르게 hostname을 변경하기 위해 hostname을 복사 붙여넣기 한 다음 $HOME 디렉토리에서 아래 한 줄짜리 명령어를 실행하세요.

sed -e 's/localhost:7051/peer0.org1.example.com:7051/' -e 's/localhost:7053/peer0.org1.example.com:7053/' -e 's/localhost:7054/ca.org1.example.com:7054/'  -e 's/localhost:7050/orderer.example.com:7050/'  < $HOME/.composer/cards/restadmin@trade-network/connection.json  > /tmp/connection.json && cp -p /tmp/connection.json $HOME/.composer/cards/restadmin@trade-network/ 

 

Step 7: Launch the persistent REST server instance

  1. REST 서버 객체를 시작하기 위해 아래 docker 명령어를 실행하세요. (restadmin 비즈니스 네트워크 카드를 사용합니다.)
docker run \
-d \
-e COMPOSER_CARD=${COMPOSER_CARD} \
-e COMPOSER_NAMESPACES=${COMPOSER_NAMESPACES} \
-e COMPOSER_AUTHENTICATION=${COMPOSER_AUTHENTICATION} \
-e COMPOSER_MULTIUSER=${COMPOSER_MULTIUSER} \
-e COMPOSER_PROVIDERS="${COMPOSER_PROVIDERS}" \
-e COMPOSER_DATASOURCES="${COMPOSER_DATASOURCES}" \
-v ~/.composer:/home/composer/.composer \
--name rest \
--network composer_default \
-p 3000:3000 \
myorg/composer-rest-server

이 명령어는 Docker 컨테이너의 ID를 출력할 것입니다. (예: 690f2a5f10776c15c11d9def917fc64f2a98160855a1697d53bd46985caf7934)

그리고 REST 서버가 실제로 시작되었는지 확인합니다.

  1. 컨테이너에 모두 ok가 떴는지 확인하세요. 아래 명령어를 통해 확인할 수 있습니다.
docker ps |grep rest
docker logs rest

로그 끝부분에서 "Browe your REST API at http://localhost:3000/explorer"를 찾고 거기에 없다면 위의 단계를 반복하세요.

 

Step 8: Test the REST APIs are protected and require authorization

  1. 브라우저를 열어서 http://localhost:3000/explorer 를 입력해 REST API를 실행하고 사용가능한 API를 확인하세요.

INFO: 관리자 id인 restadmin이 초기값으로 사용됩니다. REST 서버는 restadmin이라는 id를 특정 id, 예를 들어 jdoe가 REST client wallet에 셋팅될 때까지 사용합니다.

  1. "System: general business network methods" 섹션으로 이동하세요.

  1. "/system/historian" API로 이동해 "Try it out!" 버튼을 클랙하세요.

우리는 REST 서버 접근을 보호하기 위해 Google+ passport OAUTH2.0 authentication을 사용하도록 설정했기 때문에 아마 Authorized error가 출력될 것입니다. OAUTH2.0 authentication을 통해 한번 authentication이 완료되면 브라우저의 REST API는 Trade Commodity 비즈니스 네트워크와 상호작용할 수 있습니다. (즉, 비즈니스 카드가 import되면)

 

Step 9: Create some Participants and Identities for testing OAUTH2.0 authentication

  1. 이제 비즈니스 네트워크와 상호작용할 수 있느지 테스트하기 위해 특정 참가자 집합과 id를 만들어야 합니다. REST서버는 다중 사용자 모드에서 여러 명의 REST 클라이언트를 처리할 수 있습니다. 우리는 composer CLI 명령어를 사용해 아래와 같이 참가자 및 id를 추가할 것입니다. 첫 번째 이름은 Jo Doe입니다.
composer participant add -c admin@trade-network -d '{"$class":"org.example.trading.Trader","tradeId":"trader1", "firstName":"Jo","lastName":"Doe"}'
composer identity issue -c admin@trade-network -f jdoe.card -u jdoe -a "resource:org.example.trading.Trader#trader1"
composer card import -f jdoe.card
  1. 우리는 이 id를 영구 REST docker 컨테이너에서 테스트할 것이기 때문에, 우리는 hostname을 docker가 인식할 수 있는 hostname으로 변경해야 합니다. 아래 한 줄은 이 동작을 빠르게 수행할 수 있게 해줍니다.
sed -e 's/localhost:7051/peer0.org1.example.com:7051/' -e 's/localhost:7053/peer0.org1.example.com:7053/' -e 's/localhost:7054/ca.org1.example.com:7054/'  -e 's/localhost:7050/orderer.example.com:7050/'  < $HOME/.composer/cards/jdoe@trade-network/connection.json  > /tmp/connection.json && cp -p /tmp/connection.json $HOME/.composer/cards/jdoe@trade-network/ 
  1. 우리는 어디서든 import해서 사용하기 위해 카드를 파일로 export해야 합니다. 즉, 우리가 사용할 카드는 브라우저 클라이언트의 wallet으로 import해야 합니다. 그러므로 여기서 우리는 jdoe의 초기 비즈니스 네트워크 카드를 삭제합니다.
composer card export -f jdoe_exp.card -c jdoe@trade-network ; rm jdoe.card
  1. Ken Coe(kcoe) 라는 참가자를 위해 위 단계를 반복하세요. trader2 참가자를 생성하고 kcoe라는 id를 반복합니다. 
composer participant add -c admin@trade-network -d '{"$class":"org.example.trading.Trader","tradeId":"trader2", "firstName":"Ken","lastName":"Coe"}'
composer identity issue -c admin@trade-network -f kcoe.card -u kcoe -a "resource:org.example.trading.Trader#trader2"
composer card import -f kcoe.card

sed -e 's/localhost:7051/peer0.org1.example.com:7051/' -e 's/localhost:7053/peer0.org1.example.com:7053/' -e 's/localhost:7054/ca.org1.example.com:7054/'  -e 's/localhost:7050/orderer.example.com:7050/'  < $HOME/.composer/cards/kcoe@trade-network/connection.json  > /tmp/connection.json && cp -p /tmp/connection.json $HOME/.composer/cards/kcoe@trade-network/ 

composer card export -f kcoe_exp.card -c kcoe@trade-network ; rm kcoe.card

이제 카드는 import되어서 REST 클라이언트 (즉, 웹브라우저) 에서 사용됩니다.

 

Step 10: Authenticating from the REST API Explorer and testing using specific identities

  1. http://localhost:3000/auth/google 로 이동하세요. 이 주소는 Google Authentication consent 화면으로 바로 이동하게 해줍니다.

  1.  아래 credential을 이용해 로그인하세요. (아래의 예는, 권고대로 튜토리얼 Appendix에 지침에 따라 직접 설정해야 합니다.)

- Email: composeruser01@gmail.com

- Password:

  1. Google에 의해 authenticated되고 REST 서버 (http://localhost:3000/explorer)로 돌아가 좌측 상단에 access token 메세지를 확인할 수 있습니다. 토큰을 보기 위해 'Show' 버튼을 클릭하세요.

REST 서버는 Google+ OAUTH2.0 서비스 (이 프로젝트/클라이언트 범위에서 정의하고 OAUTH2.0 서비스에 대한 Appendix에서 설정한 client credential을 사용) 로 인증되기 때문에, 블록체인 id 혹은 Trade Commodity 비즈니스 네트워크와 상호작용하기 위해 비즈니스 네트워크 카드를 사용하는 관점에서 보면 우리는 사실 아무것도 하지 않았습니다. 우리는 다음으로 이전에 생성한 jdoe 라는 id를 사용할 것입니다.

 

Step 11: Check the Default Wallet and Import the card and set a default Identity

  1. 먼저, Wallets 내 REST endpoint로 가서 GET 동작을 수행해 wallet의 내용을 각져오세요. wallet이 아무런 비즈니스 네트워크 카드도 가지고 있지 않음을 확인하세요. [ ] 와 같이 텅 비어 있어야 합니다.
  2. REST client wallet에 id를 추가해야합니다. 그리고 이 id를 API 를 호출하는 기본값으로 설정해야 합니다. /Wallets 내 POST로 이동하세요. 이는 /Wallets/Import endpoint라고 불립니다.
  3. jode_exp.card를 import하기 위해 선택하세요. 그리고 카드의 이름을 jdoe@trade-network로 입력한 후 'Try it Out'을 클릭하세요.

  1. 스크롤을 내리세요. HTTP Status code가 204 (요청 성공) 이어야 합니다.
  2. 다음으로 GET /wallest 로 돌아가세요.

이제 jdoe@trade-network 가 wallet에 import된 것을 확인할 수 있습니다. default property의 값이 true임을 확인하세요. 이는 이 비즈니스 네트워크 카드가 Commodity Trading 비즈니스 네트워크와 상호작용할 때 기본값으로 사용됨 (다른 것으로 변경하기 전까지) 을 의미합니다.

Step 12: Test interaction with the Business Network as the default ID jdoe

  1. System REST API Methods 섹션으로 이동해 /GET/System/Historian 섹션을 클릭하세요.

  1.  'Try it Out'을 클릭하세요. Historian Registry에서 블록체인 id인 'jdoe'와 트랜잭션 집합을 확인할 수 있습니다.

  1. Trader 로 이동해 /GET Trader endpoint를 확장하고 'Try it Out' 을 클릭하세요.

authenticated session에서 jdoe로 REST 서버와 상호작용할 수 있는지 확인합니다.

이제 현재 생성된 모든 Trader 참가자를 확인할 수 있습니다. ACL이 설정되면 어느 것을 볼 수 있는지에 대한 제약사항이 설정됩니다. (현재 샘플 네트워크에는 적용되지 않지만, ACL 규칙은 ACL tutorial에서 볼 수 있습니다.) 비즈니스 네트워크에 접근하는 REST API가 플레이그라운드, JS APIs, CLI 등 같은 비즈니스 네트워크와 상호작용하는 다른 것들과 마찬가지로 이제 접근 제어를 할 수 있습니다. 

  1.  POST /wallet/import 로 돌아가서 kcoe_exp.card를 import하고 이름을 kcoe@trade-network로 설정한 후 'Try it Out'를 클릭하세요. 성공적인 응답 (204) 을 받아야 합니다.

  1. 하지만, 이 카드를 사용하기 위해서는 Wallet 의 default카드로 설정해야 합니다. POST /wallet/name/setDefault/로 이동해 kcoe@trade-network 를 default 카드 이름으로 설정하고 Try it Out을 클릭하세요. 이제 디폴트 카드가 되었습니다.

  1. Trader 로 돌아가 /GET Trader endpoint를 확장한 뒤 'Try it Out'을 클릭하세요. 우리는 지금 다른 카드 이름을 사용하고 있으며 여전히 인증을 받으면 REST 서버와 상호작용할 수 있다는 것을 확인해야 합니다.

 

Conclusion

이것으로 튜토리얼을 마칩니다. 여기서는 클라이언트 기반 Google OAUTH2.0 authentication 서비스를 어떻게 구성하고 클라이언트 애플리케이션을 인증할 수 있는지, 또 매 요청마다 인증하지 않고 보호된 리소스 서버 (REST 서버 객체) 와 상호작용하는 동의를 제공할 수 있는지에 대해 살펴보았습니다. 게다가 REST 서버는 다중 사용자 모드로 운영되어 여러 블록체인 id가 동일한 클라이언트 세션에서 토큰 만료 시간 등에 따라 배포된 Commodity Trading 비즈니스 네트워크와 상호작용할 수 있었습니다.

 

아래 appendix는 이 튜토리얼에서 Google Authentication scheme가 어떻게 설정되었는지 알려줍니다.


<Appendix - Google+ Authenticaton Configuration & Setup>

아래 appendix는 클라이언트 애플리케이션을 인증하기 위한 OAUTH2.0 authentication 서비스를 어떻게 생성하는지 설명합니다. 이 단계는 크게 아래 4가지로 구성됩니다.

  1. Google API+ 프로젝트 생성
  2. Credentials Service Account 생성
  3. OAuth2.0 Consent 생성
  4. Credentials Service Account를 위한 OAuth2.0 Client ID credential 생성

Step A1: Create Google API+ Project

  1. 구글 계정에 로그인하세요. 구글 계정이 없다면 구글 계정을 하나 생성하세요.
  2. 다음 페이지로 들어가세요. (https://console.developers.google.com/apis/)

아래와 같은 화면을 볼 수 있을 것입니다. 검색창에 Google+를 입력해 출력된 Google+ API 아이콘을 클릭하세요.

  1. Google+ APIs를 클릭해 활성화하세요.
  2. 아직 프로젝트를 갖고 있지 않다면 API를 사용하기 위한 프로젝트를 생성해야 합니다. 'Create Project'를 클릭하세요.
  3. 이름을 입력해야 합니다. 'GoogleAuth'라고 입력하고 이 경우에는 ProjectID를 기록해둡니다. 여기서는 proven-caster-19547로 표시되며 이는 나중에 사용됩니다.
  4. 프로젝트를 생성한 후 Google+ API 페이지로 다시 돌아가세요. 이제 프로젝트 이름을 볼 수 있고 'Enable' 옵션을 확인할 수 있습니다. 'Enable'을 클릭하세요.

Step A2: Create Credentials Service Account

  1. 서비스를 활성화 시키면 이 서비스를 사용하기 위한 Service Account Credentials를 생성할 수 있습니다. 'Create Credentials'를 클릭하세요.
  2. 어떤 종류의 credential이 필요한지 묻는 몇 가지 질문이 나옵니다. 아래 스크린샷을 참고해 질문에 답하세요. 'Google+ API', 웹서버 (예: Node js. Tomcat) , 애플리케이션 데이터, Engine사용 안함 등을 선택하세요.
  3. What credentials do I need를 선택하세요.

  1. 다음으로 Credentials service account를 설정합니다. 이름은 'GoogleAuthService'로 합니다. 드롭다운 메뉴에서 'Project'를 선택하고 Owner 역할과 JSON 타입을 선택합니다.
  2. 'Get your Credentials'를 선택합니다. 이는 JSON 포맷의 service credential을 다운로드할 것입니다. 이를 안전한 장소에 저장하세요.

  1. JSON 파일을 애플리케이션 credential과 함께 저장합니다. credential을 다운로드 받은 후 사이트는 credentials 홈페이지로 돌아갈 것이며 새로운 서비스 account key를 볼 수 있습니다.

Step A3: Create OAUTH2.0 Consent

  1. 'OAuth consent screen' 탭으로 이동하세요. 'Google Auth REST OAUTH2 service' 같은 'product name'이 필요할 것입니다. 요청에 대한 권한에 동의할 때 배너창이 나타납니다. (즉, 우리가 main tutotial에서 REST 클라이언트로 테스트할 때 ) 그리고 email주소를 입력한 후 'Save'를 클릭하세요.

OAuth consent 화면은 튜토리얼의 사용자가 Google Auth REST Service로 인증할 때 볼 수 있는 화면입니다.

Step A4: Create OAuth2.0 Client ID credentials for the Credentials Service Account

  1. 'Credentials' 탭으로 돌아가서 'Create Credentials'를 클릭하고 드롭다운 메뉴에서 'OAuth Client ID'를 선택하새요.
  2. 'Web Applicaton'을 선택하고 'Web Client 1' 같은 샘플 이름을 지정하세요.
  3. 'Authorised Javascript Origins' 섹션에 아래 URI를 추가하세요. 이것은 클라이언트 애플리케이션, 즉 REST 서버입니다. (http://localhost:3000)
  4. 우리는 아래에 'Authorized Redirect URIs'를 추가해야 합니다. 이것은 인증된 세션이 Google+ OAUTH2.0 authentication service에서 동의를 얻은 후 리다이릭팅되는 곳입니다. 컴포저 REST 서버 환경변수 (특히 envvars.txt 파일 내 COMPOSER_PROVIDER 변수) 에 구성한 것과 콜백함수가 매칭될 것입니다.

'Autorized Redirect URIs' 에서 아래 URIs를 autorised URIs로 추가하세요. 참고: 아래 URI를 복사 붙여넣기 하는것이 가장 좋습니다. 그리고 브라우저에서 각 라인별로 ENTER를 입력하세요. URI 라인 편집기는 간혹 입력 중에 내용을 지울 수 있기 때문입니다. (예: URI입력시 잠시 멈추는 경우)

http://localhost:3000/auth/google
http://localhost:3000/auth/google/callback

그리고 나서 하단의 'Create' 버튼을 클릭하세요.

Client ID와 Secret을 저장하라는 메시지가 표시됩니다. 이 두 가지를 복사해서 저장하세요.

모든 셋팅이 완료되었습니다. 이제 main tutorial로 돌아가 Google의 OAUTH2.0 client authentication service를 사용한 REST 서버 인증을 설정할 수 있습니다.

 

 

+ Recent posts