JEUS 보안 시스템에서 로그인은 Subject를 실행 Thread(Java Thread)에 결합시키는 것을 의미한다. 이 개념은 인증과는 다르다. 일반적으로 Subject가 실행 Thread와 결합되기 전에 인증이 일어난다. 만약 성공적으로 인증되면 로그인은 정상적으로 진행되어 Subject와 Thread가 결합하게 되지만, 인증에 실패하면 로그인은 더 이상 진행되지 않는다.

Subject가 성공적으로 로그인한 후에 로그인된 Subject를 대상으로 권한 체크가 이루어진다. 따라서, 로그인은 인증과 권한 체크, 양쪽 모두에 걸쳐있다고 할 수 있다. 로그인의 반대 개념은 로그아웃으로 현재 Subject를 실행 Thread로부터 분리하는 과정이다.

로그인 이면에는 다음과 같은 Stack 기반 오퍼레이션이 있다. 여러 개의 서로 다른 Subject로 로그인했을 경우 최근에 로그인한 Subject부터 Stack의 최상단에 쌓인다. 그 후 권한 체크에는 Stack의 최상단에 놓인 Subject(가장 최근에 로그인한 Subject)를 사용한다. 이 Subject가 로그아웃하고 나면, Stack으로부터 제거되고 바로 직전에 로그인한 Subject가 Export되어 활성화된다.

다음은 이 메커니즘에 대한 설명이다.

JEUS Subject는 UML로 다음과 같이 표기할 수 있다.

JEUS 보안 시스템에서 권한 체크는 이미 성공적으로 인증된 Subject가 특정 액션을 실행시킬 권한이 있는지 여부를 확인하는 것이다.

권한 체크는 보통 시스템 레벨에서 일어난다. 특정 Subject(보통 administrators)가 JEUS 서버를 기동 또는 종료시킬 권한을 가지고 있는지 여부를 체크하는 것이다. 또한 권한 체크는 애플리케이션 레벨에서도 일어난다. 원격지 호출자가 특정 애플리케이션 컴포넌트(특정 Jakarta™ Enterprise Beans 메소드의 실행, 특정 Servlet 호출)에 접근할 수 있는지 여부를 JEUS 엔진에서 확인하는 것은 여기에 해당한다.

그리고 Role "R"은 Resource "jndi" 리소스에 접근해 Action "lookup"을 실행할 수 있는 Resource Permission을 가지고 있다고 가정한다.

다음은 이러한 개념에 대한 설명이다.

기본적인 Permission-Based 매핑과는 별도로 권한 부여 시스템에서 모든 Permission은 다음 3가지 카테고리 중에 하나에 속한다.

이에 대한 몇 가지 예제들은 다음에 더 살펴본다.

Policy는 2가지 종류의 PermissionMap을 가지고 있다.

이들은 각각 Principal-to-Role 매핑과 Role-to-Resource 매핑을 나타낸다. 각 PermissionMap은 다시 위에서 언급한 3가지 종류(Excluded, Unchecked, Ckecked)의 Permission들을 포함하고 있다. Checked Permission의 경우 Permission과 RolePermissionMap은 Principal이나 Role을 매개로 결합되어 있고, Policy와 ResourcePermissionMap은 Context ID(권한 체크가 일어나는 범위를 나타낸다)를 통해 결합되어 있다.

다음은 Policy와 PermissionMap의 UML 다이어그램을 나타낸다.

박스 내의 타원은 Name과 Action을 가진 실제 Permission 인스턴스(Name: Action)를 나타내고 있다.

Context ID가 "A"이고, Principal이 "user1"인 Subject가 "JNDI"에 접근해서 "modify"라는 액션을 실행하고 싶다고 가정했을 때 과연 "user1"은 원하는 액션을 실행할 수 있을까?

권한 부여 시스템은 이 요구사항을 다음과 같은 방식으로 풀어나간다.

"user1"이 "Administrator" Role에 매핑되어 있지만, "Administrator" RolePermission이 Excluded Permission이므로 "user1"을 포함한 누구도 "Administrator" Role에 접근할 수 없게 된다. 이는 Excluded Permission이 Unchecked Permission과 Checked Permission보다 우선순위가 높기 때문이다.

위에서 설명한 대로 차근 차근 과정을 따라가 보면 다음 권한 체크 질의가 어떻게 풀릴지 알 수 있을 것이다.

보안 감사는 일반적으로 보안과 관련된 이벤트(인증 실패, 런타임 예외 발생)를 포착하여 적절히 처리함으로써 전반적인 보안 품질을 향상시키는 것이다.

JEUS 보안 시스템은 보안 이벤트를 기반으로 하는 단순하지만 유연한 보안 감사 메커니즘을 특징으로 한다. 주요한 이벤트가 발생할 때마다(인증 실패, 권한 부여 실패, 관심도가 높은 기타 이벤트) 이벤트는 미리 등록된 이벤트 핸들러에 포착된다. 커스텀 핸들러 구현 클래스는 이에 적절하게 대응한다.

예를 들어 한 번에 연속적으로 너무 많이 인증에 실패할 경우 해당 Subject의 Credential에 Lock을 걸도록 할 수 있다.

보안 시스템에서 서비스 인스턴스는 각각이 특정 보안 기능을 제공하는 독립적인 실체로 간주된다. 그러나 종종 서비스는 다른 SPI를 호출하기도 하기 때문에 서비스 간의 어느 정도 의존성은 존재한다. 서비스를 초기화하기 위해 모든 서비스는 "key-value"로 이루어진 한 쌍의 속성값을 전달받는다. 이러한 데이터는 설정 파일을 사용해서 저장해둘 수도 있다.

모든 서비스는 선택사항으로 JEUS 관리 시스템에 보고할 JMX Bean을 정의하기도 한다. JMX MBean은 보통 Service.getMBeanInfo() 메소드로부터 리턴받은 MBeanInfo를 기반으로 생성된다.

또한 모든 서비스는 생성(created)과 소멸(destroyed) 상태를 가지고 있다 . 이 두 상태 간의 전이는 create()와 destroy()가 불려질 때 발생한다. 이 메소드를 호출하면 실제 추상 메소드인 doCreate()와 doDestroy() 메소드가 호출된다. 이 추상 메소드들은 서비스 서브 클래스에서 구현되는데, 서비스를 초기화하고 서비스를 정리하는 작업을 포함한다.

보안 도메인(Security Domain)은 보안 서비스 인스턴스의 집합이라 할 수 있다. 하나의 보안 시스템에 여러 개의 도메인이 동시에 있을 수 있다. 도메인 개념의 배경에는 서로 다른 애플리케이션이나 JEUS 서브 시스템이 각각 별도의 보안 서비스를 사용하도록 하는 데 있다. 도메인은 보안 서비스를 각 애플리케이션별로 분리하는 역할을 한다.

예를 들어서 JEUS 시스템만 사용하는 특별한 도메인을 설정할 수 있다. JEUS가 사용하는 도메인을 SYSTEM_DOMAIN이라고 한다. 이 도메인은 JEUS를 관리하는 데 사용하는 Subject와 Policy를 포함하고 있다. SYSTEM_DOMAIN에 서버를 부트 또는 다운할 수 있는 "administrator"라는 메인 Subject에 대한 사용자 정보를 설정할 수 있을 것이다.

다음은 도메인 개념을 보여주고 있다.

본 절에서는 보안 시스템을 사용하면서 JEUS 서버 전체에 미치는 성능의 영향력을 최소화시키는 방법을 설명한다.

보안 시스템의 전반적인 성능을 향상시키는 방법은 다음과 같다.

본 절에서는 성능을 희생하더라도 보안 시스템에서 전반적인 보안 수준을 향상시키는 방법에 대해 설명한다.

JEUS의 전반적인 보안 수준을 향상하기 위한 방법은 다음과 같다.