KR100358876B1 - 네트워크 환경에의 액세스를 검증하기 위한 방법 및 시스템 - Google Patents

Abstract

본 발명의 예시적인 실시예는 관리 용도로 사용되는 분산 네트워크 환경 내의 관리 기능을 자동화하고, 상기 네트워크 내의 복수의 상이한 유형의 엔티티에 대한 엔티티로의 액세스 권한을 검증하는 방법이다. 이 방법은 사용자 ID의 리스트를 컴파일하는 것을 포함하고, 사용자 ID는 적어도 하나의 시스템과 관련된다. 어드레스 북은 검색되고 이 리스트내의 데이터는 어드레스 북내에 포함된 데이터와 비교된다. 이 리스트내의 무효 데이터는 플래그된다. 사용자 정의 레포트가 리스트 내의 데이터를 어드레스 북내에 포함된 데이터와 비교한 결과에 기초하여 발생된다. 이 방법을 구현하기 위한 시스템 및 방법이 또한 개시된다.

Description

네트워크 환경에의 액세스를 검증하기 위한 방법 및 시스템{METHOD AND SYSTEM FOR VERIFYING ACCESS TO A NETWORK ENVIRONMENT}

현재 많은 조직은 사용자가 분산 리소스 및 프로세스 어플리케이션에 액세스하는 분산 컴퓨팅 환경(DCE)과 상호 접속되는 다중 컴퓨터를 사용하고 있다. 다양한 어플리케이션이 데이터 공유와 같은 분산 서비스, 프린팅 서비스 및 분산된 파일 시스템을 통한 데이터 베이스 액세스를 제공하는데 이용될 수 있다.

분산된 파일 시스템은 데이터 및 리소스의 보다 높은 유용성, 초대규모 시스템 전체에 걸쳐 정보를 공유하는 능력, 및 안전 메카니즘의 사용을 통한 정보의 보호와 같이, 스탠드얼로운 파일 서버보다 많은 장점을 제공한다. 분산된 파일 시스템은 또한 글로벌 네임스페이스(namespace)내의 다양한 파일 시스템에 저장된 파일의 모두를 불러 모은다. 다중 서버는 그들의 파일 시스템을 이 네임스페이스에 엑스포트(export)할 수 있다. 그런데, 모든 분산된 파일 시스템 사용자는 이 네임스페이스를 공유하여, 어떤 분산된 파일 시스템으로부터 용이하게 유용한 모든 분산된 파일 시스템 파일을 만든다.

DCE가 간단히 피어-투-피어(peer-to-peer) 결합된 2개의 컴퓨터, 또는 수천의 사용자를 갖는 광역망인지에 관계없이, 안전 시스템은 전형적으로, 네트워크 상의 엔티티들(entities)(프린터, 모뎀, 다른 네트워크, 디렉토리, 파일, 데이터 등)에의 액세스 권한을 제한하고 네트워크에 접속할 수 있는 각 사용자를 식별하기 위해 포함될 것이다.

컴퓨터 네트워크 상의 엔티티에의 액세스의 제어는 매우 중요하다. 본래 개인적이거나 전유의 또는 민감한 정보를 포함하는 데이터는 네트워크에 접속된 사용자 모두에 의해 자유롭게 액세스되지 않아야 한다. 예를 들어, 이메일(e-mail) 메시지는 의도된 수령자에 의해서만 액세스되어야 한다. 회사내의 각 종업원에 관한 상세 정보를 포함하는 개인 데이터 파일은 한정된 그룹, 예를 들어 회사의 인적 자원부서내의 사람들에 의해서만 액세스되어야 한다. 파일의 내용을 변경하고 파일을 읽고 또는 파일을 실행하는 권한은 보통 프로그램을 실행할 수 있는 사용자의 수를 제한하는 라이센싱 요건을 만족시키거나 또는 네트워크 완전성을 유지하기 위해 특정한 사용자에게 제한된다.

네트워크 또는 시스템 관리자(administrator)에게는 전형적으로 정의된 사용자 그룹을 설정하고 유지하고, 네트워크에 접속할 권한이 누구에게 있는지를 결정하고, 네트워크 상의 엔티티에 대한 각 그룹 및 개인 사용자의 권한을 초기에 결정하기 위한 책임이 할당되어 있다. 한 그룹은 정상적으로 액세스 권한이 초기에 허용되는 엔티티에 대한 어떤 공통 관계를 갖는 하나 이상의 사용자를 포함할 것이다. 예를 들어, 회사의 어카운팅 부서내의 서기는 "Accounting Group"을 포함하고, 이 그룹은 소정의 어카운팅 프로그램에 그리고 소정의 어카운팅 데이터 파일에 전권을 갖고 다른 사람에게 권한을 제한한다. 어카운팅 부서의 관리자는 전형적으로 "어카운팅 그룹"의 일원일 것이고 또한 보다 민감한 어카운팅 데이터 파일에 전권을 갖고, 극도로 민감한 어카운팅 데이터 파일의 권한을 제한하는 "Accounting Supervispr Group"의 일원일 것이다.

그룹 또는 개인 사용자에게 허용된 권한은 그 그룹의 멤버 또는 사용자가 시스템 상의 다른 엔티티에의 액세스를 제어할 수 있는지를 결정할 수 있다. 그러므로, 디렉토리에 전권을 갖는 사용자는 그 디렉토리에 또는 그 디렉토리의 서브디렉토리 또는 사용자가 그 디렉토리내에서 생성한 파일에 네트워크 상의 다른 사용자에 의한 액세스를 제어할 수 있다.

엔티티에 대한 액세스 제어의 한 형태는 일련의 액세스 제어 엔티티(ACE)로 구성된 엑세스 제어 리스트(ACL)를 이용한다. ACL은 네트워크 상의 엔티티에 관련될 수 있다. ACE는 전형적으로 사용자 또는 그룹(특정된 플랫폼 또는 오퍼레이팅 시스템)에 대한 식별자 및 오브젝트에 대하여 그 사용자 또는 그룹에 허용되거나 거부된 권한을 특정하는 어떤 엔코딩 및 레프리젠테이션(representation)을 포함한다. 엔티티 상의 오브젝트에의 권한을 구하는 개인 사용자 또는 그룹은 "요구자"라고 한다. 액세스 마크는 엔티티 및/또는 그것이 사용되는 환경과 관련되는 오퍼레이션의 엔코딩을 레프리젠트한다. 따라서, ACL은 엔티티 및 그 액세스의 성질에 누가 액세스하는지를 특정한다.

보다 큰 네트워크에서는, 액세스 관리(administration)는 시간 소모적이고 상당한 사람의 개입을 필요로 한다. 전형적인 시스템 또는 액세스 관리 시스템은 하나의 위치에 집중되고 한 사람 또는 부서에 의해 관리된다. 전형적인 시스템 또는 액세스 관리자는 DCE내에서의 사용을 위한 액세스 시스템을 개발하고, 구현하고 계속적으로 업데이팅하는데 책임이 있다. 예를 들어, 새로운 패스워드의 요구는 요구됨에 따라 개인적으로 평가되고 승인(거부)될 필요가 있다. 이 처리는 각 요구에 대해 보다 많은 처리시간으로 변환하는 시스템으로 변화가 입력되기 전에 다양한 개인 또는 부서에 의한 동의 또는 고려의 다중 레벨과 관련할 것이다. 부가적으로, 시스템 또는 액세스 관리자는 액세스 권한이 조직의 필요가 요함에 따라 허용되는 시스템 기준을 계속적으로 업데이트할 필요가 있을 것이다. 이 데이터의 수동 조작의 양이 많을수록, 에러의 위험이 일어날 가능성이 높다. DCE내의 액세스 관리의 이 시스템을 용이하게 하고 자동화하는 것이 바람직하다.

본 발명의 예시적인 실시예는 네트워크내의 복수의 서로 다른 형태의 엔티티에 대한 엔티티에의 액세스 권한을 관리하고 검증하는데 사용하기 위한 분산 네트워크 환경에서의 관리를 자동화하기 위한 방법이다. 이 방법은 사용자 IDS의 리스트를 컴파일하는 것을 포함하고, 사용자 ID는 적어도 하나의 시스템과 관련된다. 어드레스 북이 검색되고 이 리스트 내의 데이터는 어드레스 북내에 포함된 데이터와 비교된다. 리스트내의 무효 데이터는 플래그된다(flagged). 사용자 정의된 레포트가 다음에 어드레스 북내에 포함된 데이터와 리스트내의 데이터를 비교한 결과에 기초하여 발생된다. 이 방법을 구현하기 위한 시스템 및 저장 매체가 또한 개시된다.

도 1은 액세스가 제어되는 복수의 워크스테이션 및 서버를 포함하는 시스템의 부분의 블럭도.

도 2는 관리자가 고객 데이터 베이스를 선택적으로 구성하고 변경하게 하는 풀 다운 메뉴 및 고객 윈도우를 포함하는 예시적인 관리 스크린.

도 3은 관리자가 어떻게 다른 원하는 기준 뿐만 아니라, 고객 내의 시스템 식별자를(SID)를 선택적으로 구성할 수 있는지를 도시한 예시적인 유지 윈도우.

도 4는 각각의 프로젝트 또는 그룹에 대해 할당된 SID 뿐만 아니라 주어진 고객에 대해 정의된 프로젝트 또는 그룹을 도시한 사용자에 의해 보여지는 예시적인 웹 스크린.

도 5는 관리자가 어떻게 주어진 SID에 대한 메인 액세스 프로필을 생성하고, 변경하고 또는 삭제하는지를 예시하는 예시적인 관리 스크린 및 메인 액세스 프로필 윈도우이며, 도 5a는 관리자가 SID 내의 새로운 액세스 파일을 어떻게 선택하는 지를 예시한 예시적인 액세스 프로필 윈도우.

도 6은 관리자가 SID 내의 클라이언트를 선택적으로 구성하게 하는 풀 다운 메뉴 및 클라이언트 윈도우를 포함하는 예시적인 관리 스크린.

도 7은 관리자가 SID를 위한 시스템 인증자 또는 승인자를 선택적으로 구성하게 하는 풀다운 메뉴 및 어프루버를 포함하는 예시적인 관리 스크린.

도 8은 관리자가 큐내의 펜딩 인증인 요구의 상태를 검토하게 하는 풀다운 메뉴 및 메인티넌스 윈도우를 포함하는 예시적인 관리 스크린.

도 9는 관리자가 큐내의 개인적인 요구에 관한 특정한 상세를 검토하게 하는 메인티넌스 윈도우 및 사용자 데이터 윈도우를 포함하는 예시적인 관리 스크린.

도 10은 관리자가 수동으로 처리되어야 하는 승인된 요구를 실행하게 하는 풀다운 메뉴 및 "Complete/Reject User Request"를 포함하는 예시적인 관리 스크린.

도 11은 네트워크 상의 엔티티에의 액세스를 선택 및 제어하도록 구현되는 논리적 단계를 도시한 예시적인 흐름도.

도 12는 관리자가 그들이 액세스 허용된 시스템에의 액세스를 어떤 사용자가 계속 요구하는지를 주기적으로 평가하게 하는 풀다운 메뉴 및 재검증 윈도우를 포함하는 관리 스크린.

도 13은 관리자가 액세스 요구가 평가될 사용자 그룹을 선택하고 정의하게 하는 예시적인 재검증 윈도우.

도 14는 시스템 또는 액세스 요구의 평가를 위해 관리자에 의해 선택된 클라이언트 내의 사용자 그룹을 포함하는 정보의 테이블을 디스플레이하는 재검증 테이블을 포함하는 예시적인 관리 스크린.

도 15는 관리자가 테이블내에 식별된 사용자가 여전히 종사하고 있는 지를검증하고 사용자 데이터를 저정하고 업데이트하게 하는 재검증 위도우 및 풀다운 메뉴를 포함하는 예시적인 관리 스크린.

도 16은 관리자가 사용자 데이타에 관한 다양한 레포트를 발생하게 하는 재검증 윈도우 및 풀다운 메뉴를 포함하는 예시적인 관리 스크린.

도 17은 관리자가 사용자 액세스 요구를 검증하도록 요구된 사용자 데이터의 리스팅을 디스플레이하는 수신 관리자에 의해 보여지는 예시적인 메일 레포트.

도 18은 관리자가 재검증 메일 레포트 처리를 관리하게 하는 예시적인 재검증 상태 레포트 스크린.

도 19는 관리자가 사용자 식별 관리 시스템 내에 포함되고 하나 또는 많은 서로 다른 선택된 기준에 의해 구성될 수 있는 다양한 데이터를 서치하게 하는 로그 뷰어 윈도우를 포함하는 예시적인 관리 스크린.

도 20은 관리자가 특정된 SID(들) 또는 클라이턴트(들)의 서치를 더욱 한정하게 하는 로그 뷰어 툴의 예시적인 서치 기능 윈도우.

도 21은 자동 패스워드 리셋을 위해 구현되는 논리적 단계를 도시한 예시적인 흐름도

<도면의 주요부분에 대한 부호의 설명>

10: 시스템

12, 14, 16: 서버

18: 네트워크

20, 22: 워크스테이션

30: 하드 드라이브

32: 디스플레이 스크린

사용자 식별 관리 시스템은 전형적으로 하나 이상의 서버 및 분산 컴퓨팅 환경(DCE) 내에 상호 접속된 하나 이상의 엔티티를 포함하는 시스템을 통해 구현될 것이다. 본 발명이 사용될 수 있는 예시적인 시스템(10)의 부분이 도 1에 도시되어 있다. 본 발명의 장점을 실현하기 위해 반드시 필요한 것은 아니지만, 시스템(10)은 서로 다른 지리적 위치가 고속 데이터 라인 또는 광범위하게 분리된 위치에서 수백개의 워크스테이션을 상호 접속하는 무선 링크에 의해, 상호 접속되는 광역망의 일부일 수 있다. 도 1의 간략화된 도면에서, 단지 3개의 서버(12, 14, 및 16)가 네트워크(18)에 의해 2개의 워크스테이션(20 및 22), 및 프린터(38)에 접속된 것으로 도시된다. 본 기술 분야에 통상의 지식을 가진 자는 본 발명은 또한 토큰 링 또는 스타 구성과 같이, 다중 형태의 네트워크 구성으로 사용될 수 있다는 것을 이해할 것이다. 네트워크된 시스템에서 전형적인 바와 같이, 서버(12, 14, 및 16) 각각은 워크스테이션(20 및 22)에 의해 액세스될 수 있는 데이터 및 어플리케이션을 포함하는 복수의 파일이 저장되는 적어도 하나의 하드 드라이브(24)를 포함한다. 또한, 각각의 서버는 모니터(26)를 구비한다. 특별하게 도시되어 있지 않지만, 각각의 서버는 또한 서버의 동작을 구성하고 제어하는데 사용되는 명령 및 데이터의 입력을 위한 키보드에 결합될 수 있다.

워크스테이션(20 및 22) 각각은 워크스테이션 내의 마더보드(도시 안됨) 상에 배치된 중앙 처리 장치(CPU)에 의해 실행될 수 있는 프로그램을 저장하기 위한 하드 드라이브(30)를 포함하는 범용 컴퓨터일 수 있다. 디스플레이 스크린(32)이 워크스테이션 각각 위에 제공된다. 사용자는 워크스테이션을 제어할 수 있고 키보드(34) 및/또는 마우스(36)(또는 다른 적합한 입력 장치)를 통해 명령 및 데이터의입력을 제공한다. 워크스테이션(20 및 22) 각각은 네트워크(18)를 통해 임의의 서버(12, 14, 또는 16)에 액세스할 수 있다.

위에 설명된 바와 같이, 컴퓨터 네트워크 상의 엔티티에의 액세스 제어는 중요하다. 네트워크 또는 시스템 관리자는 다른 사용자에 의해 네트워크내의 이들 엔티티에의 액세스를 설정하고 유지하는 것을 담당한다. 사용자 식별 관리 시스템은 요구, 요구의 승인, 및 이들 요구를 네트워크 인터페이스를 프론트 엔드로서 이용하는 쉬운 사용자 친근 툴로의 구현을 구성하도록 설계된다.

사용자 식별 관리 시스템이 설정될 때, 레벨 1 관리자라고 하는 액세스 전권을 갖는 관리자가 네트워크 허용 구조를 셋업하기를 시작할 수 있다. 아래에 더 설명되는 바와 같이, 사용자 식별 관리 시스템은 각각의 고객이 다중 그룹/프로젝트, 각각의 프로젝트 다중 시스템 식별자(SID) 및 각각의 SID 다중 클라이언트를 갖는 단일 또는 다중-고객 베이스를 지원할 수 있다.

다중 레벨 1 관리자는 주어진 네트워크에서 지정될 수 있다. 게다가, 임의의 레벨 1 관리자는 임의의 레벨 1 또는 레렐 2 ID를 생성하거나 삭제하도록 액세스하고 임의의 다른 레벨 1 또는 레벨 2 ID에 대한 어드레스 또는 패스워드를 변경할 수 있다. 처음에는, 레벨 1 관리자는 사용자 식별 관리 시스템에 로그 온하고 다중 레벨에 교차하는 허용 구조를 셋업하거나 정의한다. "customer"는 일반적인 용어이고 개별적인 조직의 필요에 일치하는 방식으로 레벨 1 관리자에 의해 정의될 수 있거나, 또는 다르게는, 함께 생략될 수 있다. 예를 들어, 보다 큰 네트워크에서, 복수의 고객이 요구되는 경우에, 고객은 조직 내의 많은 디비젼 또는 부서 중하나로서 정의될 수 있다. 보다 작은 네트워크에서, 고객 데이터베이스는 요구되지 않을 수 있고 함께 생략될 수 있다. 임의 수의 고객이 지정될 수 있다.

도 2는 관리자가 선택된 특정한 디렉토리 또는 파일에 대한 액세스 허용을 설정할 수 있는 사용자 식별 관리 시스템 'administration' 스크린(50)의 예를 도시한다. 툴 바(52)는 본 발명이 액세스가능한 어플리케이션을 식별한다. 도 2에 도시된 바와 같이, "Admin"이라고 표시된 옵션(54)은 툴 바(52)로부터 선택되었고, 복수의 부가 메뉴 옵션이 드롭 다운 리스트 박스(또는 풀 다운 메뉴)(56)에 디스플레이되게 하고, 그 중 네번째는 "change customers"이라고 읽히는 옵션(58)이다. 옵션(58)을 선택함으로써, 레벨 1 관리자는 요구된 고객을 추가, 변경 또는 삭제할 수 있다. 도 2는 8명의 고객(62)이 이미 생성 및 정의되고 8개의 미리 정의된 고객 코드(64)가 각각의 고객에 각각 할당되는 고객 윈도우(60)의 예를 도시한다. 예시적인 실시예에서, 레벨 1 관리자만이 고객을 추가 또는 삭제하는 액세스가 허용된다. 그러나, 레벨 1 관리자는 기존의 고객에 관한 정보를 변경하기 위해 레벨 2 관리자에 액세스 허가를 줄 수 있다. 고객을 추가하기 위해서, 레벨 1 관리자는 도 2의 고객 스크린 상의 "add" 기능(66)을 선택한다.

윈도우가 나타나고(도시 안됨) 사용자에게 고객 코드 및 고객 이름(도시 안됨)을 입력하라고 요구한다. 사용자는 다음에 처리를 완료하기 위해 "commit" 버튼(도시 안됨)을 선택한다(또는 선택적으로 액션을 포기하기 위해 "cancel" 버튼을 선택한다). 레벨 1 관리자에 의해 입력된 고객 코드 및 이름은 즉각 메인 메뉴 페이지(도시 안됨)상에 반영된다. SID는 이제 이 고객에 할당될 수 있다.

SID는 사용자가 도 1의 네트워크를 통해 사용자가 SID의 형태 및 SID에의 액세스를 소유하거나 제어하는 관리자에 액세스할 수 있는 시스템을 식별하는 톡특한 식별이다. 도 3은 레벨 1 관리자가 고객에 새로운 SID를 추가할 수 있는 사용자 식별 관리자 시스템 'maintenance' 윈도우(68)를 도시한다. 레벨 1 관리자만이 SID를 추가 또는 삭제할 수 있다. 그러나, 레벨 1 관리자는 레벨 2 관리자에 의해 제어되는 기존의 SID에 관한 정보를 변경하기 위해 레벨 2 관리자에게 액세스 허가를 줄 수 있다. SID를 추가하기 위해, 레벨 1 관리자는 도 2의 툴바(52) 상에서 SID 옵션(70)을 선택하고 풀다운 메뉴(도시 안됨)로부터 "new"를 클릭한다. 도 3에서 참조된 윈도우(68)가 나타난다. 레벨 1 관리자는 SID 박스(72) 내의 SID를 식별하는 고유 식별자를 할당하고 다음에 도 4에서 94로 도시된 바와 같이 메인 네트워크 페이지 상에 나타나도록 원해지는 대로 디스크립션 박스(74)에 시스템의 디스크립션을 입력한다. 레벨 1 관리자는 다음에 풀다운 메뉴(76)로부터 이 시스템을 소유하는 admin ID를 선택한다. SID에 관한 다른 정보는 도 3에 도시된 바와 같이 입력될 수 있다.

레벨 1 관리자는 다음에 풀다운 메뉴의 형태(78)로부터 시스템의 3개의 형태중 하나를 선택한다. 시스템의 형태를 특정함으로써, 레벨 1 관리자는 시스템에 액세스하는 패스워드가 어떻게 배분되는지를 제어한다. 제1 형태의 시스템은 이 시스템에 액세스하기 위한 패스워드가 새로운 ID를 포함하는 소유자의 관리자에 가는 것만을 지정하는 "production" 시스템이고 패스워드는 리셋한다. 제2 형태의 시스템은 패스워드가 소유자의 관리자 및 소유자에게 보내져야 하는 프로덕션 시스템을 지정하는 "production with password to user" 시스템이다. 제3 형태의 시스템은 시스템이 프로덕션 시스템이 아닌 논-프로덕션(non-production) 시스템이다. 논-프로덕션 시스템에서, 패스워드는 관리자 및 소유자 둘다에 보내진다. 레벨 1 관리자는 다음에 고객 코드(80) 풀다운 메뉴로부터 선택함으로써 고객에게 SID 박스(72)에 지정된 원하는 SID를 할당한다.

시스템에의 요구는 본 명세서에서 설명되는 하나 이상의 승인자에 의해 승인된다. 요구가 리마인더가 직무태만의 승인자 또는 승인자들에 보내지기 전에 액션없이 몇일을 머무를 수 있는 지를 지정하는 제1 시간 제한(82)이다. 스테이지 1 승인자가 직무태만이면, 단지 그들은 통지를 받을 것이다. 몇몇 스테이지 1 승인자들이 이미 승인했다면, 그들은 통지를 받지 않을 것이다. 스테이지 2 승인자가 직무태만 측이면, 그 승인자만이 통지를 받을 것이고 스테이지 1 승인자는 그렇지 않을 것이다. 이 통지 기능이 요구되지 않으면, 제1 시간 제한(82)은 이 통지를 비작동시키기 위해 제로로 세트되어야 한다.

제 2 시간 제한(84)은 요구가 완전히 승인되지 않고 큐(queue) 머무를수 있는 시간을 표시한다. 카운트는 원래의 요구 날짜에서 시작하여, 이 옵션은 제1 시간 제한(82) 보다 적은 날이 아니다. 제2 시간 제한(84)이 도달될 때 요구는 큐로부터 삭제된다. 요구가 삭제되었다는 것을 진술하고 여전히 요구되는 경우 재제출할 노트는 모든 승인자들 및 요구자에게 보내진다. 이 기능이 요구되지 않는다면, 제2 시간 제한(82)은 이 기능을 비작동하기 위해 제로로 세트되어야 한다.

레벨 1 관리자는 "group designation function"(86)을 선택하고 메인 네트워크 메뉴 상에 나타나야 하는 것으로 그룹 이름에 타이핑함으로써 고객 내의 그룹 또는 프로젝트를 선택적으로 지정할 수 있다. 도 4에서 재생된 네트워크 페이지에서, 사용자에 의해 보여진 고객 프로필(90)의 특정 예는 각각이 하나 이상의 SID(94)를 포함하는 3개의 사용자 정의 그룹 또는 프로젝트(92)를 도시한다.

SID를 생성하는데 있어서, 관리자는 또한 주어진 시스템에 대해 유용한 액세스 파일을 정의한다. 액세스 파일은 사용자 또는 시스템 내의 공통 직업 요건을 공유하는 사용자 그룹에게 허용된 액세스의 레벨을 정의한다. 'main' 및 'add-on'으로 정의될 수 있는 2가지 형태의 액세스 파일이 있다. 이들 형태의 액세스 프로필의 차이는 그들의 프로그램된 정의이다. 메인 액세스 프로필은 하나를 요구하고, 오직 하나의 메인 액세스 프로필이 사용자 ID를 위해 선택되게 한다. 애드-온 액세스 프로필은 아무것도 아니거나 하나 또는 많은 애드-온 액세스 프로필이 사용자 ID를 위해 선택되게 한다. 하나의 사용자 Id를 위해 오직 하나의 액세스 프로필을 원하는 이들 SID(흔히 듀티 이유의 분리를 위해 프로덕션 환경에서 사용됨)는 단지 메인 액세스 프로필을 정의할 것이고, 그러므로, 사용자 Id가 하나 보다 많은 액세스 프로필을 얻는 것을 방지한다. 직업 요건의 대부분을 포함하는 액세스 프로필을 가지나 소정의 액세스 프로필이 추가되게 하는 이들 SID는 직업 레벨 프로필에 대한 'main" 및 부가적인 권한 프로필을 위한 'add-on'을 사용할 수 있다. SID가 액세스 프로필의 임의의 조합을 요구한다면, 관리자는 단지 'add-ons'를 사용할 수 있고 그러므로 액세스 프로필의 임의의 조합의 선택을 가능하게 한다. 'category' 액세스 프로필을 사용하는 경우, 승인자는 아래에 설명되는 'definingapprovers'라고 하는 기능을 통해 카테고리에 의해 정의될 수 있다.

도 5는 어드미니스트레이티브 스크린(50) 내의 메인 액세스 프로필 윈도우(100)를 도시하고 있는데 관리자는 고객 네트워크 페이지에 새로운 액세스 프로필을 추가할 수 있다. 새로운 메인 액세스 프로필을 추가하기 위해 관리자는 먼저 어드미니스트레이티브 스크린(50)의 좌측에 위치한 SID 메뉴(102) 상에 디스플레이된 원하는 SID를 하이라이트하고, 다음에 툴바 상의 SID(70)을 선택하고 다음에 풀다운(도시 안됨) 상의 "profiles" 및 최종 풀다운 메뉴(도시 안됨) 상의 "main"(도시 안됨)을 선택한다. 도 5에 도시된 윈도우(100)는 관리자에게 제시된다. 관리자는 다음에 "add"(108) 버튼을 선택하고 도 5a의 "Add a New profile"(110) 윈도우가 나타난다. 관리자는 고객 네트워크 페이지 상의 액세스 프로필의 제시를 소트하는데 사용되는 소트 키(112)를 입력한다. 액세스 프로필은 수치적으로 소트될 것이다. 카테고리가 SID를 위해 이용되면, 액세스 프로필은 각각의 카테고리(114) 내에서 수치적으로 소트될 것이다. "category"는 일반적인 용어이고 조직의 요구에 따라 관리자에 의해 정의될 수 있다. 관리자는 다음에 "profile name" 박스(116)에 기술적 액세스 프로필을, 그리고 "description" 박스(118)에 액세스 프로필의 디스크립션을 입력한다. 액세스 프로필의 기술적 이름은 어떤 것이 Id가 생성되는 시스템에 의해 인식되는냐는 것이다. 액세스 프로필의 디스크립션은 관리자가 디스크립션에 따라 기술적 이름을 디스플레이하기를 원하지 않는 경우, 이 경우에는, 관리자는 도 3에 설명된 "Adding projects/SIDs"(68)을 통해 그렇게 하고, 고객 페이지에 반영되는 것이다.

다르게는, 관리자는 "min"(도시 안됨)을 선택하는 것 대신에 도 5에 설명된 풀다운으로부터 "add on"을 선택함으로써 "main" 액세스 파일 대신에 "add on" 액세스 프로필(도시 안됨)을 추가할 수 있다. 액세스 프로필 제시 특징의 또하나의 특징은 헤더 또는 컬럼을 포함하는 것 뿐만 아니라, 고객 네트워크 페이지상에 제시될 컬러, 스타일, 및 텍스트의 크기를 주문화하는 능력이다. 이들 효과를 달성하기 위해서, 텍스트 태그는 도 5에 설명된 메인 또는 애드-온 액세스 프로필 메뉴의 정상 텍스트 영역에서 사용될 수 있다.

DCE 조직이 SID 내의 멀티-클라이턴트 구조를 이용하길 원하는 경우, 도 6은 이러한 클라이언트를 구성하기 위한 관리 스크린(50)을 도시한다. "클라이언트"는 조직의 필요에 따라 관리자에 의해 정의될 수 있는 일반적인 용어이다. 관리자는 먼저 관리 스크린(50)의 좌측에 위치된 SID 메뉴(102)로부터 원하는 SID를 하이라이트하고, 다음에 툴바(52) 상의 "SID"(70) 옵션을 선택하고 다음에 풀다운 메뉴(128) 상의 "clients"를 선택한다. 팝업 윈도우(130)가 나타나고 관리자에게 클라이언트 코드(132) 및 이름(134)을 입력하라고 요구한다. 클라이언트 이름(134)은 즉각 컴파일되고 메인 클라이언트 리스트 헤딩(도시 안됨)하에서 메인 네트워크 페이지상에 반영된다. 클라이언트 리스트를 업데이트하는 것은 "client name" 필드(134)를 선택하고 원하는 정보를 직접 입력함으로써 완료될 수 있다. 마찬가지로, 클라이언트 이름은 "client name" 필드(134)를 선택하고 "delete"(136)을 선택함으로써 삭제될 수 있다. 확인 윈도우가 디스플레이될 것이고 관리자는 클라이언트(도시 안됨)의 제거를 확인하기 위해 "OK"를 선택할 것이다.

사용자 식별 관리 시스템의 또 하나의 특징은 승인자의 다양한 스테이지 및 형태를 통해 승인 셋업을 위해 제공되는 가변 옵션이다. "승인자"와 "인증자"의 용어는 상호 교환가능하게 사용된다. 승인자의 2개의 스테이지는 네트워크 정보에 2단계 멀티-레벨 인증을 제공하기 위해 존재한다. SID는 1-스테이지 또는 2-스테이지 승인을 포함하도록 구성될 수 있다. 또한, 스테이지 1 승인자는 지정된 스테이지 2 승인자 전에 인증 요구를 받는다. 스테이지 1 승인자가 요구를 거부하면, 스테이지 2 인증자는 요구를 받지 않을 것이다. 부가적으로, 승인의 각 스테이지내에는 여러 형태의 승인자: General, Category, Client, Delete 및 Change가 존재한다. 삭제 및 변경 승인자는 다른 형태의 승인자가 2-스테이지 승인 방법을 이용할 수 있는 1-스테이지 승인만을을 이용할 수 있다. 일반 승인자는 어떤 요구이든지 간에 승인 리스트 상에 있다. 업무 프로필이 도 5 및 도 5a에 도시된 바와 같이 고객 내의 카테고리로 그룹지워지는 경우 카테고리 승인자가 사용된다. 카테고리 승인자는 승인자가 지정되는 직업 파일이 요구자에 의해 선택되는 경우 승인 리스트 상에 있게 된다. 시스템이 멀티-클라이언트 구조인 경우, 클라이언트 승인자는 각각의 클라이언트에 대해 지정될 수 있다. 요구자가 요구를 위한 그들의 클라이언트를 선택한 경우 클라이언트 승인자는 단지 승인 리스트 상에 있을 것이다. 시스템에 대해 지정된 승인자만이 카테고리 승인자가 아닌 경우 삭제 승인자는 선택적인 것이다. 삭제 요구는 카테고리를 선택하는 것을 요구하지 않기 때문에, 삭제 승인자가 정의되어야 한다. 일반 또는 클라이언트 승인자가 이미 있는 경우 삭제 승인자는 이들 승인자에 부가하여 있을 것이다. 변경 승인자는 변경 승인을 위해서만 지정된다. 상기 승인 형태 각각은 단일 승인자, 각각이 승인하여야 하는 2 이상의 승인자, 또는 이들 승인자들 중 어느 하나가 승인하자 마자, 승인이 완전하다는 것을 표시하는 "any one of" 조건(예를 들어, 불리안 OR)와 링크되는 2 이상의 승인자를 가질 수 있다. 승인자의 메일 ID 간의 ""를 이용하여 입력되는 "and" 조건이 선택되는 경우, 각각의 승인자는 그들 자신의 고유 패스코드를 수신할 것이다. 승인자의 메일 ID 사이에서"｜"를 이용하여 입력되는 "or" 조건이 선택되는 경우, "or-ed" 승인자 모두는 동일한 패스코드를 받는다. 상기 모두는 임의의 조합으로 사용될 수 있다.

도 7은 다양한 승인자를 지정하는데 사용하기 위한 관리 스크린(50)을 도시한 것이다. 승인자를 추가하기 위해, 먼저 관리 스크린(50)의 좌측 상에 위치된 SID 메뉴 상에 디스플레이된 원하는 SID를 하이라이트하고, 다음에 툴바(52) 상의 "SID"(70)을 선택한 다음에 풀다운 메뉴(150) 상의 "authorizers"를 선택하고, 최종 풀다운 메뉴(152) 상의 인증자의 형태를 선택한다. 일반 승인자(154)을 선택하는 것은 승인의 적당한 스테이지를 위한 승인자 박스(166)내의 승인자의 직접적인 입력을 허용하는 윈도우(160)을 내놓는다. 이 승인자를 업데이트하기 위해, 관리자는 승인자 박스(166)를 선택하고 그안에 정정된 정보를 타이프하고, 다음에 변경 모드를 확인하기 위해 "commit" 버튼(168)을 선택한다. 관리자는 다음에 적당한 승인자 스테이지 박스내의 승인자의 완전한 이메일 어드레스에 타이프하여, 스테이지 1 박스(166) 또는 스테이지 2 박스(146)를 선택한다. 하나 이상의 승인자가 요구되는 경우(예를 들어, 불리안 AND 조건), 관리자는 스테이지 박스(166 또는 146)에 "emailemail"을 입력한다. 어느 승인자가 승인할 경우(예를 들어, 불리안 OR 조건), 스테이지 박스(166 또는 146)에 "email｜email"을 타이프한다. 스트링이 임의의 조합 "email｜email2email3email4" 등으로 연쇄될 수 있다. 다른 형태의 승인자가 유사하게 구성될 수 있고 더 이상 논의되지 않는다.

사용자 식별 관리 시스템은 모든 승인이 완료될 때 요구를 자동적으로 완료시키는데 사용되도록 설계된다. 그러나, 이것은 또한 승인된 요구를 자동적으로 처리하지 않도록, 그러나 대신에 수동 완료를 요구하도록 구성될 수 있다. 자동적으로 처리된 모든 요구는 입력되어, 어떤 개입을 요구하지 않고 큐로부터 제거될 것이다. 그러나, 큐내에 입력된 요구가 관리되어야 하는 여러 이유가 있다. 이들은 2가지 형태의 큐이다. 제1 큐는 펜딩중인(pending) 인증인 모든 요구를 포함한다. 이 큐의 조작은 로스트(lost) 승인 코드, 반복적으로 실수로 입력된 요구 등에 기인할 수 있다. 제2 큐는 승인 처리를 완료하고, 완전히 승인된, 요구의 실행을 대기하는 그들 요구를 포함한다. 시스템이 자동 실행을 위해 셋업되고, 요구가 에러없이 완료된 경우, 레코드는 이 큐에서 1초의 몇분의 일만 걸린다. 그러나, 요구가 에러를 갖거나(생성중에 존재하지 않는 파일과 같이), 또는 시스템이 자동 실행을 위해 셋업되지 않으면, 요구 이 큐로부터 수동으로 조작되어야 한다. 펜딩중인 인증 큐를 관리하는데 도움을 주는 다른 특징은 어떤 것을 셋팅 및 사용이 경고 필드(82 및 84) 하에서 도 3의 "Adding a SID"에 기술되는 큐 경고 셋팅이다. 이 설비는 인증 요구가 특정 시간량내에 액트되지 않는 경우, 리마인더 통지의 셋업, 또는 펜딩 요구의 제거를 가능하게 할 것이다.

요구 큐의 관리는 도 8에 도시된 큐 관리 설비를 통해 유용하다. 제1 큐에 액세스하기 위해, 관리자는 먼저 관리 스크린(50)의 좌측 상에 디스플레이된 SID(156)를 하이라이트한 다음, 툴바(52) 상의 "SID"(70) 및 풀다운 메뉴(128) 상의 "User Queue"(190)을 선택하고 요구 펜딩 인증을 위한 "Maintain"(129)을 선택한다. "Maintain User Requests" 윈도우(158)은 이 큐에 있는 모든 요구의 요약을 디스플레이하는 것으로 나타난다. 요약의 제1 필드(162)는 주 패스코드(승인자에 가는 패스코드는 승인 요구되는 부가적인 4개의 문자를 가짐)를 포함한다. 다음 필드(164)는 SID 다음의 요구(170)의 형태(추가, 변경, 리셋 등)를 포함한다. 다음 필드(172)는 사용자 정보 다음의 사용자의 메일 어드레스(178)를 포함하고, 최종 필드(180)는 상태(제2 스테이지를 위한 펜딩 또는 펜딩 2)이다. 엔트리를 삭제하기 위해, 관리자는 엔트리를 하이라이트하고 "delete"(174)를 클릭한다. 확인 윈도우가 나타날 것이고, 관리자는 다음에 "confirm"(도시 안됨)을 선택한다. 완전한 레코드를 보기 위해, 관리자는 "show detail"(176)을 클릭하거나 또는 엔트리를 더블 클릭한다. 전체 레코드(182)는 다음에 도 9에 도시된 바와 같이 디스플레이된다. 사용되지 않은 필드는 블랭크로 디스플레이된다. 할당된 승인자 및 그들의 패스코드(186) 모두 뿐만 아니라, 요구가 제출된 날짜(184)가 여기서 얻어질 수 있다. 승인자를 볼 때, 그들의 메일 Id에 인접한 풀 패스코드를 갖는 승인자는 승인하지 않은 승인자만이다. 예를 들어, 도 9에 도시된 바와 같이, "Stage 2 Approvers"(186) 하에 리스트된 제2 승인자는 레코드(182)에서 표시된 요구를 아직승인하지 않았다.

도 10에 도시된 바와 같이, 관리자는 관리 윈도우(50)의 좌측상에 디스플레이된 SID(188)를 하이라이트함으로써 큐 관리 설비의 제2 큐에 액세스하고, 다음에 툴바(52) 상의 "SID"를 클릭한 다음, 풀다운 메뉴(128) 상의 "User Queue"(190)을 클릭한다. 관리자는 다음에 요구 펜딩 완료의 "Complete/Reject"(192) 기능을 선택한다. 관리자는 "Refresh"(196) 키를 선택함으로써 이 큐내의 현재 큐에 스크린을 업데이트할 수 있다. 탐색을 재처리하기 위해, 관리자는 큐내의 요구(194)를 하이라이트하고 "Reprocess"를 누른다. 이것은 이미 생성되지 않은 요구를 시스템에 되 보낼 것이다. "Complete"(258)은 모든 아이템이 아이템에 대해 수동으로 완료된 후에 사용된다. 이것은 어떤 미결 노트를 보내고, 큐로부터 요구를 제거하고, 상태를 수동으로 완료된 것으로 설정한다. "Reject"(260) 기능은 관리자가 모든 승인자가 승인했더라도 요구를 거부하게 한다. 처리될 수 없는 코멘트 필드에 특별 명령이 있는 경우 이것이 요구될 수 있다. 마지막으로, "Show Details"(262)는 전체 레코드가 디스플레이되게 할 것이다.

도 11은 새로운 또는 업데이트된 사용자 Id의 취급 및 승인을 위한 처리를 도시한 것이다. 사용자는 302에서 요구를 제출한다. 사용자 식별 관리 시스템은 304에서 어드레스 북으로부터 모든 유용한 정보를 미리채운다, 요구자 정보가 찾아질수 없는 경우, 기존 사용자는 요구자(도시 안됨)를 스폰서하여야 한다. 스테이지 1을 위한 승인 통지(304)가 보내진다. 승인자는 그들의 어카운트를 위한 승인 페이지에 들어가고 306에서 이 요구를 위한 1회 사용 승인 코드를 입력한다.승인자는 요구를 검토하고 이 요구를 승인하거나 거부한다. 요구가 거부되는 경우, 흐름은 단계 312로 진행하여 승인자는 거부에 대한 이유 또는 다른코멘트을 타이프할 수 있다. 어떤 승인자가 요구를 거부한 경우, 요구가 거부되었다는 통지는 승인자에 의해 입력된 이유로 312에서 발생되어 모든 다른 승인자(그 스테이지 만에 대해) 및 또한 요구자에게 보내진다. 요구에 대한 어떤 미결 승인 코드는 314에서 무효화된다.

단계 308에서, 모든 스테이지 1 승인자가 응답하였는지가 결정된다. 그렇지 않으면, 흐름은 단계 306으로 진행하여 처리가 계속된다. 모든 스테이지 1 승인이 완료될 때, 스테이지 2 승인자의 존재는 단계 309에서 결정된다. 스테이지 2 승인자가 없는 경우에, 흐름은 본 명세서에 기술된 단계 320으로 진행한다. 스테이지 2 승인자가 존재하는 경우에, 흐름은 단계 316으로 진행하여 통지가 스테이지 2 승인자에게 보내진다. 스테이지 2 승인 처리는 단계 306 및 308과 유사한 방식으로 단계 317 및 318에서 수행된다.

승인이 단계 318에서 완료된 후, 사용자 식별 관리 시스템은 단계 320에서 시스템 상의 Id를 생성 또는 업데이트한다. 321에서, Id가 성공적으로 완료되었는지가 결정된다. 그렇다면, 흐름은 단계 324로 진행하여 통지가 시스템에 걸쳐 분산된다. 예를 들어, 새로운 사용자가 SID에 액세스가 허용되었다는 통지가 보내질 수 있다. 326에서 이 요구에서 코멘트가 있는지가 결정된다. 그렇지 않으면, 흐름은 단계 328로 진행하여 처리는 종료하고 요구는 완료된 것으로 표시된다. Id가 321에서 성공적으로 완료되지 않았거나 또는 326에서 요구에 코멘트가 있다면, 흐름은 단계 325로 진행하여 통지는 관리자로 보내진다. 관리자는 다음에 문제를 해결하고 코멘트를 어드레스할 수 있다. 단계 327이 완료될 때, 흐름은 단계 328로 진행하여 요구는 완료된 것으로 표시된다.

승인자를 설정하고 위에 설명된 승인을 수행하는 처리는 도 1에 도시된 바와 같은 시스템에서 구현될 수 있다. 이러한 시스템에서, 예를 들어 워크스테이션(20)에 의해 구현된 요구자는 어플리케이션, 데이터 등을 포함할 수 있는 서버(12)와 같은 네트워크 상의 엔티티에 액세스하기를 원한다. 요구자 시스템(20)은 서버(14)와 같은 관리 서버에 보내질 수 있는 액세스 요구를 제출한다. 관리 서버(14)는 예를 들어 워크스테이션(22)에 의해 구현될 수 있는 적당한 승인자에 요구를 발송할 것이다. 관리 서버(14)는 어떤 승인자가 요구 명령이 액세스하는 엔티티에 관련되는지를 결정하도록 시스템 식별자의 데이터베이스에 액세스한다. 데이터베이스는 관리 서버(14)의 일부 또는 워크스테이션(20, 22)의 일부일 수 있다. 다르게는, 이들 데이터 베이스는 리모트 기능 호출에 의해 외부적으로 저장 및 액세스될 수 있다. 승인자 시스템(22)은 위에 설명된 바와 같이 관리 서버(14)에 응답을 제공함으로써 엔티티에 액세스하는 권한을 갖는다.

관리자는 직접 또는 서버에 결합된 워크스테이션을 통해 서버로부터 시스템을 구성할 수 있다. 관리자가 SID에 변경을 초기화할 때, 사용자 식별 관리 시스템이 실행되고 패스코드에 대한 관리자를 요구한다. 사용자 식별 관리 시스템은 다음에 승인된 관리자의 리스팅 및 그 관리자의 액세스 허용을 검증하기 위해 리스트를 체크하는 대응하는 패스코드를 위한 어플리케이션 서버를 요구한다. 관리자가 액세스의 적당한 레벨을 갖는다면, 그는 다음에 그에게 할당된 SID에 많은 변경을 초기화할 수 있다. 다양한 승인자를 SID로 정의하고, 이메일 어드레스를 선택된 각 승인자에 관련시킴으로써, 관리자는 액세스 요구의 실행의 시스템을 자동화할 수 있다. 예를 들어, 사용자가 시스템에의 액세스를 요구할 때, 사용자 식별 관리 시스템은 액세스 허용 및 그들 액세스 허용에 할당된 승인자 뿐만 아니라 그 시스템에 정의된 식별자를 포함하는 데이터베이스를 검색하고 그 사용자에게 할당된 액세스 권한을 검증한다. 이것은 다음에 이 요구를 인증을 위한 지정된 승인자에게 전송하거나 또는 다르게는 추가 주의를 기다리는 큐내에 요구 정보를 저장한다. 이 큐는 네트워크내의 하나 이상의 서버상에 저장될 수 있다.

상기 특징에 부가하여, 사용자 관리 식별 시스템은 시스템 사용자에 관한 현재 정보를 관리하고 유지하는 조직의 능력을 지원하기 위해 제공한다. 이 옵션은 재검증 툴을 통해 유용하다. 재검증 툴은 사용자 액세스가 여전히 요구된다는 주기적 확인을 위한 자동화된 방법을 제공한다. 재검증 툴은 관리자에게 정의된 시스템 또는 세이브된 파일로부터 직접 사용자 정보를 로드하게 한다. 회사 어드레스 북에 따라 그 정보를 사용하면, 사용자 식별 관리 시스템 재검증 툴은 정보의 레포트를 생성하고, 통지를 생성하여 메일하고, 응답 상태를 트랙하고, 리마인드 통지를 보내고, 비응답 그룹을 록(lock)한다. 유용한 옵션은 하나의 시스템 또는 클라이언트가 계속 실행되게 하고, 또는 많은 시스템 또는 클라이언트가 계속 실행되게 하고; 어드레스(식별자)의 형태를 빠트리고 있는 이들 레코드의 레포트를 발생하고; 시스템 또는 클아이언트에 리스트되나 어드레스 북에서 발견되지 않는 그사용자 ID의 레포트를 발생하고, 'report to'에 의해 그룹지워진 사용자 정보의 레포트를 발생하고; 특정화된 개인 또는 어드레스에 보내질 해제 노트를 발생하는 것을 포함한다.

재검증 툴에 액세스하기 위해서, 관리자는 도 12의 관리 스크린 툴 바(52) 상의 "tools"를 선택하고, 풀다운 메뉴 상의 "reverification"(202)를 선택한다. 재검증 윈도우(204)가 나타난다. 재검증 툴의 어떤 기능을 이용하기 위해, 관리자는 재검증이 요구되는 사용자 그룹을 먼저 정의하여야 한다. 사용자 그룹은 시스템 또는 클라이언트에 의해 구성될 수 있다. 사용자 그룹을 정의하기 위해, 관리자는 재검증 윈도우(204) 상의 툴바(206)으로부터 "Users"(205)를 선택하고 다음에 풀다운 메뉴(도시 안됨)내의 "From system"를 선택한다. 도 13의 로그온 윈도우(208)가 나타난다. 관리자는 다음에 수집된 시스템 또는 클라이언트에 관한 정보를 입력한다. 관리자는 사용자 정보에 액세스하기 위해 Id(210) 및 패스워드(212)를 입력하여야 한다. 모든 정보가 압력되었을 때, 관리자는 "Submit"(214)를 클릭한다. 사용자 식별 관리 시스템은 시스템으로부터 정보를 검색하고 도 14에 디스플레이된 시스템으로부터 풀된 정보(213)의 원(raw) 테이블을 생성할 것이다. 완료될 때, 부가적인 클라이언트 또는 시스템 정보는 도 12 및 13에 기술된 처리를 반복함으로써 추가되거나 현재의 리스트와 그룹지워질 수 있다.

이제 도 15를 참조하면, 현재의 리스트를 클리어링하는 처리가 도시된다. 관리자는 재검증 툴 바(206)으로부터 "Users"(205)를 클릭하고, 다음에 풀다운 메뉴로부터 "Clear"(216)을 클릭한다. 조작될 모든 정보가 컴파일되었을 때, 관리자는 그들이 여전히 종사하고 있는지를 검증하기 위해 어드레스 북에 대한 각각의 사용자 Id 소유자를 체크하는 "verify" 옵션(218)을 실행한다. 기능이 실행함에 따라, "user name"(220) 및 "manager name"(222) 필드는 재검증 윈도우(204) 상에 차지될 것이다. 잃어버리거나 무효한 데이터를 갖는 사용자 ID는 빨간색(도시 안됨)으로 하이라이트된다. 정정은 완료되고 상기 단계들은 계속하기 전에 반복된다. 검증 기능이 완료되고 시스템 정보가 요구된 대로 일 때, 재검증 레포트 기능은 도 16에 도시한 바와 같이 사용될 수 있다.

하나의 예시적인 레포트는 재검증 노트를 각각의 사용자의 액세스 정보에 따라 그 관리자에 의해 소유된 사용자 ID의 리스트를 포함하는 관리자에게 보내는 메일 레포트인다. 도 16은 재검증 노트의 발생을 위한 관리자 스크린을 도시한 것이다. 도 17은 수신 관리자에 의해 보여지는 재검증 노트를 도시한 것이다. 이 관리자들은 사용자 정보의 정확성 및 현재성을 검증하고 어떤 필요한 변화를 제출하는 것이 요구된다. 관리자는 또한 그들이 응답하여야 하는 지정된 시간 제한이 주어진다. 관리자에의 노트에는 패스코드가 있다. 그들의 종사원 리스트를 검증하기 위해, 관리자는 그들의 패스코드(도시 안됨)를 자동적으로 등록하는 그들의 재검증 통지에 포함된 네트워크 페이지와의 링크를 작동시킨다. 이 네트워크 페이지 상의 확인(270)에 들어감으로써, 재검증 완료는 등록되고 날짜가 기록된다. 한명 이상의 관리자가 선정된 시간내에 재검증 노트에 응답하지 않으면, 관리자는 재검증 윈도우(274) 상의 "Report"(272) 그 다음에 풀다운 메뉴 상의 "Mail"(276), 다음에 "Positive"(278) 및 "2nd Notice"(280)을 선택함으로써, 도 16에 도시된 제2통지를 실행할 수 있다. 이것은 아직 검증되지 않은 그들 관리자에게만 제2 통지를 보낼 것이고 원래 정보의 모두를 포함할 것이다. 제2 표지는 관리자에 의해 가변되는 응답에 다른 제한된 주기를 줄 것이다. 제2 주기 후에, 관리자는 제2 통지 처리를 반복하고 록다운(즉, 액세스 권한의 거부)을 수행하는 선택을 갖는다. 록다운을 수행하기 위해, 관리자는 Users을 선택하고, 록하고, 검증(도시 안됨)을 위한 런 코드를 입력한다. 다르게는, 시스템은 제2 시간 주기가 만료할 때 자동 록다운을 수행하도록 구성될 수 있다. 록다운은 아직 검증되지 않은 모든 IDS의 타겟 SID 상에 록을 생성할 것이다. 미결 관리자로부터의 어떤 후속적인 검증은 그들의 종사원 ID를 자동적으로 록할 것이다. 도 18은 어떤 관리자가 선정된 날짜 및 어떤 미결 노트까지 응답되는 지를 검증하기 위해 관리자에 의해 컴파일된 재검증 상태 윈도우의 예를 도시한 것이다. 이 정보는 관리자가 노트에 응답되고 도 18에 도시된 네트워크 상태 페이지로부터 관리자에게 유용한 실제 날짜를 포함한다. 관리자가 선정된 시간내에 이 요구에 응답하지 않으면, 이 관리자에 의해 소유된 모든 사용자 ID는 다음에 시스템으로부터 제거된다. 새로운 액세스 요구는 다음에 초기화되어야 한다.

위에 설명된 재검증 처리는 도 1에 도시된 것과 같은 시스템에서 구현될 수 있다. 이러한 시스템에서, 통지 발송 장치는 노트를 워크스테이션(20)과 같은 통지 수신 장치에 발생하는 서버(14)에 의해 구현될 수 있다. 위에 설명된 바와 같이, 통지는 사용자가 시스템 상의 엔티티(예를 들어, 서버(12))에 액세스하는 것이 허용되는 재검증을 요구한다. 관리 서버(14)는 시스템 및 회사 어드레스 북에 관련된 사용자 ID를 포함하는 데이터베이스에 액세스한다. 데이터베이스는 관리 서버(14)의 일부 및/또는 워크스테이션(20, 22)의 일부일 수 있다. 다르게는, 이들 데이터베이스는 외부적으로 저장되고 리모트 기능 호출에 의해 액세스될 수 있다. 관리 서버(14)는 사용자 ID를 어드레스 북에 비교하여 개인이 회사를 떠났는지를 결정한다. 관리 서버(14)는 다음에 통지 발송 장치로서 기능하고 통지를 워크스테이션(20)(즉, 통지 수신 장치)에 통지를 보낸다. 위에 설명된 바와 같이, 통지 수신자는 통지에서 리스트된 사용자에 대한 액세스 권한을 확인하여야 한다. 이것은 응답을 통지 발송 장치(즉, 관리 서버(14))에 보내는 통지 수신 장치(즉, 워크스테이션(20))에 의해 달성된다.

재검증 툴에 부가하여, 사용자 식별 관리 시스템은 관리자에게 측정 데이터를 수집하는 것 뿐만 아니라 정보 서치를 위한 데이터베이스에 액세스하게 하는 로그 뷰어를 제공한다. 도 19는 관리자가 로그 뷰어 툴을 사용하여 데이터베이스를 어떻게 서치할 수 있는지를 도시한다. 관리자는 먼저 관리 스크린(50) 상의 툴 바(52)로부터 "tools" 기능(200)을 선택하고 다음에 풀다운 메뉴로부터 "log viewers"(226)를 선택한다. 로그 뷰어 윈도우(227)가 나타난다. 서치 또는 수집된 측정의 범위는 가변적이다. 그것은 모든 유용한 SID 상의 모든 클라이언트 뿐만 아니라 한 SID 상의 한 클라이언트에 제한될 수 있다. 로그 온된 admin SID에 엑세스가능한 모든 SID는 로그 뷰어 윈도우(227)내에 위치된 'SIDS"라고 표시된 스크롤가능한 서브-위도우(228)에 리스트될 것이다. 단일 SID, 다중 SID, 또는 SID의 블럭이 선택될 수 있다. 하나의 SID를 선택하기 위해, 관리자는 원하는 SID(도시 안됨)를 클릭한다. 이것은 하이라이트될 것이다. 다중 SID를 선택하기 위해서, 관리자는 원하는 SID(도시 안됨)를 선택하면서 키보드상의 "Ctrl" 키를 누른다. 선택된 SID 각각은 하이라이트될 것이다. 관리자는 또한 레인지의 상부에 있는 원하는 SID를 클릭하고, 키보드 상의 "shift" 키를 누르고 홀딩하고, 레인지(도시 안됨)의 하부에 있는 SID를 선택함으로써 SID의 레인지를 선택할 수 있다. 2개의 SID 간의 모든 SID는 하이라이트될 것이다.

오지 하나의 SID가 선택되는 경우에, 서치는 특정 클라이언트에 더 제한될 수 있다. 이것을 행하기 위해, 관리자는 먼저 위에 표시된 바와 같이 서브-윈도우(228) 상에 리스트된 원하는 SID를 선택하고, 다음에 "All Clients"라고 표시된 박스(230)내의 체크를 제거한 다음, "Refresh Client" 버튼(232)를 클릭한다. 그 SID에 대한 사용자 식별 관리 시스템에 정의된 모든 클라이언트는 "Client" 박스(234)에 표시될 것이다. 관리자는 서치에 포함될 클라이언트(들)을 선택하기 위해 SID를 선택하기 위한 위에 설명된 것과 동일한 방법을 사용할 것이다.

SID 또는 클라이언트가 선택되었을 때, 관리자는 "search" 버튼(236)을 클릭한다. 도 20의 팝업 윈도우가 나타난다. 행해질 수 있는 5개의 주요 형태의 서치가 있다. "userid" 필드(238)는 특정 사용자 Id에 제한될 서치를 허용한다. 관리자는 이 필드(238)에 서치를 위한 사용자 Id에 타이프한다. 사용자 Id가 정의되지 않으면, 이 필드(238)는 모든 사용자 ID가 선택될 것이라는 것을 표시하는 "%" 와일드카드 심볼을 제외하고 블랭크로 남을 수 있다. 다음에, 요구의 형태가 선택된다. 이 제한자는 주어진 시간 주기내에 요구된 패스워드의 수와 같은 정보상의 통계를 모으기 위해 유용하다. 서치에 요구 형태를 포함시키기 위해, "Types of requests to show" 섹션(240) 내의 5개의 박스중의 하나가 체크되어야 한다. 제3 섹션, "Status of request to show"(242)는 선택된 SID(들) 또는 클라이언트(들)내의 모든 요구의 현재 상태를 결정하는데 사용된다. 이 섹션 내의 하나 이상의 박스가 선택될 수 있다. "date range" 섹션(244)은 관리자가 특정된 날짜 범위내의 이들 상태에 대한 선택을 제한하게 한다. 예를 들어, 특정 월의 정보를 모으기 위해, 관리자는 "From" 라인(248) 내의 특정된 형태로 원하는 달의 첫번째 날과 "To" 라인(250)에 원하는 달의 마지막 날을 입력한다. "To" 라인(250)은 현재 날짜를 선택하기 위해 블랭크로 남을 수 있다. 서치 기능 상의 마지막 옵션은 "Group by Userid"이다. 관리자는 서치의 결과가 디폴트 'chronological' 소트라기 보다 사용자 아이디에 의해 알파벳으로 표시되어야 하는 경우 이것을 선택한다.

서치의 선택이 이루어졌을 때, 관리자는 실행할 "Search" 버튼(254)를 선택한다. 사용자 식별 관리 시스템은 판별에 부합하는 엔티티의 요약을 생성하고 스크린 상에 결과를 리스트할 것이다. 다양한 정보는 각각의 요구가 서치에 의해 정의된 특정 상태를 달성한 시간, 승인될 요구의 전체 시감, 완료될 요구의 전체 시간 및 서치(도시 안됨)에 의해 정의된 요구의 현재 상태와 같은 것이 디스플레이될 것이다. 관리자는 엔트리의 완전한 디테일을 디스플레이하기 위해 요약 리스팅내의 어떤 엔트리를 클릭할 수 있다. 관리자는 또한 서치에서 발견된 요구의 전체 수, 서치내의 전체 요구를 승인할 평균 시간, 요구를 완료하는 평균 시간, 및 다른유사한 형태의 정보(도시 안됨)와 같이, 서치 결과에서 리스트된 모든 레코드에 대한 요약 상태를 얻을 것이다. 새로운 서치를 수행하기 위해, 관리자는 도 19의 로그 뷰어 스크린(227)내의 "Clear" 버튼(256)을 클릭한 다음, 위에 설명된 바와 같이 "Search" 버튼(236)을 선택한다. 관리자는 서치를 정의하기 위한 도 20에서 위에 설명된 동일한 단계를 반복할 것이다.

사용자 식별 관리 시스템의 또하나의 유용한 특징은 사용자가 제3자 승인을 요구하지 않고 패스워드를 즉각 리셋하게 하는 패스워드 리셋 기능이다. 틀린 패스워드가 여러번 입력된 경우(예를 들어, 잘못된 패스워드로 3번의 로그인 시도), 소정의 시스템은 ID 및 패스워드를 디세이블할 것이다. 이것은 시스템에 인증되지 않은 액세스를 방지하는 안전 특징이다. 패스워드 리셋 기능은 관리자 정의 상황하에서 패스워드 리셋의 자동 승인을 가능하게 한다. 도 21은 패스워드를 리셋하기 위한 처리를 도시한 것이다. 사용자는 400에서 요구를 제출한다. 사용자 식별 관리 시스템은 현재 사용자 ID가 402에서 존재하는지를 검증하기 위해 시스템을 체크한다. ID가 존재하지 않으면, 흐름은 단계 404로 진행하여 ID가 존재하지 않는다는 것을 표시하는 통지가 사용자에게 즉각 보내지고 요구 처리가 다음에 406에서 종료된다. Id가 존재하면, 사용자 식별 관리 시스템은 데이터베이스(도시 안됨)로부터 사용자 정보를 검색하고 408에서 사용자에게 그 정보를 디스플레이한다. 410에서 사용자는 패스워드 리셋에 대한 요구를 제출한다. 시스템은 요구를 수신하고 412에서 ID의 소유자에게 승인 통지를 보낸다. ID의 소유자는 실제 소유자이거나, 또는 다르게는 시스템 구성에 따른 사용자의 관리자이다. 414에서, 요구가승인되는지가 결정된다. ID의 소유자가 요구를 승인하지 않으면, 요구 처리는 다음에 416에서 종료된다. 요구가 승인되면, 흐름은 단계 418로 진행하여 시스템은 시스템 상에서 패스워드 리셋을 실행하고, 필료하다면, ID를 언록한다. 단계 420에서, 리셋이 성공적으로 완료되었는지가 결정된다. 그렇다면, 흐름은 단계 422로 진행하여 통지가 시스템 전체에 걸쳐 분산된다. 예를 들어, 사용자의 패스워드가 리셋되었다는 통지는 사용자의 관리자 또는 관리자에 보내질 수 있다. 424에서 요구에 코멘트가 제시되는지가 결정된다. 그렇지 않으면, 흐름은 단계 426으로 진행하여 처리는 종료하고 요구는 "completed" 것으로 표시된다. 리셋이 420에서 성공적으로 완료되지 않거나, 또는 424에서 요구에 코멘트가 있으면, 흐름은 단계 428로 진행하여 통지는 관리자에게 보내진다. 관리자는 다음에 문제를 해결하고 코멘트를 어드레스한다. 단계 430이 완료될 때, 흐름은 단계 426으로 진행하여 요구는 "completed" 것으로 표시된다.

위에 설명된 패스워드 리셋은 도 1에 도시된 것과 같은 시스템에서 구현될 수 있다. 이러한 시스템에서, 요구 장치는 서버(14)와 같은 승인 장치에 패스워드 리셋을 위한 요구를 발생하는 워크스테이션(20)에 의해 구현될 수 있다. 위에 설명된 바와 같이, 패스워드 리셋 요구는 사용자의 패스워드로 언록으로 제출된다. 승인 장치(즉, 서버(14)는 사용자 ID의 존재를 확인하기 위해 사용자 ID를 포함하는 데이터베이스에 액세스한다. 데이터베이스는 서버(14)의 일부 및/또는 워크스테이션(20, 22)의 일부일 수 있다. 다르게는, 이들 데이터는 외부적으로 저장되고 리모트 기능 호출에 의해 액세스될 수 있다. 데이터베이스는 또한 사용자 ID의소유자의 동일성을 포함한다. 승인 장치는 다음에 사용자 ID 및 패스워드를 언록(unlock)하기 위해 승인을 요구하기 위해 사용자 ID의 소유자에게 승인 통지를 보낸다. "owner"의 어드레스는 워크스테이션(20, 22)중 하나에 대한 이메일 어드레스일 수 있다. 양호한 실시예에서, 요구 장치 및 소유자는 사용자가 그 자신의 패스워드를 리셋할 수 있도록 동일한 것으로 하나이다. 승인 장치(즉, 서버(14))는 승인이 소유자(예를 들어, 워크스테이션(20))으로부터 수신되면 리셋하거나 또는 승인이 수신되지 않는 경우 패스워드 리셋의 요구를 종료한다.

위에 설명된 바와 같이, 본 발명은 컴퓨터 구현 처리의 형태 및 이 처리를 실시하는 장치로 실시될 수 있다. 본 발명은 또한 플로피 디스크, CD-ROM, 하드 드라이브, 또는 임의의 다른 컴퓨터 판독 가능 저장 매체와 같은 실체적인 매체에서 실시되는 명령을 포함하는 컴퓨터 프로그램 코드의 형태로 실시될 수 있고, 컴퓨터 프로그램 코드가 컴퓨터내로 로드되고 컴퓨터에 의해 실행될 때, 컴퓨터는 본 발명을 실시하는 장치가 된다. 본 발명은 또한 예를 들어, 저장 매체에 저장되고, 컴퓨터내로 로드되고 컴퓨터에 의래 실행되건 또는 전기 배선 또는 케이블링을 거쳐서, 광섬유를 통해 또는 전자기 방사를 통하는 것과 같은 어떤 전송 매체를 통해 전송되는지 간에 컴퓨터 프로그램 코드의 형태로 실시될 수 있고, 컴퓨터 프로그램코드가 컴퓨터내로 로드되고 컴퓨터에 의해 실행될 때, 컴퓨터는 본 발명을 실시하기 위한 장치가 된다. 범용 마이크로프로세서 상에서 구현될 때, 컴퓨터 프로그램 코드 세그먼트는 특정한 논리 회로를 생성하도록 마이크로프로세서를 구성한다.

양호한 실시예가 도시되고 설명되었지만, 다양한 변형 및 대체가 본 발명의 취지 및 범위를 벗어나지 않고서 이루어질 수 있다. 따라서, 본 발명은 예시를 위한 것이지 제한적으로 기술된 것은 아니다.

Claims (17)

1. 관리 용도로 사용되는 분산 네트워크 환경 내의 관리 기능을 자동화하고, 상기 네트워크 내의 복수의 상이한 유형의 엔티티에 대한 엔티티로의 액세스 권한을 검증하는 방법에 있어서,

   사용자 ID의 리스트를 컴파일하는 단계 - 상기 사용자 ID는 적어도 하나의 시스템과 관련됨 - ;

   어드레스 북을 검색하는 단계;

   상기 리스트내의 데이터를 상기 어드레스 북내에 포함된 데이터와 비교하는 단계 - 상기 리스트내의 무효 데이터는 플래그됨 - ; 및

   상기 데이터 비교 결과에 기초하여 사용자 정의 레포트(user-defined reports)를 발생하는 단계

   를 포함하는 방법.
2. 관리 용도로 사용되는 분산 네트워크 환경 내의 관리 기능을 자동화하고, 상기 네트워크 내의 복수의 상이한 유형의 엔티티에 대한 엔티티로의 액세스 권한을 검증하기 위한 시스템으로서, 상기 시스템은 컴퓨터 네트워크를 구비하며,

   상기 컴퓨터 네트워크는

   적어도 하나의 엔티티;

   상기 적어도 하나의 엔티티와 통신하는 적어도 하나의 통지 발송 장치;

   상기 통지 발송 장치와 통신하는 적어도 하나의 통지 수신 장치;

   사용자 ID의 데이터베이스 - 상기 사용자 ID는 적어도 하나의 시스템과 관련됨; 및

   사용자 정보를 포함하는 어드레스 북을 포함하되,

   상기 통지 발송 장치는 상기 사용자 ID 및 상기 어드레스 북에 응답하여 액세스 권한을 검증하는 시스템.
3. 제2항에 있어서, 상기 통지 발송 장치는

   사용자 ID의 리스트를 컴파일하고,

   상기 어드레스 북을 검색하며,

   상기 리스트 내의 데이타와 상기 어드레스 북 내에 포함된 데이터의 비교를 수행하고 - 무효 데이터는 플래그됨 -,

   상기 비교 결과에 기초하여 사용자 정의 레포트를 발생하는 시스템.
4. 제3항에 있어서, 상기 사용자 ID 리스트는 리모트 기능 호출에 의해 액세스되는 시스템.
5. 제3항에 있어서, 상기 비교 결과에 포함된 데이터는 상기 통지 발송 장치에 의해 수정되는 시스템.
6. 제3항에 있어서,

   상기 통지 발송 장치는 상기 통지 수신 장치에 통지를 보내되, 상기 통지에는

   연속된 액세스 권한의 검증을 위한 확인 요구와,

   현재 액세스 권한을 갖고 있는 각각의 상기 사용자 ID에 대한 사용자 ID 데이터와,

   응답하기 위한 사용자 정의 시간 제한이 포함되며,

   상기 통지 수신 장치는 상기 통지에 대한 응답에 기초하여 상기 연속 액세스 권한을 검증하는 시스템.
7. 제6항에 있어서, 상기 통지는 제1 통지 및 제2 통지를 포함하되,

   상기 제2 통지는 상기 시간 제한까지 상기 제1 통지에 응답하지 않은 상기 통지 수신 장치에 보내지고,

   상기 제2 통지는 응답하기 위한 제2 사용자 정의 시간 제한을 포함하는 시스템.
8. 제6항에 있어서, 상기 통지는 고유 패스코드(unique passcode)를 포함하고, 상기 패스코드는 통지 수신 장치를 식별하는 시스템.
9. 제8항에 있어서, 상기 통지는 네트워크 페이지와의 링크를 포함하고, 상기링크를 작동시키면 상기 패스코드가 자동적으로 등록되는 시스템.
10. 제6항에 있어서, 상기 연속 액세스 권한의 검증은 상기 통지 수신 장치에 의한 검증의 완료를 확인하는 것을 포함하고, 상기 검증이 완료되면 검증 결과 및 상기 검증 날짜가 등록되는 시스템.
11. 제6항에 있어서, 검증을 요구하는 상기 요구에 대한 응답이 상기 시간 제한내에 상기 통지 발송 장치에 의해 전혀 수신되지 않는 상기 사용자 ID는 상기 엔티티에 대해 액세스 권한이 후속적으로 거부되는 시스템.
12. 제11항에 있어서, 상기 사용자 ID는 상기 통지 발송 장치에 의해 액세스 권한이 수동으로 거부되는 시스템.
13. 제11항에 있어서, 상기 사용자 ID는 상기 통지에서 규정된 상기 시간 제한의 만료시 액세스 권한이 자동적으로 거부되는 시스템.
14. 제11항에 있어서, 액세스 권한이 거부된 상기 사용자 ID는 상기 통지 발송 장치에 의한 상기 검증 요구에 대해 후속적인 응답이 수신되면 자동적으로 회복되는 시스템.
15. 제11항에 있어서, 액세스 권한이 거부된 상기 사용자 ID는 상기 통지 발송 장치에 의한 상기 검증의 후속적인 수신시 수동으로 회복되는 시스템.
16. 제6항에 있어서, 상기 검증 요구에 대한 응답이 상기 시간 제한내에 상기 통지 발송 장치에 의해 전혀 수신되지 않는 상기 사용자 ID는 상기 통지 발송 장치에 의해 삭제되는 시스템.
17. 제조품에 있어서,

    관리 용도로 사용되는 분산 네트워크 환경 내의 관리 기능을 자동화하고, 상기 네트워크 내의 복수의 상이한 유형의 엔티티에 대한 엔티티로의 액세스 권한을 검증하기 위해 그 안에 컴퓨터 판독가능 프로그램 코드를 갖는 컴퓨터 사용가능 매체를 포함하고,

    상기 제조품내의 상기 컴퓨터 판독가능 프로그램 코드는

    컴퓨터가 사용자 ID의 리스트를 컴파일하도록 하는 컴퓨터 판독가능 프로그램 코드 - 상기 사용자 ID는 적어도 하나의 시스템과 관련됨 - ;

    컴퓨터가 어드레스 북을 검색하도록 하는 컴퓨터 판독가능 프로그램 코드;

    컴퓨터가 상기 리스트내의 데이터를 회사 어드레스 북내에 포함된 데이터와 비교하도록 하는 컴퓨터 판독가능 프로그램 코드 - 상기 리스트내의 무효 데이터는 플래그됨-; 및

    컴퓨터가 상기 데이터의 상기 비교 결과에 기초하여 사용자 정의 레포트를발생하게 하는 컴퓨터 판독가능 프로그램 코드

    를 포함하는 제조품.