US20100162372A1 - Configurable user management - Google Patents
Configurable user management Download PDFInfo
- Publication number
- US20100162372A1 US20100162372A1 US12/660,269 US66026910A US2010162372A1 US 20100162372 A1 US20100162372 A1 US 20100162372A1 US 66026910 A US66026910 A US 66026910A US 2010162372 A1 US2010162372 A1 US 2010162372A1
- Authority
- US
- United States
- Prior art keywords
- server
- portal
- authentication technique
- password
- user
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/41—User authentication where a single sign-on provides access to a plurality of computers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
Definitions
- Enterprise portals typically seek to provide users with a single point of access to multiple resources such as information and services. For example, in a business setting, employees may use enterprise portals to manage inventory, track finances, and review procedures, all through a unified interface such as by directing a browser to an intranet site.
- the resources provided via the portal are typically gathered from multiple locations (e.g., servers) that limit access to authorized users, and may include disparate systems. For example, inventory and customer lists may be stored in a business information database, while product manuals and sales reports are stored by another component, such as a document database, with each database requiring authentication before providing access to information.
- different portal users may have different access (or no access) to some of those multiple resources. Such may be the case, for example, when two companies (with different schemas for issuing credentials to users) merge and desire to include information from both entities into a unified portal. Therefore, it would be desirable to have a better way to provide users with access to information.
- FIG. 1 illustrates an embodiment of a system for providing access to information.
- FIG. 2 is a flow chart illustrating an embodiment of a process for authenticating a portal user to a docbase using a principal login technique.
- FIG. 3 is a flow chart illustrating an embodiment of a process for authenticating a portal user to a docbase using a principal login technique.
- FIG. 4 is a flow chart illustrating an embodiment of a process for configuring a portal to authenticate users to a docbase using a principal login technique.
- FIG. 5 is a flow chart illustrating an embodiment of a process for authenticating a portal user to a docbase.
- FIG. 6 is a flow chart illustrating an embodiment of a process for configuring a portal to authenticate users to a docbase using either the principal login or the user mapping technique.
- FIG. 7 is a flow chart illustrating an embodiment of a process for configuring a portal to authenticate a user to a docbase using a user mapping technique.
- FIG. 8 is a flow chart illustrating an embodiment of a process for configuring a portal to authenticate users to a docbase using either the principal login or the user mapping technique.
- FIG. 9 is a flow chart illustrating an embodiment of a process for authenticating a portal user to a docbase.
- the invention can be implemented in numerous ways, including as a process, an apparatus, a system, a composition of matter, a computer readable medium such as a computer readable storage medium or a computer network wherein program instructions are sent over optical or communication links.
- these implementations, or any other form that the invention may take, may be referred to as techniques.
- a component such as a processor or a memory described as being configured to perform a task includes both a general component that is temporarily configured to perform the task at a given time or a specific component that is manufactured to perform the task.
- the order of the steps of disclosed processes may be altered within the scope of the invention.
- FIG. 1 illustrates an embodiment of a system for providing access to information.
- client 102 accesses portal 104 via a browser, through network 106 .
- Portal 104 is served by portal server 108 which draws content from a plurality of servers (also referred to herein as docbases) 110 - 114 , also through network 106 .
- network 106 is the Internet, a local area network, a wide area network, a wired network, a wireless network, or any other network that can enable a user to access portal 104 .
- docbases are of different types.
- docbases can include business servers configured to store, for example, plant management, engineering management, and supply chain management information, as well as related information such as accounting information, customer records, etc.
- Docbases can also include document servers configured to store documents such as web pages, text files, multimedia files, and other content.
- portal server 108 is an SAP Enterprise Portal server.
- Other portal servers such as products made by Oracle and Siebel may be used and the techniques described herein adapted, as applicable.
- Docbase 110 includes EMC Documentum software.
- docbases or components thereof are located on portal server 108 .
- a user accesses portal 104 in part to interact with information provided by docbases such as docbases 110 - 114 .
- docbases such as docbases 110 - 114 .
- Alice can use portal 104 to retrieve information such as project schedules (from docbase 110 ), design specifications (from docbase 112 ), and customer information (from docbase 114 ).
- Alice's credentials for accessing the portal include a username (“alice.jones”) and a password (“123asd$”).
- other forms of credentials such as smartcards and public key cryptography are used in addition to or instead of a username and password.
- Alice's company has a standard naming convention that requires all of her computer accounts to use the same username—“alice.jones,” though permitting users to have different passwords for different systems.
- Alice's account on docbase 110 is named “alice.jones” and has a password of “863hjd7”
- her account on docbase 112 is also named “alice.jones” but has a password of “f92d82jhs78.”
- external user management systems such as LDAP servers may be used to maintain uniformly named accounts.
- each docbase has a non-user-specific credential (e.g., a superuser password or a public key) that, when provided by portal server 108 , indicates to docbase 110 that access should be granted. For example, suppose docbase 110 has a superuser password of “XXju28s.” An administrator configuring portal server 108 for use with docbase 110 would indicate that superuser password to portal 108 .
- a non-user-specific credential e.g., a superuser password or a public key
- portal server 108 provides docbase 110 with that docbase's superuser password and indicates that docbase 110 should grant access to Alice in scope commensurate with her having typed in her own name (“alice.jones”) and docbase 110 password (“863hjd7”).
- another user such as Bob (having a company username of “bob.smith” authenticates himself to the portal and requires access to information provided by docbase 110 , instead of supplying Bob's docbase 110 password, portal server 108 would again supply the superuser password (“XXju28s.”)
- FIG. 2 is a flow chart illustrating an embodiment of a process for authenticating a portal user to a docbase using a principal login technique.
- the process of FIG. 2 is implemented by portal server 108 .
- the process begins at 202 when a portal login is received. For example, at 202 , Alice enters her username (“alice.jones”) and her portal password (“123asd$”) into a dialogue provided by portal 104 , her credentials are verified, and a portal session is started.
- At 204 it is determined whether Alice requires access to a docbase. For example, if Alice has a “start” page or summary page that lists upcoming milestones, that information may be obtained from docbase 110 and at 204 a determination that access to docbase 110 is required would be made, accordingly.
- a principal login technique is used to authenticate the user to the docbase. For example, at 206 portal server 108 would provide docbase 110 with an instruction to “logon on behalf of alice.jones, password XXju28s.” Similarly, if Bob authenticated himself to portal server 110 at 202 , at 206 an instruction to “logon on behalf of bob.smith, password XXju28s” would be provided.
- Alice is automatically authenticated to all docbases configured to work with portal server 108 . Such may be the case, for example, if the total number of docbases configured to work with portal server 108 is small. In such a case, portions of 204 - 208 may be combined or omitted as applicable.
- a superuser passphrase as a non-user-specific credential to log in on behalf of a specific user
- other non-user-specific credentials may be used instead of or in addition to a superuser passphrase, such as a digital certificate or public key.
- FIG. 3 is a flow chart illustrating an embodiment of a process for authenticating a portal user to a docbase using a principal login technique.
- the process of FIG. 3 is implemented by docbase 110 .
- the process begins at 202 when a principal login request to permit a login on behalf of a user is received.
- portal 108 provides docbase 110 with the superuser password and a request to permit Alice access to docbase 110 .
- Alice is granted access to the resources of docbase 110 commensurate in scope with her account on docbase 110 .
- Alice may have the ability to read project schedule information but not to edit that information.
- Alice would be granted read access (via portal 104 ) to project schedule information on docbase 110 accordingly.
- the scope of access granted to Alice is determined by Alice's association with one or more roles (e.g., junior engineer vs. director of sales) instead of in addition to access provided based on her account.
- Alice's access to the resources of docbase 110 is granted until she ends her session with portal 104 (such as when she selects a “logout” option). In other embodiments, Alice's access is limited in other ways, such as for a specified amount of time. Alice's access to docbase 110 terminates at 306 accordingly, as applicable.
- FIG. 4 is a flow chart illustrating an embodiment of a process for configuring a portal to authenticate users to a docbase using a principal login technique.
- the process of FIG. 4 is implemented by portal server 108 .
- the process begins at 402 when an indication that a new docbase is to be included in the sources from which portal 104 composes information is received. For example, at 402 an administrator selects an “add support for a docbase” option in an administrative interface to portal server 108 .
- the docbase indicated at 402 is not “new” in the sense that it was recently purchased—the addition of a “new” docbase may also include the first time that portal server 108 is made aware of an existing docbase.
- a principal login credential associated with the new docbase is received and stored.
- an administrator enters a superuser password associated with docbase 110 , such as “XXju28s” which is stored by portal server 108 for use in subsequent authentications on behalf of portal users (such as Alice and Bob) to docbase 110 .
- portion 404 may be repeated over time as applicable.
- Alice and Bob may also log in directly to docbase 110 using their individual (user specific passwords) in addition to accessing docbase 110 via portal 104 .
- portal server 108 can support the user mapping technique of authenticating portal users to one or more docbases.
- a user such as Alice, is provided an interface into which she can enter and store for later use the username(s) and password(s) that she typically uses to authenticate herself to docbases.
- docbase 114 For example, suppose Alice's company recently acquired another company (“Acme”) and with it docbase 114 . Acme's naming scheme for docbase 114 users is department, then first name. As such, Alice's username for docbase 114 is “FEAlice.”
- portal server 108 determines Alice's username and password for docbase 114 (from the list that Alice created and keeps current) and passes that information along to docbase 114 .
- portal server 108 can be configured to access certain docbases (such as docbase 110 and 112 ) using principal login, while accessing other docbases (such as docbase 114 ) using user mapping.
- docbases such as docbase 110 and 112
- other docbases such as docbase 114
- FIG. 5 is a flow chart illustrating an embodiment of a process for authenticating a portal user to a docbase.
- the process of FIG. 5 is implemented by portal server 108 .
- the process begins at 502 when a portal login is received. For example, at 502 , Alice enters her username (“alice.jones”) and her portal password (“123asd$”) into a dialogue provided by portal 104 , her credentials are verified, and a portal session is started.
- At 504 it is determined whether Alice requires access to a docbase. For example, suppose that in addition to the list upcoming milestones (to be provided by docbase 110 ) on her summary page, Alice is given access to a list of customers for whom the field engineering group is currently performing work (to be provided by docbase 114 ). A determination that access to docbases 110 and 114 is required would be made, accordingly at 504 .
- portal server 108 would determine that Alice should be authenticated by the portal to docbase 110 using principal login, while being authenticated to docbase 114 using user mapping.
- Alice is authenticated to docbase 110 using principal login, while at 510 , Alice is authenticated to docbase 114 using user mapping. Access is granted to additional docbases as applicable ( 512 ).
- FIG. 6 is a flow chart illustrating an embodiment of a process for configuring a portal to authenticate users to a docbase using either the principal login or the user mapping technique.
- the process of FIG. 6 is implemented by portal server 108 .
- the process begins at 602 when an indication that a new docbase is to be included in the sources from which portal 104 composes information is received, or when an indication that the authentication setting for a docbase should be changed is received. For example, at 602 an administrator selects an “add support for a docbase” option in an administrative interface to portal server 108 or selects a “modify the authentication settings of a docbase” option.
- the docbase indicated at 602 is not “new” in the sense that it was recently purchased—the addition of a “new” docbase may also include the first time that portal server 108 is made aware of an existing docbase, such as in the case where two companies or departments merge their assets.
- an administrator such as the one indicating the presence of a new docbase, is prompted to specify whether the principal login or user mapping authentication technique should be used in conjunction with authenticating users to that particular docbase. For example, at 604 an administrator may be presented with a radio button or dropdown selection option allowing the administrator to specify which technique to use with the docbase. At 606 it is determined which technique was specified.
- the portal is configured to authenticate users requiring access to the docbase via the portal using the principal login technique. For example, the process described in conjunction with FIG. 4 may be used at 608 .
- the portal is configured to authenticate users requiring access to the docbase via the portal using the user mapping technique.
- an entity such as a company may have some docbases such as docbase 110 configured one way (e.g., principal login) while having other docbases such as docbase 114 configured the other way (e.g., user mapping).
- docbase 110 configured one way (e.g., principal login)
- other docbases such as docbase 114 configured the other way (e.g., user mapping).
- the company may have legacy databases that predate the adoption of company-wide username conventions.
- FIG. 7 is a flow chart illustrating an embodiment of a process for configuring a portal to authenticate a user to a docbase using a user mapping technique.
- the process of FIG. 7 is implemented by portal server 108 .
- the process begins at 702 when an indication that user mapping is to be configured for a user is received.
- the process may be commenced a variety of ways, such as by an indication that a new portal user has been created, that an existing portal user wishes to make a change, and that a new docbase has been added.
- Alice may be presented with a prompt to configure user mapping access (e.g., specify the username and password to be used with docbase 114 ) at 702 .
- a prompt to configure user mapping access e.g., specify the username and password to be used with docbase 114
- Alice's credentials e.g., “FEAlice” and corresponding password
- Alice's credentials are received, such as through a dialogue interaction with Alice, and the received credentials are stored.
- Alice's list of username(s) and password(s) is updated and at 706 the list is associated with “alice.jones” the portal user.
- the administrator may specify a default technique to try, optionally permitting the other technique to be tried if the user cannot be authenticated using the default technique.
- a default technique may be the case, for example, where most users on most docbases are believed to have a universal login (e.g., due to use of an LDAP server), however a small number of legacy servers, users with nonstandard names (e.g., including hyphens), etc. also exist.
- FIG. 8 is a flow chart illustrating an embodiment of a process for configuring a portal to authenticate users to a docbase using either the principal login or the user mapping technique.
- the process of FIG. 8 is implemented by portal server 108 .
- the process begins at 802 when an indication that a new docbase is to be included in the sources from which portal 104 composes information is received, or when an indication that the authentication setting for a docbase should be changed is received. For example, at 802 an administrator selects an “add support for a docbase” option in an administrative interface to portal server 108 or selects a “modify the authentication settings of a docbase” option.
- the docbase indicated at 802 is not “new” in the sense that it was recently purchased—the addition of a “new” docbase may also include the first time that portal server 108 is made aware of an existing docbase, such as in the case where two companies or departments merge their assets.
- an administrator such as the one indicating the presence of a new docbase, is prompted to specify whether a default authentication technique (e.g., principal login or user mapping) should be used in conjunction with authenticating users to that particular docbase.
- a default authentication technique e.g., principal login or user mapping
- an administrator may be presented with a radio button or dropdown selection option allowing the administrator to specify whether to default to one technique and resort to the other technique in the event a user cannot be authenticated using the first technique.
- the portal is configured to authenticate users requiring access to the docbase via the portal only by using a single technique. If the administrator indicated that a default is to be set, at 810 , the portal is configured to authenticate users requiring access to the docbase via the portal using the user mapping technique and in the event that fails, to attempt to authenticate users using principal login.
- FIG. 9 is a flow chart illustrating an embodiment of a process for authenticating a portal user to a docbase.
- the process of FIG. 9 is implemented by portal server 108 .
- the process begins at 902 when a portal login is received. For example, at 902 , Alice enters her username (“alice.jones”) and her portal password (“123asd$”) into a dialogue provided by portal 104 , her credentials are verified, and a portal session is started.
- portal server 108 would evaluate Alice's list of usernames and passwords to determine if a set of credentials exists for the docbase. If so, at 910 the credentials are used to authenticate Alice to the docbase (using user mapping). If the attempts fails, or if no mapping exists, at 908 portal server 108 attempts to authenticate Alice to the docbase using principal login. Access is granted to additional docbases as applicable ( 912 ).
Abstract
A user is authenticated by receiving an indication that a portal user wants to access a server. An attempt is made to access the server using a first authentication technique. If the first technique fails, an attempt is made to access the server using a second authentication technique.
Description
- This application is a divisional of co-pending U.S. patent application Ser. No. 11/638,340 (Attorney Docket No. EMCCP177) entitled CONFIGURABLE USER MANAGEMENT filed Dec. 12, 2006, which is incorporated herein by reference for all purposes
- Enterprise portals typically seek to provide users with a single point of access to multiple resources such as information and services. For example, in a business setting, employees may use enterprise portals to manage inventory, track finances, and review procedures, all through a unified interface such as by directing a browser to an intranet site.
- The resources provided via the portal are typically gathered from multiple locations (e.g., servers) that limit access to authorized users, and may include disparate systems. For example, inventory and customer lists may be stored in a business information database, while product manuals and sales reports are stored by another component, such as a document database, with each database requiring authentication before providing access to information. In some cases, different portal users may have different access (or no access) to some of those multiple resources. Such may be the case, for example, when two companies (with different schemas for issuing credentials to users) merge and desire to include information from both entities into a unified portal. Therefore, it would be desirable to have a better way to provide users with access to information.
- Various embodiments of the invention are disclosed in the following detailed description and the accompanying drawings.
-
FIG. 1 illustrates an embodiment of a system for providing access to information. -
FIG. 2 is a flow chart illustrating an embodiment of a process for authenticating a portal user to a docbase using a principal login technique. -
FIG. 3 is a flow chart illustrating an embodiment of a process for authenticating a portal user to a docbase using a principal login technique. -
FIG. 4 is a flow chart illustrating an embodiment of a process for configuring a portal to authenticate users to a docbase using a principal login technique. -
FIG. 5 is a flow chart illustrating an embodiment of a process for authenticating a portal user to a docbase. -
FIG. 6 is a flow chart illustrating an embodiment of a process for configuring a portal to authenticate users to a docbase using either the principal login or the user mapping technique. -
FIG. 7 is a flow chart illustrating an embodiment of a process for configuring a portal to authenticate a user to a docbase using a user mapping technique. -
FIG. 8 is a flow chart illustrating an embodiment of a process for configuring a portal to authenticate users to a docbase using either the principal login or the user mapping technique. -
FIG. 9 is a flow chart illustrating an embodiment of a process for authenticating a portal user to a docbase. - The invention can be implemented in numerous ways, including as a process, an apparatus, a system, a composition of matter, a computer readable medium such as a computer readable storage medium or a computer network wherein program instructions are sent over optical or communication links. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. A component such as a processor or a memory described as being configured to perform a task includes both a general component that is temporarily configured to perform the task at a given time or a specific component that is manufactured to perform the task. In general, the order of the steps of disclosed processes may be altered within the scope of the invention.
- A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.
-
FIG. 1 illustrates an embodiment of a system for providing access to information. In the example shown,client 102 accessesportal 104 via a browser, throughnetwork 106. Portal 104 is served byportal server 108 which draws content from a plurality of servers (also referred to herein as docbases) 110-114, also throughnetwork 106. In various embodiments,network 106 is the Internet, a local area network, a wide area network, a wired network, a wireless network, or any other network that can enable a user to accessportal 104. - In some embodiments the docbases are of different types. For example, docbases can include business servers configured to store, for example, plant management, engineering management, and supply chain management information, as well as related information such as accounting information, customer records, etc. Docbases can also include document servers configured to store documents such as web pages, text files, multimedia files, and other content.
- In the example shown,
portal server 108 is an SAP Enterprise Portal server. Other portal servers, such as products made by Oracle and Siebel may be used and the techniques described herein adapted, as applicable. Docbase 110 includes EMC Documentum software. In various embodiments, docbases or components thereof (such as repositories or portions of repositories) are located onportal server 108. - As described in more detail below, a user (also referred to herein as “Alice”) accesses
portal 104 in part to interact with information provided by docbases such as docbases 110-114. For example, suppose Alice is a field engineer. Alice can useportal 104 to retrieve information such as project schedules (from docbase 110), design specifications (from docbase 112), and customer information (from docbase 114). - Alice's credentials for accessing the portal include a username (“alice.jones”) and a password (“123asd$”). In various embodiments, other forms of credentials, such as smartcards and public key cryptography are used in addition to or instead of a username and password.
- Alice's company has a standard naming convention that requires all of her computer accounts to use the same username—“alice.jones,” though permitting users to have different passwords for different systems. Thus, Alice's account on
docbase 110 is named “alice.jones” and has a password of “863hjd7” and her account ondocbase 112 is also named “alice.jones” but has a password of “f92d82jhs78.” In various embodiments, external user management systems such as LDAP servers may be used to maintain uniformly named accounts. - Configuring, or providing the ability to configure, a portal server and/or application such as
portal 108 to use a non-user-specific password to log in to one or more docbases on behalf of a portal user is disclosed, a technique sometimes referred to herein as principal login. In some embodiments, each docbase has a non-user-specific credential (e.g., a superuser password or a public key) that, when provided byportal server 108, indicates to docbase 110 that access should be granted. For example, suppose docbase 110 has a superuser password of “XXju28s.” An administrator configuringportal server 108 for use withdocbase 110 would indicate that superuser password toportal 108. Subsequently, when Alice authenticates to portal 104 (logging in to the portal), when she needs information provided bydocbase 110,portal server 108 providesdocbase 110 with that docbase's superuser password and indicates thatdocbase 110 should grant access to Alice in scope commensurate with her having typed in her own name (“alice.jones”) anddocbase 110 password (“863hjd7”). Similarly, when another user, such as Bob (having a company username of “bob.smith” authenticates himself to the portal and requires access to information provided bydocbase 110, instead of supplying Bob'sdocbase 110 password,portal server 108 would again supply the superuser password (“XXju28s.”) -
FIG. 2 is a flow chart illustrating an embodiment of a process for authenticating a portal user to a docbase using a principal login technique. In some embodiments the process ofFIG. 2 is implemented byportal server 108. The process begins at 202 when a portal login is received. For example, at 202, Alice enters her username (“alice.jones”) and her portal password (“123asd$”) into a dialogue provided byportal 104, her credentials are verified, and a portal session is started. - At 204 it is determined whether Alice requires access to a docbase. For example, if Alice has a “start” page or summary page that lists upcoming milestones, that information may be obtained from
docbase 110 and at 204 a determination that access todocbase 110 is required would be made, accordingly. - If access to a docbase is required, at 206, a principal login technique is used to authenticate the user to the docbase. For example, at 206
portal server 108 would provide docbase 110 with an instruction to “logon on behalf of alice.jones, password XXju28s.” Similarly, if Bob authenticated himself toportal server 110 at 202, at 206 an instruction to “logon on behalf of bob.smith, password XXju28s” would be provided. - If access to multiple docbases is required (208) the process continues as applicable. In various embodiments Alice is automatically authenticated to all docbases configured to work with
portal server 108. Such may be the case, for example, if the total number of docbases configured to work withportal server 108 is small. In such a case, portions of 204-208 may be combined or omitted as applicable. - Additionally, while the principal login technique is described herein as including the use of a superuser passphrase as a non-user-specific credential to log in on behalf of a specific user, in various embodiments, other non-user-specific credentials may be used instead of or in addition to a superuser passphrase, such as a digital certificate or public key.
-
FIG. 3 is a flow chart illustrating an embodiment of a process for authenticating a portal user to a docbase using a principal login technique. In some embodiments the process ofFIG. 3 is implemented bydocbase 110. The process begins at 202 when a principal login request to permit a login on behalf of a user is received. For example, at 302, portal 108, providesdocbase 110 with the superuser password and a request to permit Alice access todocbase 110. - At 304, if the credentials are confirmed, e.g., by
docbase 110 verifying that the supplied superuser passphrase is correct, Alice is granted access to the resources ofdocbase 110 commensurate in scope with her account ondocbase 110. For example, Alice may have the ability to read project schedule information but not to edit that information. At 304, Alice would be granted read access (via portal 104) to project schedule information ondocbase 110 accordingly. In some embodiments, the scope of access granted to Alice is determined by Alice's association with one or more roles (e.g., junior engineer vs. director of sales) instead of in addition to access provided based on her account. - In some embodiments, Alice's access to the resources of
docbase 110 is granted until she ends her session with portal 104 (such as when she selects a “logout” option). In other embodiments, Alice's access is limited in other ways, such as for a specified amount of time. Alice's access todocbase 110 terminates at 306 accordingly, as applicable. -
FIG. 4 is a flow chart illustrating an embodiment of a process for configuring a portal to authenticate users to a docbase using a principal login technique. In some embodiments the process ofFIG. 4 is implemented byportal server 108. The process begins at 402 when an indication that a new docbase is to be included in the sources from which portal 104 composes information is received. For example, at 402 an administrator selects an “add support for a docbase” option in an administrative interface toportal server 108. In some cases, the docbase indicated at 402 is not “new” in the sense that it was recently purchased—the addition of a “new” docbase may also include the first time thatportal server 108 is made aware of an existing docbase. - At 404, a principal login credential associated with the new docbase is received and stored. For example, at 404 an administrator enters a superuser password associated with
docbase 110, such as “XXju28s” which is stored byportal server 108 for use in subsequent authentications on behalf of portal users (such as Alice and Bob) todocbase 110. In the event that the superuser password needs to be changed (e.g., due to pdssword rotation policies),portion 404 may be repeated over time as applicable. - In some embodiments, Alice and Bob may also log in directly to docbase 110 using their individual (user specific passwords) in addition to accessing docbase 110 via
portal 104. - User Mapping
- In addition to principal login,
portal server 108 can support the user mapping technique of authenticating portal users to one or more docbases. In a user mapping scenario, a user, such as Alice, is provided an interface into which she can enter and store for later use the username(s) and password(s) that she typically uses to authenticate herself to docbases. - For example, suppose Alice's company recently acquired another company (“Acme”) and with it docbase 114. Acme's naming scheme for
docbase 114 users is department, then first name. As such, Alice's username fordocbase 114 is “FEAlice.” - In a user mapping scenario, when Alice attempts to connect to
docbase 114,portal server 108 determines Alice's username and password for docbase 114 (from the list that Alice created and keeps current) and passes that information along todocbase 114. - As described in more detail below,
portal server 108 can be configured to access certain docbases (such asdocbase 110 and 112) using principal login, while accessing other docbases (such as docbase 114) using user mapping. -
FIG. 5 is a flow chart illustrating an embodiment of a process for authenticating a portal user to a docbase. In some embodiments the process ofFIG. 5 is implemented byportal server 108. The process begins at 502 when a portal login is received. For example, at 502, Alice enters her username (“alice.jones”) and her portal password (“123asd$”) into a dialogue provided byportal 104, her credentials are verified, and a portal session is started. - At 504 it is determined whether Alice requires access to a docbase. For example, suppose that in addition to the list upcoming milestones (to be provided by docbase 110) on her summary page, Alice is given access to a list of customers for whom the field engineering group is currently performing work (to be provided by docbase 114). A determination that access to
docbases - If access to a docbase is required, at 506, it is determined whether a principal login technique or user mapping technique should be used to authenticate Alice to the docbase. For example, at 506
portal server 108 would determine that Alice should be authenticated by the portal to docbase 110 using principal login, while being authenticated to docbase 114 using user mapping. - At 508, Alice is authenticated to docbase 110 using principal login, while at 510, Alice is authenticated to docbase 114 using user mapping. Access is granted to additional docbases as applicable (512).
-
FIG. 6 is a flow chart illustrating an embodiment of a process for configuring a portal to authenticate users to a docbase using either the principal login or the user mapping technique. In some embodiments the process ofFIG. 6 is implemented byportal server 108. The process begins at 602 when an indication that a new docbase is to be included in the sources from which portal 104 composes information is received, or when an indication that the authentication setting for a docbase should be changed is received. For example, at 602 an administrator selects an “add support for a docbase” option in an administrative interface toportal server 108 or selects a “modify the authentication settings of a docbase” option. In some cases, the docbase indicated at 602 is not “new” in the sense that it was recently purchased—the addition of a “new” docbase may also include the first time thatportal server 108 is made aware of an existing docbase, such as in the case where two companies or departments merge their assets. - At 604, an administrator, such as the one indicating the presence of a new docbase, is prompted to specify whether the principal login or user mapping authentication technique should be used in conjunction with authenticating users to that particular docbase. For example, at 604 an administrator may be presented with a radio button or dropdown selection option allowing the administrator to specify which technique to use with the docbase. At 606 it is determined which technique was specified.
- If the administrator indicated that the principal login technique is to be used, at 608, the portal is configured to authenticate users requiring access to the docbase via the portal using the principal login technique. For example, the process described in conjunction with
FIG. 4 may be used at 608. If the administrator indicated that a user mapping technique is to be used, at 610, the portal is configured to authenticate users requiring access to the docbase via the portal using the user mapping technique. As described above, in some cases an entity such as a company may have some docbases such asdocbase 110 configured one way (e.g., principal login) while having other docbases such asdocbase 114 configured the other way (e.g., user mapping). One reason for this is that the company may have legacy databases that predate the adoption of company-wide username conventions. -
FIG. 7 is a flow chart illustrating an embodiment of a process for configuring a portal to authenticate a user to a docbase using a user mapping technique. In some embodiments the process ofFIG. 7 is implemented byportal server 108. The process begins at 702 when an indication that user mapping is to be configured for a user is received. The process may be commenced a variety of ways, such as by an indication that a new portal user has been created, that an existing portal user wishes to make a change, and that a new docbase has been added. The first time that Alice logs intoportal 104 afterdocbase 114 has been added, Alice may be presented with a prompt to configure user mapping access (e.g., specify the username and password to be used with docbase 114) at 702. - At 704, Alice's credentials (e.g., “FEAlice” and corresponding password) are received, such as through a dialogue interaction with Alice, and the received credentials are stored. For example, at 704, Alice's list of username(s) and password(s) is updated and at 706 the list is associated with “alice.jones” the portal user.
- Configuring a Default
- In some embodiments, in addition to permitting an administrator to specify whether principal login or user mapping should be used when authenticating a portal user to a docbase, the administrator may specify a default technique to try, optionally permitting the other technique to be tried if the user cannot be authenticated using the default technique. Such may be the case, for example, where most users on most docbases are believed to have a universal login (e.g., due to use of an LDAP server), however a small number of legacy servers, users with nonstandard names (e.g., including hyphens), etc. also exist.
-
FIG. 8 is a flow chart illustrating an embodiment of a process for configuring a portal to authenticate users to a docbase using either the principal login or the user mapping technique. In some embodiments the process ofFIG. 8 is implemented byportal server 108. The process begins at 802 when an indication that a new docbase is to be included in the sources from which portal 104 composes information is received, or when an indication that the authentication setting for a docbase should be changed is received. For example, at 802 an administrator selects an “add support for a docbase” option in an administrative interface toportal server 108 or selects a “modify the authentication settings of a docbase” option. In some cases, the docbase indicated at 802 is not “new” in the sense that it was recently purchased—the addition of a “new” docbase may also include the first time thatportal server 108 is made aware of an existing docbase, such as in the case where two companies or departments merge their assets. - At 804, an administrator, such as the one indicating the presence of a new docbase, is prompted to specify whether a default authentication technique (e.g., principal login or user mapping) should be used in conjunction with authenticating users to that particular docbase. For example, at 804 an administrator may be presented with a radio button or dropdown selection option allowing the administrator to specify whether to default to one technique and resort to the other technique in the event a user cannot be authenticated using the first technique. At 806 it is determined whether a default was specified.
- If the administrator indicates that no default should be used, at 808, the portal is configured to authenticate users requiring access to the docbase via the portal only by using a single technique. If the administrator indicated that a default is to be set, at 810, the portal is configured to authenticate users requiring access to the docbase via the portal using the user mapping technique and in the event that fails, to attempt to authenticate users using principal login.
-
FIG. 9 is a flow chart illustrating an embodiment of a process for authenticating a portal user to a docbase. In some embodiments the process ofFIG. 9 is implemented byportal server 108. The process begins at 902 when a portal login is received. For example, at 902, Alice enters her username (“alice.jones”) and her portal password (“123asd$”) into a dialogue provided byportal 104, her credentials are verified, and a portal session is started. - At 904 it is determined whether Alice requires access to a docbase. If access to a docbase is required, at 906, it is determined whether there exists a user mapping associated with Alice that indicates a login and password that should be used to authenticate Alice to the docbase. For example, at 906
portal server 108 would evaluate Alice's list of usernames and passwords to determine if a set of credentials exists for the docbase. If so, at 910 the credentials are used to authenticate Alice to the docbase (using user mapping). If the attempts fails, or if no mapping exists, at 908portal server 108 attempts to authenticate Alice to the docbase using principal login. Access is granted to additional docbases as applicable (912). - Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not restrictive.
Claims (22)
1. A method of authenticating a user comprising:
receiving an indication that a portal user wants to access a server;
attempting to access the server using a first authentication technique; and
attempting to access the server using a second authentication technique if the first technique fails.
2. The method of claim 1 , wherein the first authentication technique includes portal user mapping which includes providing, to the server, a stored username that is unique to the portal user being authenticated.
3. The method of claim 1 , wherein the second authentication technique includes principal login which includes providing, to the server, a non-user-specific password that is not unique to the portal user being authenticated.
4. The method of claim 3 , wherein the non-user-specific password includes a superuser password and/or a public key.
5. The method of claim 1 further comprising receiving, from an administrator, a configuration specifying which authentication technique to use as the first authentication technique and which authentication technique to use as the second authentication technique.
6. The method of claim 5 wherein the server is one of a plurality of servers and the method further includes selecting which authentication technique to use as the first authentication technique and which authentication technique to use as the second authentication technique based at least in part on the types and numbers of authentication techniques used by the plurality of servers.
7. The method of claim 1 further comprising:
receiving from the portal user a first username and a first password at a portal server; and
authenticating the portal user at the portal server using the first username and the first password, wherein:
attempting to access the server using a first authentication technique includes determining, at the portal server, a second username and a second password and passing the second username and the second password from the portal server to the server; and
attempting to access the server using a second authentication technique includes determining, at the portal server, a third username and a third password and passing the third username and the third password from the portal server to the server.
8. A system for authenticating a user comprising:
a processor; and
a memory coupled with the processor, wherein the memory is configured to provide the processor with instructions which when executed cause the processor to:
receive an indication that a portal user wants to access a server;
attempt to access the server using a first authentication technique; and
attempt to access the server using a second authentication technique if the first technique fails.
9. The system of claim 8 , wherein the first authentication technique includes portal user mapping which includes providing, to the server, a stored username that is unique to the portal user being authenticated.
10. The system of claim 8 , wherein the second authentication technique includes principal login which includes providing, to the server, a non-user-specific password that is not unique to the portal user being authenticated.
11. The system of claim 10 , wherein the non-user-specific password includes a superuser password and/or a public key.
12. The system of claim 8 , wherein the memory is configured to provide the processor with further instructions to receive, from an administrator, a configuration specifying which authentication technique to use as the first authentication technique and which authentication technique to use as the second authentication technique.
13. The system of claim 12 wherein the server is one of a plurality of servers and the memory is configured to provide the processor with further instructions to select which authentication technique to use as the first authentication technique and which authentication technique to use as the second authentication technique based at least in part on the types and numbers of authentication techniques used by the plurality of servers.
14. The system of claim 8 , wherein the memory is configured to provide the processor with further instructions to:
receive from the portal user a first username and a first password at a portal server; and
authenticate the portal user at the portal server using the first username and the first password, wherein:
the instructions for attempting to access the server using a first authentication technique include instructions for determining, at the portal server, a second username and a second password and passing the second username and the second password from the portal server to the server; and
the instructions for attempting to access the server using a second authentication technique include instructions for determining, at the portal server, a third username and a third password and passing the third username and the third password from the portal server to the server.
15. The system of claim 8 , wherein the server includes one or more of the following: a business server, a document server, a database, or a docbase.
16. A computer program product for authenticating a user, the computer program product being embodied in a computer readable storage medium and comprising computer instructions for:
receiving an indication that a portal user wants to access a server;
attempting to access the server using a first authentication technique; and
attempting to access the server using a second authentication technique if the first technique fails.
17. The computer program product of claim 16 , wherein the first authentication technique includes portal user mapping which includes providing, to the server, a stored username that is unique to the portal user being authenticated.
18. The computer program product of claim 16 , wherein the second authentication technique includes principal login which includes providing, to the server, a non-user-specific password that is not unique to the portal user being authenticated.
19. The computer program product of claim 18 , wherein the non-user-specific password includes a superuser password and/or a public key.
20. The computer program product of claim 1 further comprising computer instructions for receiving, from an administrator, a configuration specifying which authentication technique to use as the first authentication technique and which authentication technique to use as the second authentication technique.
21. The computer program product of claim 20 wherein the server is one of a plurality of servers and the computer program product further includes computer instructions for selecting which authentication technique to use as the first authentication technique and which authentication technique to use as the second authentication technique based at least in part on the types and numbers of authentication techniques used by the plurality of servers.
22. The computer program product of claim 16 further comprising computer instructions for:
receiving from the portal user a first username and a first password at a portal server; and
authenticating the portal user at the portal server using the first username and the first password, wherein:
the computer instructions for attempting to access the server using a first authentication technique include computer instructions for determining, at the portal server, a second username and a second password and passing the second username and the second password from the portal server to the server; and
the computer instructions for attempting to access the server using a second authentication technique include computer instructions for determining, at the portal server, a third username and a third password and passing the third username and the third password from the portal server to the server.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/660,269 US20100162372A1 (en) | 2006-12-12 | 2010-02-23 | Configurable user management |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/638,340 US7702787B1 (en) | 2006-12-12 | 2006-12-12 | Configurable user management |
US12/660,269 US20100162372A1 (en) | 2006-12-12 | 2010-02-23 | Configurable user management |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/638,340 Division US7702787B1 (en) | 2006-12-12 | 2006-12-12 | Configurable user management |
Publications (1)
Publication Number | Publication Date |
---|---|
US20100162372A1 true US20100162372A1 (en) | 2010-06-24 |
Family
ID=42103329
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/638,340 Active 2028-07-18 US7702787B1 (en) | 2006-12-12 | 2006-12-12 | Configurable user management |
US12/660,269 Abandoned US20100162372A1 (en) | 2006-12-12 | 2010-02-23 | Configurable user management |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/638,340 Active 2028-07-18 US7702787B1 (en) | 2006-12-12 | 2006-12-12 | Configurable user management |
Country Status (1)
Country | Link |
---|---|
US (2) | US7702787B1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130333002A1 (en) * | 2012-06-07 | 2013-12-12 | Wells Fargo Bank, N.A | Dynamic authentication in alternate operating environment |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20110246524A1 (en) * | 2010-04-01 | 2011-10-06 | Salesforce.Com, Inc. | System, method and computer program product for portal user data access in a multi-tenant on-demand database system |
Citations (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5768504A (en) * | 1995-06-30 | 1998-06-16 | International Business Machines Corporation | Method and apparatus for a system wide logan in a distributed computing environment |
US6163844A (en) * | 1997-03-06 | 2000-12-19 | Software And Systems Engineering Limited | Method for granting accesses to information in a distributed computer system |
US6668322B1 (en) * | 1999-08-05 | 2003-12-23 | Sun Microsystems, Inc. | Access management system and method employing secure credentials |
US20040243626A1 (en) * | 2003-05-30 | 2004-12-02 | Sureprep, Llc | System and method for managing login resources for the submission and performance of engagements |
US20050015490A1 (en) * | 2003-07-16 | 2005-01-20 | Saare John E. | System and method for single-sign-on access to a resource via a portal server |
US6892307B1 (en) * | 1999-08-05 | 2005-05-10 | Sun Microsystems, Inc. | Single sign-on framework with trust-level mapping to authentication requirements |
US20050105122A1 (en) * | 2003-11-14 | 2005-05-19 | Canon Kabushiki Kaisha | Image formation apparatus, control method of image formation apparatus, storage medium of storing computer-readable program, and program |
US20050188222A1 (en) * | 2004-02-24 | 2005-08-25 | Covelight Systems, Inc. | Methods, systems and computer program products for monitoring user login activity for a server application |
US20060193473A1 (en) * | 2005-02-28 | 2006-08-31 | Judy Fu | Key management for group communications |
US7124203B2 (en) * | 2000-07-10 | 2006-10-17 | Oracle International Corporation | Selective cache flushing in identity and access management systems |
US7137006B1 (en) * | 1999-09-24 | 2006-11-14 | Citicorp Development Center, Inc. | Method and system for single sign-on user access to multiple web servers |
US20070033643A1 (en) * | 2005-07-19 | 2007-02-08 | Ssh Communications Security Corp. | User authentication in connection with a security protocol |
US20070050850A1 (en) * | 2005-08-30 | 2007-03-01 | Fujitsu Limited | Control method, control program, and control system |
US20070213033A1 (en) * | 2006-03-10 | 2007-09-13 | Samsung Electronics Co., Ltd. | Method and apparatus for authenticating mobile terminal on handover |
US20080091948A1 (en) * | 2006-10-17 | 2008-04-17 | Hofmann Christoph H | Propagation of principal authentication data in a mediated communication scenario |
US7412720B1 (en) * | 2001-11-02 | 2008-08-12 | Bea Systems, Inc. | Delegated authentication using a generic application-layer network protocol |
US7444368B1 (en) * | 2000-02-29 | 2008-10-28 | Microsoft Corporation | Methods and systems for selecting methodology for authenticating computer systems on a per computer system or per user basis |
US7443983B2 (en) * | 2003-12-19 | 2008-10-28 | Kabushiki Kaisha Toshiba | Communication apparatus and method |
US7496761B2 (en) * | 2004-09-29 | 2009-02-24 | Microsoft Corporation | Method and system for batch task creation and execution |
US7668871B1 (en) * | 2005-04-20 | 2010-02-23 | Network Appliance, Inc. | Providing mapped user account information to a storage server |
US8046823B1 (en) * | 2006-10-03 | 2011-10-25 | Stamps.Com Inc. | Secure application bridge server |
US8056124B2 (en) * | 2005-07-15 | 2011-11-08 | Microsoft Corporation | Automatically generating rules for connection security |
-
2006
- 2006-12-12 US US11/638,340 patent/US7702787B1/en active Active
-
2010
- 2010-02-23 US US12/660,269 patent/US20100162372A1/en not_active Abandoned
Patent Citations (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5768504A (en) * | 1995-06-30 | 1998-06-16 | International Business Machines Corporation | Method and apparatus for a system wide logan in a distributed computing environment |
US6163844A (en) * | 1997-03-06 | 2000-12-19 | Software And Systems Engineering Limited | Method for granting accesses to information in a distributed computer system |
US6892307B1 (en) * | 1999-08-05 | 2005-05-10 | Sun Microsystems, Inc. | Single sign-on framework with trust-level mapping to authentication requirements |
US6668322B1 (en) * | 1999-08-05 | 2003-12-23 | Sun Microsystems, Inc. | Access management system and method employing secure credentials |
US7137006B1 (en) * | 1999-09-24 | 2006-11-14 | Citicorp Development Center, Inc. | Method and system for single sign-on user access to multiple web servers |
US7444368B1 (en) * | 2000-02-29 | 2008-10-28 | Microsoft Corporation | Methods and systems for selecting methodology for authenticating computer systems on a per computer system or per user basis |
US7124203B2 (en) * | 2000-07-10 | 2006-10-17 | Oracle International Corporation | Selective cache flushing in identity and access management systems |
US7412720B1 (en) * | 2001-11-02 | 2008-08-12 | Bea Systems, Inc. | Delegated authentication using a generic application-layer network protocol |
US20040243626A1 (en) * | 2003-05-30 | 2004-12-02 | Sureprep, Llc | System and method for managing login resources for the submission and performance of engagements |
US20050015490A1 (en) * | 2003-07-16 | 2005-01-20 | Saare John E. | System and method for single-sign-on access to a resource via a portal server |
US20050105122A1 (en) * | 2003-11-14 | 2005-05-19 | Canon Kabushiki Kaisha | Image formation apparatus, control method of image formation apparatus, storage medium of storing computer-readable program, and program |
US7443983B2 (en) * | 2003-12-19 | 2008-10-28 | Kabushiki Kaisha Toshiba | Communication apparatus and method |
US20050188222A1 (en) * | 2004-02-24 | 2005-08-25 | Covelight Systems, Inc. | Methods, systems and computer program products for monitoring user login activity for a server application |
US7496761B2 (en) * | 2004-09-29 | 2009-02-24 | Microsoft Corporation | Method and system for batch task creation and execution |
US20060193473A1 (en) * | 2005-02-28 | 2006-08-31 | Judy Fu | Key management for group communications |
US7668871B1 (en) * | 2005-04-20 | 2010-02-23 | Network Appliance, Inc. | Providing mapped user account information to a storage server |
US8056124B2 (en) * | 2005-07-15 | 2011-11-08 | Microsoft Corporation | Automatically generating rules for connection security |
US20070033643A1 (en) * | 2005-07-19 | 2007-02-08 | Ssh Communications Security Corp. | User authentication in connection with a security protocol |
US20070050850A1 (en) * | 2005-08-30 | 2007-03-01 | Fujitsu Limited | Control method, control program, and control system |
US20070213033A1 (en) * | 2006-03-10 | 2007-09-13 | Samsung Electronics Co., Ltd. | Method and apparatus for authenticating mobile terminal on handover |
US8046823B1 (en) * | 2006-10-03 | 2011-10-25 | Stamps.Com Inc. | Secure application bridge server |
US20080091948A1 (en) * | 2006-10-17 | 2008-04-17 | Hofmann Christoph H | Propagation of principal authentication data in a mediated communication scenario |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130333002A1 (en) * | 2012-06-07 | 2013-12-12 | Wells Fargo Bank, N.A | Dynamic authentication in alternate operating environment |
US8875252B2 (en) * | 2012-06-07 | 2014-10-28 | Wells Fargo Bank, N.A. | Dynamic authentication in alternate operating environment |
US9742770B2 (en) | 2012-06-07 | 2017-08-22 | Wells Fargo Bank, N.A. | Dynamic authentication in alternate operating environment |
US10193888B1 (en) * | 2012-06-07 | 2019-01-29 | Wells Fargo Bank, N.A. | Dynamic authentication in alternate operating environment |
Also Published As
Publication number | Publication date |
---|---|
US7702787B1 (en) | 2010-04-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10003667B2 (en) | Profile and consent accrual | |
US7516134B2 (en) | Controlling access to a database using database internal and external authorization information | |
US7925752B2 (en) | System for providing single sign-on user names for web cookies in a multiple user information directory environment | |
US7225256B2 (en) | Impersonation in an access system | |
CA2574883C (en) | Single sign-on with common access card | |
US7447701B2 (en) | Automatic configuration of attribute sets | |
EP2109955B1 (en) | Provisioning of digital identity representations | |
JP4782986B2 (en) | Single sign-on on the Internet using public key cryptography | |
US8375113B2 (en) | Employing wrapper profiles | |
US8407767B2 (en) | Provisioning of digital identity representations | |
US7512585B2 (en) | Support for multiple mechanisms for accessing data stores | |
US20070143860A1 (en) | Networked identity framework | |
US20040010519A1 (en) | Rule based data management | |
US20020147813A1 (en) | Proxy system | |
US20030236977A1 (en) | Method and system for providing secure access to applications | |
JP5422753B1 (en) | Policy management system, ID provider system, and policy evaluation apparatus | |
US7188252B1 (en) | User editable consent | |
US7702787B1 (en) | Configurable user management | |
US8533789B1 (en) | User management for repository manager | |
US20080294639A1 (en) | System and Method For Delegating Program Management Authority | |
JP2005107984A (en) | User authentication system | |
Alenius | Authentication and Authorization: Achieving Single Sign-on in an Erlang Environment |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: EMC CORPORATION,MASSACHUSETTS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:RAGHUNATHAN, SRIKANTHAN;PRADHAN, ARATI;THOMAS, JOHN;AND OTHERS;SIGNING DATES FROM 20070116 TO 20070122;REEL/FRAME:024054/0510 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: OPEN TEXT CORPORATION, CANADA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:EMC CORPORATION;REEL/FRAME:041347/0160 Effective date: 20170112 |