Features Matrix – Muse^® Proxy

* Applications number counts the predefined MuseProxyFoundation and Anonymous sample applications as well. The predefined sample applications should not be used in production as they will be rewritten by future Muse Proxy upgrades.

Below there are listed the most important Muse Proxy Features. All of them are available for Small Organization Edition, Medium Organization Edition and Large Organization Edition unless specified otherwise.

General Features

1. Works as a regular HTTP proxy with HTTP and HTTPS (CONNECT tunnel) support;
2. Individual authentication per each Web Module (running inside a Web Context) in part;
3. Supports public, authenticated and private resources in each Web Context;
4. The static resources are served using the Last-Modified HTTP response header in order to be cached by the browsers;
5. Configurable patterns for defining the list of server IP(s) on which Muse Proxy listens. A request received on a specific server IP is forwarded to the target site from the same server IP on which the request came;
6. Support for configuring different SSL certificate for each server IP;
7. Cache support;
8. Support for having a separate cache directory per each Server IP, based on the configuration;
9. Compression (gzip) support both for pages that are served after being rewritten (remote rewritten content from vendors) and for content originating to Muse Proxy itself;
10. For rewritten pages there is support for SSL termination to ensure Load Balancing HTTPS traffic in a manner that avoids unnecessary encryption cycles. This is achieved by Muse Proxy understanding X-Forwarded-Proto header field or the RFC 7239's Forwarded header field containing "proto=https" or "proto=http"; the other pages are all using relative links;
11. Support for configuring the redirect of HTTP requests against Applications and Administrator Console to HTTPS;
12. Default log in which there are written messages regarding Muse Proxy activity and the errors encountered in a human readable format;
13. Access log in which there are written the requests served/relayed by Muse Proxy. The Access log can be analyzed using tools like AWStats (http://awstats.sourceforge.net/);
14. Statistics log in which there are written detailed messages regarding Muse Proxy activity in a machine readable format. Automatic tools can be created to extract any information needed regarding the Muse Proxy activity from the Statistics log;
15. Support for tracking the user activity using data from the Default or Statistics logs (by Connection ID, Client Session ID and Navigation Session ID);
16. Supports global proxy chaining with a next proxy using Proxy Host and Proxy Port or using Proxy PAC;
17. Supports configurable authentication using authentication login modules;
18. Supports Read Time Out, Keep Alive and Keep Alive Interval with the Client;
19. Supports Connect Time Out, Read Time Out, Keep Alive and Keep Alive Interval with the target site;
20. Supports IPv6 and IPv4 addresses;
21. No need for dynamically assigned ports when doing the rewriting. The port on which the rewriting started is used for all the subsequent navigation;
22. If using only Rewrite by Path there is no need for dynamically assigned domains when doing the rewriting. The domain on which the rewriting started is used for all the subsequent navigation in case of Rewrite by Path; Rewrite by Host was introduced with Muse Proxy version 4.0 and is selectable on a source by source basis;
23. All the configuration files are self documented. All the options that can be set in a configuration file are present in that configuration file. There are no hidden options that could be found only after using the product for a long period;
24. The workflow used by Muse Proxy to assign a request to the component that handles it is defined externally, in the configuration files. It is easy to understand how the requests are mapped to the Proxy component or to the corresponding Web Context. In the Statistics log there are also written all the details needed to know how the requests are mapped to the corresponding component;
25. The information written in the configuration files is multi-level (the configuration files are in XML format). This allows to define an option exactly on the level where that option makes sense. In this way, complex settings are better understood by the Muse Proxy Administrator.
26. Muse Proxy can create access log files in the same configurable format as those created by standard web servers such as Apache HTTP Server, format which can be set via a % style pattern (an extension of the Common Logging format). In order to do this, the LOG_FORMAT element should have the type="apache" attribute set. To have a good base for statistical information, especially in a multi-tenant environment, we recommend using more items besides Common Logging, by adding the inbound server IP address, Muse Proxy application, user session, content type:

    <LOG_FORMAT type="apache">%h %A %w %W %u %S %t "%r" "%{Content-Type}o" %s %b</LOG_FORMAT>

27. Support for specifying IP ranges in ALLOW and DENY rules for both IPv4 and IPv6. All types of rules can be mixed if need be, for example one allow/deny rule can be a wildcard such as 217.156.14.*, another rule can be a CIDR rule such as 217.156.0.0/16 and another one can be expressed using the range 217.156.11.0-217.156.15.255.
28. Supports redirection to remote Sources depending on the end-user IP (non-proxied links). This is done via Sources.xml file via the new REDIRECT section containing IP_RULES elements which are applied on a set of sources and, if the request is for a source that matches the APPLY pattern and the request's end-user IP satisfies the ALLOW/DENY sequences, then the response will be a native redirect to the source URL.

Muse Navigation Manager (Rewriting Component) Features

1. Support for flexible URL patterns, using include and exclude rules, matching all URL components (domain, port, path, CGI parameters), to specify which URLs will be rewritten;
2. Rewrites automatically links from HTML attributes. Rewrites only the links from HTML attributes and not also texts from the page which represent URLs;
3. Rewrites automatically most of the links constructed from JavaScript;
4. Manages, at server side level, Cookies from the Set-Cookie HTTP Headers received from the target rewritten sites;
5. Tries to intercept and rewrite automatically Cookies from document.cookie JavaScript object and passes them to be stored at server side;
6. Rewrites automatically links from CSS files;
7. Rewrites automatically links written via JS document.write sequences;
8. Rewrites links from XML, using Muse Navigation Manager rewriting filters;
9. Rewrites links from JSON, using Muse Navigation Manager rewriting filters;
10. Rewrites automatically HTML OBJECT tag;
11. Rewrites automatically HTML EMBED tag;
12. Rewrites Flash Objects Parameters, using Muse Navigation Manager rewriting filters;
13. Rewrites HTTP and HTTPS sites;
14. Configurable Find and Replace filters acting on the HTTP body can be crafted in the XML source profiles and will be interpreted at run-time, without the need to write Java code. Two types of filters: regular expression based and Muse Proxy token rule based similar to the token rules written in Muse Proxy Java filters. Simple (just find/replace) and complex filter configurations involving conditions (such as APPLY_IF_FIRST) and variables are supported;
15. If configurable filters are not covering special complex cases, the administrators can create, using a Java API, their custom Muse Navigation Manager rewriting filters, that will be executed only for specific Muse Proxy Sources links. The mechanism allows to create a great number of Muse Navigation Manager custom rewriting filters without affecting the overall Muse Navigation Manager reliability, because each Muse Navigation Manager custom rewriting filter will be executed only for the Muse Proxy Source for which it was created;
16. Supports automatic authentication for rewritten links using an authentication token generated by Muse Proxy and stored in the Navigation Session;
17. Supports a custom charset in the Content-Type HTTP header returned by the rewritten pages;
18. Supports chaining, at server side level, with a next proxy, set using Proxy Host and Proxy Port or set using Proxy PAC, for the rewritten links. Supports chaining with different proxies for different rewritten links;
19. Supports Proxy-Authorization using Basic and Digest authorization schemes, at server side level, with a next proxy, for the rewritten links. Supports separate proxy authorization for different rewritten links;
20. Supports HTTP Authorization using Basic and Digest authorization schemes, at server side level, with the target site, for the rewritten links. Supports separate HTTP authorization for different rewritten links;
21. Supports setting an initial set of Cookie HTTP headers, at server side level, when navigating on a rewritten link. Supports separate sets of cookies for separate rewritten links navigated for the same target site;
22. Supports setting an initial Referer, at server side level, when navigating on a rewritten link. Supports separate Referer authorization for different rewritten links;
23. Control of the resulting protocol which could totally decouple server end and source end or could replicate source behaviour;
24. Supports, by configuration, for a Type 2 rewritten link obtained by a Client, to be passed to another Client, who will be allowed to navigate on it; this option should be used with care;
25. The Muse Navigation Manager component (mnm.jar file) can be updated at run-time, without restarting Muse Proxy;
26. Supports Type 1 rewritten links - entry point links coming from a Muse Search Application;
    The Type 1 rewritten links are entry links having the rewriting information stored in them as CGI parameters. Example of Type 1 rewritten URL:

    http://navigationManagerHost:navigationManagerPort/com/site/
    ?MuseProtocol=ProtocolValue
    &MuseHost=some.site.com
    &targetSiteParameter1=targetSiteParameterValue1...
    &targetSiteParameterN=targetSiteParameterValueN
    &MuseCookie=CookieValue
    &MuseReferer=RefererValue
    &MuseAuthorization=AuthorizationValue
    &MuseAuthorizationScheme=AuthorizationSchemeValue
    &MuseProxyHost=ProxyHostValue
    &MuseProxyPort=ProxyPortValue
    &MuseProxyPac=ProxyPacValue
    &MuseProxyAuthorization=ProxyAuthorizationValue
    &MuseProxyAuthorizationScheme=ProxyAuthorizationSchemeValue
    &MuseCharset=CharsetValue
    &MuseUID=UIDValue
    &MuseProxyAuthenticationToken=ProxyAuthenticationTokenValue
    &MuseSourceID=SourceIDValue
    &MuseNavigationManagerMode=NavigationManagerModeValue
    &MusePath=PathValue

    This feature is available only for Software Integration Edition;
27. Supports Tiny URL(s);
    A Tiny URL is a wrapper for a Type 1 link which has either very large GET parameters (such as exceeding 2048 bytes) or needs to perform a POST action. Hence it is another entry point used from Muse Search into the Muse Proxy for navigation purposes. The URL may not really seem visually tiny, but it can reduce the size of the initial URL even to 1% and resolve impossible situations.

    http://proxy.museglobal.ro/com/edulib/?MuseTinyURLID=5746a08c3142d74cadecf6a8b84d78bc&MuseHost=www.edulib.com&MuseProxyAuthenticationToken=f4dd4e1125ef591ec8678921f0a9634c&MusePath=/

    This feature is available only for Software Integration Edition.
28. Supports Source Type URLs - entry point links which are associated with a Muse Proxy Application, authentication group and source identifier. For example:

    http(s)://${navigationManagerHost}:${navigationManagerPort}/${MuseProxyAppID}?groupID=${groupIDValue}[&${applicationAuthenticationParameters}]&action=source&sourceID=${sourceIDValue}

    http://proxy.museglobal.ro/MuseProxyFoundation?groupID=1&action=source&sourceID=PUBMED

29. Supports Extended Source Type URLs;
    Extended Source Type URLs are entry point links which are associated with a Muse Proxy Application, authentication group, source identifier and an exact URL from that source. For example:

    http(s)://${navigationManagerHost}:${navigationManagerPort}/${MuseProxyAppID}?groupID=${groupIDValue}&action=source&sourceID=${sourceIDValue}[&$applicationAuthenticationParameters]&qurl=${encodedURL}

    http://proxy.museglobal.ro/MuseProxyFoundation?groupID=1&action=source&sourceID=PUBMED&qurl=http%3A%2F%2Fwww.ncbi.nlm.nih.gov%2Fpccompound

    These types of links are also used for Search Widgets and Form Integration.
30. Supports Shortcut Source Type URLs - entry point links for source navigation where one does not need to provide the sourceID parameter, but just an URL parameter. The sourceID is automatically discovered based on Muse Proxy configuration. This ensures an easier integration as the other parties do not have to maintain sourceIDs mappings on their side thus a permanent link of a certain target could be proxied much easier as long as the URL host is bound to a source defined in Muse Proxy. For example:

    http(s)://${navigationManagerHost}:${navigationManagerPort}/${MuseProxyAppID}?[groupID=${groupIDValue}&][$applicationAuthenticationParameters&]url=${nonEncodedRemoteURL}

    http(s)://${navigationManagerHost}:${navigationManagerPort}/${MuseProxyAppID}?[groupID=${groupIDValue}&][$applicationAuthenticationParameters&]qurl=${encodedRemoteURL}

    http://proxy.museglobal.ro/MuseProxyFoundation?url=http://www.ncbi.nlm.nih.gov/assembly

    http://proxy.museglobal.ro/MuseProxyFoundation?qurl=http%3A%2F%2Fwww.ncbi.nlm.nih.gov%2Fassembly

    The encoded form of the remote URL is recommended.
31. Supports Rewrite by Path (Type 2) rewritten links;
    Type 2 rewritten links are internal, follow-up URLs after an entry point link (either Type1, Tiny URL or Source type) was successfully processed; they are dynamical links containing in them a Navigation Session ID, as value for the MuseSessionID field (marker), in the path part of the URL. The Type 2 rewritten URLs are valid only for a small period of time (by default 30 minutes after they are last accessed), while the Navigation Session associated with them is still valid. This type of URL should not be used as an entry point. Example of Type 2 rewritten URL:

    http(s)://navigationManagerHost:navigationManagerPort
    /MuseSessionID=SessionIDValue
    /MuseProtocol=ProtocolValue
    /MuseHost=some.site.com
    /MusePath
    /targetSitePathPart1/...
    /targetSitePathPartN/
    ?targetSiteParameter1=targetSiteParameterValue1...
    &targetSiteParameterN=targetSiteParameterValueN

32. Supports Rewrite by Host (Type 3) rewritten links.
    Rewrite by Host (Proxy by Host) is the second type of internal, follow-up URL where the Muse Proxy markers for navigation session, protocol, ID (if needed for load balancing) and native host and port are added as part of the proxy sub-domain, while the path remains untouched. This type of URL should not be used as an entry point. Example of a Rewrite by Host URL:

    http://01105002q.p0.y.http.www.ncbi.nlm.nih.gov.proxy.museglobal.ro:9797/pccompound

Muse Proxy Applications Features

1. A Muse Proxy Application can be configured to respond only on certain server IP(s) (domains) on which Muse Proxy listens;
2. A Muse Proxy Application supports expiry after a certain date;
3. Muse Proxy Applications users can be authenticated using configurable Authentication Groups;
4. An Authentication Group used in a Muse Proxy Application performs the authentication using a list of configurable Login Modules. The current list of Login Modules that can be used by Muse Proxy Applications is: IP, User/Password, LDAP, IMAP, SQL, FTP, Referer, HMAC based validation, SAML 2.0, External HTTP service, OAuth, OAuth2, OpenID Connect, CAS SSO based authentication, SIP and Barcode;
5. An Authentication Group has a dedicated login page, corresponding with the list of logon parameters required by the Login Modules configured in that Authentication Group;
6. An Authentication Group used in a Muse Proxy Application allows access to the Sources from a Sources Group;
7. SAML 2.0 Authentication  as a Service Provider is supported for a Muse Proxy Application. Being based on  Spring Security SAML Extension , theoretically all products supporting SAML 2.0 in Identity Provider mode (e.g. ADFS, Okta, Shibboleth, OpenAM, Efecte EIM or Ping Federate) should be compatible; some of the SAML 2.0 related features are:
   1. Includes a local Discovery service;
   2. Supports external Discovery;
   3. Metadata management supporting adding IDP metadata and generating of SP metadata, pre-validation of IDP metadata to detect the need of certificates, tests for authentication, seeing SAML attributes, guidelines and more;
   4. Supports specifying the IDP metadata either by uploading the IDP metadata file or by specifying the IDP metadata URL with a local file backup with periodically refreshes;
   5. Supports specifying IDP metadata as a file/URL containing one EntityDescriptor or as multiple EntityDescriptor wrapped in EntitiesDescriptor (e.g. a federation) with filters eliminating conflicts if the SP metadata is also present in the same file;
   6. Post-SAML authentication decisions via server side JavaScript on letting the user in the application, choosing a source group, choosing an attribute to be logged into the statistics. These, as well as other settings are grouped in the ProxyLoginModuleSAML.xml configuration file of the SAML login module.
8. Other Single sign-on (SSO) Authentication protocols (distinct than SAML) are supported: a wide range of OAuth, OAuth2, OpenID Connect, CAS SSO based authentication.
   1. The out of the box OAuth specific support is for: BitBucket, DropBox, Facebook, Foursquare, Github, Google, LinkedIn, Odnoklassniki, ORCiD, Paypal, Strava, Twitter, Vk, Windows Live, Word Press, Yahoo. Note that Google ensures authentication with both the public gmail.com domain as well as Google hosted institutions via Google Apps for Education, for example;
   2. Besides the above out of the box support, a generic OAuth client implementation can be configured for authentication to the providers that are not diverging from the usual practices in OAuth requests and responses (e.g. return the access token in JSON as "access_token" : "{value}", return profile in JSON and not XML, use "code" and "state" parameter names, no additional hashes with the access token);
   3. There's also a general configuration for any CAS server using OAuth protocol and a general support for the providers that are following the usual practices as described above;
   4. Post-SSO authentication decisions on letting the user in the application, choosing a source group, choosing an attribute to be logged into the statistics can be configured via server side JavaScript;
   5. OAuth Guidelines and JSON profile inspection are available in Muse Proxy Administrator Console.
9. A Muse Proxy Source can be profiled via EXTRACTORs, URLs, and POST_PARAMETERs to conduct an extract and navigation scenario in order to obtain tokens or navigate to the desired link before handing over control to the browser with the first rewritten link. Apache HTTP Client library can now be configured in Sources.xml for the first source request (extract and navigate scenario). Because the Oracle JDK URLConnection does not allow the control of the outbound IP address up to now we were forced to perform an extra request through Muse Proxy and this increases the complexity of troubleshouting and authentication configuration and adds an extra request. Also it supports encodeURIComponent and decodeURIComponent to be used for reference and parameter process for first source requests. The functions are compatible with the JavaScript ones. The existent encodeURL and decodeURL are based on JDK URLEncoder/URLDecoder which are using application/x-www-form-urlencoded MIME format which is not entirely the same as the URI encoding which, for example transforms space into %20 instead of +, for example and some servers are sensitive to these differences.
10. The Muse Proxy Application web interface is completely configurable using FreeMarker template files (see http://freemarker.sourceforge.net/). At server side level, for each action, only the FreeMarker objects are created, and the way in which the information from the FreeMarker objects is written in the response page is completely defined by the template file used. In this way, using different template files, the same action, may generate responses in different formats: HTML, JSON, XML etc. The FreeMarker objects also store information regarding the HTTP headers and CGI parameters of the request, etc;
11. The FreeMarker templates are read from disk using UTF-8 encoding. The response pages generated using FreeMarker templates are returned using UTF-8 encoding. This encoding is specified in the Content-Type HTTP header using the charset attribute;
12. The Content-Type returned by a Muse Proxy Application request corresponds with the MIME type associated with the extension of the template file. This assures support for JSON and XML AJAX requests;
13. The values returned by the FreeMarker objects methods and properties can be escaped for including them in HTML attributes, XML content or JSON content;
14. The FreeMarker template files defined as public can be requested using the getResource action without needing authentication. In such case no persistent Client Session will be created. This mechanism allows the customers to include links, pointing to Application FreeMarker resources in their web pages. So the end-users can navigate through a number of public application pages, served using the getResource action and generated using FreeMarker templates, without needing to authenticate to that Application;
15. If a FreeMarker template file is defined as authenticated and if the end-user is not authenticated yet, when accessing it there will be displayed the logon page corresponding to the authentication group specified using groupID CGI parameter. If the groupID CGI parameter is not present in the URL there will be displayed the logon page corresponding to the default authentication group. After the authentication succeeds, a persistent Client Session will be created and the FreeMarker template file requested using the getResource action will be interpreted and served;
16. MuseProxyFoundation based application supports source icon configuration. If configured, the image will be displayed under the Source name, next to the source description;
17. Sources can be hidden from the source listing but still usable via Entry Points either shortcuts, extended or normal;
18. MuseProxyFoundation based application supports category based grouping for source layer presentation by defining them in Sources.xml. Multiple areas can be defined (Subjects, Vendor), including A-Z ones and these are displayed in different tabs. Integration with MuseSearch passthrough is available if dblist source attributes are defined;
19. Custom source attributes can be defined in Sources.xml and these will be represented as data-name="this value" in the DOM element corresponding to the source;
20. A Muse Proxy Application supports a configurable HTML index page to be displayed when accessing the Muse Proxy Application's home URL. In that index page there can be present links to the logon pages for a list of Authentication Groups defined. If the index page path is set to void, the logon page for the default Authentication Group is displayed when accessing the Muse Proxy Application's home URL. A single Muse Proxy Application may support separate logon pages (the links to these logon pages will be referred from the index page) for each group of users and also each group of users may have access to separate sets of sources;
21. A Muse Proxy Application supports a default Authentication Group that is used by default when no specific groupID CGI parameter (which specifies the Authentication Group ID) is specified in the logon request;
22. Automatic logon in a Muse Proxy Application is supported using IP authentication for the default Authentication Group;
23. A Muse Proxy Application supports a configurable logout page that is displayed when the user was logged out;
24. A Muse Proxy Application supports saving information, through an HTTP request in a special format, in the Application Session, at server side level. That information can be written later in response pages generated using FreeMarker templates;
25. Multiple Muse Proxy Applications may run in the same Muse Proxy installation, there is no need to have separate Virtual Machines for each Muse Proxy Application. This saves Operating System resources;
26. The resources used by a Muse Proxy Application (*.css, *.js, images, etc) can be stored and referred from the Muse Proxy Application's level. Separate Muse Proxy Applications may use separate logon pages and separate skins;
27. A Muse Proxy Application may use static and dynamic resources. The static resources will be cached in the user's browser, assuring a fast user access to the Muse Proxy Application's web interface even from mobile devices;
28. Complex web interfaces can be created easily using the Muse Proxy Applications environment. Passing parameters from one page to another, AJAX requests, saving data in Session for using it later, caching of static resources in browsers to reduce the loading time for the subsequent pages navigated, etc all are ready to be used for creating complex web pages. Integrating a Muse Proxy Application as a page inside an existing site is also possible;
29. Muse Proxy Applications are ready for Load Balancing, including support for: SSL Termination, detecting the end-user IP through HAProxy PROXY Protocol or X-Forwarded-For. Detailed documentation is available regarding how to setup a Load Balancing environment for Muse Proxy Applications;
30. Links to Muse Proxy Sources from Muse Proxy Applications can be embedded dynamically in external portals. In this way, a customer may use the external portal authentication, but still provide access to Muse Proxy Sources links. A documented example PHP script, showing this dynamic integration, is provided in the product installation.

Administrator Console Features

1. Modern and fully integrated AJAX console;
2. Connections monitoring;
3. Client Sessions monitoring;
4. Log Files download;
5. Tiny URL(s) monitoring;
   This feature is available only for Software Integration Edition.
6. Customize the network traffic exported at run-time using JMX per each server IP, in order to prevent network traffic counting with remote IP(s) from the local network;
7. Configure at run-time the patterns for the server IP(s) on which Muse Proxy must listen;
8. Configure the Administrative Access Rules;
9. Configure the Administrative Passwords;
10. Configure the list of Administrative Login Modules executed to authenticate each Administrative Web Context and the regular Proxy requests;
11. Configure the Java policy rules;
12. Configure the SAML Authentication details, from metadata administration for both Service providers and Identity providers, to actions for restarting the SSO engine or refreshing the configuration;
13. Configure the SSO Authentication details for the OAuth, OAuth2, OpenID Connect and CAS based SSO authentications.
14. View the Cache Status global statistics;
15. View the Cache Files for each cache directory;
16. Configure the access details to Global InfoBase, used for downloading the Muse Navigation Manager (mnm.jar) component;
17. Schedule the update to the latest version of Muse Navigation Manager (mnm.jar) component;
18. Backup/Restore for the Muse Navigation Manager (mnm.jar) component;
19. Generate Type 1 rewritten links and Tiny URL(s);
    This feature is available only for Software Integration Edition.
20. Un-Rewrite a Muse Proxy Rewritten URL in Type 1 or Type 2 format;
21. Encrypt a password using SHA1, MD5 or DES algorithms;
22. Clean the Proxy PAC cache;
23. Refresh the Muse Proxy Applications on demand;
24. See information regarding the Java Virtual Machine;
25. Troubleshoot filter configurations via regular expression by Find and Replace sequences. The section is split in two tabs one for raw Java Regex testing ("By JDK Regex") and one that simulates the exact process of the filtering code ("By Running Filter");
26. Generate test HMAC links used for transparent log-on from a portal so that the end-user is not requested an explicit authentication to Muse Proxy;
27. Test which sourceID is detected for a certain application when receiving only the url/qurl parameter without the sourceID parameter;
28. Manage assigned keystores from SSL_KEYSTORE_FILE configuration element: add new entries, edit and delete. View all details about the certificates from keystore;
29. Complete management of the Muse Proxy Applications and their resources, from end-user authentication to sources.
30. The access to the /admin context is secured, if not accessing from an authorized IP address a 404 Not Found error page is displayed.

JMX (Java Management Extension) Features

1. See at run-time information regarding the memory and CPU used by Muse Proxy;
2. See at run-time information regarding the Muse Proxy threads;
3. Set at run-time the Authentication Timeout for Proxy Requests and save the configuration to disk;
4. Set at run-time the default Authentication Timeout and Client Session Timeout for the Web Contexts and save the configuration to disk;
5. Set at run-time the Authentication Timeout for a specific Web Context and save the configuration to disk;
6. See the File Sets mappings (public, authenticated and private) for each Web Context;
7. See the MIME Mappings for each Web Context;
8. Set the configurable parameters for each Web Module and see the value for the read-only parameters;
9. See the global proxy configuration fields and update the editable fields;
10. See the Muse Proxy Statistics (traffic statistics and other server statistics) globally and per server IP;
11. Set at run-time the patterns for the server IP(s) on which Muse Proxy must listen and save the configuration to disk;
12. Schedule the update to the latest version of Muse Navigation Manager (mnm.jar) component;
13. Refresh the Muse Proxy Applications on demand.

Muse Proxy Services Features

1. Support for http://${Muse Proxy Host}:${Muse Proxy Port}/ProxyInformation request;
   This feature is available only for Software Integration Edition.
2. Support for http://${Muse Proxy Host}:${Muse Proxy Port}/TinyURLGenerator request.
   This feature is available only for Software Integration Edition.

General Features

• Works as a regular HTTP proxy with HTTP and HTTPS (CONNECT tunnel) support;
• Individual authentication per each Web Module (running inside a Web Context) in part;
• Supports public, authenticated and private resources in each Web Context;
• The static resources are served using the Last-Modified HTTP response header in order to be cached by the browsers;
• Configurable patterns for defining the list of server IP(s) on which Muse Proxy listens. A request received on a specific server IP is forwarded to the target site from the same server IP on which the request came;
• Support for configuring different SSL certificate for each server IP;
• Cache support;
• Support for having a separate cache directory per each Server IP, based on the configuration;
• Compression (gzip) support both for pages that are served after being rewritten (remote rewritten content from vendors) and for content originating to Muse Proxy itself;
• For rewritten pages there is support for SSL termination to ensure Load Balancing HTTPS traffic in a manner that avoids unnecessary encryption cycles. This is achieved by Muse Proxy understanding X-Forwarded-Proto header field or the RFC 7239's Forwarded header field containing "proto=https" or "proto=http"; the other pages are all using relative links;
• Support for configuring the redirect of HTTP requests against Applications and Administrator Console to HTTPS;
• Default log in which there are written messages regarding Muse Proxy activity and the errors encountered in a human readable format;
• Access log in which there are written the requests served/relayed by Muse Proxy. The Access log can be analyzed using tools like AWStats (http://awstats.sourceforge.net/);
• Statistics log in which there are written detailed messages regarding Muse Proxy activity in a machine readable format. Automatic tools can be created to extract any information needed regarding the Muse Proxy activity from the Statistics log;
• Support for tracking the user activity using data from the Default or Statistics logs (by Connection ID, Client Session
ID and Navigation Session ID);
• Supports global proxy chaining with a next proxy using Proxy Host and Proxy Port or using Proxy PAC;
• Supports configurable authentication using authentication login modules;
• Supports Read Time Out, Keep Alive and Keep Alive
Interval with the Client;
• Supports Connect Time Out, Read Time Out, Keep
Alive and Keep Alive Interval with the target site;
• Supports IPv6 and IPv4 addresses;
• No need for dynamically assigned ports when doing the rewriting. The port on which the rewriting started is used for all the subsequent navigation;
• If using only Rewrite by Path there is no need for dynamically assigned domains when doing the rewriting. The domain on which the rewriting started is used for all the subsequent navigation in case of Rewrite by Path; Rewrite by Host was introduced with Muse Proxy version 4.0 and is selectable on a source by source basis;
• All the configuration files are self documented. All the options that can be set in a configuration file are present in that configuration file. There are no hidden options that could be found only after using the product for a long period;
• The workflow used by Muse Proxy to assign a request to the component that handles it is defined externally, in the configuration files. It is easy to understand how the requests are mapped to the Proxy component or to the corresponding Web Context. In the Statistics log there are also written all the details needed to know how the requests are mapped to the corresponding component;
• The information written in the configuration files is multi-level (the configuration files are in XML format). This allows to define an option exactly on the level where that option makes sense. In this way, complex settings are better understood by the Muse Proxy Administrator.
• Muse Proxy can create access log files in the same configurable format as those created by standard web servers such as Apache HTTP Server, format which can be set via a % style pattern (an extension of the Common Logging format). In order to do this, the LOG_FORMAT element should have the type="apache" attribute set. To have a good base for statistical information, especially in a multi-tenant environment, we recommend using more items besides Common Logging, by adding the inbound server IP address, Muse Proxy application, user session, content type:
  <LOG_FORMAT type="apache">%h %A %w %W %u %S %t "%r" "%{Content-Type}o" %s %b</LOG_FORMAT>
• Support for specifying IP ranges in ALLOW and DENY rules for both IPv4 and IPv6. All types of rules can be mixed if need be, for example one allow/deny rule can be a wildcard such as 217.156.14.*, another rule can be a CIDR rule such as 217.156.0.0/16 and another one can be expressed using the range 217.156.11.0-217.156.15.255.
• Supports redirection to remote Sources depending on the end-user IP (non-proxied links). This is done via Sources.xml file via the new REDIRECT section containing IP_RULES elements which are applied on a set of sources and, if the request is for a source that matches the APPLY pattern and the request's end-user IP satisfies the ALLOW/DENY sequences, then the response will be a native redirect to the source URL.

Muse Navigation Manager (Rewriting Component) Features

• Support for flexible URL patterns, using include and exclude rules, matching all URL components (domain, port, path, CGI parameters), to specify which URLs will be rewritten;
• Rewrites automatically links from HTML attributes. Rewrites only the links from HTML attributes and not also texts from the page which represent URLs;
• Rewrites automatically most of the links constructed from JavaScript;
• Manages, at server side level, Cookies from the Set-Cookie HTTP Headers received from the target rewritten sites;
• Tries to intercept and rewrite automatically Cookies from document.cookie JavaScript object and passes them to be stored at server side;
• Rewrites automatically links from CSS files;
• Rewrites automatically links written via JS document.write sequences;
• Rewrites links from XML, using Muse Navigation Manager rewriting filters;
• Rewrites links from JSON, using Muse Navigation Manager rewriting filters;
• Rewrites automatically HTML OBJECT tag;
• Rewrites automatically HTML EMBED tag;
• Rewrites Flash Objects Parameters, using Muse Navigation Manager rewriting filters;
• Rewrites HTTP and HTTPS sites;
• Configurable Find and Replace filters acting on the HTTP body can be crafted in the XML source profiles and will be interpreted at run-time, without the need to write Java code. Two types of filters: regular expression based and Muse Proxy token rule based similar to the token rules written in Muse Proxy Java filters. Simple (just find/replace) and complex filter configurations involving conditions (such as APPLY_IF_FIRST) and variables are supported;
• If configurable filters are not covering special complex cases, the administrators can create, using a Java API, their custom Muse Navigation Manager rewriting filters, that will be executed only for specific Muse Proxy Sources links. The mechanism allows to create a great number of Muse Navigation Manager custom rewriting filters without affecting the overall Muse Navigation Manager reliability, because each Muse Navigation Manager custom rewriting filter will be executed only for the Muse Proxy Source for which it was created;
• Supports automatic authentication for rewritten links using an authentication token generated by Muse Proxy and stored in the Navigation Session;
• Supports a custom charset in the Content-Type HTTP header returned by the rewritten pages;
• Supports chaining, at server side level, with a next proxy, set using Proxy
Host and Proxy Port or set using Proxy PAC, for the rewritten links. Supports chaining with different proxies for different rewritten links;
• Supports Proxy-Authorization using Basic and Digest authorization schemes, at server side level, with a next proxy, for the rewritten links. Supports separate proxy authorization for different rewritten links;
• Supports HTTP Authorization using Basic and Digest authorization schemes, at server side level, with the target site, for the rewritten links. Supports separate HTTP authorization for different rewritten links;
• Supports setting an initial set of Cookie HTTP headers, at server side level, when navigating on a rewritten link. Supports separate sets of cookies for separate rewritten links navigated for the same target site;
• Supports setting an initial Referer, at server side level, when navigating on a rewritten link. Supports separate Referer authorization for different rewritten links;
• Control of the resulting protocol which could totally decouple server end and source end or could replicate source behaviour;
• Supports, by configuration, for a Type 2 rewritten link obtained by a Client, to be passed to another Client, who will be allowed to navigate on it; this option should be used with care;
• The Muse Navigation Manager component (mnm.jar file) can be updated at run-time, without restarting Muse Proxy;
• Supports Type 1 rewritten links - entry point links coming from a Muse Search Application;
  The Type 1 rewritten links are entry links having the rewriting information stored in them as CGI parameters. Example of Type
1 rewritten URL:

  http://navigationManagerHost:navigationManagerPort/com/site/
  ?MuseProtocol=ProtocolValue
  &MuseHost=some.site.com
  &targetSiteParameter1=targetSiteParameterValue1...
  &targetSiteParameterN=targetSiteParameterValueN
  &MuseCookie=CookieValue
  &MuseReferer=RefererValue
  &MuseAuthorization=AuthorizationValue
  &MuseAuthorizationScheme=AuthorizationSchemeValue
  &MuseProxyHost=ProxyHostValue
  &MuseProxyPort=ProxyPortValue
  &MuseProxyPac=ProxyPacValue
  &MuseProxyAuthorization=ProxyAuthorizationValue
  &MuseProxyAuthorizationScheme=ProxyAuthorizationSchemeValue
  &MuseCharset=CharsetValue
  &MuseUID=UIDValue
  &MuseProxyAuthenticationToken=ProxyAuthenticationTokenValue
  &MuseSourceID=SourceIDValue
  &MuseNavigationManagerMode=NavigationManagerModeValue
  &MusePath=PathValue