GB2467038A

GB2467038A - Generating portal navigational elements based on a users authentication level

Info

Publication number: GB2467038A
Application number: GB201000391A
Authority: GB
Inventors: Matthias Falkenberg; Stefan Schmitt; Michael Wasmund
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2009-01-19
Filing date: 2010-01-12
Publication date: 2010-07-21
Also published as: GB201000391D0

Abstract

A request for a portal view (402, fig 4) is received from a client (502, fig 5) and the client's permission level determines (106) the set of resources available to the client, preferably by filtering out resources from a a portal resource set that do not correspond to the permission level. The client user's authentication level is also determined and viewable resources, from the set of available resources, are determined based on the authentication level (110), the viewable resources being portal level resources. Portal view code is generated and transmitted to the client for rendering (112), including code for displayable navigation elements corresponding to the viewable resources. When the portal view code is rendered by the client, no interface elements exist for viewable resources for which the authorisation level - either the permission or the authentication level - was insufficient. The viewable resources may be determined based on a visibility depth parameter - possibly associated with the user and possibly based on a context of the client - in addition to the authentication level.

Description

INTELLECTUAL

. .... PROPERTY OFFICE Application No. GB1000391.l RTM Date:26 April 2010 The following terms are registered trademarks and should be read as such wherever they occur in this document: Java Smalitalk Intellectual Property Office is an operating name of the Patent Office www.ipo.gov.uk

GENERATING PORTAL NAVIGATIONAL ELEMENTS

BASED ON A USER'S AUTHENTICATION LEVEL

FIELD OF THE INVENTION

The present invention relates to the field of user interfaces in computing environments, and more particularly to controlling the rendering of navigational elements rendered in an application or portal view associated with restricted resources.

BACKGROUND OF THE INVENTION

Networked computing environments are in widespread use, and allow easy access to, and processing of information. A common mode of operating a networked system is the client-server mode, where a remote system, referred to as a client, having limited resources accesses a server to allow a user of the client to interact with the resources associated or linked to the server. A user interface is rendered at the client system to allow the user to navigate views and operation of resources at the server. The same type of graphical navigation interface may be used for locally executed software applications as well to access and manipulate locally protected resources.

Protected resources are accessible to users depending on their permissions level relating to the resource, and include resources such as information in a database. Users are allowed, or not allowed to access resources based on their permissions settings or attributes. Pennissions are related to user identity, which may be determined by a variety of methods. The use of a user-name and password being perhaps the most common means of identifying a user. Typically a user requests access to a resource via a user interface, such as one rendered by a browser. The system providing the code for rendering the user interface often generates the code based on the identity of the user and the user's permissions. In some cases navigational elements to resources which the user does not have sufficient permission to access are displayed, but not actively linked. Sometimes they are shown as being "grayed out." Alternatively, upon clicking on the navigational element, a message similar to "you do not have permission to access this resource" may be displayed to the user. Still other times the server may challenge a user for a higher authentication level before allowing the user to access resources when clicking on a navigational element.

The conventional method of rendering navigational elements therefore may result in a number of navigational elements being displayed which are not active for a given user, or which require further identificationlauthentication. This creates a few problems. First, rendering "dead" navigational elements takes up space in the user's view. Second, displaying a dead navigational element discloses the presence of a corresponding resource, even though the user may not have permission to access the resource, which is a security issue. Similarly, navigational elements which are rendered, but result in an "insufficient permissions" message reveal the existence of the resource, as do navigational elements which result in an authentication challenge. Therefore there is a need better control of rendering navigational elements to minimize the number of elements displayed and to minimize exposure of the existence of protected resources.

DISCLOSURE OF THE INVENTION

The invention, in one embodiment, provides a method to control the rendering of navigational elements at a client machine in a portal view. The method commences at a portal server upon receiving a request for a portal view from a client. The client is a computer system used by a user to access the portal server. The portal server then commences determining a set of resources available to the user based on a permissions level of the user. The available resources are filtered in view of the user's permission to access each of the available resources. The portal server then commences determining an authentication level of a user of the user. The authentication level is determined by the method of accessing the portal server used by the user. Once the authentication level of the user is ascertained, the portal server then commences determining viewable resources from the set of resources, based on the authentication level. Once the resources which are available to the user, based separately on the user's permissions to access the resources, the user's authentication level, and the authentication level required for resources the user has permission to access, the portal server then commences generating portal view code including code for displayable navigational elements corresponding to the viewable resources, whereupon the portal server transmits the portal view code to the client for rendering.

The invention further provides a computer program product stored in a machine readable storage medium having machine readable code for operating a portal which, when executed by the portal configures the portal to receive a request for a portal view from a client, then determine a set of resources available to the client based on a permissions level of the client.

Upon determining the set of resources available, the portal is further configured to determine an authentication level of a user of the client, and determine the viewable resources available to the user from the set of resources which the user has permission to access, based on the authentication level. Once the accessible resources are determined, based separately on the user's permissions to access the resources, the user's authentication level, and the authentication level required for resources the user has permission to access, the portal is further configured to generate portal view code including displayable navigational elements corresponding to the viewable resources, and transmit the portal view code to the client for rendering.

The invention further embodies a portal view generation system, which includes a portal site configured to receive a request for a portal view from a client, and determine a set of resources available to a user of the client based on a permissions level associated with the user for each of the plurality of resources. The portal site is further configured to determine an authentication level of the user of the client, and determine viewable resources from the set of resources based on the authentication level. The portal site is further configured to generate portal view code including code for displayable navigational elements corresponding to the viewable resources, and transmit the portal view code to the client for rendering.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flow chart diagram of a method of determining which navigational elements to allow a requesting user to render in response to receiving a request for access to resources, in accordance with an embodiment of the invention; FIG. 2 is a flow chart diagram of a method of determining which navigational elements to allow a requesting user to render in response to receiving a request for access to resources in view of the user's authentication level and visibility depth, in accordance with an embodiment of the invention; FIG. 3 is a flow chart of a method of using a rendered navigational element, in accordance with an embodiment of the invention; FIG. 4 is a portal GUI window showing rendered navigational elements which correspond to pages holding portlets for accessing various resources associated with the portlets, in accordance with an embodiment of the invention; and FIG. 5 shows a system diagram and signal flow in a portal site for generating navigational elements, in accordance with an embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

The present invention discloses a solution for the problem of rendering unusable or inoperative navigational elements by rendering them only if the requesting user has both proper permission to access a resource, and has authenticated to a given level dictated by the resource. More specifically, the invention determines which navigational elements to deliver to a requesting user by both the user's permissions level as well as the user's authentication level. Although a user may have permission to access a given resource, the resource may dictate that a particular authentication level be employed in order to grant access, despite the user's permission level. Upon receiving the request, the portal server which generates the code for rendering the user interface determines a set of resources which the user has permission to access. This set is further filtered based on the authentication method used by the user. Those resources which the user has permission to access, but has not authenticated to a sufficient level are removed from consideration. The remaining resources determine which navigational elements are needed, and the server generates code for rendering those navigational elements which is then returned to the user.

As will be appreciated by one skilled in the art, the present invention may be embodied as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit," "module" or "system." Furthermore, the present invention may take the form of a computer program product on a computer-usable storage medium having computer-usable program code embodied in the medium. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc. Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer-usable medium may include a propagated data signal with the computer-usable program code embodied therewith, either in baseband or as part of a carrier wave. The computer usable program code may be transmitted using any appropriate medium, including but not limited to the Tnternet, wireline, optical fiber cable, RF, etc. Any suitable computer usable or computer readable medium may be utilized. The computer-usable or computer-readable medium may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory, a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk -read oniy memory (CD-ROM), compact disk -read/write (CD-RIW) and DYD. Other computer-readable medium can include a transmission media, such as those supporting the Tnternet, an intranet, a personal area network (PAN), or a magnetic storage device. Transmission media can include an electrical connection having one or more wires, an optical fiber, an optical storage device, and a defined segment of the electromagnet spectrum through which digitally encoded content is wirelessly conveyed using a carrier wave.

Note that the computer-usable or computer-readable medium can even include paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory.

Computer program code for carrying out operations of the present invention may be written in an object oriented programming language such as Java, Smalitalk, C++ or the like. However, the computer program code for carrying out operations of the present invention may also be written in conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus.

The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.

Input/output or I/O devices (including, but not limited to, keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers.

Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.

The present invention is described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the functionlact specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

FIG. 1 is a flow chart diagram 100 of a method of determining or controlling which navigational elements to render in response to receiving a request for access to resources, in accordance with an embodiment of the invention. The method represented by the present flow chart diagram is performed by, for example, a portal site. At the start of the method 102, the portal site receives a request for access to various portal resources. The request identifies the requesting user, and may be made using any one of several authentication methods. The portal site generates code for use by the requesting user's computer to render a user interface including navigational elements to navigate the portal resources. For example, the portal resources may be made available in portlets displayed at the user's computing equipment.

Different resources may be accessed by different portlets. Therefore, to select the desired resource, a navigational element will be required to allow the user to link to the resource and generate the associated portlet or portlets that are grouped together on one page. However, only those resources which the user has a sufficient authentication level to access are to be made available with appropriate navigational elements. The first process, then, is to determine if a given resource is protected (104). Assuming the resource in question is protected, the site then determines whether the requesting user has permission to access the particular resource (106). If the user has sufficient permission, then the site determines whether the particular resource requires a minimum authentication level for access (108).

Furthermore, if the resource is not protected, the site may still check to determine whether the resource requires a particular level of authentication, which may occur, for example, in a private network where permissions are not used. If the resource does require a minimum authentication level, then the site determines whether the authentication method used by the requesting user meets the minimum authentication level for the resource (110).

Authentication may be performed by any one of a variety of known authentication methods, including methods of passive authentication. A base level of authentication is to provide a password when logging on to the site. Higher levels of authentication may include submission of a digital certificate, answering challenge questions, and so on. Passive methods may include, for example, identifying the media access controller (MAC) address of the computer used by the requesting user, biometric information such as comparing typing patterns used by the requesting user with known typing patterns associated with the user, and encrypted cookies, among other methods. Once the site determines that the requesting user has used a sufficiently trustworthy method of authentication, the site will render the navigational element (112). To render the navigational elements, the site will generate code for the navigational element that will be included in the code sent to the user's computer equipment for rendering, and displaying the navigational element. The navigational element includes a hyperlink to the resource, and may further include a graphical element such as the image of a button, and it may further include an application programming interface (API) to launch a portlet in the user interface at the requesting user's terminal. The method then terminates 114 for the present resource. However, the method is repeated for each resource which may be available within the scope of the request. As will be appreciated by those skilled in the art, the present method uses a two step filtering process for each available resource within the scope of the received request. First, the resources are filtered by permissions level; any resources the user does not have sufficient permissions to access are eliminated from further processing. Then the resources are again filtered by authentication level. Those viewable resources for which the user has sufficiently authenticated determine which navigational elements will be required in the generation of the site code returned to the user in response to the request. It will be appreciated by those skilled in the art that, although the invention has been presented here by showing determination of permissions, and then authentication level, those processes may be performed in reverse order, or simultaneously.

FIG. 2 is a flow chart diagram 200 of a method of determining which navigational elements to allow a requesting user to render in response to receiving a request for a portal view providing a view of, and possibly access to resources, in accordance with an embodiment of the invention. The present embodiment illustrated here is similar to that shown in FIG. 1, except that a visibility depth parameter is used in association with the authentication of the user for the purpose of determining whether to render navigational elements associated with protected resources. The method starts 202 by receiving a request for access to resources at a server, site, or other entity controlling access to resources. The response to the request will include code for rendering a user interface in a browser at the requesting user's equipment. Each resource available within the scope of the request must be determined, and filtered out if the requesting user doesn't either have sufficient permissions on the resource, or hasn't sufficiently authenticated. Therefore, the method commences on a given resource, such as a resource made accessible via a portlet in the rendered user interface, by determining if the resource is protected (204). If the resource is protected, the site determines whether the requesting user has sufficient permission to access the particular resource under consideration (206). If the user has sufficient permission to access the resource, the system determines the user's level of authentication in addition to a visibility depth parameter, and whether that range is sufficient to render a navigational element for the resource (208). The user's present authentication level may be adjusted by a visibility depth parameter for the purpose of allowing the user to see navigational elements relating to otherwise restricted resources. The user may still be denied access to those resources without sufficient authentication, but the user will be aware of the existence of the resource by virtue of the rendered navigational element. The visibility depth parameter augments the user's present authentication level for navigational element consideration, and is a parameter stored in the serving system. The visibility depth parameter may be associated with a record corresponding to the user, or it may relate to a particular resource, or it may be a global parameter which applies to all user and all resources, or combinations of these. It may be stored, for example, with the user's permissions record, and accessed when the system checks the user's permissions against the present resource. The user's method of authentication is determined and classified as to a level of trust. In the embodiment of FIG. 1, the user's authentication level, based on the method of authenticating used, was strictly followed for determining whether to render navigational elements. Accordingly, the server site will generate code for a navigational element corresponding to the resource to allow rendering of the navigational element (210).

The method terminates (212) upon rendering the navigational elements, by generating the code for the navigational elements, or if the requesting user either does not have sufficient permission or appropriate authentication level to access the requested resource.

FIG. 3 is a flow chart of a method of using a rendered navigational element, in accordance with an embodiment of the invention. The present method illustrates operation of the visibility depth parameter for rending navigational elements, while maintaining the security of protected resources. At the start 302, the user has requested a portal view. In response, the portal server transmits code for rending a particular navigation element relating to a protected resource (304). The navigational element includes an address such as a URL or other network locator corresponding to the protected resource, which allows the user to click on the rendered navigational element in the user's portal view to gain access to the resource. Once the user clicks on the rendered navigational element, a request is issued from the user's terminal to the portal site, which receives the request (306). In the present embodiment, the portal site determines whether the user previously authenticated, for the purpose of receiving a portal view, using a visibility depth parameter (308). This may be performed, for example, by tracking the user, or the visibility depth parameter may be indicated in the link address received with the request. If the user was authenticated at a high enough level that no visibility depth parameter was necessary, the user is granted access to the resource (310), and the method terminates (312).

However, in cases where the user was allowed to render the navigational element due to the user's authentication level being increased via a visibility depth parameter, the user must then authenticate the user's identity at a level required by the resource. For example, the portal site may issue a challenge (314), requesting a password or a response to a question to which the user had previously provided an answer. Other means of authenticating the user may be used as well, or alternatively. The portal site then determines whether the user has sufficiently responded to the authentication challenge (316). If so, then the user is permitted access to the resource (310). If the user is unable to appropriately authenticate, then access to the resource may be denied (318).

FIG. 4 is a portal GUI window 400 showing rendered navigational elements 402 which correspond to pages for accessing various resources associated with the portlets on that page, in accordance with an embodiment of the invention. The illustrated GU window may be, for example, a browser window. The GUI window is the result of rendering code received from the server site in response to a request log onto the site and access site resources. The navigational elements are rendered as graphical buttons. Each of the buttons has an associated link or hyperlink, and may further be associated with code for calling applets, scripts, and so on. When selected and clicked on, information corresponding to the link is rendered in the user interface, such as in a frame or portlet below the navigational elements.

The navigational elements shown in the present example show a full set of navigational elements available for the exemplary site. The authentication level of each rendered navigational element is shown in parenthesis, and has a value of from ito 5, with 5 being the highest level. The numbers in parenthesis would not be shown in an actual navigational element, and are shown here oniy for purposes of explanation. If the user's authentication level were only level i, then the navigational elements for "AddPortlet," "Level 3 Data," "Root Data Control," Site Management," and "Add Data" would not be visible.

Alternatively, if the site allowed a visibility depth parameter and the user had a visibility depth of at least + 1, then additional navigational elements would be rendered since the serving site would have generated code for rendering them in response to the request.

Alternatively, it is contemplated that the visibility depth parameter may be dictated by the resource. For example, a particular resource may require a level 5 authentication to access the resource, but will allow all users who authenticate to at least level 3 to render the navigational element for the resource. Additionally, the portal site may provide a global visibility depth parameter which applies to all users or resources, or both.

Although shown here as graphical buftons on a menu, those skilled in the art will appreciate that navigational elements can be configured in a variety of shapes and in various locations in a user interface. For example, a conventional portal view provides columns of portlet windows, such as portlets 404-409. Within any of the portlets there may be a navigational element 410 for manipulating the view or information shown in the portlet. The rendering of these navigational elements may be accomplished in the same manner as described with regard to FIGs. 1-3.

FIG. 5 shows a system diagram of a portal server or portal view generation system 500 and signal flow in a portal site for generating navigational elements, in accordance with an embodiment of the invention. The portal site is an exemplary serving site for purposes of illustrating the invention. A portal site allows a user to view and access various portal resources via portlets in the user interface. Control and navigation of the portlets is performed using navigational elements which include links and calls to portal sites and applications running on portal sites. The process starts when a portal user 502 transmits a request 520 to a portal site 504. The request indicates a desire of the user to access resources under control of the portal site, and may include an identification of the user making the request. Furthermore, the request may be made by using one of several modes of authentication available, or authentication may have been performed previously, for example, upon logging into the portal site or network supporting the portal site. The portal site 504 includes code elements and graphical elements for generating portal themes and portlet navigational elements. For example, the portal site may store Java server page (JSP) tags and Java API calls to be used in association with graphical elements in generating navigational elements. The portal site, in response to the request 520, may pass 522 the navigational components, including JSP tags and APIs, to a portal engine 506. The portal engine then passes 524 the identifiers of portal resources which should be linked to a portal model 510. The portal model represents the portal's content structure, such as the hierarchical structure of portal pages, which may contain nested pages and portlets arranged in pages. The portal model in turn requests 526 the requesting user's permissions for the portal resources from the portal access control 514 to determine which resources are available to the requesting user. The portal access control 514 has access to a permissions data 518, and queries 528 the data for the appropriate permissions, which are returned 530 to the portal access control. The portal access control then returns 532 the user's permissions to the portal model 510 for the requested resources. The portal model filters 534 the set of available portal resources to produce a set of resources the user has permission to access. Any resource which the user doesn't have at least "view" permission for is typically filtered out of the full set of portal resources. Once the set of resources which the requesting user has permission to access is obtained, the portal model passes 536 authentication information to an authentication engine 512. The authentication engine determines the level of authentication associated with the user. Various modes of authentication may be used, including those which the user does not directly control, such as by determining the media access control (MAC) identifier of the network adapter of the equipment used by the user, or whether the IP address and port indicate the request is being originated at a controlled-access network location. Other conventional authentication mechanisms may be used as well, such as, for example, using a digital certificate. The various means of authenticating the user's identity may be categorized into a plurality of categories to indicate a level of trust in each of the various authentication methods. The invention determines portal navigation elements based on the level of authentication of the user's identity, not based on the permissions the user has for the various portal resources.

Accordingly, the authentication engine accesses 538 an authentication data store 516 to determine the authentication level required for each resource in the set of resources for which the user can view with a navigational element. In one embodiment the viewable resources are the same as the resources which the user may access, but if the visibility depth parameter embodiment is user, the user may view resources via a corresponding navigational element, but does not necessarily have access to the resource, at least not without satisfying a further authentication process.. The authentication levels needed for the portal resources are then returned 540 to the authentication engine. The authentication engine may then filter 542 the set of resources which the user has permission to access based on authentication level. For example, if the user authenticates at a level of 3, where the maximum level is 5, then any resources requiring an authentication level of 4 or 5 will be filtered out, regardless of whether the user has permission to access the resources. The result is a set of viewable resources which the requesting user has both permission to access, and the user has sufficiently authenticated to allow the requesting user access to the resources, although a further authentication process may be necessary before granting actual access to the resource. The identifiers of accessible resources are then passed 544 back to the portal model 510.

Alternatively, the authentication engine may determine a visibility depth parameter for the requesting user, which allows the user to render navigational elements for resources categorized at a higher authentication level than that which the requesting user has presently authenticated, and upon attempting to access such resources, the user may be re-challenged for authentication purposes before access is granted. Thus, the visibility depth parameter allows users to see additional navigational elements which correspond to resources which would not otherwise be provided. For example, a given user or resource may have a visibility depth of + 1, which would then allow the user to render navigational resources for resources requiring authentication one level higher than the user's level of authentication. Furthermore, it is contemplated that the value of the visibility depth may be variable, depending on one or more factors or a context associated with the requesting user. For example, if the user is accessing the portal from a protected network, as indicated by the user's MAC address, for example, the visibility depth may be increased. Alternatively, in another example, the visibility depth may be increased during certain times of day. These same conditions may be used to determine whether or not to use the visibility depth parameter at all.

Once the viewable resources have been determined by permission and authentication filtering, including any applicable visibility depth parameter, the portal model 510 returns 546 the viewable resources or resource identifiers to the portal engine. The viewable resources are those resources which the user has both permission to access and has authenticated at the required level for each resource, taking into account any applicable visibility depth parameter.

The portal engine then employs the portal state API to create or generate the link to be used in the rendered navigational elements corresponding to the viewable resources for the portlets that will be made viewable to the user. The portal engine returns 552 the links to the portal site 504 so that they may be rendered in the portal theme. The portal site then generates code to render the portal view, including the navigational elements which are viewable to the requesting user. The code then transmitted 454 to the user's equipment or client 502 for rendering.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

Furthermore, while the invention has been discussed in the context of a visual system, it is intended that the inventive concepts disclosed and claimed herein apply to other means of perception other than visual perception, allowing the invention to be adapted for use by people who may be visually impaired.

The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.

Claims

CLAIMS1. A method of controlling rendering of navigational elements, comprising: receiving a request for a portal view from a client; determining a set of resources available to the client based on a permissions level of the client; determining an authentication level of a user of the client; determining viewable resources from the set of resources based on the authentication level, wherein the viewable resources are portal level resources; generating portal view code including code for displayable navigational elements corresponding to the determined viewable resources; and transmitting the portal view code to the client for rendering, wherein when the portal view code is rendered by the client, no interface elements exist for viewable resources from the set for which the authorization level was insufficient.
2. A method as defined in claim 1, wherein determining the set of resources comprises filtering out resources that do not correspond to the permission level from a portal resource set.
3. A method as defined in claim 1, wherein determining viewable resources comprises determining a visibility depth parameter, and wherein the accessible resources are determined based on the authentication level and the visibility depth parameter.
4. A computer program product stored in a machine readable storage medium having machine readable code for operating a portal which, when executed by the portal configures the portal to: receive a request for a portal view from a client; determine a set of resources available to the client based on a permissions level of the client; determine an authentication level of a user of the client; determine viewable resources from the set of resources based on the authentication level, wherein the viewable resources are portal level resources; generate portal view code including displayable navigational elements corresponding to the determined viewable resources and; transmit the portal view code to the client for rendering, wherein when the portal view code is rendered by the client, no interface elements exist for viewable resources from the set for which the authorization level was insufficient.
5. A computer program product as defined in claim 4, wherein the code further configures the portal to filter out resources that do not correspond to the permission level from a portal resource set in order to determine the set of resources.
6. A computer program product as defined in claim 4, wherein the code further configures the portal to determine a visibility depth parameter, and wherein the portal determine viewable resources based on the authentication level and the visibility depth parameter.
7. A portal view generation system, comprising a portal site configured to: receive a request for a portal view from a client; determine a set of resources available to the client based on a permissions level of the client; determine an authentication level of a user of the client; determine viewable resources from the set of resources based on the authentication level, wherein the viewable resources are portal level resources; generate portal view code including code for displayable navigational elements corresponding to the determined viewable resources; and transmit the portal view code to the client for rendering, wherein when the portal view code is rendered by the client, no interface elements exist for viewable resources from the set for which the authorization level was insufficient.
8. A portal view generation system as defined in claim 7, wherein the portal site is further configured to determine viewable resources in view of the user's authentication level and a visibility depth parameter associated with the user.
9. A portal view generation system as defined in claim 8, wherein a value of the visibility depth parameter is based on a context of the client.