네이밍 역할
J2EE(Java™ 2 Platform, Enterprise Edition) 역할 기반 권한 개념은 CosNaming 서비스를 보호하도록 확장되었습니다.
CosNaming 보안은 CosNaming 기능에 대한 보안 제어의 증가된 세분성을 제공합니다. CosNaming 기능은 WebSphere® Application Server와 같은 CosNaming 서버에서 사용 가능합니다. 이러한 기능은 네임스페이스의 내용에 영향을 줍니다. 일반적으로 클라이언트 프로그램에서 CosNaming 호출이 생성되는 방법으로는 두 가지가 있습니다. 첫 번째는 JNDI(Java Naming and Directory Interface) 메소드를 통한 방법입니다. 두 번째는 CosNaming 메소드를 직접 호출하는 CORBA 클라이언트입니다.
- CosNamingRead. CosNamingRead 역할이 지정되는 사용자는 JNDI 검색 메소드와 같은
네임스페이스 조회를 수행할 수 있습니다. Everyone 특수 주제는 이 역할에 대한
기본 정책입니다.
표 1. CosNamingRead 역할 패키지 및 인터페이스 메소드. 다음 표는 CosNamingRead 역할 패키지 및 인터페이스 메소드를 나열합니다. 패키지 인터페이스 메소드 javax.naming - Context.list
- Context.listBindings
- Context.lookup
- NamingEnumeration.hasMore
- NamingEnumeration.next
org.omg.CosNaming - NamingContext.list
- NamingContext.resolve
- BindingIterator.next_one
- BindingIterator.next_n
- BindingIterator.destroy
- CosNamingWrite. CosNamingWrite 역할이 지정된 사용자는 쓰기 조작(예: JNDI 바인드, 리바인드 또는 바인드 취소) 및
CosNamingRead 조작을 수행할 수 있습니다. 기본 정책으로서, 이 역할에는 주제가 지정되지 않습니다.
표 2. CosNamingWrite 역할 패키지 및 인터페이스 메소드. 다음 표는 CosNamingWrite 역할 패키지 및 인터페이스 메소드를 나열합니다. 패키지 인터페이스 메소드 javax.naming - Context.bind
- Context.rebind
- Context.rename
- Context.unbind
org.omg.CosNaming - NamingContext.bind
- NamingContext.bind_context
- NamingContext.rebind
- NamingContext.rebind_context
- NamingContext.unbind
- CosNamingCreate. CosNamingCreate 역할이 지정된 사용자는 JNDI createSubcontext 조작 및 CosNamingWrite 조작을 통해
네임스페이스에서 새 오브젝트를 작성할 수 있습니다. 기본 정책으로서, 이 역할에는 주제가 지정되지 않습니다.
표 3. CosNamingCreate 역할 패키지 및 인터페이스 메소드. 다음 표는 CosNamingCreate 역할 패키지 및 인터페이스 메소드를 나열합니다. 패키지 인터페이스 메소드 javax.naming Context.createSubcontext org.omg.CosNaming NamingContext.bind_new_context - CosNamingDelete. CosNamingDelete 역할이 지정된 사용자는 예를 들어, JNDI destroySubcontext 메소드 및
CosNamingCreate 조작을 사용하여 네임스페이스에 있는 오브젝트를 삭제할 수 있습니다. 기본 정책으로서, 이 역할에는 주제가 지정되지 않습니다.
표 4. CosNamingDelete 역할 패키지 및 인터페이스 메소드. 다음 표는 CosNamingDelete 역할 패키지 및 인터페이스 메소드를 나열합니다 패키지 인터페이스 메소드 javax.naming Context.destroySubcontext org.omg.CosNaming NamingContext.destroy
- javax.naming
- 이 패키지는 CosNaming 메소드 호출에서 NoPermissionException으로 NO_PERMISSION을 맵핑하는 javax.naming.NoPermissionException 예외를 작성합니다.
- org.omg.CosNaming
- 이 패키지는 org.omg.CORBA.NO_PERMISSION 예외를 작성합니다.
언제든지 WebSphere Application Server 관리 콘솔에서 사용자, 그룹 또는 특수 주제 AllAuthenticated 및 Everyone을 네이밍 역할에 추가하거나 제거할 수 있습니다. 그러나 변경사항을 적용시키려면 서버를 다시 시작해야 합니다. 가장 좋은 방법은 특정 사용자가 아닌 그룹 또는 특수 주제 중 하나에 맵핑시키는 것입니다. 장기간 관리하기에는 이 방법이 보다 융통성이 있고 쉽습니다. 그룹을 네이밍 역할에 맵핑하면 사용자를 그룹에(서) 추가하거나 제거하는 조작이 WebSphere Application Server 외부에서 발생하므로, 변경사항을 적용하기 위해 서버를 다시 시작할 필요가 없습니다.
사용자에게 특정 네이밍 역할이 지정되고 이 사용자가 다른 네이밍 역할에 지정된 그룹의 멤버인 경우 이 사용자에게는 자신에게 지정된 역할과 해당 그룹에게 지정된 역할 사이의 가장 큰 액세스 권한이 부여됩니다. 예를 들어, MyUser 사용자에게 CosNamingRead 역할이 지정된 것으로 가정합니다. 또한 MyGroup 그룹에 CosNamingCreate 역할이 지정된 것으로 가정합니다. MyUser 사용자가 MyGroup 그룹의 멤버인 경우 MyUser 사용자에게는 MyGroup 그룹의 역할인 CosNamingCreate 역할이 지정됩니다. MyUser 사용자가 MyGroup 그룹의 멤버가 아닌 경우 CosNamingRead 역할이 지정됩니다.
CosNaming 권한 정책은 관리 보안이 사용 가능할 때만 강제 실행됩니다. 관리 보안을 사용할 수 있을 때 적절한 역할을 지정하지 않고 CosNaming 조작을 수행하려고 시도하면 CosNaming 서버에서 org.omg.CORBA.NO_PERMISSION 예외가 발생합니다.
WebSphere Application Server에서는 각 CosNaming 기능이 하나의 역할에만 지정됩니다. 따라서 CosNamingCreate 역할이 지정된 사용자는 CosNamingRead 역할도 함께 지정되지 않는 한 네임스페이스를 조회할 수 없습니다. 대부분의 경우 작성자에게는 세 가지 CosNamingRead, CosNamingWrite 및 CosNamingCreate 역할이 지정되어야 합니다. 예에서 작성자에 대한 CosNamingRead 및 CosNamingWrite 역할 지정은 CosNamingCreate 역할에 포함되었습니다. 대부분의 경우, 이전 릴리스에서 이 릴리스로 이동할 때 WebSphere Application Server 관리자가 모든 사용자 또는 그룹에 대한 역할 지정을 변경할 필요는 없습니다.
기본 정책을 변경하여 네임스페이스에 대한 액세스를 엄격히 제어할 수도 있지만 이러한 경우 런타임에서 예상치 못한 org.omg.CORBA.NO_PERMISSION 예외가 발생할 수 있습니다. 일반적으로 J2EE 애플리케이션이 네임스페이스에 액세스하며 ID는 J2EE 애플리케이션이 액세스할 때 WebSphere Application Server에 인증된 사용자의 ID입니다. J2EE 애플리케이션 제공자가 예상 네이밍 역할과 확실하게 통신하지 않는 경우 기본 네이밍 권한 정책 변경을 고려해야 합니다.