IT/모바일
제공: 한빛 네트워크
저자: Tieu Luu, 이대엽 역
원문: Separation of Concerns in Web Service Implementations
관심의 분리는 서비스 지향 아키텍처(Service-Oriented Architecture; SOA)의 핵심 원칙이다. 불행히도 이 원칙은 SOA 서비스의 구현으로 이어질 때 종종 사라지곤 한다. 너무나도 자주 우리는 보안, 트랜잭션 관리, 그리고 로깅과 같은 다수의 관심사들이 비즈니스 로직과 함께 하나의 커다란 구현 클래스에 한데 섞여있는 것을 보곤 한다. 우리는 스프링(Spring) 프레임워크와 관점 지향 프로그래밍(Aspect Oriented Programming; AOP)의 원칙들을 이용하여 서비스 구현으로 관심의 분리를 이끌어 갈 수 있다.
이 기사에서는 아파치 Axis와 스프링을 이용하여 어떻게 웹 서비스를 개발하는지, 그리고 개발한 웹 서비스를 Acegi Security로 어떻게 보호하는 지에 대해 보여줄 것이다. 모든 관심들을 깔끔하게 분리하면서 말이다.
동기와 설계
이 기사에서 사용할 예제는 FundsTransferService라 불리는 서비스인데 은행에서 예금을 한 계정에서 다른 계정으로 이체하는데 사용하기 위한 것이다. 이 서비스에 대한 WSDL은 모든 소스코드, 설정 파일, 그리고 빌드 파일과 함께 이 기사의 리소스 단락에서 찾아볼 수 있다. 그리고 이 기사와 관련된 측면에만 좀 더 집중할 수 있도록 이 서비스를 일부러 매우 단순하게 만들었다. 이 서비스의 구현에서는 다음의 세 가지 관심사를 다루게 될 것이다:
이 구현을 위한 설계가 그림 1에 나타나 있다. 노란색 객체는 우리가 직접 구현해야 할 필요가 있는 것들이다. 파란색은 Axis로부터, 분홍색은 Acegi로부터, 그리고 녹색은 스프링으로부터 제공되는 객체들이다. FundsTransferService는 WSDL에 정의되어 있는 것과 같이 우리가 제공할 서비스에 대한 인터페이스이다. 다이어그램을 단순화시키기 위해 모든 Axis 클래스는 Axis 엔진이라 불리는 컴포넌트로 나타내었다. BasicHandler 또한 Axis 클래스이나 다이어그램에는 분리해서 나타내었는데, 왜냐하면 그것은 우리의 설계에서 중요한 의미를 지니기 때문이다(자세한 내용은 차후에 소개된다). FundsTransferServiceSoapBindingImpl은 서비스 기능성을 제공하기 위해 구현해야 할 필요가 있는 Axis로부터 생성된 클래스이다. 그것은 스프링을 통해 간접적으로 비즈니스 로직 POJO인 AccountMgrImpl를 위임할 것이다(이 역시 차후에 자세하게 설명될 것이다). AccountMgrImpl은 AccountMgr 인터페이스에 래핑되는데 왜냐하면 이는 좋은 설계 사례이며 그리고 그것은 또한 스프링으로 하여금 마법을 부릴 수 있도록 해주기 때문이다(비록 인터페이스 없이 스프링을 이용하는 다른 방법이 있기는 하지만 말이다).
그림 1. FundsTransferService의 구현에 대한 설계(전체 크기의 이미지를 보려면 클릭하시오).
이제 BasicHandler로 돌아가보자. 이 객체가 필요한 이유는 우리가 보안을 어떻게 제공할지에 대해 결정한 것과 관련되어 있다. 이 예제에서는 서로 다른 두 단계에 걸쳐 보안을 처리하는데, 웹 서비스를 위한 보안과 애플리케이션 코드(예를 들어, POJO와 같은)를 위한 보안이다. 관심의 분리에 입각하여 우리는 이것들을 분리할 수 있도록 해주는 설계를 고안하였다. Axis는 우리가 요청과 응답 메시지를 가로채어 보안과 같은 추가 기능을 제공할 사용자 정의 핸들러를 끼워 넣을 수 있게끔 해준다. 따라서 우리는 웹 서비스 보안을 처리하는 것을 책임질 AcegiBridgeAuthenticationHandler라는 사용자 정의 핸들러를 생성할 것이다. 그것은 Axis 클래스의 BasicHandler를 확장하므로 우리가 그것을 Axis 핸들러 프레임워크에 끼워 넣을 수가 있다. Acegi는 애플리케이션 단계의 보안, 예를 들면 POJO에 대한 접근제어 제공과 같은 것을 제공하는데 사용될 것이다.
이들 모두를 서로 끊김없이(seamless) 작동시키기 위해서는 웹 서비스 보안 컨텍스트와 Acegi 보안 컨텍스트를 서로 연동시킬 필요가 있으며 따라서 우리의 사용자 정의 Axis 핸들러 클래스의 이름을 AcegiBridgeAuthenticationHandler라 명명한다. 이것은 웹 서비스 보안 처리뿐만 아니라 웹 서비스 보안 처리로부터 획득된 보안컨텍스트를 Acegi 환경과 연동시키는 것을 책임질 것이며, 그러므로 Acegi가 POJO로의 접근에 대한 승인 여부를 결정할 수 있게 된다. 이것은 웹 서비스 메시지로부터 보안 요구를 추출하고, 검증하고, 그 다음으로 인증 토큰(엄밀히 말하면 UsernamePasswordAuthenticationToken인데 왜냐하면 이 예제에서는 사용자명/비밀번호 인증을 선택했기 때문이다)을 생성함으로써 이루어진다. 그리고 나서 요청자의 자격증명과 퍼미션이 차후 비즈니스 로직 POJO로의 접근을 통제할 때 Acegi에서 사용 가능해지도록 이 인증토큰을 Acegi SecurityContext에 설정한다.
이제 모든 것들을 한데 묶기 위해 스프링을 어떻게 사용해야 하는지 설명할 차례이다. 그림 1에서 마법은 작은 녹색 객체에 들어 있는데 AOP 프록시라 불리며 스프링에 의해 생성된다. 이 객체는 AccountMgr 인터페이스를 구현하며 비즈니스 로직 POJO인 AccountMgrImpl에 대한 프록시로 작동한다. 이것은 스프링이 Acegi의 MethodSecurityInterceptor에 끼워져서 누군가가 POJO상의 메소드를 호출하려 할 때 접근 통제 점검을 수행하도록 해준다. FundsTransferServiceSoapBindingImpl이 웹 서비스 요청을 POJO에 위임할 때 그것은 직접 AccountMgrImpl로 가는 것이 아니라 실제로는 AOP 프록시의 인스턴스로 위임된다. 왜냐하면 FundsTransferServiceSoapBindingImpl은 ServletEndpointSupport를 확장하기 때문에 우리가 이전에 설정했던 적절한 인터페이스, 인터셉터, 그리고 대상 클래스인 AccountMgrImpl에 대한 AOP 프록시로의 참조를 얻기 위하여 스프링 애플리케이션 컨텍스트에 접근할 수 있다.
그림 2의 시퀀스 다이어그램은 클라이언트가 FundsTransferService를 호출했을 때 발생하는 처리과정의 흐름을 보여준다. 요청 메시지는 Axis 엔진에 의해 수신되는데, 수신된 다음에는 AcegiBridgeAuthenticationHandler를 호출한다. AcegiBridgeAuthenticationHandler는 인증 정보를 확인한 다음 UsernamePasswordAuthenticationToken을 생성한다. 다음으로 AcegiBridgeAuthenticationHandler는 이 토큰을 나중에 사용할 목적으로 Acegi의 SecurityContext에 설정해 놓는다. AcegiBridgeAuthenticationHandler가 성공적으로 리턴된 후 Axis 엔진은 FundsTransferServiceSoapBindingImpl에 있는 transferFunds() 메소드를 호출한다. FundsTransferServiceSoapBindingImpl는 이것을 AOP 프록시에게 위임하는데 이 AOP 프록시는 초기화되는 무렵인 이전에 스프링 웹 애플리케이션 컨텍스트로부터 획득된다. AOP 프록시는 보안 검사를 수행할 수 있도록 Acegi MethodSecurityInterceptor를 호출한다. MethodSecurityInterceptor는 SecurityContext로부터 인증토큰을 획득하고 그것이 이미 인증되었는지 여부를 확인한다. 다음으로 MethodSecurityInterceptor는 인증 토큰에 들어있는 정보를 이용하여 클라이언트가 AccountMgrImpl에 있는 transferFunds() 메소드를 호출하기 위한 접근이 허가되었는지를 살핀다. 클라이언트가 접근에 대해 허가되었다면 그 다음으로 MethodSecurityInterceptor는 AccountMgrImpl로 나아가기 위한 메소드 호출을 허가한다. 최종적으로 AccountMgrImpl는 요청을 처리하여 결과를 반환하는데, 이 결과는 궁극적으로 다시 클라이언트 프로그램으로 전달된다.
그림 2. 서비스 구현상의 처리 흐름을 보여주는 시퀀스 다이어그램 (전체 크기의 이미지를 보려면 클릭하시오).
비즈니스 로직 구현과 환경설정
먼저 비즈니스 로직 클래스에 대한 구현과 환경설정을 설명하는 것으로부터 시작할 텐데 왜냐면 그게 가장 간단하기 때문이다. 다운로드 가능한 샘플 코드안에 있는 AccountMgr 인터페이스 AccountMgrImpl 클래스에 대한 소스코드를 살펴보라. 소스코드에서 볼 수 있는 것처럼 구현코드는 실제로 아무것도 하지 않는데 이 기사가 예금 이체에 대한 코드를 어떻게 작성하는 지에 관한 것이 아니기 때문에 그런 식으로 단순성을 유지할 수 있다. 아래는 스프링의 AOP 기능을 이용할 수 있도록 비즈니스 로직에 대한 스프링 빈의 설정 방법을 보여주는 스프링 환경설정 파일(전체 환경설정 파일은 리소스 섹션에서 볼 수 있다)의 일부이다. 첫 번째 빈 설정은 단순히 AccountMgrImpl 클래스에 대한 빈을 설정한다. 두 번째 빈 설정은 앞에서 언급했던 모든 AOP 프록시 마법이 어떻게 이루어지는지에 대한 것이다. 우리는 ProxyFactoryBean으로부터 획득될 accountMgr라는 아이디를 가지는 빈을 설정하였다. FundsTransferServiceSoapBindingImpl 클래스가 스프링에게 이 아이디를 가진 빈을 요청하게 되면 ProxyFactoryBean이 AOP 프록시 객체의 인스턴스를 리턴해줄 것이다. 우리는 클라이언트 프로그램이 비즈니스 로직 객체하고만 작업하고 있다고 생각하도록 AccountMgr 인터페이스를 구현하도록 설정하였다. interceptorNames라는 이름을 가진 두 번째 속성를 통해 우리는 보안 검사를 수행하기 위해 메소드 호출을 가로챌 수 있는 securityInterceptor와 같은 이름으로 불리는 빈을 설정할 수 있다. 이것은 우리가 비즈니스 로직 코드 내에 아무런 의존성을 삽입하지 않고도 Acegi 보안 메커니즘에 끼워 넣을 수 있도록 해준다. 마지막으로 결국 메소드 호출이 실질적인 비즈니스 로직 클래스인 AccountMgrImpl로 전달될 수 있도록 대상 객체를 accountMgrTarget 빈으로 지정하였다.
FundsTransferServiceSoapBindingImpl 클래스는 이 웹 서비스의 구현이다. 다운로드 가능한 샘플 코드에서 이 클래스의 소스코드를 보라. 이 클래스의 골격은 Axis에 의해 생성되는데 우리는 단지 구현을 제공하는 메소드의 내용을 채우기만 하면 된다. 이 클래스가 ServletEndpointSupport를 확장하고 있음을 주목하라. 이 클래스는 스프링에서 제공되는 편의를 위한 클래스인데, 스프링 애플리케이션 컨텍스트에 대한 참조를 획득하는 JAX-RPC 웹 서비스 구현에 사용될 수 있다. 이 클래스를 확장함으로써 FundsTransferServiceSoapBindingImpl 클래스는 앞에서 설명한 accountMgr 빈에 대한 참조를 획득하기 위해 스프링 컨텍스트에 접근할 수 있다. FundsTransferServiceSoapBindingImpl 클래스가 Axis에 의해 관리되기 때문에 자동적으로 그러한 빈에 대한 참조를 얻기 위한 스프링의 의존성 삽입 기능을 이용할 수 없다. 그러므로 우리는 그러한 것들을 onInit() 메소드 내에서 명시적으로 수행해야 한다. 불행히도 이는 이 클래스 안에 몇몇 스프링에 구체적인 클래스로의 의존성을 추가하게 한다. 뭐 어쩔 수 없이 스프링과 Acegi를 사용하는 것의 이점을 이용할 수 있도록 하는 데 대해 지불해야 할 약간의 비용이라 생각하자. 실제 transferFunds() 메소드 안의 코드는 단순히 accountMgr 빈에 위임하기만 할 뿐이라는 것을 유의하자.
Axis 환경설정 파일(deploy.wsdd와 server-config.wsdd)에서는 서비스에 대한 구현 클래스가 Axis에 의해 생성되는 다른 골격 클래스(FundsTransferServiceSoapBindingSkeleton)가 아닌 FundsTransferServiceSoapBindingImpl 클래스로 지정되어 있는지 확인해볼 필요가 있다. 스프링이 Axis와 같은 동일한 웹 애플리케이션에서 적절하게 작동하도록 만들기 위해 다음의 내용들을 web.xml 파일에 추가할 필요가 있다. context-param 항목은 스프링 환경설정 파일이 어디에 위치해 있는지를 지정한다. listener 항목은 스프링 환경설정과 컨텍스트가 시작시에 로딩되도록 설정한다.
이제 스프링 환경설정 파일에서 Acegi Security를 어떻게 설정하는지에 대해 논의할 것이다. 앞에서 설명했듯이 보안 검사를 수행하기 위하여 securityInterceptor 빈에 의해 메소드 호출이 가로챌 수 있도록 비즈니스 로직 빈을 설정하였다. 이제 이 빈이 어떻게 설정되어 있는지 살펴보도록 하자. 아래에 나와있는 것은 securityInterceptor 빈을 위한 스프링 환경설정 파일의 일부분이다. securityInterceptor 빈은 MethodSecurityInterceptor이라 불리는 Acegi로부터 제공되는 클래스이다. 이름이 의미하듯이 이 클래스는 메소드 호출을 가로채어 메소드 호출자가 인증되고 권한부여가 이루어졌는지를 확인함으로써 메소드 호출에 대한 보안을 집행하는데 사용된다.
다음으로 빈의 accessDecisionManager 속성에 누군가의 메소드 호출을 위한 접근을 허가할 것인지의 여부를 어떻게 결정할지 지정할 필요가 있다. Acegi에는 AffirmativeBased, ConsensusBased, 그리고 UnanimousBased의 세 가지 접근 결정 관리자의 구상 구현 클래스가 따른다. Acegi는 투표자가 특정 활동을 수행하기 위한 누군가의 접근을 허가할 것인가 말 것인가에 대한 투표를 하게 하는 것에 기반함으로써 접근 결정을 한다. 접근 결정 관리자로서 여기서에서는 UnanimousBased를 선택했는데, 이는 클라이언트의 특정 활동을 수행할 수 있게 하는 접근을 승인하는 투표에 모든 투표자들을 참여하게 한다. 이것이 어떻게 작동하는지에 대한 좀 더 심층적인 설명을 보려면 Acegi 문서를 읽어야 한다. 다음으로는 accessDecisionManager에 투표자 목록을 설정해야 한다. 여기에서는 Rolevoter라 불리는 하나의 투표자만을 사용할 것이다. 이 Acegi 클래스는 역할기반의 접근제어에 기반하여 접근에 대한 승인 여부를 투표한다. 다시 말하지만 여러분은 RoleVoter가 어떻게 작동하는지에 대한 상세한 설명은 Acegi 문서를 참고해야 한다.
마지막으로 설정해야 할 필요가 있는 속성은 objectDefinitionSource이다. 이것은 현재 보호되고 있는 객체상의 다양한 메소드에 접근하는데 있어 어떠한 퍼미션이 필요한지를 지정하는 것이다. 여기에서는 transferFunds() 메소드만을 보호하고 관리자에게만 접근을 허락하고자 한다. 이는 완전히 한정된(fully qualified) 클래스명과 메소드명, 그리고 그것에 접근하는데 필요한 역할의 목록을 나열함으로써 이루어진다.
앞에서 언급했듯이, 우리는 웹 서비스 보안 컨텍스트와 Acegi 보안 컨텍스트를 연동시켜줄 무언가가 필요하다. 연동이 필요한 곳은 사용자 정의 Axis 핸들러인 AcegiBridgeAuthenticationHandler로 보여진다. AcegiBridgeAuthenticationHandler의 소스코드는 다운로드 가능한 샘플 코드 섹션에서 사용 가능하다. 우리는 구현을 매우 단순하게 하여 설명하기 쉽도록 하였다. 먼저 여러분이 알아챌 수도 있는 것은 그것은 어떠한 실질적인 인증은 하지 않는다는 것이다. 단순히 MessageContext에서 사용자명과 비밀번호를 가져와서 그냥 그대로 사용한다. 실제 구현은 물론 그 정보에 대하여 실질적인 검증을 시도할 것이다. 또 다른 고려할 사항은 실제 구현은 단순히 우리가 여기에서 하고 있는 Axis MessageContext 객체로부터 인증정보를 추출하는 것이 아니라 인증정보를 얻기 위하여 SOAP 메시지로부터 WS-Security 보안 헤더를 추출 및 처리해야 한다는 것이다.
인증정보를 획득한 후의 다음 단계는 그 인증정보를 Acegi에서 사용 가능토록 만드는 것이다. 이는 인증 토큰을 생성하여 Acegi 보안 컨텍스트에 할당함으로써 이루어진다. 우리는 사용자명/비밀번호 인증을 하고 있기 때문에 UsernamePasswordAuthenticationToken의 인스턴스를 생성할 것이다. 인스턴스를 생성하기 전에 우리는 이 사용자에게 어떠한 권한(예를 들어, 퍼미션과 같은)이 승인되었는지를 지정해야 할 필요가 있다. 이는 GrantedAuthority 인터페이스와 GrantedAuthorityImpl라 불리는 간단한 구현을 사용함으로써 이루어진다. 우리는 접근 의사결정에 RoleVoter를 이용하고 있으므로 우리가 승인받을 권한들은 역할들이다. 다시 한번 말하지만 관리자 역할에 대한 승인을 하드코딩해서 구현을 단순하게 하였는데, 이는 POJO상의 transferFunds() 메소드를 호출하는 데에는 승인이 필요하기 때문이다. 실제 구현은 아마도 사용자명과 비밀번호를 받아와 실질적으로 어떠한 역할이 그 계정과 연결되어 있는지 확인하기 위해 데이터베이스나 디렉터리 서버에서 찾아볼 것이다. 아니면 어떤 경우에는 그러한 정보들은 WS-Security에 SAML 검증(assertion) 형태로 사용가능 할지도 모른다.
어쨌든 일단 여기까지 완료한 다음, 사용자 이름과 비밀번호, 그리고 승인된 역할들을 전달하는 UsernamePasswordAuthenticationToken의 인스턴스를 생성한다. GrantedAuthority의 배열을 인자로 받는 형태의 생성자를 이용하여 실질적으로 Acegi에게 이 토큰은 이미 인증되었으므로 재인증 받지 말아야 함을 알린다. 다음으로 SecurityContextHolder의 정적 메소드를 호출하여 SecurityContext를 얻어온 다음 SecurityContext에 인증 토큰을 설정한다. 이제 보안 검사를 수행하는데 사용할 Acegi의 인증 및 역할 정보가 사용가능하다. 이와 같이 웹 서비스 보안 컨텍스트와 Acegi 보안 컨텍스트를 효율적으로 연동하였다.
아직도 추가적으로 고려해야 할 것들이 있다. 먼저 Acegi 역시 충분히 강력한 인증능력을 제공하므로 따라서 여러분은 Axis 핸들러가 인증을 처리하게 하는 대신 Acegi가 그것들을 처리하도록 하는 게 낫다. 이렇게 하기 위해서는 GrantedAuthority 배열을 받지 않는 생성자를 사용함으로써 인증되지 않은 인증 토큰을 생성한다. 여러분은 또한 AnonymousAuthenticationProvider를 사용하는 대신 적절한 인증 제공자를 지정하도록 할 필요가 있을 것이다. 다음으로 Acegi는 단순한 사용자 이름/비밀번호 인증 이외의 것들도 제공한다. 예를 들어, 여러분이 PKI 기반의 인증을 하고 있다면 여러분은 UsernamePasswordAuthenticationToken 대신 X509AuthenticationToken을 사용할 수 있다.
마지막으로 Axis로 하여금 이 핸들러를 서비스의 요청-처리 경로에 포함하도록 설정할 필요가 있다. 이것은 다음의 사항들을 Axis 설정 파일인 deploy.wsdd와 server-config.wsdd에 추가함으로써 이루어진다:
관심의 분리는 서비스 지향 아키텍처를 개발하기 위한 중요한 원칙이다. 그러나 그것은 아키텍처 단계에서뿐만 아니라 구현 단계에서도 적용되어야 할 필요가 있다. 이 기사에서는 SOA 원칙에 충실한 안전한 웹 서비스를 구현하기 위해 Axis, 스프링, 그리고 Acegi를 어떻게 사용해야 하는지에 대해 설명하였다. 샘플 코드에서도 보았듯이 이러한 접근법을 사용하는 것은 우리가 서비스의 각 관심사를 처리하는 코드내의 횡적 의존성(cross-dependency)을 최소할 수 있도록 해준다. 우리가 보여준 예제는 일부러 단순하게 만들었지만 그것은 웹 서비스 보안과 Acegi에서 제공된 애플리케이션 단계의 보안을 결합한 강건한 보안 메커니즘을 지닌 웹 서비스를 개발하는 토대로서 받아 들어져야 한다. 앞에서 언급했다시피 실제 시스템은 WS-Security 헤더를 처리하고 그것들을 Acegi 보안 컨텍스트와 연동시킬 수 있는 핸들러를 개발해야 할 필요가 있을 것이다. 이를 이룰 수 있는 한가지 방법은 WSS4J를 채택하는 것인데, 이는 아파치에서 제공되며 이 기사에서도 기술했듯이 자체 Axis 핸들러를 확장하여 Acegi 보안 컨텍스트에서도 사용할 수 있게끔 해준다. 여러분은 Acegi 보안 예외를 잡아내고 좀 더 의미있는 SOAP 실패내역을 클라이언트에게 돌려주는 Axis 외부 핸들러를 생성하려면 추가적인 작업을 해야 할지도 모른다.
리소스
저자: Tieu Luu, 이대엽 역
원문: Separation of Concerns in Web Service Implementations
관심의 분리는 서비스 지향 아키텍처(Service-Oriented Architecture; SOA)의 핵심 원칙이다. 불행히도 이 원칙은 SOA 서비스의 구현으로 이어질 때 종종 사라지곤 한다. 너무나도 자주 우리는 보안, 트랜잭션 관리, 그리고 로깅과 같은 다수의 관심사들이 비즈니스 로직과 함께 하나의 커다란 구현 클래스에 한데 섞여있는 것을 보곤 한다. 우리는 스프링(Spring) 프레임워크와 관점 지향 프로그래밍(Aspect Oriented Programming; AOP)의 원칙들을 이용하여 서비스 구현으로 관심의 분리를 이끌어 갈 수 있다.
이 기사에서는 아파치 Axis와 스프링을 이용하여 어떻게 웹 서비스를 개발하는지, 그리고 개발한 웹 서비스를 Acegi Security로 어떻게 보호하는 지에 대해 보여줄 것이다. 모든 관심들을 깔끔하게 분리하면서 말이다.
동기와 설계
이 기사에서 사용할 예제는 FundsTransferService라 불리는 서비스인데 은행에서 예금을 한 계정에서 다른 계정으로 이체하는데 사용하기 위한 것이다. 이 서비스에 대한 WSDL은 모든 소스코드, 설정 파일, 그리고 빌드 파일과 함께 이 기사의 리소스 단락에서 찾아볼 수 있다. 그리고 이 기사와 관련된 측면에만 좀 더 집중할 수 있도록 이 서비스를 일부러 매우 단순하게 만들었다. 이 서비스의 구현에서는 다음의 세 가지 관심사를 다루게 될 것이다:
- 기능을 서비스로 외부에 노출시키기 위한 웹 서비스 기반 작업
- 예금 이체를 위한 비즈니스 로직
- 오직 허가된 개체만이 예금 이체를 수행할 수 있게끔 하는 보안성
이 구현을 위한 설계가 그림 1에 나타나 있다. 노란색 객체는 우리가 직접 구현해야 할 필요가 있는 것들이다. 파란색은 Axis로부터, 분홍색은 Acegi로부터, 그리고 녹색은 스프링으로부터 제공되는 객체들이다. FundsTransferService는 WSDL에 정의되어 있는 것과 같이 우리가 제공할 서비스에 대한 인터페이스이다. 다이어그램을 단순화시키기 위해 모든 Axis 클래스는 Axis 엔진이라 불리는 컴포넌트로 나타내었다. BasicHandler 또한 Axis 클래스이나 다이어그램에는 분리해서 나타내었는데, 왜냐하면 그것은 우리의 설계에서 중요한 의미를 지니기 때문이다(자세한 내용은 차후에 소개된다). FundsTransferServiceSoapBindingImpl은 서비스 기능성을 제공하기 위해 구현해야 할 필요가 있는 Axis로부터 생성된 클래스이다. 그것은 스프링을 통해 간접적으로 비즈니스 로직 POJO인 AccountMgrImpl를 위임할 것이다(이 역시 차후에 자세하게 설명될 것이다). AccountMgrImpl은 AccountMgr 인터페이스에 래핑되는데 왜냐하면 이는 좋은 설계 사례이며 그리고 그것은 또한 스프링으로 하여금 마법을 부릴 수 있도록 해주기 때문이다(비록 인터페이스 없이 스프링을 이용하는 다른 방법이 있기는 하지만 말이다).
그림 1. FundsTransferService의 구현에 대한 설계(전체 크기의 이미지를 보려면 클릭하시오).
이제 BasicHandler로 돌아가보자. 이 객체가 필요한 이유는 우리가 보안을 어떻게 제공할지에 대해 결정한 것과 관련되어 있다. 이 예제에서는 서로 다른 두 단계에 걸쳐 보안을 처리하는데, 웹 서비스를 위한 보안과 애플리케이션 코드(예를 들어, POJO와 같은)를 위한 보안이다. 관심의 분리에 입각하여 우리는 이것들을 분리할 수 있도록 해주는 설계를 고안하였다. Axis는 우리가 요청과 응답 메시지를 가로채어 보안과 같은 추가 기능을 제공할 사용자 정의 핸들러를 끼워 넣을 수 있게끔 해준다. 따라서 우리는 웹 서비스 보안을 처리하는 것을 책임질 AcegiBridgeAuthenticationHandler라는 사용자 정의 핸들러를 생성할 것이다. 그것은 Axis 클래스의 BasicHandler를 확장하므로 우리가 그것을 Axis 핸들러 프레임워크에 끼워 넣을 수가 있다. Acegi는 애플리케이션 단계의 보안, 예를 들면 POJO에 대한 접근제어 제공과 같은 것을 제공하는데 사용될 것이다.
이들 모두를 서로 끊김없이(seamless) 작동시키기 위해서는 웹 서비스 보안 컨텍스트와 Acegi 보안 컨텍스트를 서로 연동시킬 필요가 있으며 따라서 우리의 사용자 정의 Axis 핸들러 클래스의 이름을 AcegiBridgeAuthenticationHandler라 명명한다. 이것은 웹 서비스 보안 처리뿐만 아니라 웹 서비스 보안 처리로부터 획득된 보안컨텍스트를 Acegi 환경과 연동시키는 것을 책임질 것이며, 그러므로 Acegi가 POJO로의 접근에 대한 승인 여부를 결정할 수 있게 된다. 이것은 웹 서비스 메시지로부터 보안 요구를 추출하고, 검증하고, 그 다음으로 인증 토큰(엄밀히 말하면 UsernamePasswordAuthenticationToken인데 왜냐하면 이 예제에서는 사용자명/비밀번호 인증을 선택했기 때문이다)을 생성함으로써 이루어진다. 그리고 나서 요청자의 자격증명과 퍼미션이 차후 비즈니스 로직 POJO로의 접근을 통제할 때 Acegi에서 사용 가능해지도록 이 인증토큰을 Acegi SecurityContext에 설정한다.
이제 모든 것들을 한데 묶기 위해 스프링을 어떻게 사용해야 하는지 설명할 차례이다. 그림 1에서 마법은 작은 녹색 객체에 들어 있는데 AOP 프록시라 불리며 스프링에 의해 생성된다. 이 객체는 AccountMgr 인터페이스를 구현하며 비즈니스 로직 POJO인 AccountMgrImpl에 대한 프록시로 작동한다. 이것은 스프링이 Acegi의 MethodSecurityInterceptor에 끼워져서 누군가가 POJO상의 메소드를 호출하려 할 때 접근 통제 점검을 수행하도록 해준다. FundsTransferServiceSoapBindingImpl이 웹 서비스 요청을 POJO에 위임할 때 그것은 직접 AccountMgrImpl로 가는 것이 아니라 실제로는 AOP 프록시의 인스턴스로 위임된다. 왜냐하면 FundsTransferServiceSoapBindingImpl은 ServletEndpointSupport를 확장하기 때문에 우리가 이전에 설정했던 적절한 인터페이스, 인터셉터, 그리고 대상 클래스인 AccountMgrImpl에 대한 AOP 프록시로의 참조를 얻기 위하여 스프링 애플리케이션 컨텍스트에 접근할 수 있다.
그림 2의 시퀀스 다이어그램은 클라이언트가 FundsTransferService를 호출했을 때 발생하는 처리과정의 흐름을 보여준다. 요청 메시지는 Axis 엔진에 의해 수신되는데, 수신된 다음에는 AcegiBridgeAuthenticationHandler를 호출한다. AcegiBridgeAuthenticationHandler는 인증 정보를 확인한 다음 UsernamePasswordAuthenticationToken을 생성한다. 다음으로 AcegiBridgeAuthenticationHandler는 이 토큰을 나중에 사용할 목적으로 Acegi의 SecurityContext에 설정해 놓는다. AcegiBridgeAuthenticationHandler가 성공적으로 리턴된 후 Axis 엔진은 FundsTransferServiceSoapBindingImpl에 있는 transferFunds() 메소드를 호출한다. FundsTransferServiceSoapBindingImpl는 이것을 AOP 프록시에게 위임하는데 이 AOP 프록시는 초기화되는 무렵인 이전에 스프링 웹 애플리케이션 컨텍스트로부터 획득된다. AOP 프록시는 보안 검사를 수행할 수 있도록 Acegi MethodSecurityInterceptor를 호출한다. MethodSecurityInterceptor는 SecurityContext로부터 인증토큰을 획득하고 그것이 이미 인증되었는지 여부를 확인한다. 다음으로 MethodSecurityInterceptor는 인증 토큰에 들어있는 정보를 이용하여 클라이언트가 AccountMgrImpl에 있는 transferFunds() 메소드를 호출하기 위한 접근이 허가되었는지를 살핀다. 클라이언트가 접근에 대해 허가되었다면 그 다음으로 MethodSecurityInterceptor는 AccountMgrImpl로 나아가기 위한 메소드 호출을 허가한다. 최종적으로 AccountMgrImpl는 요청을 처리하여 결과를 반환하는데, 이 결과는 궁극적으로 다시 클라이언트 프로그램으로 전달된다.
그림 2. 서비스 구현상의 처리 흐름을 보여주는 시퀀스 다이어그램 (전체 크기의 이미지를 보려면 클릭하시오).
비즈니스 로직 구현과 환경설정
먼저 비즈니스 로직 클래스에 대한 구현과 환경설정을 설명하는 것으로부터 시작할 텐데 왜냐면 그게 가장 간단하기 때문이다. 다운로드 가능한 샘플 코드안에 있는 AccountMgr 인터페이스 AccountMgrImpl 클래스에 대한 소스코드를 살펴보라. 소스코드에서 볼 수 있는 것처럼 구현코드는 실제로 아무것도 하지 않는데 이 기사가 예금 이체에 대한 코드를 어떻게 작성하는 지에 관한 것이 아니기 때문에 그런 식으로 단순성을 유지할 수 있다. 아래는 스프링의 AOP 기능을 이용할 수 있도록 비즈니스 로직에 대한 스프링 빈의 설정 방법을 보여주는 스프링 환경설정 파일(전체 환경설정 파일은 리소스 섹션에서 볼 수 있다)의 일부이다. 첫 번째 빈 설정은 단순히 AccountMgrImpl 클래스에 대한 빈을 설정한다. 두 번째 빈 설정은 앞에서 언급했던 모든 AOP 프록시 마법이 어떻게 이루어지는지에 대한 것이다. 우리는 ProxyFactoryBean으로부터 획득될 accountMgr라는 아이디를 가지는 빈을 설정하였다. FundsTransferServiceSoapBindingImpl 클래스가 스프링에게 이 아이디를 가진 빈을 요청하게 되면 ProxyFactoryBean이 AOP 프록시 객체의 인스턴스를 리턴해줄 것이다. 우리는 클라이언트 프로그램이 비즈니스 로직 객체하고만 작업하고 있다고 생각하도록 AccountMgr 인터페이스를 구현하도록 설정하였다. interceptorNames라는 이름을 가진 두 번째 속성를 통해 우리는 보안 검사를 수행하기 위해 메소드 호출을 가로챌 수 있는 securityInterceptor와 같은 이름으로 불리는 빈을 설정할 수 있다. 이것은 우리가 비즈니스 로직 코드 내에 아무런 의존성을 삽입하지 않고도 Acegi 보안 메커니즘에 끼워 넣을 수 있도록 해준다. 마지막으로 결국 메소드 호출이 실질적인 비즈니스 로직 클래스인 AccountMgrImpl로 전달될 수 있도록 대상 객체를 accountMgrTarget 빈으로 지정하였다.
웹 서비스 구현과 설정. . . . . .
com.mybank.bizlogic.AccountMgr
securityInterceptor
FundsTransferServiceSoapBindingImpl 클래스는 이 웹 서비스의 구현이다. 다운로드 가능한 샘플 코드에서 이 클래스의 소스코드를 보라. 이 클래스의 골격은 Axis에 의해 생성되는데 우리는 단지 구현을 제공하는 메소드의 내용을 채우기만 하면 된다. 이 클래스가 ServletEndpointSupport를 확장하고 있음을 주목하라. 이 클래스는 스프링에서 제공되는 편의를 위한 클래스인데, 스프링 애플리케이션 컨텍스트에 대한 참조를 획득하는 JAX-RPC 웹 서비스 구현에 사용될 수 있다. 이 클래스를 확장함으로써 FundsTransferServiceSoapBindingImpl 클래스는 앞에서 설명한 accountMgr 빈에 대한 참조를 획득하기 위해 스프링 컨텍스트에 접근할 수 있다. FundsTransferServiceSoapBindingImpl 클래스가 Axis에 의해 관리되기 때문에 자동적으로 그러한 빈에 대한 참조를 얻기 위한 스프링의 의존성 삽입 기능을 이용할 수 없다. 그러므로 우리는 그러한 것들을 onInit() 메소드 내에서 명시적으로 수행해야 한다. 불행히도 이는 이 클래스 안에 몇몇 스프링에 구체적인 클래스로의 의존성을 추가하게 한다. 뭐 어쩔 수 없이 스프링과 Acegi를 사용하는 것의 이점을 이용할 수 있도록 하는 데 대해 지불해야 할 약간의 비용이라 생각하자. 실제 transferFunds() 메소드 안의 코드는 단순히 accountMgr 빈에 위임하기만 할 뿐이라는 것을 유의하자.
Axis 환경설정 파일(deploy.wsdd와 server-config.wsdd)에서는 서비스에 대한 구현 클래스가 Axis에 의해 생성되는 다른 골격 클래스(FundsTransferServiceSoapBindingSkeleton)가 아닌 FundsTransferServiceSoapBindingImpl 클래스로 지정되어 있는지 확인해볼 필요가 있다. 스프링이 Axis와 같은 동일한 웹 애플리케이션에서 적절하게 작동하도록 만들기 위해 다음의 내용들을 web.xml 파일에 추가할 필요가 있다. context-param 항목은 스프링 환경설정 파일이 어디에 위치해 있는지를 지정한다. listener 항목은 스프링 환경설정과 컨텍스트가 시작시에 로딩되도록 설정한다.
Acegi Security 환경설정contextConfigLocation /WEB-INF/spring-config.xml . . . org.springframework.web.context. ContextLoaderListener
이제 스프링 환경설정 파일에서 Acegi Security를 어떻게 설정하는지에 대해 논의할 것이다. 앞에서 설명했듯이 보안 검사를 수행하기 위하여 securityInterceptor 빈에 의해 메소드 호출이 가로챌 수 있도록 비즈니스 로직 빈을 설정하였다. 이제 이 빈이 어떻게 설정되어 있는지 살펴보도록 하자. 아래에 나와있는 것은 securityInterceptor 빈을 위한 스프링 환경설정 파일의 일부분이다. securityInterceptor 빈은 MethodSecurityInterceptor이라 불리는 Acegi로부터 제공되는 클래스이다. 이름이 의미하듯이 이 클래스는 메소드 호출을 가로채어 메소드 호출자가 인증되고 권한부여가 이루어졌는지를 확인함으로써 메소드 호출에 대한 보안을 집행하는데 사용된다.
securityInterceptor의 authenticationManager 속성에 어떤 종류의 인증을 사용할지 지정하도록 설정할 필요가 있다. 인증을 수행하기 위한 설계가 Axis 핸들러에 기반하고 있으므로 여기서는 인증이 필요없으며 따라서 AnonymousAuthenticationProvider로 설정하기만 하면 된다. 추가적으로 Axis 핸들러의 인증 토큰을 생성하는 방식은 Acegi로 하여금 그것이 이미 인증되었음을 알게 해줄 것이며, 따라서 Acegi가 재인증을 시도하지 않을 것이다. 이것에 대해서는 나중에 Axis 핸들러에 대해서 논의할 때 좀 더 자세히 설명할 것이다.. . . . . .
com.mybank.bizlogic.AccountMgr. transferFunds=ROLE_MANAGER
다음으로 빈의 accessDecisionManager 속성에 누군가의 메소드 호출을 위한 접근을 허가할 것인지의 여부를 어떻게 결정할지 지정할 필요가 있다. Acegi에는 AffirmativeBased, ConsensusBased, 그리고 UnanimousBased의 세 가지 접근 결정 관리자의 구상 구현 클래스가 따른다. Acegi는 투표자가 특정 활동을 수행하기 위한 누군가의 접근을 허가할 것인가 말 것인가에 대한 투표를 하게 하는 것에 기반함으로써 접근 결정을 한다. 접근 결정 관리자로서 여기서에서는 UnanimousBased를 선택했는데, 이는 클라이언트의 특정 활동을 수행할 수 있게 하는 접근을 승인하는 투표에 모든 투표자들을 참여하게 한다. 이것이 어떻게 작동하는지에 대한 좀 더 심층적인 설명을 보려면 Acegi 문서를 읽어야 한다. 다음으로는 accessDecisionManager에 투표자 목록을 설정해야 한다. 여기에서는 Rolevoter라 불리는 하나의 투표자만을 사용할 것이다. 이 Acegi 클래스는 역할기반의 접근제어에 기반하여 접근에 대한 승인 여부를 투표한다. 다시 말하지만 여러분은 RoleVoter가 어떻게 작동하는지에 대한 상세한 설명은 Acegi 문서를 참고해야 한다.
마지막으로 설정해야 할 필요가 있는 속성은 objectDefinitionSource이다. 이것은 현재 보호되고 있는 객체상의 다양한 메소드에 접근하는데 있어 어떠한 퍼미션이 필요한지를 지정하는 것이다. 여기에서는 transferFunds() 메소드만을 보호하고 관리자에게만 접근을 허락하고자 한다. 이는 완전히 한정된(fully qualified) 클래스명과 메소드명, 그리고 그것에 접근하는데 필요한 역할의 목록을 나열함으로써 이루어진다.
com.mybank.bizlogic.AccountMgr.transferFunds= ROLE_MANAGER사용자 정의 Axis 핸들러
앞에서 언급했듯이, 우리는 웹 서비스 보안 컨텍스트와 Acegi 보안 컨텍스트를 연동시켜줄 무언가가 필요하다. 연동이 필요한 곳은 사용자 정의 Axis 핸들러인 AcegiBridgeAuthenticationHandler로 보여진다. AcegiBridgeAuthenticationHandler의 소스코드는 다운로드 가능한 샘플 코드 섹션에서 사용 가능하다. 우리는 구현을 매우 단순하게 하여 설명하기 쉽도록 하였다. 먼저 여러분이 알아챌 수도 있는 것은 그것은 어떠한 실질적인 인증은 하지 않는다는 것이다. 단순히 MessageContext에서 사용자명과 비밀번호를 가져와서 그냥 그대로 사용한다. 실제 구현은 물론 그 정보에 대하여 실질적인 검증을 시도할 것이다. 또 다른 고려할 사항은 실제 구현은 단순히 우리가 여기에서 하고 있는 Axis MessageContext 객체로부터 인증정보를 추출하는 것이 아니라 인증정보를 얻기 위하여 SOAP 메시지로부터 WS-Security 보안 헤더를 추출 및 처리해야 한다는 것이다.
인증정보를 획득한 후의 다음 단계는 그 인증정보를 Acegi에서 사용 가능토록 만드는 것이다. 이는 인증 토큰을 생성하여 Acegi 보안 컨텍스트에 할당함으로써 이루어진다. 우리는 사용자명/비밀번호 인증을 하고 있기 때문에 UsernamePasswordAuthenticationToken의 인스턴스를 생성할 것이다. 인스턴스를 생성하기 전에 우리는 이 사용자에게 어떠한 권한(예를 들어, 퍼미션과 같은)이 승인되었는지를 지정해야 할 필요가 있다. 이는 GrantedAuthority 인터페이스와 GrantedAuthorityImpl라 불리는 간단한 구현을 사용함으로써 이루어진다. 우리는 접근 의사결정에 RoleVoter를 이용하고 있으므로 우리가 승인받을 권한들은 역할들이다. 다시 한번 말하지만 관리자 역할에 대한 승인을 하드코딩해서 구현을 단순하게 하였는데, 이는 POJO상의 transferFunds() 메소드를 호출하는 데에는 승인이 필요하기 때문이다. 실제 구현은 아마도 사용자명과 비밀번호를 받아와 실질적으로 어떠한 역할이 그 계정과 연결되어 있는지 확인하기 위해 데이터베이스나 디렉터리 서버에서 찾아볼 것이다. 아니면 어떤 경우에는 그러한 정보들은 WS-Security에 SAML 검증(assertion) 형태로 사용가능 할지도 모른다.
어쨌든 일단 여기까지 완료한 다음, 사용자 이름과 비밀번호, 그리고 승인된 역할들을 전달하는 UsernamePasswordAuthenticationToken의 인스턴스를 생성한다. GrantedAuthority의 배열을 인자로 받는 형태의 생성자를 이용하여 실질적으로 Acegi에게 이 토큰은 이미 인증되었으므로 재인증 받지 말아야 함을 알린다. 다음으로 SecurityContextHolder의 정적 메소드를 호출하여 SecurityContext를 얻어온 다음 SecurityContext에 인증 토큰을 설정한다. 이제 보안 검사를 수행하는데 사용할 Acegi의 인증 및 역할 정보가 사용가능하다. 이와 같이 웹 서비스 보안 컨텍스트와 Acegi 보안 컨텍스트를 효율적으로 연동하였다.
아직도 추가적으로 고려해야 할 것들이 있다. 먼저 Acegi 역시 충분히 강력한 인증능력을 제공하므로 따라서 여러분은 Axis 핸들러가 인증을 처리하게 하는 대신 Acegi가 그것들을 처리하도록 하는 게 낫다. 이렇게 하기 위해서는 GrantedAuthority 배열을 받지 않는 생성자를 사용함으로써 인증되지 않은 인증 토큰을 생성한다. 여러분은 또한 AnonymousAuthenticationProvider를 사용하는 대신 적절한 인증 제공자를 지정하도록 할 필요가 있을 것이다. 다음으로 Acegi는 단순한 사용자 이름/비밀번호 인증 이외의 것들도 제공한다. 예를 들어, 여러분이 PKI 기반의 인증을 하고 있다면 여러분은 UsernamePasswordAuthenticationToken 대신 X509AuthenticationToken을 사용할 수 있다.
마지막으로 Axis로 하여금 이 핸들러를 서비스의 요청-처리 경로에 포함하도록 설정할 필요가 있다. 이것은 다음의 사항들을 Axis 설정 파일인 deploy.wsdd와 server-config.wsdd에 추가함으로써 이루어진다:
결론. . . . . .
관심의 분리는 서비스 지향 아키텍처를 개발하기 위한 중요한 원칙이다. 그러나 그것은 아키텍처 단계에서뿐만 아니라 구현 단계에서도 적용되어야 할 필요가 있다. 이 기사에서는 SOA 원칙에 충실한 안전한 웹 서비스를 구현하기 위해 Axis, 스프링, 그리고 Acegi를 어떻게 사용해야 하는지에 대해 설명하였다. 샘플 코드에서도 보았듯이 이러한 접근법을 사용하는 것은 우리가 서비스의 각 관심사를 처리하는 코드내의 횡적 의존성(cross-dependency)을 최소할 수 있도록 해준다. 우리가 보여준 예제는 일부러 단순하게 만들었지만 그것은 웹 서비스 보안과 Acegi에서 제공된 애플리케이션 단계의 보안을 결합한 강건한 보안 메커니즘을 지닌 웹 서비스를 개발하는 토대로서 받아 들어져야 한다. 앞에서 언급했다시피 실제 시스템은 WS-Security 헤더를 처리하고 그것들을 Acegi 보안 컨텍스트와 연동시킬 수 있는 핸들러를 개발해야 할 필요가 있을 것이다. 이를 이룰 수 있는 한가지 방법은 WSS4J를 채택하는 것인데, 이는 아파치에서 제공되며 이 기사에서도 기술했듯이 자체 Axis 핸들러를 확장하여 Acegi 보안 컨텍스트에서도 사용할 수 있게끔 해준다. 여러분은 Acegi 보안 예외를 잡아내고 좀 더 의미있는 SOAP 실패내역을 클라이언트에게 돌려주는 Axis 외부 핸들러를 생성하려면 추가적인 작업을 해야 할지도 모른다.
리소스
- 이 기사에서 사용된 예제에 대한 완전한 소스코드, 환경설정 파일, 빌드 파일. 예제를 빌드하고 실행하기 위해서는 Axis, 스프링, Acegi 라이브러리는 아래의 링크에서 구하여야 한다.
- 아파치 Axis
- 스프링 프레임워크
- 스프링용 Acegi 보안 시스템
- WS-Security, OASIS의 웹 서비스 보안 표준
- WSS4J, WS-Security의 아파치 구현
TAG :
이전 글 : XAML로 사진 업로더 만들기
다음 글 : 웹 응용프로그램 보안 취약점 발견하기
최신 콘텐츠