REGISTER  |  SIGN IN
United States Patent7194764
Martherus , ; et al.March 20, 2007
Title
User authentication
Abstract
The present invention authenticates a user for multiple resources distributed across multiple domains through the performance of a single authentication. User access requests for a protected resource in a first domain are received and redirected to a second domain. User authentication is performed at the second domain. In one embodiment, the system transmits an authentication cookie for the second domain to the user after authentication at the second domain. In another embodiment, the system further redirects subsequent resource requests for resources in the first domain or a third domain to the second domain. The second domain confirms the user's authentication for applicable portions of the first, second, and third domains using the cookie.
Inventors:Martherus; Robin E. (San Jose, CA), Ramamurthy; Srinivasagopalan  (Sunnyvale, CA)
Assignee:Oracle International Corporation (Redwood Shores, CA)
Appl. No.:09/793,658
Filed:February 26, 2001
PCT Pub Date:March 21, 2007
Current U.S. Class:726/8 726/3 726/4 
Current International Class:G06F 17/30 (20060101)
Field of Search:713/202,200,150,155,156,175 726/8,4,3
U.S. Patent Documents
20010037469November 2001Gupta et al.
20010054153December 2001Wheeler et al.
20020032684March 2002Kobayashi et al.
20020091745July 2002Ramamurthy et al.
20020091798July 2002Joshi et al.
20020099671July 2002Crosbie et al.
20020112083August 2002Joshi et al.
20020112185August 2002Hodges
20020116642August 2002Joshi et al.
20020120599August 2002Knouse et al.
20020165960November 2002Chan
20030145074July 2003Penick
20030149737August 2003Lambert et al.
20030158897August 2003Ben-Natan et al.
4484306November 1984Kulczyckyj et al.
4956769September 1990Smith
4961224October 1990Yung
5077666December 1991Brimm et al.
5113499May 1992Ankney et al.
5226143July 1993Baird et al.
5428795June 1995Johnson et al.
5455953October 1995Russell
5530861June 1996Diamant et al.
5557742September 1996Smaha et al.
5581691December 1996Hsu et al.
5678041October 1997Baker et al.
5689679November 1997Jouppi
5692125November 1997Schloss et al.
5708780January 1998Levergood et al.
5757920May 1998Misra et al.
5764890June 1998Glasser et al.
5765153June 1998Benantar et al.
5793966August 1998Amstein et al.
5802518September 1998Karaev et al.
5812776September 1998Gifford
5819271October 1998Mahoney et al.
5826029October 1998Gore, Jr. et al.
5842212November 1998Ballurio et al.
5872969February 1999Copeland et al.
5875461February 1999Lindholm
5889952March 1999Hunnicutt et al.
5892903April 1999Klaus
5893149April 1999Hagersten et al.
5903878May 1999Talati et al.
5907621May 1999Bachman et al.
5908469June 1999Botz et al.
5924096July 1999Draper et al.
5940394August 1999Killian
5944780August 1999Chase et al.
5944824August 1999He
5978779November 1999Stein et al.
5991771November 1999Falls et al.
5991810November 1999Shapiro et al.
5991881November 1999Conklin et al.
5999911December 1999Berg et al.
6005571December 1999Pachauri
6012059January 2000Neimat et al.
6026474February 2000Carter et al.
6028605February 2000Conrad et al.
6029195February 2000Herz
6032227February 2000Shaheen et al.
6041357March 2000Kunzelman et al.
6058381May 2000Nelson
6058480May 2000Brown
6061799May 2000Eldridge et al.
6064656May 2000Angal et al.
6073109June 2000Flores et al.
6073174June 2000Montgomerie et al.
6081518June 2000Bowman-Amuah
6088679July 2000Barkley
6088796July 2000Cianfrocca et al.
6098056August 2000Rusnak et al.
6119167September 2000Boyle et al.
6131120October 2000Reid
6133916October 2000Bukszar et al.
6134658October 2000Multerer et al.
6138104October 2000Marchak et al.
6141778October 2000Kane et al.
6151531November 2000Frankel et al.
6154741November 2000Feldman
6157925December 2000Jenkins et al.
6157942December 2000Chu et al.
6158010December 2000Moriconi et al.
6163844December 2000Duncan et al.
6170013January 2001Murata
6178418January 2001Singer
6182086January 2001Lomet et al.
6182142January 2001Win et al.
6185608February 2001Hon et al.
6185650February 2001Boonie et al.
6192476February 2001Gong
6208986March 2001Schneck et al.
6212558April 2001Antur et al.
6212640April 2001Abdelnur et al.
6216199April 2001DeKoning et al.
6226752May 2001Gupta et al.
6230185May 2001Salas et al.
6233576May 2001Lewis
6233618May 2001Shannon
6240360May 2001Phelan
6240414May 2001Beizer et al.
6243816June 2001Fang et al.
6253248June 2001Nakai et al.
6256739July 2001Skopp et al.
6266420July 2001Langford et al.
6275944August 2001Kao et al.
6279001August 2001DeBettencourt et al.
6282546August 2001Gleichauf et al.
6286098September 2001Wenig et al.
6289462September 2001McNabb et al.
6301668October 2001Gleichauf et al.
6311269October 2001Luckenbaugh et al.
6314492November 2001Allen et al.
6321338November 2001Porras et al.
6324656November 2001Gleichauf et al.
6338097January 2002Krenzke et al.
6339423January 2002Sampson et al.
6345266February 2002Ganguly et al.
6347312February 2002Byrne et al.
6347374February 2002Drake et al.
6357010March 2002Viets et al.
6366913April 2002Fitler, Jr. et al.
6374359April 2002Shrader et al.
6381579April 2002Gervais et al.
6385653May 2002Sitaraman et al.
6393569May 2002Orenshteyn
6415321July 2002Gleichauf et al.
6421682July 2002Craig et al.
6421781July 2002Fox et al.
6430688August 2002Kohl et al.
6434531August 2002Lancelot et al.
6442567August 2002Retallick et al.
6453342September 2002Himmel et al.
6460141October 2002Olden
6463418October 2002Todd
6463509October 2002Teoman et al.
6466932October 2002Dennis et al.
6470386October 2002Combar et al.
6487663November 2002Jaisimha et al.
6499107December 2002Gleichauf et al.
6507847January 2003Fleischman
6513056January 2003Copeland et al.
6519643February 2003Foulkes et al.
6519648February 2003Eyal
6526438February 2003Bienvenu et al.
6526447February 2003Giammaria
6536037March 2003Guheen et al.
6539379March 2003Vora et al.
6539382March 2003Byrne et al.
6539396March 2003Bowman-Amuah
6542993April 2003Erfani
6557039April 2003Leong et al.
6578147June 2003Shanklin et al.
6584548June 2003Bourne et al.
6584569June 2003Reshef et al.
6591347July 2003Tischler et al.
6598058July 2003Bird et al.
6609205August 2003Bernhard et al.
6615218September 2003Mandal et al.
6618806September 2003Brown et al.
6629132September 2003Ganguly et al.
6636891October 2003LeClair et al.
6640307October 2003Viets et al.
6647393November 2003Dietterich et al.
6668322December 2003Wood et al.
6675261January 2004Shandony
6678828January 2004Pham et al.
6691232February 2004Wood et al.
6697849February 2004Carlson
6711632March 2004Chow et al.
6718328April 2004Norris
6741992May 2004McFadden
6742126May 2004Mann et al.
6745221June 2004Ronca
6748447June 2004Basani et al.
6754696June 2004Kamath et al.
6757708June 2004Craig et al.
6763370July 2004Schmeidler et al.
6772214August 2004McClain et al.
6775704August 2004Watson et al.
6779120August 2004Valente et al.
6782379August 2004Lee
6804221October 2004Magret et al.
6859834February 2005Arora et al.
6868406March 2005Ogg et al.
6879995April 2005Chinta et al.
6901433May 2005San Andres et al.
6957237October 2005Traversat et al.
Other References
"DNS--Contents", Dec. 7, 1999, [Retrieved from Internet Aug. 30, 2004], "http://www2.rad.com/networks/198/dns/main.html". cited by examiner .
"Introduction to SSL", Oct. 9, 1998, [Retrieved from Internet May 19, 2004], "http://developer.netscape.com/docs/manuals/security/sslin/content- s.htm". cited by examiner .
Improving Cross-domain Authentication overWireless Local Area Networks; Hahnsang Kim; Shin, K.G.; Dabbous, W.; Security and Privacy for Emerging Areas in Communications Networks, 2005. SecureComm 2005. First International Conference on Sep. 5-9, 2005 pp. 127-138. cited by examiner .
A wireless-based authentication and anonymous channels for large scale area Whe Dar Lin; Jinn-Ke Jan; Computers and Communications, 2001. Proceedings. Sixth IEEE Symposium on Jul. 3-5, 2001 pp. 36-41. cited by examiner .
Design choices for symmetric key based inter-domain authentication protocols in distributed systems Hitchens, M.; Varadharajan, V.; Computer Security Applications Conference, 1996., 12th Annual Dec. 9-13, 1996 pp. 105-116. cited by examiner .
Leon, McAfee's NetTools Promises to Ease Network Desktop Diagnosis, InfoWorld, San Mateo. Jul. 24, 1995. vol. 17, Iss. 30. p. 53. cited by other .
Cooney, IBM rolls out host- and server-based mgmt. apps, Network World, Framingham, Feb. 6, 1995, vol. 12, Iss. 6, pp. 6-7. cited by other .
Walsh, Remedy releases three applications for help-desk suite, InfoWorld, San Mateo, Apr. 21, 1997, vol. 19, Iss. 16, p. 34. cited by other .
Schmersal, Testing to maintain service standards, Communications News, Nokomis, Mar. 1998, vol. 35, Iss. 3, pp. 22-23. cited by other .
Musthaler, The trouble with help desk selection, Network World, Framingham, Feb. 20, 1995, vol. 12, Iss. 8, pp. 35-39. cited by other .
Clear Trust, Unified Access Management, Securant Technologies, Inc., pp. 1-23, 1997. cited by other .
SiteMinder Agent Operations, Version 4.0 Netegrity Inc., 1997. cited by other .
SiteMinder Deployment Guide, Version 4.0, Netegrity Inc., 1997. cited by other .
SiteMinder Policy Server Operations Guide, Version 4.0, Netegrity Inc., 1997. cited by other .
SiteMinder Developer's API Guide, Version 4.0, Netegrity Inc., 1997. cited by other .
SiteMinder Installation Guide, Version 4.0, Netegrity Inc., 1997. cited by other .
Clear Trust, Unified Access Management, Securant Technologies, Inc., pp. 1-23, 1997. cited by other .
SiteMinder Agent Operations, Verson 4.0, Netegrity Inc., 1997. cited by other .
SiteMinder Deployment Guide, Version 4.0, Netegrity Inc., 1997. cited by other .
SiteMinder Policy Server Operations Guide, Version 4.0, Netegrity Inc., 1997. cited by other .
SiteMinder Developer's API Guide, Version 4.0, Netegrity Inc., 1997. cited by other .
SiteMinder Installation Guide, Version 4.0, Netegrity Inc., 1997. cited by other .
Hayes, Jeff, Policy-based Authentication and Authorization: Secure Access to the Network Infrastructure, 2000, IEEE, pp. 328-333. cited by other .
Barrett, Debbie, "Diary Of A Break-And-Enter, Cyber Style," Technology in Government, p. 22, Jan. 2000. cited by other .
Cholter, William La et al., "IBAN: Intrusion Blocker Based On Active Networks," Proceedings of the DARPA Active Networks Conference and Exposition (DANCE'02), 11 pages, 2002. cited by other .
Easter, C., "Method To Report Access Control of LAN Server Resources O A Per User Basis," IBM Technical Disclosure Bulletin, p. 172, Apr. 1992. cited by other .
Good, G., "The LDAP Data Interchange Format (LDIF)--Technical Specification," RFC 2849, 14 pages, Jun. 2000. cited by other .
Hayes, Jeff, "Policy-Based Authentication And Authorization: Secure Access To The Network Infrastructure," IEEE, pp. 328-333, 2000. cited by other .
Hewlett-Packard, "HP Introduces Next-Generation Web Authorization Products For E-Business," Press Release, 3 pages, Jan. 18, 1999. cited by other .
Hewlett-Packard, "HP Introduces Security For Microsoft NT Extranets, Portals And E-services," Press Release, 3 pages, Jan. 17, 2000. cited by other .
Hewlett-Packard, "HP Provides Unprecedented Range Of Authentication Options," Press Release, 3 pages, Sep. 1, 1999. cited by other .
Holdges, J. et al., "Lightweight Directory Access Protocol (v3): Extension For Transport Layer Security," RFC 2830, 12 pages, May 2000. cited by oth- er .
Howard, L., "An Approach For Using LDAP As A Network Information Service," RFC 2307, 20 pages, Mar. 1998. cited by other .
Janis, Reference Monitor-Creating Group Membership, IBM Technical Disclosure Bulletin, p. 431, Mar. 1990. cited by other .
Luciani, J. et al., "Server Cache Synchronization Protocol (SCSP)," RFC 2334, 39 pages, Apr. 1998. cited by other .
Netscape Communications Corporation, "Introduction To SSL," http://developer.netscape.com/docs/manuals/security/sslin/contents.htm, 12 pages, Oct. 9, 1998. cited by other .
Oblix, Inc., "Oblix CSA Solution Administration Guide," Version 3.5, 328 pages, 1999. cited by other .
Park, Joon S. et al., "Secure Cookies On The Web," IEEE Internet Computing, pp. 36-44, Jul./Aug. 2002. cited by other .
Pfitzmann, Birgit et al., "Analysis Of Liberty Single-Sign-On With Enabled Clients," IEEE Internet Computing, pp. 38-44, Nov./Dec. 2003. cited by other .
Phipatanasuphom, Veradej et al., "Vulnerability Of Sensor Networks To Unauthorized Traversal And Monitoring," IEEE Transactions on Computers, vol. 53, No. 3, pp. 364-369, Mar. 2004. cited by other .
Piscitello, David M. et al., "Project Guards Laptop And Desktop Data," InfoWorld, pp. 48 and 54, Jun. 21, 1999. cited by other .
Skaggs, B. et al., "Network Vulnerability Analysis," IEEE, pp. III-493-III-495, 2002. cited by other .
Stokes, E. et al., "Access Control Requirements For LDAP," RFC 2820, 9 pages, May 2000. cited by other .
Sun Microsystems, Inc., "Appendix B--ACL File Syntax," iPlanet Web Server: FastTrack Edition Administrator's Guide, 7 pages, Jul. 13, 2000. cited by other .
Sun Microsystems, Inc., "Chapter 2--Syntax And Use Of obj.conf," iPlanet Web Server, FastTrack Edition NSAPI Programmer's Guide, 16 pages, Jul. 20, 2000. cited by other .
Sun Microsystems, Inc., "Chapter 12--Controlling Access To Your Server," iPlanet Web Server: FastTrack Edition Administrator's Guide, 24 pages, Jul. 13, 2000. cited by other .
U.S. Appl. No. 09/792,911, Office Action dated Sep. 9, 2004, 18 pages. cit- ed by other .
U.S. Appl. No. 09/792,911, Final Office Action filed May 9, 2005, 17 pages. cited by other .
U.S. Appl. No. 09/792,911, Advisory Action filed Aug. 9, 2005, 3 pages. cited by other .
U.S. Appl. No. 09/792,911, Office Action filed Dec. 2, 2005, 13 pages. cit- ed by other .
U.S. Appl. No. 09/792,915, Office Action filed Jul. 23, 2004, 17 pages. cited by other .
U.S. Appl. No. 09/792,915, Final Office Action filed Mar. 8, 2005, 19 pages. cited by other .
U.S. Appl. No. 09/792,915, Final Office Action filed Jun. 30, 2005, 18 pages. cited by other .
U.S. Appl. No. 09/792,915, Office Action filed Oct. 4, 2005, 17 pages. cit- ed by other .
U.S. Appl. No. 09/792,918, Office Action filed Sep. 8, 2004, 22 pages. cit- ed by other .
U.S. Appl. No. 09/792,918, Final Office Action filed Jun. 21, 2005, 16 pages. cited by other .
U.S. Appl. No. 09/792,918, Advisory Action filed Sep. 20, 2005, 3 pages. cited by other .
U.S. Appl. No. 09/792,934, Office Action filed Sep. 21, 2004, 19 pages. cited by other .
U.S. Appl. No. 09/792,934, Final Office Action filed Jun. 2, 2005, 10 pages. cited by other .
U.S. Appl. No. 09/792,934, Office Action filed Aug. 19, 2005, 5 pages. cit- ed by other .
U.S. Appl. No. 09/793,196, Office Action filed Jul. 14, 2004, 19 pages. cited by other .
U.S. Appl. No. 09/793,196, Final Office Action filed Mar. 8, 2005, 15 pages. cited by other .
U.S. Appl. No. 09/793,196, Advisory Action filed Jul. 21, 2005, 3 pages. cited by other .
U.S. Appl. No. 09/793,196, Office Action filed Dec. 13, 2005, 12 pages. cited by other .
U.S. Appl. No. 09/793,320, Office Action filed Aug. 4, 2004, 18 pages. cit- ed by other .
U.S. Appl. No. 09/793,320, Final Office Action filed May 10, 2005, 19 pages. cited by other .
U.S. Appl. No. 09/793,320, Office Action filed Sep. 20, 2005, 15 pages. cited by other .
U.S. Appl. No. 09/793,320, Final Office Action filed Mar. 17, 2006, 18 pages. cited by other .
U.S. Appl. No. 09/793,354, Office Action filed Oct. 1, 2003, 12 pages. cit- ed by other .
U.S. Appl. No. 09/793,354, Final Office Action filed Apr. 19, 2004, 15 pages. cited by other .
U.S. Appl. No. 09/793,354, Office Action filed Jan. 4, 2005, 11 pages. cit- ed by other .
U.S. Appl. No. 09/793/354, Final Office Action filed Aug. 26, 2005, 9 pages. cited by other .
U.S. Appl. No 09/793,354, Advisory Action filed Dec. 15, 2005, 3 pages. cited by other .
U.S. Appl. No. 09/793,355, Office Action filed Mar. 12, 2004, 13 pages. cited by other .
U.S. Appl. No. 09/793,355, Final Office Action filed Apr. 6, 2005, 16 pages. cited by other .
U.S. Appl. No. 09/793,355, Advisory Action filed Jun. 21, 2005, 7 pages. cited by other .
U.S. Appl. No. 09/793,355, Office Action filed Sep. 7, 2005, 13 pages. cit- ed by other .
U.S. Appl. No. 09/814,091, Office Action filed Jul. 14, 2004, 22 pages. cited by other .
U.S. Appl. No. 09/814,091, Final Office Action filed Apr. 8, 2005, 24 pages. cited by other .
U.S. Appl. No. 09/814,091, Advisory Action filed Jul. 5, 2005, 3 pages. cited by other .
U.S. Appl. No. 09/814,091, Office Action filed Nov. 1, 2005, 18 pages. cit- ed by other .
U.S. Appl. No. 09/886,515, Office Action filed Dec. 28, 2004, 35 pages. cited by other .
U.S. Appl. No. 09/886,515, Office Action filed Aug. 29, 2005, 35 pages. cited by other .
U.S. Appl. No. 09/886,515, Final Office Action filed Feb. 14, 2006, 36 pages. cited by other .
Wahl, M. et al., "Authentication Methods For LDAP," RFC 2829, 16 pages, May 2000. cited by other .
Wahl, M. et al., "Lightweight Directory Access Protocol (v3)," RFC 2251, 48 pages, Dec. 1997. cited by other .
Wu, Kun-Lung et al., "Personalization With Dynamic Profiler," IEEE, pp. 12-20, 2001. cited by other .
Yaacovi, Y. et al., "Lightweight Directory Access Protocol (v3): Extensions For Dynamic Directory Services," RFC 2589, 12 pages. May 1999. cited by other .
US Appl. No. 09/793,196, Final Office Action dated May 31, 2006, 22 pages. cited by other.~
Primary Examiner: Jung; David
Attorney, Agent or Firm:Townsend and Townsend and Crew LLP
Parent Case Text


CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No. 60/216,955, Web Access Management, filed Jul. 10,2000, incorporated herein by reference.

This Application is related to the following Applications:

Access Tester, by Christine Wai Han Chan, Ser. No. 09/792,918, filed the same day as the present application;

Cache Flushing, by Joshi, et al., Ser. No. 09/792,911, filed the same day as the present application;

Post Data Processing, by Knouse, et al., Ser. No. 09/793,196, filed the same day as the present application;

Localized Access, by Ramamurthy, et al., Ser. No. 09/793,354, filed the same day as the present application;

Query String Processing, by Crosbie, et al., Ser. No. 09/793,355, filed the same day as the present application;

Logging Access System Events, by Joshi, et al., Ser. No. 09/792,915, filed the same day as the present application;

Providing Data To Applications from an Access System, by Joshi, et al., Ser. No. 09/792,934, filed the same day as the present application; and

Intrusion Threat Detection, by Jeffrey D. Hodges, Ser. No. 09/793,320, filed the same day as the present application.

Each of these related Applications are incorporated herein by reference.
Claims

We claim:
1. A method for authenticating a user for a plurality of domains in a network-based system, comprising: receiving at said first domain a request from said user, for a protected resource, said resource is in said first domain; redirecting said user to a second domain for authentication; and authenticating said user for said first domain at said second domain.

2. The method of claim 1, further comprising the step of: determining whether said first and second domains reside on a single Web Server.

3. The method of claim 1, further comprising the step of: transmitting an authentication cookie for said second domain to said user after said step of authentication.

4. The method of claim 3, further comprising the step of: authorizing said user for said resource.

5. The method of claim 3, further comprising the steps of: redirecting a subsequent resource request for a resource in a third domain to said second domain; transmitting said cookie to said second domain; and confirming authentication of said user for said third domain using said cookie.

6. The method of claim 5, wherein: said first and third domains are one domain.

7. The method of claim 6, wherein: said first, second, and third domains reside on a single Web Server.

8. The method of claim 6, wherein: said step of redirecting a subsequent resource request is transparent to said user.

9. The method of claim 3, wherein: said cookie is encrypted.

10. The method of claim 3, wherein: said cookie is encrypted using RC4 encryption, said cookie comprising: an authentication level, a user id, a user ip address, a session start time, an idle start time, and a secured hash.

11. The method of claim 1, wherein: said system is an Access System.

12. The method of claim 11, wherein: said Access System includes an access management system and an identity management system.

13. The method of claim 1, wherein: said first and second domains reside on a single Web Server.

14. The method of claim 1, wherein: said step of authenticating is performed according to an authentication rule of said second domain.

15. The method of claim 14, wherein: said authentication rule is a default rule for verifying user identities to authenticate users for resources in said second domain.

16. The method of claim 14, wherein: said authentication rule is a policy rule for verifying user identities to authenticate users for resources matched to a policy of said second domain.

17. The method of claim 1, wherein: said second domain is a preferred host.

18. The method of claim 1, wherein: said step of redirecting is transparent to said user.

19. The method of claim 1, wherein: said system is an Access Management System.

20. The method of claim 1, wherein: said step of authenticating comprises the steps of: receiving entered user data; accessing user identity profile information for a Directory Server; and comparing said entered user data with said user identity profile information.

21. The method of claim 1, wherein: said network is the Internet.

22. The method of claim 1, wherein: said resource is a web page.

23. The method of claim 1, wherein: said resource is an application.

24. The method of claim 1, wherein: said step of redirecting is performed by a Web Server plug-in.

25. The method of claim 24, wherein: said plug-in is an NSAPI Web Server plug-in.

26. The method of claim 24, wherein: said plug-in is an ISAPI Web Server plug-in.

27. One or more processor readable storage devices having processor readable code embodied on said processor readable storage devices, said processor readable code for programming one or more processors to perform a method comprising: receiving a user request for a protected resource, said resource is in a first domain; redirecting said request to a second domain; and authenticating said user at said second domain, wherein said authenticating includes: receiving user data at said second domain, said user data is received at said second domain from said user, accessing user identify profile information for said user from a Directory Server, said user identity profile information including a plurality of attributes having attribute values, wherein at least one of said attribute values includes information other than an authentication certificate, and comparing said received user data with said user identity profile information, said comparing includes comparing said received user data with said information other than an authentication certificate.

28. One or more processor readable storage devices according to claim 27, wherein said method further comprises the step of: determining whether said first and second domains reside on a single Web Server.

29. One or more processor readable storage devices according to claim 27, wherein said method further comprises the step of: transmitting an authentication cookie for said second domain to said user after said step of authentication.

30. One or more processor readable storage devices according to claim 29, wherein said method further comprises the step of: authorizing said user for said resource.

31. One or more processor readable storage devices according to claim 29, wherein said method further comprises the steps of: redirecting a subsequent resource request for a resource in a third domain to said second domain; transmitting said cookie to said second domain; and authenticating said user at said second domain using said cookie.

32. One or more processor readable storage devices according to claim 27, wherein: said second domain is a preferred host.

33. One or more processor readable storage devices according to claim 29, wherein: said cookie is encrypted.

34. One or more processor readable storage devices according to claim 27, wherein: said system is an Access Management System.

35. One or more processor readable storage devices according to claim 27, wherein: said system is an Access System.

36. One or more processor readable storage devices according to claim 35, wherein: said Access System includes an access management system and an identity management system.
Description


BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention is directed to technology for authenticating users.

2. Description of the Related Art

As the impact of the Internet continues to alter the economic landscape, companies are experiencing a fundamental shift in how they do business. Business processes involve complex interactions between companies and their customers, suppliers, partners, and employees. For example, businesses interact constantly with their customers--often other businesses--to provide information on product specification and availability. Businesses also interact with vendors and suppliers in placing orders and obtaining payments. Businesses must also make a wide array of information and services available to their employee populations, generating further interactions. To meet new challenges and leverage opportunities, while reducing their overall cost-of-interactions, many organizations are migrating to network-based business processes and models. Among the most important of these is Internet-based E-business.

To effectively migrate their complex interactions to an Internet-based E-business environment, organizations must contend with a wide array of challenges and issues. For example, businesses need to securely provide access to business applications and content to users they deem authorized. This implies that businesses need to be confident that unauthorized use is prevented. Often, this involves the nontrivial, ongoing task of attempting to tie together disparate, system-specific authentication and/or authorization schemes.

To meet these challenges, an E-business host company needs a web access management solution that delivers the ability to effectively secure and manage all the various network-based interactions. A system should accommodate all participants involved with the E-business, whether they are local or remote. It must also be able to distinguish between the E-business' employees and all the users who are affiliated with the E-business host's customers, suppliers and/or partners.

Prior to authorizing a user to access a resource, previous access management systems will authenticate a user. That is, they will verify the identity of the user. After a user successfully authenticates for a first protected resource, the user may request access to a second resource. If the second resource is also protected, the user may be required to perform a second authentication for the second resource. However, it may be redundant to force the user to re-authenticate for the second resource, especially if the previous authentication occurred relatively recently. Requiring repetitive re-authentications can unduly burden both users and networks, causing reductions in productivity and degradations in network performance.

At least one prior art method allows users to avoid such re-authentication in certain limited contexts. For web-based resources existing within a single domain, a single authentication cookie may be set to prove a user's previous successful authentication for a resource within the single domain. If a second resource in the same domain is requested, the previously set cookie can be referenced as proof of a prior authentication in the same domain. If such a cookie exists, the user can bypass authentication for the second resource, as long as the cookie is still valid.

However, authentication becomes significantly more complicated when requested resources reside in multiple domains, any of which may be contained within a single server or distributed across multiple servers. In prior art systems, even if a user need not re-authenticate for access to resources within a single domain, re-authentication would still be required for successive requests made for access to resources residing in different domains. As network-based resources continue to become ever more distributed, these re-authentication inefficiencies grow. Thus, there is a need to authenticate users for multiple resources distributed across multiple domains through a single authentication step without unduly burdening users and systems with unnecessary re-authentication steps.

SUMMARY OF THE INVENTION

The present invention, roughly described, provides for a system capable of authenticating a user for a plurality of domains in a network-based system. The present invention allows a user to be authenticated for multiple resources spanning multiple domains through the performance of a single authentication.

One embodiment of the present invention includes receiving a request for a protected resource in a first domain. The system redirects the request to a second domain and authenticates a user for the first domain at the second domain. In one embodiment, the system transmits an authentication cookie for the second domain to the user after authentication at the second domain. In another embodiment, the system further redirects a subsequent resource request for a resource in a third domain to the second domain. The system transmits the authentication cookie to the second domain. The second domain confirms the user's authentication for the third domain using the cookie.

The present invention can be implemented using hardware, software, or a combination of both hardware and software. The software used for the present invention is stored on one or more processor readable storage devices including hard disk drives, CD-ROMs, DVDs, optical disks, floppy disks, tape drives, RAM, ROM or other suitable storage devices. In alternative embodiments, some or all of the software can be replaced by dedicated hardware including custom integrated circuits, gate arrays, FPGAs, PLDs, and special purpose computers. Hardware that can be used for the present invention includes computers, handheld devices, telephones (e.g. cellular, Internet enabled, etc.), etc. Some of these devices includes processors, memory, nonvolatile storage, input devices and output devices.

These and other objects and advantages of the present invention will appear more clearly from the following description in which the preferred embodiment of the invention has been set forth in conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram depicting the components of one embodiment of the present invention.

FIG. 2 is a block diagram depicting the components of the computing system that can be used with the present invention.

FIG. 3 is a block diagram depicting the components of a Directory Server.

FIG. 4 is an example of a directory tree structure.

FIG. 5 is a flow chart describing a process for setting up access rules for an Identity Management System.

FIG. 6 is a flow chart describing a process for editing an attribute access criteria.

FIG. 7 is a flow chart describing a process for configuring localized access.

FIG. 8 is a flow chart describing a process for controlling access to attributes in the Identity Management System.

FIG. 9 is a flow chart describing a process for determining access to attributes of a target.

FIG. 10 is a flow chart describing a process for determining whether there is a localized access violation for a class.

FIG. 11 is a flow chart describing a process for determining whether there is localized access for an attribute.

FIG. 12 is a flow chart describing a process for modifying an attribute.

FIG. 13 is a flow chart describing the active automation process.

FIG. 14 is a block diagram depicting the components of a Web Gate.

FIG. 15 is a block diagram depicting the components of an Access Server.

FIG. 16 is a flow chart describing a process for creating a policy domain.

FIG. 17 is a flow chart describing a process for adding an authorization rule.

FIG. 18 is a flow chart describing a process for adding header variables to an HTTP request.

FIG. 19 is a flow chart describing a process for adding an authentication rule.

FIG. 20 is a flow chart describing a process for configuring an audit rule.

FIG. 21 is a flow chart describing a process for creating a policy.

FIG. 22 is a flow chart describing an exemplar process performed by the Access System of one embodiment of the present invention.

FIG. 23 is a flow chart describing a process for determining whether a particular resource is protected.

FIG. 24 is a flow chart describing a process for mapping a resource with a policy domain.

FIG. 25 is a flow chart describing a process for retrieving first and second level authentication rules.

FIG. 26 is a flow chart describing a process for determining whether a resource URL matches a specific policy URL.

FIG. 26A is a flow chart describing a process for determining whether a resource matches a specific policy using POST data.

FIG. 27 provides a block diagram of a retainer data structure.

FIG. 28 is a flow chart describing authentication.

FIG. 29 is a block diagram depicting various components involved in the authentication process.

FIG. 30 is a flow chart describing a process for authentication.

FIG. 31 is a flow chart describing a process for retrieving an authentication challenge scheme from a Directory Server.

FIG. 32 is a flow chart describing a method for performing basic authentication.

FIG. 33 is a flow chart describing the process performed by an Access Server to authenticate using a user ID and password.

FIG. 34 is a flow chart describing form authentication.

FIG. 35 is a flow chart describing a process for client certificate authentication.

FIG. 36 is a flow chart describing a process for authenticating a user using certificates.

FIG. 37 is a block diagram depicting the components of one embodiment of an encrypted cookie.

FIG. 38 is a flowchart describing a process for authorization.

FIG. 39 is a flow chart describing the steps performed when passing authorization information using POST data.

FIG. 40 is a block diagram of an exemplar HTTP request.

FIG. 41 is a flow chart describing a process for obtaining first and second level authorization rules from a Directory Server.

FIG. 42 is a flow chart describing a process for evaluating an authorization rule.

FIG. 43 is a flow chart describing a process for applying an authorization rule to extracted POST data.

FIG. 44 is a flow chart describing a process for performing authentication success actions.

FIG. 45 is a flow chart describing a process for performing authentication and authorization failure actions.

FIG. 46 is a flow chart describing a process for performing authorization success actions.

FIG. 47 is a flow chart describing a process for using header variables.

FIG. 48 is a flow chart describing the steps performed by the auditing module of one embodiment of the present invention.

FIG. 49 is a flow chart describing a method for retrieving first and second level audit rules.

FIG. 50 is a block diagram depicting one embodiment of components used for intrusion detection.

FIG. 51 is a flow chart describing a process for detecting intrusions.

FIG. 52 is a flow chart describing a process performed at a security server as part of a process for detecting intrusions.

FIG. 53 is a flow chart describing a process for flushing/synchronizing caches performed by an Access Manager.

FIG. 54 is a block diagram depicting a synchronization record.

FIG. 55 is a flow chart describing a process for flushing/synchronizing caches performed by an Access Server.

FIG. 56 is a flow chart describing a process for flushing/synchronizing caches performed by a Web Gate.

FIG. 57 is a flow chart describing a process for testing access criteria.

DETAILED DESCRIPTION

FIG. 1 depicts an Access System which provides identity management and access management for a network. In general, an Access System manages access to resources available to a network. The identity management portion of the Access System (hereinafter "the Identity Management System") manages end user identity profiles, while the access management portion of the Access System (hereinafter "the Access Management System") provides security for resources across one or more web servers. Underlying these modules is active automation, a delegation and work flow technology. The active automation technology couples the Identity and Access Management Systems by facilitating delegation of roles and rights, plus providing workflow-enabled management of end user identity profiles. A key feature of one embodiment of this system is the centralization of the repositories for policies and user identity profiles while decentralizing their administration. That is, one embodiment of the system centralizes the policy and identity repositories by building them on a directory service technology. The system decentralizes their administration by hierarchly delegated Administrative roles. Although the Access System of FIG. 1 includes an Identity Management System and an Access Management System, other Access Systems may only include an Identity Management System or only include an Access Management System.

FIG. 1 is a block diagram depicting one embodiment for deploying an Access System. FIG. 1 shows web browsers 12 and 14 accessing Web Server 18 and/or Administration Server 20 via Internet 16. In one embodiment, web browsers 12 and 14 are standard web browsers known in the art running on any suitable type of computer. FIG. 1 depicts web browsers 12 and 14 communicating with Web Server 24 and Administration Server 20 using HTTP over the Internet; however, other protocols and networks can also be used.

Web Server 18 is a standard Web Server known in the art and provides an end user with access to various resources via Internet 16. In one embodiment, there is a first firewall (not shown) connected between Internet 16 and Web Server 18, a second firewall (not shown) connected between Web Server 18 and Access Server 34.

FIG. 1 shows two types of resources: resource 22 and resource 24. Resource 22 is external to Web Server 18 but can be accessed through Web Server 18. Resource 24 is located on Web Server 18. A resource can be anything that is possible to address with a uniform resource locator (URL see RFC 1738). A resource can include a web page, software application, file, database, directory, a data unit, etc. In one embodiment, a resource is anything accessible to a user on a network. The network could be the Internet, a LAN, a WAN, or any other type of network. Table 1, below, provides examples of resources and at least a portion of their respective URL syntax:

TABLE-US-00001 Resource URL Encoding Directory /Sales/ HTML Page /Sales/Collateral/index.html CGI Script with no query /cgi-bin/testscript.cgi CGI Script with query /cgi_bin/testscript.cgi?button=on Application /apps/myapp.exe

A URL includes two main components: a protocol identifier and a resource name separated from the protocol identifier by a colon and two forward slashes. The protocol identifier indicates the name of the protocol to be used to fetch the resource. Examples includes HTTP, FTP, Gopher, File and News. The resource name is the complete address to the resource. The format of the resource name depends on the protocol. For HTTP, the resource name includes a host name, a file name, a port number (optional) and a reference (optional). The host name is the name of the machine on which the resource resides. The file name is the path name to the file on the machine. The port number is the number of the port to which to connect. A reference is a named anchor within a resource that usually identifies a specific location within a file. Consider the following URL:"http://www.oblix.com/oblix/sales/index.html." The string "http" is the protocol identifier. The string "www.oblix.com" is the host name. The string "/oblix/sales/index.html" is the file name.

A complete path, or a cropped portion thereof, is called a URL prefix. In the URL above, the string "/oblix/sales/index.html" is a URL prefix and the string "/oblix" is also a URL prefix. The portion of the URL to the right of the host name and to the left of a query string (e.g. to the left of a question mark, if there is a query string) is called the absolute path. In the URL above, "/oblix/sales/index.html" is the absolute path. A URL can also include query data, which is typically information following a question mark. For example, in the URL: http://www.oblix.com/oblix/sales/index.html?user=smith&dept=sales the query data is "user=smith&dept=sales." Although the discussion herein refers to URLs to identify a resource, other identifiers can also be used within the spirit of the present invention.

FIG. 1 shows Web Server 18 including Web Gate 28, which is a software module. In one embodiment, Web Gate 28 is a plug-in to Web Server 18. Web Gate 28 communicates with Access Server 34. Access Server 34 communicates with Directory Server 36.

Administration Server 20 is a web-enabled server. In one embodiment, Administration Server 20 includes Web Gate 30. Other embodiments of Administration Server 20 do not include Web Gate 30. Administration Server 20 also includes other software modules, including User Manager 38, Access Manager 40, and System Console 42. Directory Server 36 is in communication with User Manager 38, Access Manager 40, System Console 42, and Access Server 34. Access Manager 40 is also in communication with Access Server 34.

The system of FIG. 1 is scalable in that there can be many Web Servers (with Web Gates), many Access Servers, and multiple Administration Servers. In one embodiment, Directory Server 36 is an LDAP Directory Server and communicates with other servers/modules using LDAP over SSL. In other embodiments, Directory Server 36 can implement other protocols or can be other types of data repositories.

The Access Management System includes Access Server 34, Web Gate 28, Web Gate 30 (if enabled), and Access Manager 40. Access Server 34 provides authentication, authorization, and auditing (logging) services. It further provides for identity profiles to be used across multiple domains and Web Servers from a single web-based authentication (sign-on). Web Gate 28 acts as an interface between Web Server 18 and Access Server 34. Web Gate 28 intercepts requests from users for resources 22 and
24, and authorizes them via Access Server 34. Access Server 34 is able to provide centralized authentication, authorization, and auditing services for resources hosted on or available to Web Server 18 and other Web Servers.

Access Manager 40 allows administrators access to manage multiple resources across an enterprise and to delegate policy administration to the persons closest to specific business applications and content. In one embodiment, administrators perform these tasks using an intuitive graphical user interface ("GUI").

User Manager 38 provides a user interface for administrators to use, establish and/or manage identity profiles. An identity profile (also called a user profile or user identity profile) is a set of information associated with a particular user. The data elements of the identity profile are called attributes. In one embodiment, an attribute may include a name, value and access criteria. In one embodiment, an identity profile stores the following attributes: first name, middle name, last name, title, email address, telephone number, fax number, mobile telephone number, pager number, pager email address, identification of work facility, building number, floor number, mailing address, room number, mail stop, manager, direct reports, administrator, organization that the user works for, department number, department URL, skills, projects currently working on, past projects, home telephone, home address, birthday, previous employers and anything else desired to be stored by an administrator. Other information can also be stored. In other embodiments, less or more than the above-listed information is stored.

System Console 42 provides a GUI for administrators to perform various tasks such as managing Administration roles, managing various system wide settings, and configuring the Identity and Access Management Systems. System Console 42 can be used to manage groups (optional) and departing users, reclaim unused resources, manage logging, configure parameters for authentication, configure parameters for authorization, and so on. Additionally, System Console 42 can be used to configure user schemes and control access to certain Identity Management System capabilities (such as "new user," "deactivate user," "workflow," and so on).

The system of FIG. 1 is used to protect a web site, network, Intranet, Extranet, etc. To understand how the system of FIG. 1 protects a web site (or other structure), it is important to understand the operation of unprotected web sites. In a typical unprotected web site, end users cause their browsers to send a request to a Web Server. The request is usually an HTTP request which includes a URL. The Web Server then translates, or maps, the URL into a file system's name space and locates the matching resource. The resource is then returned to the browser.

With the system of FIG. 1 deployed, Web Server 18 (enabled by Web Gate 28, Access Server 34, and Directory Server 36) can make informed decisions based on default and/or specific rules about whether to return requested resources to an end user. The rules are evaluated based on the end user's profile, which is managed by the Identity Management System. In one embodiment of the present invention, the general method proceeds as follows. An end user enters a URL or an identification of a requested resource residing in a protected policy domain. The user's browser sends the URL as part of an HTTP request to Web Server 18. Web Gate 28 intercepts the request. If the end user has not already been authenticated, Web Gate 28 causes Web Server 18 to issue a challenge to the browser for log-on information. The received log-on information is then passed back to Web Server 18 and on to Web Gate 28. Web Gate 28 in turn makes an authentication request to Access Server 34, which determines whether the user's supplied log-on information is authentic or not. Access Server 34 performs the authentication by accessing attributes of the user's profile and the resource's authentication criteria stored on Directory Server 36. If the user's supplied log-on information satisfies the authentication criteria, the process flows as described below; otherwise, the end user is notified that access to the requested resource is denied and the process halts. After authenticating the user, Web Gate
28 queries Access Server 34 about whether the user is authorized to access the resource requested. Access Server 34 in turn queries Directory Server 36 for the appropriate authorization criteria for the requested resource. Access Server 34 retrieves the authorization criteria for the resource and, based on that authorization criteria, Access Server 34 answers Web Gate 28's authorization query. If the user is authorized, the user is granted access to the resource; otherwise, the user's request is denied. Various alternatives to the above described flow are also within the spirit and scope of the present invention.

In one embodiment, the system of FIG. 1 includes means for providing and managing identity profiles, and means for defining and managing authentication and authorization policies. In one implementation, user identity and authentication/authorization information is administered through delegable Administration roles. Certain users are assigned to Administration roles, thus conferring to them the rights and responsibilities of managing policy and/or user identities in specific portions of the directory and web name spaces. The capability to delegate Administration duties enables a site to scale administratively by empowering those closest to the sources of policy and user information with the ability to manage that information.

A role is a function or position performed by a person in an organization. An administrator is one type of role. In one embodiment, there are at least five different types of administrators: System Administrator, Master Access Administrator, Delegated Access Administrator, Master Identity Administrator, and Delegated Identity Administrator. A System Administrator serves as a super user and is authorized to configure the system deployment itself and can manage any aspect of the system.

A Master Access Administrator is assigned by the system administrator and is authorized to configure the Access Management System. The Master Access Administrator can define and configure Web Gates, Access Servers, authentication parameters, and policy domains. In addition, Master Access Administrators can assign individuals to Delegated Access Administrator roles. A Delegated Access Administrator is authorized to create, delete and/or update policies within their assigned policy domain (described below), and create new policy domains subordinate to their assigned policy domains. A Delegated Access Administrator may also confer these rights to others. A Master Identity Administrator, assigned by the System Administrator, is authorized to configure the Identity Management System, including defining and configuring end user identities and attributes, per attribute access control, who may perform new user and deactivate (revocation) user functions. Master Identity Administrators may also designate individuals to Delegate Identity Administrator roles. A Delegated Identity Administrator is selectively authorized to perform new user and deactivate user functions.

A policy domain is a logical grouping of Web Server host ID's, host names, URL prefixes, and rules. Host names and URL prefixes specify the course-grain portion of the web name space a given policy domain protects. Rules specify the conditions in which access to requested resources is allowed or denied, and to which end users these conditions apply. Policy domains contain two levels of rules: first level default rules and second level rules contained in policies. First level default rules apply to any resource in a policy domain not associated with a policy.

A policy is a grouping of a URL pattern, resource type, operation type (such as a request method), and policy rules. These policy rules are the second level rules described above. There are two levels of rules available (first and second levels) for authentication, authorization, and auditing. Policies are always attached to a policy domain and specify the fine-grain portion of a web name space that a policy protects. In practice, the host names and URL prefixes from the policy domain the policy belongs to are logically concatenated with the policy's URL pattern and the resulting overall patterns compared to the incoming URL. If there is a match, then the policy's various rules are evaluated to determine whether the request should be allowed or denied; if there is not a match, then default policy domain rules are used.

FIG. 2 illustrates a high level block diagram of a computer system which can be used for the components of the present invention. The computer system of FIG. 2 includes a processor unit 50 and main memory 52. Processor unit 50 may contain a single microprocessor, or may contain a plurality of microprocessors for configuring the computer system as a multi-processor system. Main memory 52 stores, in part, instructions and data for execution by processor unit 50. If the system of the present invention is wholly or partially implemented in software, main memory 52 can store the executable code when in operation. Main memory 52 may include banks of dynamic random access memory (DRAM) as well as high speed cache memory.

The system of FIG. 2 further includes a mass storage device 54, peripheral device(s) 56, user input device(s) 60, portable storage medium drive(s) 62, a graphics subsystem 64 and an output display 66. For purposes of simplicity, the components shown in FIG. 1 are depicted as being connected via a single bus 68. However, the components may be connected through one or more data transport means. For example, processor unit 50 and main memory 52 may be connected via a local microprocessor bus, and the mass storage device 54, peripheral device(s) 56, portable storage medium drive(s) 62, and graphics subsystem 64 may be connected via one or more input/output (I/O) buses. Mass storage device 54, which may be implemented with a magnetic disk drive or an optical disk drive, is a non-volatile storage device for storing data and instructions for use by processor unit 50. In one embodiment, mass storage device 54 stores the system software for implementing the present invention for purposes of loading to main memory 52.

Portable storage medium drive 62 operates in conjunction with a portable non-volatile storage medium, such as a floppy disk, to input and output data and code to and from the computer system of FIG. 2. In one embodiment, the system software for implementing the present invention is stored on such a portable medium, and is input to the computer system via the portable storage medium drive 62. Peripheral device(s) 56 may include any type of computer support device, such as an input/output (I/O) interface, to add additional functionality to the computer system. For example, peripheral device(s) 56 may include a network interface for connecting the computer system to a network, a modem, a router, etc.

User input device(s) 60 provide a portion of a user interface. User input device(s) 60 may include an alpha-numeric keypad for inputting alpha-numeric and other information, or a pointing device, such as a mouse, a trackball, stylus, or cursor direction keys. In order to display textual and graphical information, the computer system of FIG. 2 includes graphics subsystem 64 and output display 66. Output display 66 may include a cathode ray tube (CRT) display, liquid crystal display (LCD) or other suitable display device. Graphics subsystem 64 receives textual and graphical information, and processes the information for output to display 66. Additionally, the system of FIG. 2 includes output devices 58. Examples of suitable output devices include speakers, printers, network interfaces, monitors, etc.

The components contained in the computer system of FIG. 2 are those typically found in computer systems suitable for use with the present invention, and are intended to represent a broad category of such computer components that are well known in the art. Thus, the computer system of FIG. 2 can be a personal computer, workstation, server, minicomputer, mainframe computer, or any other computing device. The computer can also include different bus configurations, networked platforms, multi-processor platforms, etc. Various operating systems can be used including Unix, Linux, Windows, Macintosh OS, Palm OS, and other suitable operating systems.

FIG. 3 is a block diagram of Directory Server 36. Directory Server 36 stores user identity profiles 102. Each identity profile includes a set of attributes for the particular end users. Group information 104 is also stored, which describes logical relationships and groupings of users having identity profiles 102 stored on Directory Server 36. A plurality of policies 106, each of which is associated with a policy domain as described above, are also stored on Directory Server 36. Revoked user list 108 identifies users previously (but no longer) allowed access to resources on their system. Shared secret(s) 110 are keys stored on Directory Server 36 used for encrypting cookies set on browsers 12 or 14 after a successful user authentication. Shared secret(s) (keys) 110 can change as often as desired by an administrator. In one embodiment of the present invention, previously valid keys are "grandfathered" such that both a current key and an immediately prior key will de-crypt encrypted cookies. Global sequence number (GSN) 112 is a unique number stored on Directory Server 36 which is assigned to a policy domain change (first level default rules) or policy change (second level resource-specific rules) and updated in response to subsequent policy changes for cache flushing purposes. In one embodiment of the present invention, the GSN is incremented to the next sequential number after detection of a policy domain or policy change. User attribute list 114 is a list of user identity profile attributes used by cached authentication and authorization rules.

FIG. 4 depicts an exemplar directory tree that can be stored on Directory Server 36. Each node on the tree is an entry in the directory structure. Node 130 is the highest node on the tree and represents an entity responsible for the directory structure. In one example, an entity may set up an Extranet and grant Extranet access to many different companies. The entity setting up the Extranet is node 130. Each of the companies with Extranet access would have a node at a level below node 130. For example, company A (node 132) and company B (node 134) are directly below node 130. Each company may be broken up into organizations. The organizations could be departments in the company or logical groups to help manage the users. For example, FIG. 4 shows company A broken up into two organizations: organization A with node 136 and organization B with node 138. Company B is shown to be broken up into two organizations: organization C with node 140 and organization D with node 142. FIG. 4
shows organization A having two end users: employee 1 with node 150 and employee 2 with node 152. Organization B is shown with two end users: employee 3 with node 154 and employee 4 with node 156. Organization C is shown with two end users: employee 5
with node 158 and employee 6 with node 160. Organization D is shown with two end users: employee 7 with node 162 and employee 8 with node 164.

Each node depicted in FIG. 4 can include one or more identity profiles stored in Directory Server 36. In one embodiment, there are different types of object-oriented classes for storing information for each identity profile. One exemplar class pertains to entities such as entity 130, company A (node 133), and company B (node 134). A second exemplar class stores information about organizational units such as organization A (node 136), organization B (node 138), organization C (node 140), and organization D (node 142). In one embodiment, each of the organizations are departments in a company and each of the users are employees who work for that particular organization. A third exemplar class is for individual persons such as employee 1
(node 150), employee 2, (node152), . . . employee 8 (node 164). Although the directory tree is depicted as having three levels, more or less than three levels can be used.

In a typical use of the Identity Management System shown in FIG. 4, a source from the Identity Management System attempts to access a target in the Identity Management System. For example, employee 1 (node 150) may seek to access the profile for employee4 (node 156). Thus, node 150 is the source and node 156 is the target. For efficiency purposes, one embodiment stores access information at the target and at the highest level for targets with common access rules. In some cases, access information is stored at a higher level even if a lower level does not include common access rules.

FIG. 5 is a flow chart describing the process for setting up an identity profile by an administrator having authority to do so. In step 200, the administrator selects the object class to be used for the directory entry or entries being created. As previously described, there are at least three classes: organization, organizational unit, and user. In step 200, the master identity administrator selects which class is to be used for the entry. After the object class is selected in step 200, all possible attributes for the particular class appear on a graphical user interface (GUI) (step 202). In step 204, the administrator selects one of the attributes. In step 206, the master identity administrator edits the access criteria for the attribute. In step 210, it is determined whether there are any more attributes to consider. If so, the method loops back to step 204. Otherwise, the process of FIG. 5 is completed (step 214).

FIG. 6 is a flow chart describing step 206 of FIG. 5, editing access criteria for an attribute. In step 230, the administrator selects where in the tree structure of FIG. 4 to store the access information for the particular attribute under consideration. For example, if the administrator is setting up an identity profile for employee 2 (node 152) of FIG. 4, attribute access information can be stored at node 152, node 136, node 132, or node 130. In step 230, it is determined which one of those available nodes will store the information. In step 232, the permissions to modify the attribute are set up using a policy. A policy can identify person(s) who can modify the attribute. The policy can identify a set of people by identifying a role, by identifying a rule for identifying people, by identifying one or more people directly by name, or by identifying a named group. In step 236, permissions are set up to determine who can view the attributes. The Identity Management System policy determines which users can view identity profile attributes by defining a role, defining a rule, identifying persons by name, or listing an identified group. In one embodiment, the rule mentioned above is an LDAP rule. In step 238 (an optional step), the ability to edit the permissions are delegated to others. In step 240, a notify list is set up. The notify list identifies a set of zero or more persons who are notified (e.g. by email) when the attribute is modified.

In one embodiment, the Identity Management System includes a localized access feature. This feature restricts certain user's access to identity profiles within a defined locale. For example, if an entity sets up an Extranet similar to the tree of FIG. 4, and allows two of its suppliers (e.g. company A and company B) to access the Extranet, company A may not want employees from company B to access identity profiles for employees of company A. In accordance with the present invention, a set of identity profiles can be defined as a locale. Users outside the locale can be restricted from accessing identity profiles inside the locale. Alternatively, users outside the locale can be restricted from accessing certain attributes of identity profiles inside the locale. The localized access feature can be used to prevent any nodes, including node 132 and any nodes below node 132, from accessing node 134 and any node below node 134. The localized access feature can be used at other levels of granularity and/or at other levels of the organizational hierarchy. For example, users below node 136 can be blocked from accessing profiles below node 138, node 140, node 142, node 134, etc.

FIG. 7 is a flow chart describing the process for configuring localized access. In step 262, a localized access parameter for the entire system of FIG. 1 is set. This parameter turns on the localized access function. In step 266 of FIG. 7, a class attribute can be set for localized access. Each identity profile has a set of attributes. One of those attributes is designated as the class attribute. The class attribute is used to identify the identity profile. A reference to a particular identity profile is a reference (or pointer) to the class attribute for the identity profile. The class attribute can be configured for localized access by setting up a localized access filter that identifies the locale. If the source of a request is in a different locale than the locale defined for the class attribute, then the source is denied access to the target. The localized access filter can be an absolute test such as "Company=Acme" or the filter can name another attribute (called a domain attribute). If the filter names a domain attribute (e.g. company attribute, address attribute, last name attribute, organization attribute, etc.), then the filter is satisfied if the named attribute for source matches the named attribute for the target. For example, if the domain attribute named for the class attribute is "Company Name," than a source can only access a target if the company name for the source is the same as the company name for the target. Using a domain attribute, rather than hard coding the criteria, is more dynamic because it depends on the run-time relationship of the source and target. In one embodiment, multiple domain attributes can be used to define the locale. Users whose domain attributes are equal, are in the same locale. A user can be a member of multiple locales.

In step 268, individual attributes for a profile can be configured for localized access. That is, some attributes in an identity profile can be configured for localized access, while other attributes are not. Each attribute can be provided with a localized access filter that identifies the locale for that attribute. The localized access filter can include an absolute test, an LDAP test or one or more domain attributes. In one embodiment, individual attributes are not configured in step 268 if the class attribute for the profile has already been set. It is possible to configure the class attribute for localized access and not configure the other attributes for localized access. Similarly, in some embodiments it is possible to not configure the class attribute for localized access while configuring the other attributes for localized access.

In one embodiment, when a source seeks to access a particular attribute in a target, the system first checks to see if the localized access filter for the class attribute of the target is satisfied. If it is not satisfied, then access is denied. If it is satisfied, then the system first checks to see if the localized access filter for the particular attribute of the target is satisfied. If it is or it is not configured for localized access, then access can be granted. If the localized access filter for the particular attribute of the target is not satisfied, access to the particular attribute is denied. In summary, the localized access filter for the class attribute determines access to the entire identity profile, while the localized access filter for a specific attribute (other than the class attribute) determines access to the specific attribute. After the steps of FIG. 7 are completed, the profiles (or portions of profiles) that have been set for localized access can only be accessed by those within the same locale.

FIG. 8 is a flow chart describing the process for accessing data in the Identity Management System. The data can be accessed for viewing, modifying, etc. As described above, the entity attempting to access a profile in the Identity Management System is the source and the profile being accessed is the target. In step 290, the source user's browser sends a request to access attributes of a target directory entry. In step 292, the request is received by User Manager 38. In step 294, User Manager 38 accesses the target profile and the source profile on Directory Server 36. In step 296, User Manager 38, based on the attribute settings created or modified by the process of FIG. 5 and (possibly) the source profile, determines whether the source should have access to each of the different attributes of the target profile. This step is discussed in further detail below. In step 298, User Manager 38 passes the information for the attributes that access is allowed for to the source's browser. In step 300, the attributes that the source may view are displayed on the source's browser.

FIG. 9 is a flow chart describing the process of step 296 of FIG. 8, determining whether the source should have access to the various attributes of the target. In step 320, the system determines whether a localized access violation for the class attribute has occurred. A localized access violation is found when the target's class attribute is configured for localized access and the source is not in the locale for the target. If there is a localized access violation, the method of FIG. 9 is done (step 344) and none of the attributes for the target may be accessed by the source. For example, if the source is employee 1 (node 150 of FIG. 4), the target is employee 8 (node 164 of FIG. 4), and all of company B is subject to localized access with a domain attribute set as "company" (in one embodiment the actual syntax is %company%) a localized access violation will be found in step 320.

If no localized access violation is found in step 320, then one of the attributes for the target is selected in step 322 and User Manager 38 determines whether the access information for that selected attribute is at the current level in the tree. The first time step 324 is performed, the current level in the tree is the level of the target. As previously explained, access information can be stored at the target's node or nodes above the target. If the access information is not found at the current level, then in step 340, it is determined whether the system is inquiring at the top level of the directory structure (e.g. node 130 of FIG. 4). If the system is at the top level, then the system determines whether all attributes have been evaluated in step 332. If all attributes have been evaluated, then the process of FIG. 9 is done (step 348). If all attributes have not been evaluated, then the system accesses the initial level again in step 334 and loops back to step 322. If in step
340, it is determined that the system is not at the top level, then the system moves up one level (step 342) and loops back to step 324.

While in step 324, if the access information for the attribute is at the current level being considered, then in step 326 it is determined whether there is a local access violation for the attribute under consideration. If the particular attribute being considered was configured for localized access and the source is not in the relevant locale for the target, then a localized access violation occurs and the method of FIG. 9 is done (step 346). It will be appreciated that localized access can apply to entire profiles or only certain portions (certain attributes) of profiles. If the attribute under consideration was not configured for localized access, then there is no localized access violation for the attribute under consideration. If there is no localized access violation for the attribute under consideration, then the identity profile for the source is applied to any additional access criteria to see whether the source should have access to the target's attribute. If the criteria is met, access is granted in step 330 and the method loops to step 332. At the end of the process of FIG. 9, a source will be granted access to zero or more attributes. Step 300 of FIG. 8 displays only those attributes for which the source has been granted access.

FIG. 10 is a flow chart describing the process of step 320 in FIG. 9, determining whether a localized access violation has occurred for a class attribute. In step 360, the Identity Management System determines whether the localized access parameter is set. If not, there is no localized access violation. If so, then in step 364, the system determines whether a class attribute is configured for localized access. If the class attribute is not configured for localized access, there is no local access violation (step 362). If the class attribute is configured for localized access, then in step 366 it is determined whether the localized access filter is satisfied (e.g. does the domain attribute for the target must match the domain attribute for the source?). If the localized access filter is satisfied, no localized access violation occurs (step 362). If the localized access filter is not satisfied, then a localized access violation exists and access should be denied (step 368).

FIG. 11 is a flow chart describing the process performed in step 326 of FIG. 9, determining whether there is a localized access violation for a particular attribute. In step 380, it is determined whether a localized access parameter is set. If not, thee is no localized access violation (step 382). Otherwise, in step 384, it is determined whether the particular attribute is configured for localized access. If the particular attribute is not configured for localized access, then there is no localized access violation (step 382). If the particular attribute is configured for localized access, then in step 386 it is determined whether the localized access filter for the attribute under consideration is satisfied. If the localized access filter is satisfied, then there is no localized access violation (step 382). If the localized access filter is not satisfied, then there is a localized access violation and access should be denied (step 388).

FIG. 12 is a flow chart describing the process of how a source user can modify an attribute of a target profile. In step 410, the source user attempts to modify an attribute. For example, in one embodiment the source user is provided a GUI which depicts the directory tree. The source user can select any node in the directory tree and click on a button to modify a target profile. Alternatively, the source user can type in a URL, distinguished name, or other identifying information for the target. Once presented with a target profile (e.g. the process of FIG. 8), the user selects a particular attribute and attempts to modify it by selecting a modify button on the GUI. This request to modify is sent to User Manager 38. In step 412, User Manager 38 searches for the modify criteria for the attribute in the target directory. This modify criteria is the information set up in step 232 of FIG. 6. User Manager 38 searches in the current target directory. If the criteria is not found in the current directory being accessed (see step 414), then it is determined whether the system is at the top of the directory tree structure (step 416). If not, then the system moves up one level in step 418. If the top of the directory structure is reached, then the source user is not allowed to modify the attribute (step 420). In step 422, User Manager 38 searches for the modify criteria in a new directory. After step 422, the method loops back to step 414. If in step 414, it is determined that the criteria was found at the current level being considered, then in step 430, the User Manager evaluates the criteria against the target user's identity profile. If the identity profile for the target user satisfies the criteria for modifying the attribute (step 432) then the source user is allowed to modify the attribute (step 434). Otherwise, the source user is not allowed to modify the attribute (step 420).

FIG. 13 is a flow chart describing a process for automating the updating of identity profiles when a source user requesting the update is not allowed to modify the target profile. In one embodiment, the source user is the person identified by the target profile. In step 450, the source user requests modification of the target profile. This can be a request to modify any or all of the attributes for the target profile (e.g. address, telephone number, creation of the profile, deletion of the profile, etc.). In step 452, it is determined whether the target profile is protected. It is possible to set all attributes such that any source entity can modify the attributes In such a configuration; the profile is not protected. If the target profile is not protected, then, in step 454, the target profile is modified as per the source user's request. If the target profile is protected, then in step 456, the User Manager 38 issues an electronic message ("ticket") sent to a responsible party requesting that the modification be made. The responsible party is a person granted access to modify a particular attribute and has the responsibility for doing so. In step 458, the ticket appears in a service queue accessible by the responsible party. The service queue can be a directory which stores all tickets or can be any database which is used to store the tickets. The responsible party may access a GUI which indicates all tickets in the service queue, the date they were received, and what service is requested. In step 460, the requesting source user can view whether a ticket has been serviced. In step 462, the ticket is fully serviced, partially serviced or denied by the responsible party. If the ticket is serviced, then the target will be modified. However, the target will not be modified if the ticket is denied. After the target is modified (or purposely not modified) and a ticket is responded to, the ticket is removed from the service queue in step 464. In an optional embodiment, the source is automatically notified that the ticket is removed from the service queue and notified of the result of the request.

FIG. 14 provides a block diagram of Web Gate 28. In one embodiment, Web Gate 28 is a Web Server plug-in running on Web Server 18. In another embodiment, Web Gate 28 is an NSAPI Web Server plug-in. In another embodiment, Web Gate 28 is an ISAPI Web Server plug-in. In still a further embodiment, Web Gate 28 is an Apache Web Server plug-in. In another embodiment, a plurality of Web Gates conforming to different plug-in formats are distributed among multiple Web Servers.

Resource cache 502 caches authentication information for individual resources. The information stored in resource cache 502 includes: request method, URL, retainer 505, and audit mask 503. In one embodiment of the present invention, audit mask
503 is a four bit data structure with separate bits identifying whether authentication and/or authorization successes and/or failures are audited (logged) for a given resource.

Authentication scheme cache 506 stores authentication scheme information, including information necessary for the performance of each different authentication challenge scheme. For example, if the authentication scheme ID parameter of a resource cache 502 entry references a "client certificate" authentication scheme, then the authentication scheme ID parameter of the entry would reference an authentication scheme cache 506 entry (keyed by the authentication challenge method ID). In one embodiment, authentication scheme cache stores redirect URL, authentication challenge method ID (identifying an authentication challenge method), challenge parameters for authentication and authentication level. Web Gate 28 also stores the most recent global sequence number 510 received from Access Server 34 pursuant to a cache flushing operation, as further described below.

Event manager 514 calls redirection event handler 504, resource protected event handler 508, authentication event handler 512, or authorization event handler 516 to perform redirection, a resource protected method, an authentication method, or an authorization method (all further described herein), respectively. Redirection event handler 504 redirects browser 12 or 14 in response to redirection events initiated by Access Server 34 or other components of Web Gate 28. Resource protected event handler 508 performs steps in a method for determining whether a requested resource falls protected within a policy domain. Authentication event handler 512 performs steps in a method for authenticating a user of browser 12 or 14 upon a finding that a requested resource is protected. Authorization event handler 516 performs steps in a method for determining whether a user of browser 12 or 14 is authorized to access a requested resource upon a successful authentication or receipt of a valid authentication cookie, further described herein. Sync record table 518 identifies all existing synchronization records not yet processed by Web Gate 28 as further described herein.

FIG. 15 provides a block diagram of Access Server 34. Authentication module 540 is provided for carrying out steps in a method for authenticating a user as further described herein. Authorization module 542 is provided for carrying out steps in a method for authorizing a user to access a requested resource as further described herein. Auditing module 544 carries out steps in a method for auditing (logging) successful and/or unsuccessful authentications and/or authorizations as further described herein. Audit logs 546 store information logged by auditing module 544 in accordance with the present invention. Audit logs sensors 548 include one or more sensors that monitor the audit logs for certain types of events. Synchronization records 550 are stored on Access Server 34 in accordance with a method for flushing caches as further described herein.

Access Server 34 stores the most recent global sequence number 554 received from Access Manager 40 pursuant to a cache flushing operation. URL prefix cache 564 stores the URL prefixes associated with policy domains that are protected by the Access Management System. URL prefix cache 564 facilitates the mapping of requested resources to policy domains, as further described herein. URL prefix cache 564 is loaded from Directory Server 36 upon initialization of Access Server 34.

Policy domain cache 566 caches all default authentication rules of each policy domain in accordance with the present invention. Policy domain cache further stores an array of rules 565 listing all default and resource-specific rules associated with resources in a given policy domain. Each rule entry in array 565 includes the ID of the rule and compiled information about the URL pattern (resource) to which the rule applies. Array 565 enables Access Server 34 to quickly find the first level default authentication, authorization, and auditing rules for a given policy domain, as well as second level rules (authentication, authorization, and auditing rules) associated with particular policies in the policy domain.

Authentication scheme cache 568 caches information necessary for the performance of different authentication challenge methods as similarly described above for authentication scheme cache 506 of Web Gate 28. Authentication rule cache 570 caches second level authentication rules associated with policies. The rules in authentication rule cache 570 are listed in array 565. Upon determining that a second level authentication rule exists and learning its ID (by looking in array 565), Access Server
34 can easily find the second level authentication rule in authentication rule cache 570. The second level rules are the rules associated with policies, discussed above.

Authorization rule cache 572 caches first level default authorization rules as well as second level authorization rules. The rules in authorization rule cache 572 are listed in array 565. Upon determining that a first or second level authorization rule exists and learning its ID (by looking in array 565), Access Server 34 can easily find the applicable authorization rule for a given resource in authorization rule cache 572.

Audit rule cache 574 caches first level default audit rules as well as second level audit rules. The rules in audit rule cache 574 are listed in array 565. Upon determining that a first or second level audit rule exists and learning its ID (by looking in array 565), Access Server 34 can easily find the applicable audit rule for a given resource in audit rule cache 574.

User profile cache 576 stores identity profile attributes previously used in authentications, authorization, or audit steps, in accordance with the present invention. User policy cache 578 stores the successful and unsuccessful authorization results for specific users requesting specific resources governed by authorization rules based on an LDAP filter or a group membership. User policy cache 578 allows Access Server 34 to quickly recall a user's authorization if the user has recently accessed the resource.

FIG. 16 is a flow chart which describes the process of creating a policy domain. In step 600, System Console 42 (or Access Manager 40) receives a request to create a policy domain. In step 602, the name of the policy domain and the description of the policy name are stored. In step 604, one or more URL prefixes are added to the policy domain. In step 605, one or more host ID's are added to the policy domain (optional). Next, one or more access rules are added to the policy domain. An access rule is a rule about accessing a resource. Examples of access rules include authorization rules, authentication rules, auditing rules, and other rules which are used during the process or attempting to access a resource. In step 606, a first level (default) authentication rule is added to the policy domain. In general, authentication is the process of verifying the identity of the user. Authentication rules specify the challenge method by which end users requesting access to a resource in the policy domain must prove their identity (authentication). As previously discussed, first level (default) authentication rules apply to all resources in a policy domain, while second level authentication rules are associated with policies that apply to subsets of resources or specific resources in the policy domain. In one embodiment, there is only one default authentication rule for a policy domain. If an administrator desires an authentication rule to apply to only a specific resource in the policy domain, a separate policy for that specific resource having a second level (specific) authentication rule should be defined, as discussed below. After setting up the authentication rule in step 606, one or more first level or default authorization rules are added to the policy domain in step 608. In general, an authorization rule determines who can access a resource. The default authorization rule allows or denies users access to resources within its applicable policy domain. If multiple authorization rules are created, then they are evaluated in an order specified in step 610. In step 612, a first level (default) audit rule is configured for the policy domain. In step 614, zero or more policies are added to the policy domain. In step 616, the data for the policy domain is stored in Directory Server 36 and appropriate caches (optional) are updated. In one embodiment, an authorization rule or an authentication rule can be set up to take no action. That is, always grant authentication without any challenge or verification; or always grant authorization without any verification.

FIG. 17 is a flow chart describing the process of adding one or more authorization rules to a policy domain (step 608 of FIG. 16). In step 632, timing conditions are set up for the authorization rule. Timing conditions restrict the time when the authorization rule is in effect. For example, users can be allowed access to URLs in the policy domain only during business hours, Monday through Friday. In one embodiment, if timing conditions are not set, the authorization rule is always in effect. The timing conditions include selecting a start date, an end date, selecting a start time and an end time, selecting the months of the year, selecting the days of the month, and selecting the days of the week that the rule is valid. In steps
634 and 636, authorization actions are set up. Authorization actions personalize the end user's interaction with the Web Server. In step 634, header variables are provided for authorization success events and authorization failure events. This feature allows for the passing of header variables about the end user (or other information) to other web-enabled resources. Web-enabled applications can personalize the end user's interaction with the Web Server using these header variables. As a simple example, the actions could supply each application with the user's name. An application could then greet the user with the message "hello<user's name>" whenever the user logs on. Header variables are variables that are part of an HTTP request. FIG. 40 below illustrates the format of an HTTP request that includes header variables 1554. If an authorization rule is set up with header variables as part of an authorization success action, then when a successful authorization occurs the HTTP request to the resource will include the header variables. Similarly, if there are header variables for an authorization failure, then an authorization failure event will include adding header variables to the HTTP request that redirects a browser to an authorization failure web page. The resources identified by the HTTP requests, that include the header variables can use the header variables any way desired. In one embodiment of the method of FIG. 17, one or more groups can be specified for authorization to the resource(s).

FIG. 18 is a flow chart that describes the process of adding header variables to an HTTP request (see step 634 of FIG. 17). Header variables can be added during an authorization success event, authorization failure event, authentication success event or authentication failure event. In step 650, the variable name is entered. In step 652, a text string is entered. In step 654, one or more LDAP attributes are entered. In step 656, it is determined whether any more header variables will be added. If not, the method of FIG. 18 is done (step 658). If so, the method of FIG. 18 loops back to step 650.

The variable name entered in step 650 is a value that appears in the HTTP header that names the variable. The downstream res