This application claims priority to U.S. Provisional Application No. 60/826,633 entitled “Runner Security” by Pandrangi et al., filed Sep. 22, 2006 which is hereby incorporated by reference [Atty. Docket No. BEAS-02041US0] and to U.S. Provisional Application No. 60/883,398 entitle “Runner” by Hayler et al., filed Jan. 4, 2007 which is incorporated by reference [Atty. Docket No. BEAS-02042US0].
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
Web applications have become increasingly popular within the enterprise as a result of their flexibility of deployment and their relatively intuitive interfaces, but web applications present potential problems in the enterprise environment due to security and governance issues.
FIG. 1 illustrates a reverse proxy system of one embodiment.
FIGS. 2A-2B illustrates a method of encrypting a credential vault.
FIGS. 3A-3B illustrates a role abstraction system.
FIG. 4A illustrates the use of pagelet tags.
FIG. 4B illustrates a non-invasive way to insert a pagelet that does not use pagelet tags.
FIG. 5 illustrates the use of interstitial pages.
FIG. 6 illustrates request/response management.
FIG. 7 shows an exemplary module system.
FIG. 8A shows an exemplary single-sign-on and authorization system.
FIG. 8B shows an exemplary interactive system with interstitial pages.
FIG. 9 illustrates an exemplary request flow system.
FIG. 10 shows an exemplary deployment of Spnego.
FIGS. 11A-11B shows an exemplary SSO.
FIG. 12 illustrates an exemplary auditing API.
FIGS. 13A and 13B show current and new architectures of one embodiment.
FIG. 14 shows an exemplary product UI catalog.
Some embodiments of the present invention may be useful in reverse proxy and Single Sign On (SSO) environments.
FIG. 1 shows an exemplary reverse proxy, single-sign-on environment. A user browser 102 can access functionality through the reverse proxy 104 . In the example of FIG. 1, a request for “http://reverseproxy.companyname.com/mail” is sent to the reverse proxy 104 and mapped to a resource 106 at “http://mail.companyname.com”. In one embodiment, the reverse proxy 104 can be set up to access the web application instances 106 and 108 .
For purposes of this application a reverse proxy can be any system that can do such a reverse mapping. In one embodiment, a reverse proxy is a server that proxies content from a remote web application to an end-user and may or may not modify that content.
No additional or supplemental functionality, such as SSO, should be imputed to the meaning of the term “Reverse Proxy” or “Proxy”.
Supplemental functionalities can include authentication to determine who the user is; authorization to determine if the user has access to the requested resources; transformation functionality to use tags to combine data from different applications, such as web applications and/or rewrite URLs within a response to point to the reverse proxy 104 . The functionality can also include gathering analytics and auditing data.
Authentications and authorizations can be part of a SSO system such that all requests through the reverse proxy 104 only require a single sign on.
Authorization can be done by having the reverse proxy 104 handle the mapping of users for a web application to roles. In one embodiment, the web applications can use different roles while the mapping of users to user can be controlled by the reverse proxy 104 .
In one embodiment, different types of authentication can be ranked in order of security. The authentication can be used to access the application if the SSO authentication has a security authorization at or above that required by the application.
The use of a reverse proxy can also allow for centralized governance. The reverse proxy can keep a central record of web application usage statistics.
Single sign on can be enabled by having the reverse proxy 104 send credentials (such as user names and passwords) from a credential vault 110 to the application.
In an exemplary case, the rewriting of URLs can be done by checking the URL for a prefix mapped by the reverse proxy and then converting the prefix to point to the reverse proxy. For example, “http://mail.companyname.com/billing” can be converted to “http://reverseproxy.companyname.com/mail/billing”. Adaptive and pagelet tags are discussed below in more detail and are a way to combine functionality from applications.
One embodiment of the present invention concerns the control of passwords in a credential vault. For the purpose of this application a credential vault is any storage location for credentials (such as passwords).
It is desirable that any passwords in the credential vault remain secure. For this reason, these passwords can be encrypted.
One embodiment of the present invention comprises encrypting a number of secondary passwords with a primary password. The secondary passwords can be passwords to applications accessed through a reverse proxy. The primary password can be for a single sign on system such as a reverse proxy. The secondary passwords can be stored in a credential vault 202 . An encrypted secondary password can be decrypted from the credential vault using the primary password and provided to an application.
The primary password can be a password to a reverse proxy system or SSO system. The secondary passwords can be passwords to remote web applications. The secondary passwords can be encrypted with a function, such as a hash, of the primary password. A fixed string can be encrypted and stored in the credential vault in the same manner. This encrypted fixed string can be used to test to see if the primary password has changed since the secondary passwords and fixed string have been encrypted. The user can be prompted to input the new and old primary passwords, if the primary password has been changed. The secondary password can be decrypted using the old primary password and re-encrypted using the new primary password.
FIG. 2A shows an example wherein a primary password 201 is used by a main authentication component 204 to authorize a user. The primary password 201 can be used to encrypt the secondary passwords stored in the credential vault. For example, an encrypted password can be given by:
and the secondary password can be reconstructed using:
Where E x (y) is the encryption of y using key x, and D x (y) is the decryption of y using key x. The key can be a hash, or any other function, of the primary password. Any type of encryption can be used.
FIG. 2B shows the example when the primary password has changed. In that case:
To avoid sending the wrong secondary password to an application a known string can be encrypted and a test can be done, If:
Then the user can be prompted to input the old and new password with a page 220 . The encrypted secondary passwords can then be decrypted with the old primary password then re-encrypted with the new password.
This system avoids the problems of an admin user easily decrypting the credentials of a user. Anything that the system knows, the admin user will generally be able to know as well. For example, if the security system is configured to mutate all stored passwords with the same key, an admin user, who has access to the box running the security system, can decompile the program and figure out the encryption method. The admin user can then apply that decryption method to every password in the credential vault.
Since the credential vault password is encrypted with a user's password or a hash of the password, an admin won't have access to a way to decrypt the secondary password. If a user's primary password changes, all credential vault passwords are no longer retrievable.
In one embodiment, whenever a user enters a password into an Authenticator, the Authenticator can pass the password to Security Service for validation. The Security Service can use this password (or a one way hash of this password) to encrypt any passwords that get stored in the credential vault. The user's password can be a symmetric key which need not be persisted anywhere.
The user's password can also be used to encrypt a static string, such as “BOJAMBLES”, which is known to Security Service. This encrypted String can be persisted to the database.
Id encrypted(“BOJAMBLES)”
User 1 asdkfjlasdkfjalsdkjfklasdjflksdjf
User 2 sdfsjkl23jkl23jkl
The next time the user logs in to the reverse proxy server, this password can again be sent to Security Service. If Security Service can log in to the back-end repository with this password, it can do another check. Security Service can use the latest sent password to decrypt the BOJAMBLES string. If the decrypted value is indeed BOJAMBLES, Security Service knows that the user's password has not changed. The security service can now use this password to decrypt every password in User 1 's credential vault using the last sent password. User 1 now has access to all his credential vault passwords for auto-login with backend apps.
Assume User 1 now changes his password to POKEMONRULEZ.
User 1 now tries to access a resource and the reverse proxy server can ask for a login (assuming session expired after password change). User 1 now logs on with the new password. This password gets sent to Security Service. It can validate the password with a back-end repository, and then it can attempt to decrypt BOJAMBLES with POKEMONRULEZ. The security service can then realize that the user's password has changed. The security service can then let the reverse proxy system know that the user's password has changed.
The reverse proxy system can then display a page to the user. This page can say something like: “the security service has detected that your password has changed recently. In order to re-encrypt your credentials, please enter both your new and old password. Otherwise, the security service can not be able to re-encrypt your credentials and you can be forced to re-login to all your applications”.
If User 1 is able to recall his previous password and enters it in to the form, the reverse proxy system can send the two passwords back to the security service. The security service can now be able to decrypt BOJAMBLES with the old password. Once that is validated, the security service can decrypt all of the user's credentials in the vault. The security service can then re-encrypt those passwords with the new password, and also re-encrypt BOJAMBLES with the new password.
Credential acquisition can also be an important part of the credential vault. If a user logs in to the remote web application, we can acquire their password and store it in the credential vault.
Roles and policies can allow the display and access to data in a flexible manner. Users can be mapped to roles and policies to indicate whether users (as a result of one of these roles) have access to a display or other application resource. A description of one system using roles and policies is given in the U. S. Pat. No. 6,158,010 “System and Method for Maintaining Security in a Distributed Computer Environment” which is incorporated hereby reference.
Requiring each web application to implement roles and policies can complicate the development of these web applications. One embodiment of the present invention is a way for web applications to use roles without doing the mapping of users to those roles.
As shown in FIG. 3A, a reverse proxy 302 can maintain role mappings and policies for a web application in a central store 304 . The web applications 306 and 308 can be written such that certain roles are defined for the web application.
One embodiment of the present invention is a method comprising maintaining a central store 304 of application role mappings at a reverse proxy server 302 ; receiving a request for a web application at the reverse proxy server (such as from browser 310 ); determining the proper user role for the web application at the reverse proxy server 302 ; and sending the proper user role as part of a HTTP header 312 to the web application 308 .
The web application 308 can use the user role without doing an independent mapping of the user to a role. The reverse proxy server can interrogate the web application to determine the set of roles used by the web application. The reverse proxy server can implement policies to determine a user's access to the web application. As described in more detail below, code for the web application can include a tag to cause the reverse proxy system to insert a second web application into the displayed page. This second web application can use independent user roles. The reverse proxy server 302 can look up roles for multiple web applications that are combined into a single presentation to the user.
Administrators can specify which roles the web application support in the administration UI.
FIG. 3B shows an example where a user “FrankF” can access a web application 325 only within a specified time period as a result of a mapped role and policy for application 320 . The role mapping and policies for “FrankF” can be different for web application 322 than for web application 320 and this can be managed at the reverse proxy server 302 .
In one case, the web application 320 can include a pagelet tag (described below) that cause the proxy server 324 to insert a display from web application 322 into the display for web application 320 .
In one embodiment if a user, such as “FrankF”, is unable to access the web application 322 independent of web application 320 , the pagelet will not be displayed to the user.
Pagelets can be comparable to portlets in that they both contain user interfaces (UIs) that can be displayed in more than one consuming application. But, in one embodiment, there are significant differences.
Portlets can only be displayed in one type of consuming application—a portal. In fact, most portlets are written using proprietary code which requires that they be consumed in a particular vendor's portal. Pagelets, on the other hand, are a much more general technology. Any application when viewed using the runner reverse-proxy can consume any pagelet.
Portlets often require that the consuming application be written in the same language or on the same platform as the portlet. Pagelets can be invoked using XML, a language and platform independent standard, so pagelets and their consumers can be written in different languages and on different platforms.
Portlets, because of their link to portals, assume a specific environment for resolving security and role questions. Pagelets can generalize the functionality, so that security and roles can be customized for any environment.
Portlets, again due to their link to portals, assume a specific UI paradigm (e.g. view modes). Pagelets require no such constraints. Any standard web technology (i.e. any technology supported by web browsers) can be used to generate any type of UI and that UI will be rendered in the consuming application.
FIG. 4A shows an exemplary system using pagelet tags. The browser 402 provides a request to the reverse proxy system 404 in step A. The reverse proxy system 404 can check for authorization based on Roles and Policies as discussed below. Assuming these are good, the request can be rerouted to a web application 406 in step B. The first web application 406 can respond with code 408 that includes a pagelet tag 410 in step C. The reverse proxy system 404 can determine the pagelet web application 414 based on the pagelet tag 410 . Assuming that the authorization from the user is good, the pagelet code can be requested in step D and the pagelet code can be returned in step E. The pagelet can be added into a first web application page as a combined presentation and provided to the browser in step F. URLs in the combined presentation can be modified to point to the reverse proxy system.
The user roles can be sent to the web applications in an HTTP header so that the web application need not do an independent mapping of the user to a role. The tags can include a namespace and ID.
One embodiment of the present invention comprises determining a pagelet web application from a tag in a first web application and inserting the pagelet web application into the display of a page of the first web application.
A reverse proxy server adapted to receive user request for web application can obtain web application code for the first web application and interpret a tag in the first web application to indicate a pagelet web application. Pagelet web application code, from the pagelet web application and web application code, from the first web application, can be merged and a combined presentation can be provided.
One embodiment of the present invention is a non-invasive way to insert pagelets into a web page. In some cases, it is desired to not modify the source code of a web page using pagelet tags. For example, the web application may be obtained from a third party or it would be otherwise undesirable or difficult to modify the web application code. In this embodiment, a proxy, such as a reverse proxy, can search for an identifier, such as a name or a code pattern, in the web page and then use this identifier to determine whether to insert the pagelet.
FIG. 4B shows one example of a non-invasive pagelet insertion method. In this example, proxy 420 keeps a table 422 , or other data structure, that indicates what web page(s) a pagelet is to be inserted into. The table 422 can include an indication of the page that the pagelet is to be inserted into and an indication of the pagelet to be inserted.
In the example of FIG. 4B, the table 422 indicates page “A.JSP” and pagelet “B”. When page “A.JSP” 424 is obtained by the proxy 420 from source 421 to send to a browser 426 , pagelet “B” 428 can be inserted into the displayed page 430 .
The table 422 can also include a location indicator that can indicate to proxy 420 where in the web page to insert the pagelet.
The indication of page and location can be by pattern matching. For example, a search string can be indicated and each page with the string can have the pagelet inserted. In one embodiment, the web page indication can use Boolean operators such as “AND” and “OR”.
Optionally, the table 422 can indicate wrapper code for the pagelet. In the example of FIG. 4B, the wrapper code indicates that the pagelet is to be inserted into a table on the web page. The use of wrapper code can help the pagelet be used in different display contexts.
The table 422 can also optionally include attributes that are to be obtained from the page and provided to the pagelet. In the example of FIG. 4B, the attribute is a title that is obtained from the web page and provided to the pagelet for display. This example shows extraction info and attribute name. The string indicated by the extraction info on the web page is given the value indicated by the attribute and then given to the pagelet. More than one attribute/extraction pair can be used to provide attributes to a single pagelet.
Looking at FIG. 4B, in one embodiment, in step A, a request is received at proxy 420 for the first web application. The proxy 420 gets the web application code from the first web application 421 in steps B and C. The proxy 420 can then use the data 422 to determine whether a pagelet is to be inserted.
In the example of FIG. 4B, web page code 424 is a page that a pagelet is to be inserted into. In steps D and C, the pagelet is obtained from pagelet web application 430 . In step E, the pagelet 428 (pagelet B) is inserted into page 430 (Page A) to produce a combined application that is sent to the browser 426 .
One embodiment of the present invention comprises determing a pagelet web application by recognizing a particular page in a first web application to indicate a pagelet web application and inserting the pagelet web application into a pre-configured section of a page of the first web application. The first web application page and the location to insert the pagelet web application can be determined either programmatically or by specifying a specific page or location directly. This embodiment allows a pagelet web application code to be inserted into a first web application, where the first web application code has not been modified prior to the first web application being proxied.
FIG. 5 shows an example of an interstitial page system. In this example, a request from browser 502 is received by reverse proxy 504 in step A. The reverse proxy server checks to see if the requested URL is associated with an interstitial page. If so, in step B, the interstitial page 506 is provided to the browser without needing to access web applications 508 and 510 .
A reverse proxy server can produce interstitial pages to the user. The interstitial pages need not be generated with the web application code.
The reverse proxy can block access to the web application until the specified interstitial pages have been processed.
In one embodiment, the interstitial page HTML can comes from a separate web application. This allows you to write one web application that can provide interstitial pages to many web applications. Alternately, there can be different interstitial pages for different web applications.
In addition, while interstitial pages usually come before you can access the web application, they can come at different points in the login cycle. Interstitial pages can be provided before logging in, and after logging in, in any combination.
Different interstitial pages can be used for different resources, users, or other conditions.
In one embodiment, at least one interstitial page is used to receive a user password as a warning page and/or a license agreement page. The interstitial page can include user info. In one embodiment, the user need not be signed in to receive the interstitial pages.
An exemplary embodiment of a system using methods of the present invention is described below. The following exemplary embodiment is not meant to be limiting as to terms, definitions and the like. For example, language in this section is not intended to limit or define the claim terms but only to describe how the components work in the particular exemplary embodiment. This section merely describes one exemplary way to implement the present invention. Other architectures implementing the methods and systems of the present invention can be done.
In one embodiment, Pagelets can be composed of two basic parts: a front-end pagelet tag and a Pagelet Engine. The pagelet tag can be used to insert a pagelet into HTML. The pagelet tag can then replaced by a reverse proxy server with the content of the pagelet. The Pagelet Engine can be a massively parallel pagelet processing engine that is used to retrieve multiple pagelets from back end resources simultaneously.
Pagelet configuration information can be persisted in an IPersistentPagelet interface.
The Pagelet Tag can be a simple tag that can allow one to specify the pagelet ID and include data to be passed to the pagelet. In one embodiment, there can be two kinds of data passed to the pagelet. The first is tag attributes, and the second is an XML payload. Standard xhtml tag attributes in the pagelet tag (i.e. not pt: attributes) can be passed to the pagelet directly. The XML payload can allow the HTML author of the consuming page to include more complicated data to be passed to the pagelet.
An exemplary pagelet tag can look like this:
| < pt:ensemble.inject pt:name=”al-collab:discussion”discussionid=”21”> |
| <discussion> |
| <expandedmessages> |
| <messageid>27<messageid> |
| <messageid>36<messageid> |
| <messageid>144<messageid> |
| </expandedmessages> |
| <currentmessage> |
| <messageid>27</messageid> |
| </currentmessageid> |
| </discussion> |
| </pt:ensemble.inject |
Pagelets can be identified by a unique combination of namespace and pagelet name. These values can be constant when pagelets are migrated or moved to different servers. Pagelet names can be unique within a namespace. Namespaces are also known as Pagelet Libraries. Namespaces and pagelets can be concatenated together separated by a colon to provide a unique reference to a pagelet (i.e. financeapp:myvacationhours).
The namespace can be any text string, such as “financeapp” or “Urn://www.mycomp.com/apps/finance”. The namespace can be a part of the pagelet. Namespaces need not be required to be between parent resources as customers may have several near-identical resources that differ only in security that each contains different, but related pagelets from the same back-end resource or multiple back-end resources. This can require a check for pagelet uniqueness within a namespace whenever new pagelets are created or pagelet namespaces are edited.
A Pagelet Engine can allow the pagelet system to retrieve multiple pagelets simultaneously. In order to retrieve content, a client component can create a Request Chain composed of individual Requests. Each request can contain all of the information necessary to retrieve a single pagelet. This information can include the ID of the pagelet, the back-end resource URL, the pagelet attributes, and the XML payload.
The Request Chain can then send off multiple HTTP requests to retrieve the data, and the data can be available to the client component after all requests have returned or timed out. The data can then be transformed and converted into a Markup Array.
The Pagelet Request Flow can involve two passes through the HTML data. The first pass can collect the pagelet data and initiate content retrieval, while the second pass can convert the standard Adaptive Tags and replace the pagelet tags with the pagelet data.
In one embodiment, pagelet tags work in place. The pagelet tags can be placed in a DHTML area so they can be refreshed individually. In one embodiment, an HTML page with placeholder data for slow pagelets can be returned. The Request Chain can be stored on the session and have it continue to retrieve the slow data in the background. Then, the end users' browser can initiate an AJAX request to the reverse proxy server for the additional pagelet content, which could then be filled in dynamically. This can mitigate the problem of slow pagelets.
The Reverse Proxy System can manage Primary and Resource Authentication, as well as Primary Authorization. The Reverse Proxy System can determine if this user is logged in to the reverse proxy system using the correct authentication method to see this pagelet, whether this user has permission to use this pagelet, and perform Auto-login to remote pagelet servers.
A login sequence for primary pagelet Authentication/Authorization can look something like this:
An auto-login sequence for pagelet remote servers can look something like this:
An auto-login sequence for pagelet remote servers that requires the user to fill out a login form can look something like this:
Remote pagelet data can be checked for login requests by all Auto-login components (i.e. Form, Basic Auth, etc . . . ).
In one embodiment, there are two main requirements for Pagelet JavaScript and Style Sheets. The first requirement is that there be a way to put JavaScript and Style Sheets into the Head element of the HTML page. The second requirement is that duplicate .js and .css files only are included once per HTML page.
Pagelet developers can mark their JavaScript & style sheet links to be included in the head using a special JavaScript tag (i.e. <pt:common.includeinhead>). Pagelet consumers can then need to include a special Include JavaScript Here tag (i.e. <pt:common.headincludes>) in the Head element of their HTML page. Pagelet JavaScript from the include-in-head tags can then be included in the output of the Head Includes tag. The Includes tag can also filter out duplicate .js and .css files.
The head includes tag can be optional. If the tag is not present, then JavaScript and cascading style sheets can be added at the end of the head tag in the main page. If the main page does not have a head tag, a head tag can be added at the beginning of the page. This can require the Transformer to identify the head element when parsing the page. The headincludes tag can be used when control over the insertion of the pagelet JavaScript and Security Service within the head element is required. There need be no way to specify the order of includes from various pagelets.
The includeinhead tag can work within a pagelet to add Style Sheets and JavaScript to the main page, but it can also be used directly in a main page. In one embodiment, since the includeinhead tag filters Style Sheets & JavaScript file includes to remove duplicates, a main page developer could include their Style Sheets & JavaScript includes in the includeinhead tag, which would ensure that there are no duplicate files included from the pagelet and main page.
In one embodiment, during In-place Refresh, JavaScript and Style Sheets cannot be inserted into the head element, as it has already been displayed. Therefore, the includeinhead tag does not function in in-place refresh pagelets. In order to facilitate building simple in-place refresh pagelets, the includeinhead tag can be ignored during in-place refresh of a pagelet. This means that a pagelet author can use the includeinhead tag to insert JavaScript libraries into the main page the first time the pagelet is displayed on a page, but that the JavaScript libraries can not be re-included during in-place refresh of the pagelet.
In transparent proxy mode, the transformURL function is only be used on pagelet content; general resource content doesn't need it. In non-transparent proxy mode, transformURL function is needed for all Javascript URLs.
If a page requires transformURL function, then the reverse proxy server code can automatically insert to include the transformation Javascript library, as well as an initialization Javascript statement similar to the PTPortlet constructor in portal.
In-place-refresh libraries: by default, pagelet content need not be set to in-place-refresh; by using an inplacerefresh tag, pagelet developers can turn on in-place refresh (IPR). With IPR turned on, all URLs within pagelet content are prefixed with JavaScript which does in-place refresh.
If IPR is not turned on, they can manually insert the inplacerefresh tag around a URL to transform that URL into in-place-refresh link. (This tag can be applied to URLs in resource content as well).
If a resource content page uses in-place refresh (through tags), or has a pagelet inside it which uses in-place refresh, the reverse proxy server can automatically insert the Javascript includes for in-place refresh on the page. Alternatively, the developer can add an inplacerefreshjslibrary tag on a resource or pagelet to make the reverse proxy server insert the in-place refresh libraries. Then the developer can be able to use the .refresh calls that Scripting Framework libraries provide.
In-place refresh Javascript libraries can also contain Javascript Session Prefs functions in them. So if a resource uses session prefs, it can include the inplacerefreshjslibrary tag to tell the reverse proxy server to include in-place refresh Javascript libraries.
Below is a list of exemplary public Javascript functions that Scripting Framework can support for developers:
public static function getPageletByName (namespace, id)
public static function getPortletByUniqueID(id)
public static function getSessionPref(name)
public static function getSessionPrefs(names)
public static function setSessionPref(name,value)
public static function setSessionPrefs(hash)
public function clearEvent(eventName,eventNamespace)
public function deleteSessionPref(name)
public function deleteSessionPrefs(array)
public function formGetRefresh(form)
public function formPostRefresh(form)
public function formRefresh(form)
public function getRefreshInterval( )
public function getRefreshURL( )
public function raiseEvent(eventName,eventArgs,eventNamespace)
public function refresh(url)
public function refreshOnEvent(eventName,eventNamespace)
registerForEvent(eventName,eventCallback,eventNamespace)
public function setInnerHTML(html)
public function setRefreshInterval(refreshInterval,startNewRefreshTimer)
public function setRefreshURL(url)
private function PTPagelet(namespace, uniqueid, containerID, refreshURL, refreshInterval)
The Javascript library which does only transformation can have the following functions:
private function transformURL(url)
private function PTPagelet(pageletid, containerID, remoteRequestURL, remoteBaseURL, resourcePrefixURL, resourceGatewayPrefixURL)
Pagelet discovery can include retrieving a list of available pagelets and the following data about each pagelet:
Pagelet name, description, and HTML sample code
Pagelet parameters (name, description, type, and mandatory)
Pagelet payload XML Schema URL
pagelet meta-data (name value pairs)
Pagelet consumer developers can go to an HTML page to find pagelet information. Pagelet developers/administrators can have the option of removing pagelets from this list. In one embodiment, since consuming resource security checks cannot be handled automatically, the list of allowable consumer resources should be included on the page.
In order to simplify the reverse proxy server, this UI need not be hosted as part of the reverse proxy server, but should rather be combined with the login server. This can be available through a known URL, which can then be exposed through the reverse proxy server if desired. The reverse proxy server should come with a pre-configured resource that point to this known URL, although by default no one should be able to access the resource.
Accessing the Pagelet Catalog UI need not require the reverse proxy server admin user login, although it can be secured via basic auth with a static user name. This security should be easy to disable. The pre-existing resource can be setup to auto-login using the static user name.
This UI can be a simple set of jsp or jsf pages that access the reverse proxy server database and display the pagelet information. Ideally, this UI can also be available to be copied and hosted on a developer website or other location. However, since the pages can be dynamic, that can require the pages to be crawled or manually saved from a browser. The index links can also need to be rewritten to point to static pages.
The UI can include both dynamic pagelets, and the tag libraries included with the reverse proxy server.
In one embodiment, since performance is not crucial on the admin server, the pages need not be cached and can access the database for every page view.
Pagelets can be discoverable programmatically. This can allow an application (such as Holland) to discover which pagelets are available to the current user. Since pagelet security is enforced programmatically, pagelet developers/administrators need not be able to remove their pagelet from this list (via the Publish checkbox). Since the Pagelet Discovery Client can always be running inside the context of a the reverse proxy server resource, the results can only contain pagelets that can be consumed by the current resource.
A simple Java only API in the client can be provided that can allow an application to query for the available pagelets for the current user in the current request. The API can do automatic filtering of the results based on user access and consuming resource restrictions. The API can also allow filtering of the pagelet results based on other criteria, such as last modified. The queries can return either basic information about the pagelet, such as it's name and description, or full information for the pagelets.
The queries can be processed by a simple the reverse proxy server based web service on the Admin UI box. The web service can require a valid the reverse proxy server security token from the client. The web service can query for the pagelets available to the consuming resource, and then evaluate the Security Service security policies for the pagelet parent resources to see which ones are visible to the user in the current request.
In order to provide the correct security filtering, the current request information (i.e. user, IP, time, etc . . . ) can be passed by the client to the web service. The EDK on the remote resource should already have all of the request headers and information necessary.
The pagelet information can be published to a secured registry for programmatic discovery and IDE integration.
Pagelet Discovery Web Service APIs can be exposed as a client-side API similar to the Embedded Development Kit (EDK). The client can be Java only and a Java Archive (JAR) can be provided as one of the reverse proxy server build artifacts.
The underlying transport can be done by turning the PageletManager query class into a web service using RAT. The web service can return all query information in a single response, rather than sending individual requests for pieces of data. This means that a pagelet query could theoretically be quite expensive. The best practice for querying can be to query for pagelet info for large numbers of pagelets, and then query for the entire pagelet information for an individual pagelet, or a small number of pagelets.
| public class PageletManager { | |
| public IPageletInfoQueryResult QueryPageletInfo(PageletFilter _filter, | |
| RunnerSecurityContext); | |
| public IPageletQueryResult QueryPagelets(PageletFilter _filter, | |
| RunnerSecurityContext); | |
| } | |
| public class RunnerSecurityContext { | |
| public RunnerSecurityContext(String _IPAddress, int _CurrentResourceID, String | |
| _RequestURL, OKHTTPHeaders _headers, RunnerSecurityToken, _token); | |
| } | |
| public class PageletFilter { | |
| public void addSearchProperty(PageletSearchProperty _property, String _value); | |
| public void addSearchProperty(PageletSearchProperty _property, String[ ] _values); | |
| public void setResultsRange (int _firstItem, int _lastItem); | |
| } | |
| public enum PageletSearchProperty { | |
| name, namespace, ID; | |
| } | |
| Public interface IPageletQueryResult { | |
| public int GetTotalResults( ); | |
| } | |
| public interface IPageletQueryResult extends IPageletQueryResult { | |
| public List<IPagelet> GetPageletResults( ); | |
| } | |
| public interface IPageletInfoQueryResult extends IPageletQueryResult { | |
| public List<IPageletInfo> GetPageletInfoResults( ); | |
| } | |
| public interface IPageletInfo { | |
| public int GetID( ); | |
| public String GetName( ); | |
| public String GetDescription( ); | |
| public String GetNamespace( ); | |
| } | |
| public interface IPagelet extends IPageletInfo { | |
| public string GetCodeSample( ); | |
| public string GetPayloadSchemaURL( ); | |
| public int GetParentResourceID( ); | |
| public Boolean GetIsAllowAllConsumers( ); | |
| public int[ ] GetConsumerResources( ); | |
| public List<IPageletParameter> GetParameters( ); | |
| public Map<String, String> GetMetadata( ); | |
| } | |
| public interface IPageletParameter { | |
| public String GetName( ); | |
| public String GetDescription( ); | |
| public String GetType( ); | |
| public Boolean GetIsMandatory( ); | |
| } | |
When inserting a pagelet tag into a resource, developers can be able to specify an XML payload within a pagelet tag. That payload can be transferred to the remote tier over HTTP, within the HTTP request for the pagelet content.
The payload can be sent in the body of a POST request—in our opinion, as discussed above, the pros overweigh the cons. Other CSP data can be sent in HTTP headers, as in previous protocols. Non-payload pagelet requests can be sent as GETs; requests with payload can be sent as POSTs.
In order to encourage best practices around pagelets, sample pagelets can demonstrate the following principles/practices:
The sample pagelet code can look something like the following, although this is not a definition of the IDK API.
| <%@ page language=“java” import=“com.plumtree.remote.pagelet.*” %> |
| <% |
| // get the pagelet idk |
| IPageletContext pageletContext = |
| PageletContextFactory.createPageletContext(request, |
| response); |
| IPageletRequest pageletRequest = pageletContext.getRequest( ); |
| String styleSheetOverride = |
| pageletRequest.getPageletAttribute(“StyleSheetOverride ”); |
| String pageletSize = |
| pageletRequest.getPageletAttribute(“RecommendedSize” ); |
| // If the pagelet consumer has specified an alternate style sheet, use that |
| if (null != styleSheetOverride) |
| { |
| %> |
| <pt:common.includeinhead> |
| <link type=“text/css” href=“<%=styleSheetOverride%>” |
| rel=“StyleSheet”/> |
| </pt:common.includeinhead> |
| <% |
| } else |
| { |
| // otherwise use the standard stylesheet |
| %> |
| <link type=“text/css” href=“/styles/mypageletstyles.css” |
| rel=“StyleSheet”/> |
| <% |
| } |
| // pagelet content |
| //get the pagelet/portlet idk |
| IPortletContext portletContext = |
| PortletContextFactory.createPortletContext(request, response); |
| IPortletRequest portletRequest = |
| portletContext.getRequest( ); |
| String settingvalue = |
| portletRequest.getSettingValue(SettingType.Portlet, “myPageletActionID); |
| //if the entry has already been set, display it here |
| if ((null != settingvalue) && (myPageletActionID == “2”)) |
| { |
| %> |
| <p class=“pagelet-notification-text”>Pagelet action successfully |
| completed.</p> |
| <% |
| } |
| %> |
| <p class=“pagelet-standard-text”>Hello world style override |
| pagelet content.</p> |
| <% |
| if ((pageletSize != null) && (pageletSize == “large”)) |
| { |
| %> |
| // Display complete data in a table |
| <% |
| } else { |
| // If the pagelet is supposed to display in small mode, just display a link to |
| the data |
| %> |
| <a class=“pagelet-linik” href=“datalink.html”>Click here to view |
| complete data.</a> |
The pagelet components list can include components that are used exclusively during pagelet processing, as well as other modules that are involved in the pagelet processing lifecycle.
The Tag Engine can process both tags and pagelets. The Tag Engine Module can use the Tag Engine shared component to process the tags, and then processes the pagelets. This module can control the overall pagelet flow, utilize other components, and delegate processing to other modules.
The same retriever can be used both for pagelets and regular resource requests. Retriever can know what type of request it is (through an argument passed to it) and may do some things differently (create multiple parallel requests for pagelets vs. only one for resources; different timeout; pass through different parameters to CSP library, etc).
The reverse proxy server can support CSP features both on resources, and on pagelets. The reverse proxy server can support a subset of the portal's CSP features.
There can be a CSP library (not a module) created which can handle adding/processing of CSP headers. This library can be called by retriever can appropriate arguments.
User Info, Roles, user id, user name, login token can be available off IProxyUserSession interface.
Session Prefs can be available from ISessionPrefs interface. IRunnerResource object can contain a list of user info prefs, session prefs, login token sending info to send to remote tier.
ImageserverURI and Comsuming Resource URI (for pagelets only) can be passed into the CSP library by the retriever. CSP libraries can have different modes: regular (resource); pagelet, and in-place-refresh. The mode can be passed in by retriever.
When pagelet data is retrieved from the remote server, it can be checked for login pages. This could happen the first time a remote server is accessed by a particular user, or if the session times out. The Auto-login Module can identify and process remote login pages for a resource, including pagelets.
The Auto-login Module can run during the onTransformContent phase and process all remote responses for login pages. Since pagelet processing essentially duplicates normal page processing many times on a single page, the Auto-login component can be broken out into separate classes so that it can be used by both the Auto-login Module and the Pagelet processor (TagEngine Module). This can include both form based login and basic auth login.
The Auto-login component can be used to check all pagelet responses for login pages. If login pages are detected, the module can be used to generate a login request for the remote resource. This can then be processed using the Retriever. The response can be checked again for login pages and used in place of the original response once the login cycle is finished.
In order to maintain performance, pagelet responses can be checked for login pages, and then all login pages can be processed in parallel. Even though this is done in parallel, the login cycle for each pagelet could comprise multiple pages, which may mean all pagelets would have to wait until the pagelet with the longest login cycle had finished. A pagelet login is expected to be infrequent so this should not affect normal pagelet usage very much.
In addition, if the credential vault is being used and login fails for a pagelet, the Auto-login Component (& Tag Engine) candisplay the login page to the user so they can login successfully. The Auto-login Component then needs to capture the login information from the user's request, store it in the credential vault, and then process the originally requested page.
The Pagelet Discovery API can be a standalone web service. It can be deployed to the same embedded Tomcat server as the Admin UI and Login Server. There can be a Java-only client similar to the EDK.
The Pagelet Catalog UI can be a simple set of JAVA Server Pages (JPS) Java Server Faces (JSF) pages that display a list of available pagelets and a detail view for pagelet information. This can be setup so it can easily be configured to be either protected by basic auth with a static username/password or unprotected.
The UI can be a combination of static HTML pages generated by our tagdocs utility, and jsp/jsf pages to view the pagelets. The static tagdocs index can be included as a jsp include into the complete index. The PageletListBean and the PageletViewBean can handle data access using RMS.
The reverse proxy server can provide both its own unique tags, as well as extensions to the common tags provided by the Portal. It can also provide the set of portal tags specified in the PRD. In order to maximize interoperability between pagelets and portlets, the portal can be upgraded to include the new common tags. The portal can also know to ignore the reverse proxy server tags, rather than treating them as an error.
Exemplary Reverse Proxy Server Tags can be Included in the Tag Library:
Auth Source Tag
| Tag | authsourcedata |
| Description | This stores a list of available auth sources for the |
| currently requested resource in memory. The data | |
| is stored as a collection, and each item in the collection | |
| is a data object containing information about the auth | |
| source (id, name, description) accessible through the | |
| data object dot notation ($curauth.name). | |
| Attributes | |
| id | The key used to store the data list in memory . . . |
| scope | Which scope (tag, request, application, etc . . . ) to use to |
| store the data list in memory. | |
| <pt:runner.authsourcedata pt:id=”authsources”/> |
| <pt:logic.collectionlength pt:data=”authsources” pt:key=”numauths”/> |
| <pt:logic.if pt:expr=”($numauths)>1”> |
| <pt:logic.if-true> |
| <!--display as HTML drop down --> |
| </pt:logic. if-true> |
| <pt:logic.if-false> |
| <!--display as hidden input --> |
| </pt:logic. if-false> |
| </pt:logic.if> |
Resource Link Tags
| Tag | resourcelink |
| Description | This stores the URL to a specific resource, if available, |
| in memory. | |
| Attributes | |
| resourceid | The resource ID. |
| id | The key used to store the data in memory. |
| scope | Which scope (tag, request, application, etc . . . ) to use to |
| store the data in memory. | |
| Tag | resourcedata |
| Description | This stores a list of resources in memory that are available |
| to the current user. The data is stored as a collection, | |
| and each item in the collection is a data object containing | |
| information about the resource (id, name, description, url) | |
| accessible through the data object dot notation | |
| ($curresource.name). | |
| Attributes | |
| id | The key used to store the data list in memory. |
| scope | Which scope (tag, request, application, etc . . . ) to use to |
| store the data list in memory. | |
These tags behave similarly to the ptdata tags in the Portal.
Pagelets
| Tag | inject |
| Description | This tag is replaced with the output of the specified pagelet. |
| Attributes | |
| namespace | The pagelet namespace. |
| id | The pagelet ID. |
| Tag | pageletaccessdenied |
| Description | This tag displays a custom “access denied” error message |
| when a user does not have proper security to see a pagelet. | |
| If this tag does not exist, a generic “access denied” | |
| message can be displayed, otherwise the | |
| contents of this tag can be shown. | |
| Attributes | |
The pagelet tag is simply the way to add a pagelet to an HTML page.
| <pt:ensemble.inject pt:name=”al-collab:discussion” pt:id=”discussion” |
| discussionid=”21”> |
| <discussion> |
| <expandedmessages> |
| <messageid>27<messageid> |
| <messageid>36<messageid> |
| <messageid>144<messageid> |
| </expandedmessages> |
| <currentmessage> |
| <messageid>27</messageid> |
| </currentmessageid> |
| </discussion> |
| </pt:ensemble inject> |
| <pt:ensemble.inject pt:name=”al-collab.discussion” pt:id=”discussion” |
| discussionid=”21”> |
| <pt:pageletaccessdenied> |
| <B>Unable to display the current pagelet. Please contact |
| your system administrator.</B> |
| </pt:pageletaccessdenied/> |
| </pt:esemble.inject> |
Role Tag
| Tag | roledata |
| Description | This stores a list of the roles in memory that the current |
| user has available. The data is stored as a collection, and | |
| each item in the collection is a variable containing the role | |
| name. This can be used with the for each tag to iterate | |
| over role data. | |
| Attributes | |
| id | The key used to store the data list in memory. |
| scope | Which scope (tag, request, application, etc . . . ) to use to |
| store the data list in memory. | |
<pt:ensemble.roledata pt:id=“myroles”/>
| Tag | roleexpr |
| Description | This tag evaluates a role expression and stores the result |
| in memory. It is designed to work with the logic.if tag. | |
| Attributes | |
| expr | An expression consisting of the hasRole keyword followed |
| by an application role. This expression evaluates | |
| whether or not the current user has the specified role. | |
| key | The key used to store the data in memory. |
| scope | Which scope (tag, request, application, etc . . . ) to use to |
| store the data in memory. | |
<pt:ensemble.roleexpr pt:expr=“hasRole admin-role”/>
User/Group/Role Picker Tag
| Tag | picker |
| Description | This tag selects a user/group/role and passes the result to |
| the specified JavaScript function. | |
| Attributes | |
| form | The form of the HTML element to display (link, button, or |
| URL). If the form is URL, anything nested within this | |
| tag can not be displayed. Default is link. | |
| type | The type of object to select (user, group, or role). |
| multi | A boolean specifying whether or not the user can select |
| multiple items. | |
| Default to false. | |
| Jscallback | The JavaScript callback. This method can be passed a |
| 2d javascript array containing the type (user, group, | |
| or role), name, and ID of each selected item. | |
<pt: ensemble.picker pt:type=“user” pt:jscallback=“myJSCallbackfunc”/>
This tag can output an HTML element that can display a pop-up page containing the picker. The picker can be a simple list with filter box, similar to the ones used in the reverse proxy server admin UI.
Analytics Tag
This tag may or may not be included in the reverse proxy server, depending on details of the Analytics integration.
| Tag | Analytics | |
| Description | This sends an analytics event to the analytics | |
| server. | ||
| Attributes | ||
| Id | The event id. | |
| Data | The event data. | |
<pt: ensemble.analytics pt:id=“myeventid” pt:data=“myeventdata”/>
The reverse proxy server Debug Tags
| Tag | debug |
| Description | These outputs debug information about the current roles or |
| experience definitions (i.e. how did you get the current | |
| role and/or login page). | |
| Attributes | |
| Type | The type of debug info to display (role or experience |
| definition). | |
| <pt:ensemble.debug pt:type=”role”/> | |
| <pt: ensemble. debug pt:type=”experience definition”/> | |
The reverse proxy server In-place Refresh Tags
| Tag | inplacerefreshjslibraries |
| Description | This tag includes the JavaScript libraries necessary for |
| in-place refresh on a page. | |
| Attributes | |
| Tag | inplacerefresh |
| Description | This tag enables or disables in-place refresh on the |
| current page. | |
| Attributes | |
| enable | ‘true’ enables in-place refresh. ‘false’ disables in-place |
| refresh. If this attribute is not present, in-place refresh is | |
| enabled for the contents of the tag, and then the previous | |
| in-place refresh setting is restored. | |
| <pt: ensemble.inplacerefreshjslibraries/> | |
| <a href=”full-page -url>normal link </a> | |
| <pt: ensemble.inplacerefresh pt:enable=”true”/> | |
| <a href=”in-place-refresh-url>in-place link</a> | |
| </pt: ensemble.inplacerefresh pt:enable=”false”/> | |
| or | |
| <pt: ensemble.inplacerefresh> | |
| <a href=”in-place-refresh-url>second in-place link</a> | |
| </pt: ensemble.inplacerefresh> | |
Common tags can be shared between the reverse proxy server and portal. They can include new tags (with the reverse proxy server specific implementations) and enhancements to the pre-existing general tag libraries for specific the reverse proxy server needs.
Tags can be used for doing conditionals using tags. A variety of expr tags (such as the roleexpr tag) can store Boolean results for use by the if tag. This can simplify the if tag, and avoid the problem of having to figure out if the expression is an integer expression, a role expression, or something else.
| Tag | if |
| Description | This tag evaluates an expression and then displays either the |
| if-true or if-false tag contents. | |
| Attributes | |
| expr | A Boolean value. This can be input as an tag variable using |
| the $ attribute notation (i.e. pt: expr = “$myboolean”). | |
The corresponding if-true and if-false tags do not have any attributes. They are simply displayed or not displayed depending on the results of the tag expr parameter.
| Tag | iftrue |
| Description | This tag is displayed if the surrounding if tag evaluates to |
| true. | |
| Tag | iffalse |
| Description | This tag is displayed if the surrounding if tag evaluates to |
| false. | |
| Tag | intexpr |
| Description | This tag evaluates an integer expression and stores the |
| result in memory. | |
| Attributes | |
| expr | An integer value or a tag variable, followed by an integer |
| comparator, and then another integer value or tag variable. | |
| The tag variables must evaluate to an integer and be in $ | |
| attribute notation surrounded by parentheses. The | |
| following comparators are allowed: ‘==’, ‘!=’, ‘<’, ‘>’. | |
| key | The key used to store the data in memory. |
| scope | Which scope (tag, request, application, etc . . . ) to use to |
| store the data in memory. | |
| Tag | boolexpr |
| Description | This tag evaluates a boolean expression and stores |
| the result in memory. | |
| Attributes | |
| expr | A boolean value or a tag variable, followed by a boolean |
| comparator, and then another boolean value or tag variable. | |
| The tag variables must evaluate to a boolean and be in $ | |
| attribute notation surrounded by parentheses. The | |
| following operators are allowed: ‘&&’, ‘||’, ‘==’, and ‘!=’. | |
| key | The key used to store the data in memory. |
| scope | Which scope (tag, request, application, etc . . . ) to use to |
| store the data in memory. | |
| <pt:logic.intexpr pt:expr=”($numauths) > 1”/> | |
| <pt:logic.if pt:expr=”$if-result”> | |
| <pt:logic.iftrue> | |
| <!-- This is displayed if expr evaluates to true. --> | |
| </pt:logic.iftrue> | |
| <pt:logic.iffalse> | |
| <!-- This is displayed if expr evaluates to false. --> | |
| </pt:logic.iffalse> | |
| </pt:logic.if> | |
An alternate way of handling the expression tags is to have the arguments be tag attributes, rather than having an expression string that the tag parses. For example:
<pt:logic.intexpr pt:value1=“$numauths” pt:operator=“>” pt:value2=“1”/>
CollectionLength Tag
The collectionlength tag can be necessary to enable conditional logic based on how many auth sources or resources are returned (i.e. empty, a single item, or a list).
| Tag | collectionlength |
| Description | This tag evaluates the length of a collection and stores the |
| result in memory. | |
| Attributes | |
| data | The key used to store the collection. |
| key | The key used to store the result in memory. |
| scope | Which scope (tag, request, application, etc . . . ) to use to |
| store the data in memory. | |
Variable Tag Enhancement
This tag can be converted for use with the collection tag so that you can create collections of variables, in addition to collections of data objects. This can be useful for the rolesdata tag. The collection tag can also need to be updated to mention the new related child tag, as well as a warning not to mix data types in a collection.
Error Tags
These tags can allow the reverse proxy server errors to be formatted as desired on a custom error page. There are two ways to implement this. The first can require either adding an API to the Tag Engine to allow the reverse proxy server to set error messages for a user. The reverse proxy server can then need to set the error information before displaying an error page to the user. The second involves implementing the reverse proxy server specific error tags that meet a common error tag API specified by the tag engine.
| Tag | error |
| Description | This tag displays errors on the page so that they can be |
| placed and formatted as desired. If the errortext tag is | |
| included inside this tag, the contents of this tag can only be | |
| processed if there is an error. If the child tag is not present, | |
| then the error messages can be formatted and displayed | |
| from this tag in the standard style. | |
| Tag | errortext |
| Description | This tag displays the current error text on the page so that |
| it can be placed and formatted as desired. | |
| Attributes | |
| text | This attribute allows you to override the error text with text |
| of your own choosing. | |
| <pt:common.error/> | |
| or | |
| <pt:common.error> | |
| <p> | |
| <pt: common.errortext/> | |
| <p/> | |
| </pt:common.error> | |
| Tag | errorcode |
| Description | This tag stores the error code in tag memory. |
| Attributes | |
| key | The key used to store the data in memory. |
| scope | Which scope (tag, request, application, etc . . . ) to use to |
| store the data in memory. | |
<pt:common.errorcode pt:key=“myerrorcode”/>
User Info Tag
| Tag | userinfo |
| Description | This stores and retrieves user info data. |
| Attributes | |
| info | The name of the user info data. If this is used alone, the |
| data can be retrieved. | |
| value | The value to store in user info. |
| <pt:common.userinfo pt:info=”email”/> | |
| <pt:common.userinfo pt:info=”email” pt:value=”test@test.com”/> | |
Head Includes Tag Set
| Tag | includeinhead |
| Description | This marks JavaScript & Security Service links to be |
| included in the Head element of the HTML page by the | |
| headincludes tag. If no headincludes tag is present, it can be | |
| included at the bottom of the Head element, or a Head | |
| element can be inserted if there is none. If a .js or .css file | |
| is marked for inclusion multiple times, it can only be | |
| included once. This tag can be ignored during automatic | |
| in-place refresh requests, although custom in-place refresh | |
| solutions can need to remove this tag during refresh to | |
| function correctly. | |
| Attributes | |
| Tag | headincludes |
| Description | This tag allows JavaScript and Style Sheet include |
| information to be added to a specific point in the Head | |
| element of an HTML page, as required by the XHTML | |
| specification. If a .js or .css file is included multiple times, | |
| it can actually only be included once in the Head element. | |
| Attributes | |
Main Page HTML:
| <head> | |
| <script type=“text/javascript” src=“http://acme.com/main.js”/> | |
| <pt:common.headincludes/> | |
| </head> | |
Pagelet HTML:
| <pt:common.includeinhead> |
| <script type=“text/javascript”><!--JavaScript --></script> |
| <script type=“text/javascript” src=“http://acme.com/test.js”/> |
| <link rel=“stylesheet” href=“http://acme.com/test.css” type=“text/css”/> |
| </pt:common.includeinhead> |
In one embodiment, in the reverse proxy server proxy, URLs for various links in the HTML returned by resources are transformed in the reverse proxy mode, but not for transparent proxy mode. For pagelets, URLs can be rewritten in the transparent proxy mode—Javascript refresh can have the same domain, machine name, and port as the main page, otherwise ugly browser warnings appear. Another reason for rewriting URLs is branding: customers want a consistent URL experience for their users in the URL. (i.e. machine name/host doesn't change).
A “mini-gateway” for URLs inside pagelets can be used, both in transparent and reverse proxy mode. All URLs within can be rewritten with a following scheme, like the following:
http[s]://includingresourcehost:port/includingresourcepat h/PTARGS_pageletresourceid/pageletrelativeurl
For example:
Consuming resource with an external URL: http://runner.bea.com/crm/can include a pagelet. Pagelet's parent resource can have internal URL: http://collab.bea.com/and its ID in the reverse proxy server DB is 15. Pagelet has internal URL http://collab.bea.com/discussion/pagelet.jsp. Within the pagelet, there can be a link to http://collab.bea.com/discussion/viewthread.jsp.
User can hit http://runner.bea.com/crm/main.aspx, which includes the discussion pagelet. The link within a pagelet can get rewritten to http://runner.bea.com/cnn/PTARGS — 15/discussion/viewthread.jsp. This link can be composed of the consuming resource URL followed by the PTARGS, pagelet ID, and the remainder of the link in the pagelet after the pagelet parent internal URL.
Internally, mini-gateway can be a resource mapper which extracts resource ID from the URL and sets the appropriate resource on IntermoduleData. On pagelet URLs, it gets called instead of the regular resource mapper.
Embodiments of the present invention can provide a proxy and SSO solution that interoperates with a portal product. In one embodiment, there can be three major components to: proxy, administration console, and core resource API. These can be called RProxy, Admin Console, and Core API respectively.
In support of the primary components can be the additional, top level features of Auditing, Analytics, and Development Tools.
RProxy can support two modes of operation: reverse and transparent. These two modes can interoperate seamlessly. The end user only needs to be aware of when DNS changes are needed; they do not need to know about the distinction between transparent and reverse proxies.
In reverse proxy mode, RProxy can map resources based on the first part of the destination path in a request. For example, if a user requests proxy.external.com/resourceA/somepage.html then, according to user defined rules, the reverse proxy server map that traffic to resourceA.internal.com/somepage.html. This mode of operation requires content rewriting so that URLs in the HTML returned from a resource point to the reverse proxy server and not to the resource itself. Transparent proxy mode can use DNS configuration such that IP addresses of the desired, external hostnames point to RProxy. In this configuration, RProxy can use the request hostname to determine where to redirect traffic. For example, www.resourceA.com can have an IP address identical to proxy.external.com, and RProxy can accept a request to www.resourceA.com/somepage.html and redirects it to the internal address resourceA.internal.com/somepage.html—HTML content rewriting is required in this case. Alternatively, RProxy may map the resource to the internal address 192.168.1.2 and this host is configured with the hostname www.resourceA.com—in this case HTML content rewriting is unnecessary because the host resourceA is configured using its externally facing DNS name, www.resourceA.com, which has a external DNS address mapping to the same IP as proxy.external.com. That is, www.resourceA.com returns URLs that point to itself at www.resourceA.com (instead of returning URLs that point to an internal hostname).
Finally, these two modes can be used in combination such that www.resourceA.com has an IP address identical to proxy.external.com and www.resourceA.com/appB is mapped to resourceA.internal.com/appB. The users should be aware from the UI and from logs that a true transparent proxy case requires adding a new, internal only DNS entry that map to the internal IP address. This applies when the protected resource has an identical machine name to the external DNS name. For example, mail.ford.com can have an external IP address identical to RProxy. The protected resource can have a hostname of mail.ford.com as well. The user can manually add a DNS entry for an arbitrary internal hostname, say mail.internal.ford.com and map it to the internal address, say 192.168.1.2. When they configure an RProxy Resource, they can specify that mail.ford.com maps to mail.internal.ford.com. The machine mail.ford.com can retain its hostname internally and externally (so no URL rewriting is needed), and RProxy can know how to properly redirect the traffic.
The following are general steps for processing a request. When the reverse proxy server proxy receives a request from the browser there can be several things that can to happen:
These stages can be conceptually the same for any kind of request, in other words, no matter if the reverse proxy server received an upload request or download request, WebDAV request or Secure Sockets Layer (SSL) request—the logical stages that the request has to go through can be the same. On the other hand, the behavior of each of the stages could be different for different kind of requests. For example, transformation stage does not do anything for responses containing binary data (images/word documents/etc). Another example is that URL re-writing rules are different for normal pages and pagelet responses.
Another point to keep in mind is that logic to handle a particular type of request might span multiple stages. For example, a FormPickerModule can responsible for detecting login forms served by remote applications and automatically logging the users into those apps. In order to do this, it can add data to the request (retrieval stage) and examine the date of the response (transformation stage).
RProxy can manage ACLs on Resource Objects to determine if a user (who has already authenticated with RProxy via SSO login) has access to a requested resource. The reverse proxy server uses Role Based Access Control (RBAC), based on users, groups, and roles as defined below.
Furthermore, user customizable rules can be mapped to resources. For example, a rule can be created that says, “If a user is from IP address range 192.168.0.1 to 192.168.0.254 then always allow access.” Or, “if a user is accessing this from 8 am to 5 pm, allow access, otherwise deny.” Custom rules are the most likely use of scripting.