developerWorks에 처음 로그인하면 developerWorks프로파일이 생성됩니다.귀하의 프로파일에서 동의하신 내용이 공개되지만 이 사항은 언제든지 변경 가능합니다. 귀하의 성명(숨김으로 체크되어 있어도 표시됩니다)과 디스플레이 이름은 게시한 컨텐츠나 사이트 엑세스시 표시됩니다.

모든 정보가 안전하게 전송되었습니다.

처음 developerWorks에 로그인할 때 프로파일이 작성되므로, 이를 위해 디스플레이 이름을 선택해야 합니다. 선택하신 디스플레이 이름은 developerWorks에 게시한 컨텐츠에 표시됩니다.

3글자 이상 31글자 이하의 길이로 사용 가능합니다. dW커뮤니티 내에서는 보안상 이메일주소를 제외한 다른 이름을 지정하셔야 합니다.

모든 정보가 안전하게 전송되었습니다.

My developerWorks：

나의 통지：

로그아웃

언어 선택：

IBM SmartCloud Enterprise 팁: 프록시를 사용하여 인증 정책 통합

사설 애플리케이션과 IBM Could 간에 프록시 브릿지 작성

Dominique Vernier, IT아키텍트, IBM

최근 몇 년간 Dominique Vernier는 Java 기술과 클라우드 아키텍처에 주목했다. 그는 정보 기술 분야에서 오랜 기간 동안 작업하는 동안 메시징, 데이터베이스, SOA, EAI, 클라이언트/서버, C/C++ 및 기존 프레임워크 등의 기술과 제품 부문에서 폭넓은 경험을 얻었다. Dominique는 전기 통신, CRM, 물류 및 보험과 같은 산업 영역에서 광범위한 지식도 보유하고 있다. 그는 상태 엔진과 자원 관리와 관련된 작업을 하는 네 가지 특허의 저자/공동 저자이다. 현재 Dominique는 IBM GTS Global 팀에서 IBM SmartCloud Enterprise 솔루션의 책임자이다.

요약： IBM® SmartCloud Enterprise 환경에서 주문 제작형 클라우드 애플리케이션의 인증과 권한 부여를 위한 비즈니스 규칙을 관리하는 태스크가 어려울 필요는 없습니다. 저자는 비즈니스 규칙을 Java™ 및 RESTful API 간을 연결하는 프록시와 명령행으로 빌드하는 방법을 IBM Cloud API의 구조를 사용하여 설명합니다. 또한, 프록시를 사용하면 사용자가 IBM Cloud 포털을 액세스할 때 해당 비즈니스 규칙을 반드시 거쳐가게 됩니다.

이 연재 자세히 보기

여기에 태그 달기!

기사 게재일： 2011 년 9 월 06 일
난이도： 중급
원문： 보기
PDF： A4 and Letter (57KB | 10 pages)Get Adobe® Reader®
페이지뷰： 1181 회
의견：

대부분의 엔터프라이즈에서는 IBM SmartCloud Enterprise에서 화이트 레이블 애플리케이션(사용자 정의하여 자체 상표를 부착할 수 있거나 직접 빌드하는 애플리케이션)의 인증과 권한 부여 작업을 관리하는 기능이 중요하다. 이러한 애플리케이션 중에는 다음과 같은 특성을 제어하는 비즈니스 규칙이 수반되지 않는 것도 있다.

사용자를 특정 서비스 레벨로 제한(예를 들면, IBM Cloud에서는 사용자가 Bronze 레벨로 유지됨)
사용자를 특정 비용 레벨로 제한
사용자를 특정 기간 내에서 특정 비용으로 제한

IBM Cloud 포털에서는 이러한 규칙을 직접 구현할 수 없으므로 자체 포털에서 이러한 규칙을 구현해야 한다.

이 기사에서는 다양한 사설 애플리케이션으로부터 모든 요청을 수신하여 이 요청에 비즈니스 규칙을 적용한 후, 이 요청을 IBM Cloud 플랫폼으로 전송하거나 거부하는 프록시로 이러한 모든 규칙을 중앙화하는 방법을 설명한다.

IBM Cloud API를 구현하는 방법

IBM Cloud 플랫폼은 다음과 같은 세 가지 유형의 API를 제공한다.

RESTful API
Java API
명령행 API

기본 API는 RESTful API이며 기타 API는 RESTful API를 기반으로 빌드된다.

Java API는 RESTful API를 둘러싸고 있는 랩퍼이다. 따라서 Java API는 메소드를 호출할 클래스와 Bean을 제공하고 각 메소드는 RESTful API를 호출한다.

명령행 API는 RESTful API 요청을 트리거하는 Java API 메소드를 호출한다.

정의에 따르면 RESTful API는 URL과 메소드를 기반으로 한다. 예를 들면, GET 메소드는 플랫폼에서 정보를 검색하며 POST 메소드는 플랫폼에서 자원을 생성한다. IBM Cloud RESTful API는 IBM Cloud 플랫폼에 위치한 애플리케이션 서버에서 구현된다. 따라서 이 애플리케이션 서버를 지정할 기본 URL 주소가 제공된다.

따라서 이 개념은 사설 애플리케이션과 IBM Cloud 플랫폼 간에 프록시를 작성하는 것이다. 이 프록시는 요청을 받아서 비즈니스 규칙을 적용한 후에 IBM Cloud 플랫폼으로 전달한다.

모든 사설 애플리케이션이 프록시를 거쳐가는지 확인하려면 다음을 수행한다.

IBM Cloud 플랫폼 URL을 사용하는 대신 프록시 URL을 기본 URL로 호출하면 RESTful API을 적용할 수 있다.
Java API 패키지의 경우에는 environment.properties 파일에 있는 기본 URL을 수정할 수 있다.
마지막으로 명령행 API의 경우에는 이 API가 Java API를 사용하므로 environment.properties 파일을 수정하여 기본 URL을 변경할 수 있다.

회피해야 할 또 다른 문제점은 사용자가 비즈니스 규칙을 건너뛰어 직접 IBM Cloud 플랫폼에서 세션을 여는 것이다. 이런 경우에는 엔터프라이즈 사용자 ID를 IBM Cloud 플랫폼 사용자 ID 및 비밀번호와 맵핑하는 맵핑 테이블을 간단히 작성한다. IBM Cloud 플랫폼 사용자 ID와 비밀번호는 엔터프라이즈 사용자가 볼 수 없다.

이러한 솔루션에서는 프록시를 요청 서버로 사용하는 모든 사설 애플리케이션이 인증 및 권한 부여 비즈니스 규칙을 자동으로 적용하기 때문에 인증 및 권한 부여 비즈니스 규칙을 중앙에서 관리할 수 있다. 따라서 이러한 비즈니스 규칙을 여러 가지 버전으로 구현하여 모든 사설 애플리케이션 전체로 배포하지 않아도 된다는 장점이 생긴다. 엔터프라이즈 사용자는 신임 정보가 없기 때문에 포털이나 API를 사용하여 IBM Cloud 플랫폼에 직접 연결할 수 없다.

위로

컴포넌트를 상위 레벨 설계 관점에서 보기

이 기사에서 다루는 컴포넌트는 다음과 같다.

IBM Cloud 플랫폼
프록시 서버
LDAP 컴포넌트
비즈니스 규칙 엔진
사용자 맵핑 엔진
RESTful API
Java API
명령행 API

그림 1. 이 기사에서 다루는 컴포넌트

이제 이러한 컴포넌트를 각각 자세히 살펴보도록 하자.

IBM Cloud 플랫폼

IBM Cloud 플랫폼은 클라우드 자원을 관리할 서비스를 제공하며 전 세계에 있는 IBM 건물 내부에 위치하고 있다.

프록시 서버

프록시 서버는 다양한 API로부터 요청을 받아서 이 요청을 비즈니스 규칙 컴포넌트에서 제공하는 비즈니스 규칙을 대상으로 확인하여 IBM Cloud 플랫폼에 전달하는 역할을 한다.

프록시 서버는 모든 조작에 기본 URL을 사용하며 이러한 조작 URL은 IBM Cloud 서버로 전달된다. 예를 들어, 프록시 서버가 로컬 호스트에 설치된 경우에는 API가 http://localhost:9080/cloudproxy/offering/storage와 같은 요청을 전송한다. 비즈니스 규칙을 확인한 후에는 프록시 서버가 https://www-147.ibm.com/computecloud/enterprise/api/rest/20100321/offering/storage URL을 사용하여 IBM Cloud 플랫폼을 호출한 후, 그 결과를 다시 API에게 리턴한다.

프록시 서버는 인증을 위해 LDAP 디렉토리를 사용하도록 설정된다. 프록시는 사용자 맵핑 컴포넌트를 사용하여 엔터프라이즈 사용자 ID를 IBM Cloud 신임 정보와 맵핑하여 IBM Cloud에서 세션을 열고 해당 요청을 실행한다.

프록시 서버 예제는 다음 doGet() 서블릿 메소드를 사용하여 구현할 수 있다.

     /**
      * @see HttpServlet#doGet(HttpServletRequest request, HttpServletResponse
      *      response)
      */
     protected void doGet(HttpServletRequest request,
               HttpServletResponse response) throws ServletException, IOException {
          String user = request.getUserPrincipal().getName();
          Security.setProperty("ssl.SocketFactory.provider",
                    "com.ibm.jsse2.SSLSocketFactoryImpl");
          Security.setProperty("ssl.ServerSocketFactory.provider",
                    "com.ibm.jsse2.SSLServerSocketFactoryImpl");
          String mappedUser = userMapping.getMapUser(user);
          String mappedPassword = userMapping.getMapPassword(user);
          boolean authorized = true;
          if (mappedUser != null && mappedPassword != null) {
               authorized = BusinessRules.getCheckRequest(request);
          } else {
               authorized = false;
          }

          if (authorized) {
               // Create an http client
               HttpClient httpclient = new HttpClient();
               Credentials defaultcreds = new UsernamePasswordCredentials(
                         mappedUser, mappedPassword);
               httpclient.getState().setCredentials(AuthScope.ANY, defaultcreds);

               HttpsURL httpsURL = new HttpsURL(basedURL + request.getPathInfo());
               HttpMethod method;
               String methodType = request.getMethod();
               if (methodType.equals("GET")) {
                    method = new GetMethod(httpsURL.getEscapedURI());
               } else if (methodType.equals("POST")) {
                    method = new PostMethod(httpsURL.getEscapedURI());
               } else if (methodType.equals("PUT")) {
                    method = new PutMethod(httpsURL.getEscapedURI());
               } else {
                    method = new DeleteMethod(httpsURL.getEscapedURI());
               }

               // Execute the request
               httpclient.executeMethod(method);

               // Get the result
               InputStream result = method.getResponseBodyAsStream();
               OutputStream pw = response.getOutputStream();
               int i;
               while ((i=result.read())!=-1) {
                    pw.write(i);
               }
               pw.close();
               response.setStatus(method.getStatusCode());
          } else {
               response.setStatus(HttpServletResponse.SC_FORBIDDEN);
               response.sendError(HttpServletResponse.SC_FORBIDDEN);
          }

     }

이 메소드는 userMapping 클래스를 사용하여 사용자 맵핑 컴포넌트를 호출하고 BusinessRules 클래스를 호출하여 비즈니스 맵핑 컴포넌트를 호출한다.

LDAP 컴포넌트

LDAP 컴포넌트는 모든 엔터프라이즈 사용자를 유지할 뿐만 아니라 인증에 필요한 일부 비즈니스 규칙과 사용자 맵핑 테이블을 유지한다. 기타 모든 수단은 이러한 기능을 이행하는 데 사용된다.

비즈니스 규칙 컴포넌트

비즈니스 규칙 컴포넌트는 요청이 실행될 수 있는지 여부를 확인한다. 가능한 모든 규칙이 이 컴포넌트에서 구현된다. 이 기사에서 사용한 예제에서는 비즈니스 규칙 컴포넌트를 사용하여 요청을 수락하거나 거부할 뿐만 아니라 요청을 수정할 비즈니스 규칙이 있는지 여부를 판별할 수 있다. 예를 들면, 사용자가 IBM Cloud에 있는 Gold 인스턴스를 요청하지만, Bronze 레벨만 사용 가능하다.

사용자 맵핑 컴포넌트

또한, 사용자가 IBM Cloud 포털에 직접 액세스하거나 API를 사용할 수 있게 되어 설정한 권한 부여 규칙이 적용되지 않는 상태에서 자원을 직접 관리할 수 있는 상황이 발생하지 않도록 해야 한다. 이렇게 하려면 LDAP에서 선언된 그리고 IBM Cloud 플랫폼을 사용하도록 권한이 부여된 각 엔터프라이즈 사용자를 대상으로 IBM Cloud 플랫폼 사용자를 작성해야 한다. (사용자 ID는 엔터프라이즈 사용자 ID와 달라야 한다.)

엔터프라이즈 사용자 ID와 IBM Cloud 플랫폼에 연결하는 데 사용되는 IBM Cloud 사용자 ID 및 비밀번호 간에 맵핑을 설정하여 유지한다. 이는 LDAP 서버에 대한 좋은 사용법이다. 이러한 방법으로 IBM Cloud 플랫폼 신임 정보를 엔터프라이즈 사용자가 볼 수 없도록 유지하기 때문에 엔터프라이즈 사용자는 IBM Cloud 포털이나 API에 직접 연결할 수 없다.

또 다른 옵션은 하나의 IBM Cloud 사용자 ID로 모든 엔터프라이즈 사용자를 맵핑하는 것이다. 이렇게 하면 IBM Cloud 사용자로 추적할 수 없을 뿐만 아니라 엔터프라이즈 사용자가 어떤 자원을 사용하는지도 추적할 수 없게 된다. 따라서 자체 애플리케이션 내에서 이러한 데이터를 추적해야 한다. 자원의 상태와 요청을 기반으로 이용을 추적하는 데 필요한 생성된 자원 ID를 포함하여 모든 요청을 기록하도록 프록시에 로그를 추가할 수 있다.

RESTFul API 컴포넌트

프록시는 단지 요청을 IBM Cloud 플랫폼에 전달하므로 인증/권한 부여 규칙을 적용한 후에는 프록시 서버를 통해 RESTFul API를 호출할 기본 URL만 변경되어야 한다. 예를 들면, 다음 URL 대신

https://www-147.ibm.com/computecloud/enterprise/api/rest/20100321/

다음 URL을 사용한다.

http://localhost:9080/cloudproxy/

Java API 컴포넌트

Java API에는 기본 URL이 Java API JAR 파일에 있는 environment.properties 파일에 저장되어 있다. 이 JAR 파일을 압축 해제하여 environment.properties 파일을 수정한 후, 이 파일을 다시 JAR 파일로 압축하여 수정된 JAR 파일을 개발자에게 배포할 수 있다.

api.host=www-147.ibm.com
api.port=443
api.scheme=https
api.context=/computecloud/enterprise/api/rest/
api.version=20100331
ram.url=https://www-147.ibm.com/cloud/enterprise/ram.ws
# Set the socket timeout in seconds for waiting for data
api.sotimeout=300

자체 값을 설정하여 environment.properties 파일을 변경할 수 있다.

api.host=localhost
api.port=9080
api.scheme=http
api.context=/CloudProxy/
api.version=
ram.url=https://www-147.ibm.com/cloud/enterprise/ram.ws
# Set the socket timeout in seconds for waiting for data
api.sotimeout=300

명령행 API 컴포넌트

명령행 API는 Java API를 사용하므로 이전 섹션에서 설명한 것과 같은 기술이 적용될 수 있다.

추가 보안 팁

몇 가지 더 기억해야 할 사항은 다음과 같다.

프록시 서버만 IBM Cloud 플랫폼에 접근할 수 있도록 방화벽 규칙을 추가할 수 있다.
사설 애플리케이션이 직접 회사의 네트워크를 통하거나 VPN을 통해서만 이용 가능한지 확인한다.

이렇게 한다고 해서 사용자가 직접 IBM Cloud 포털에 접근하는 것을 막을 수는 없지만, 사용자는 IBM Cloud 사용자 ID를 모르기 때문에 안전하다.

위로

결론

IBM SmartCloud Enterprise API의 구조와 이 API의 작동 방식에 대한 지식에 의존하는 이러한 기술을 적용하여 인증/권한 부여 비즈니스 논리를 프록시 서버로 중앙화할 수 있으며 그렇게 함으로써 비즈니스 규칙이 사설 애플리케이션 전체로 퍼지는 것을 방지할 수 있다. 이렇게 하면 비즈니스 논리를 유지보수하는 과정을 많이 단순화할 수 있다.

참고자료

교육