FAQ

Most Popular

The overall steps would be: 1) Create the new application as copy of the MuseProxyFoundation template, the ID of the new application to be MuseProxyFoundationHMAC for example. 2) Edit the file $MUSE_HOME\proxy\webcontexts\Applications\MuseProxyFoundationHMAC\ profiles\AuthenticationGroups.xml and do the following: – Locate the /ICE-CONFIG/AUTHENTICATION_GROUPS/AUTHENTICATION_GROUP/AUTHENTICATIONS node and remove its content, thus obtaining an empty node: <AUTHENTICATIONS> </AUTHENTICATIONS> – Edit the value of the node /ICE-CONFIG/AUTHENTICATION_GROUPS/AUTHENTICATION_GROUP/NAME to be: HMAC Authentication – Add the following sequence under the node /ICE-CONFIG/AUTHENTICATION_GROUPS/AUTHENTICATION_GROUP/AUTHENTICATIONS <AUTHENTICATION> <IDENTIFIER>9</IDENTIFIER> <LEVEL>requisite</LEVEL> <CLASS>com.edulib.muse.proxy.authentication.modules.ProxyLoginModuleHMAC </CLASS> <HANDLER> <CLASS>com.edulib.muse.proxy.authentication.modules .ProxyLoginModuleHMACDataHandlerXml</CLASS> <PARAMETERS> <CONFIGURATION_FILE>${WEB_CONTEXT_HOME}/profiles/login /ProxyLoginModuleHMAC.xml</CONFIGURATION_FILE> </PARAMETERS> </HANDLER> </AUTHENTICATION> (make sure that after pasting the content the XML file is still valid) 3) Refresh the applications properties via the Muse Proxy Administrator Console -> Advanced left menu section -> Operations item -> Refresh Applications button. Now the HMAC is set with HMAC authentication. 4) Establish and configure the parameters for the HMAC authentication. For this edit the file: $MUSE_HOME\proxy\webcontexts\Applications\MuseProxyFoundationHMAC \profiles\login\ProxyLoginModuleHMAC.xml and make changes according to your requirements. E.g. you may want to change the secret value (default is quiet) and the parameters that you want to hash as part of the signature. By default only the userName (Application ID) and timestamp are used, however you can add the userAgent and/or referer and/or userAddress to be hashed. We assume for the examples purposes that all defaults remain (e.g. the quiet secret and userName.timestamp as message to sign with HmacSHA1). Assuming that you want to proxify an URL (ex. http://www.amazon.com/) for the MuseProxyFoundationHMAC Muse Proxy application, the generated HMAC URL will look like: http://MUSE_PROXY_HOST:PORT/MuseProxyFoundationHMAC?userName=MuseProxyFoundationHMAC &ts=1469524141&sig=ee5a160dbd37c4867e34e6147a3421d2289bec14 &qurl=http%3A%2F%2Fwww.amazon.com%2F where MUSE_PROXY_HOST:PORT are the Muse Proxy server details. Note that by default the validity of this URL is 30 seconds. For more detailed information on enabling and configuring HMAC authentication refer to the Muse Proxy Advanced Configuration.pdf manual, 6.4.5.8 ProxyLoginModuleHMAC chapter. 5) Create your server side implementation that will generate dynamically the HMAC link(s). Notes: 1) The generated HMAC URL will work only for 30 seconds (configurable in the value of the TS_EXPIRY field in $MUSE_HOME\proxy\webcontexts\Applications\MuseProxyFoundationHMAC \profiles\login\ProxyLoginModuleHMAC.xml) 2) The server generating the HMAC links and the Muse Proxy server must be time synchronized. This is a must, otherwise if the 2 machines are not synchronized with regard to the time, the HMAC links will not work due to the validity value of the signature. 3) If you create proxified links, the destination URL (e.g the value of the qurl parameter) must be URL encoded.
Categories: Muse Proxy, Usage

You can configure LDAP authentication as a single authentication method. The steps are:
– copy the ${MUSE_HOME}/use/ice/profiles/ICELoginModuleLDAP.xml file into the application which is to be configured, into the ${MUSE_HOME}/home/ApplicationID/profiles/ folder, where replace ApplicationID with the exact application ID you wish to configure with LDAP authentication.
– configure the necessary Muse login modules for the application. Below is their list in the correct order along with the correct flag values:
– ICELoginModuleXML – required;
– ICELoginModuleParametersRemap – required;
– ICELoginModuleLDAP – requisite.
The configuration of the login modules is done through the Muse Console for Applications Administration as follows: select the desired application from the list of applications and click on the left menu – “Login Modules”; from this location manage the login modules: add, delete or edit them. The ICELoginModuleParametersRemap login module must have the following attributes and values: ldapUserPwd=”wwwAuthPwd” ldapUserID=”wwwAuthID” .
– Configure the properties of the ICELoginModuleLDAP login module:
– in the MCAA console select the desired application from the list of applications and click on the left menu – “Login Modules” and in the “Login Modules” panel click on the “Edit” link from next to the ICELoginModuleLDAP entry;
– in the editor page change the value for the “config” field from the default "${ICE_HOME}/profiles/ICELoginModuleLDAP.xml" to
${MUSE_HOME}/home/ApplicationID/profiles/ICELoginModuleLDAP.xml
where replace ApplicationID with the exact application ID you wish to configure with LDAP authentication.
– click the “Update” button;
– click the “Edit Config File” and configure the elements specific to the LDAP server, such as LDAP-URL, BASE-DN…etc.
– Create a login page where the enduser will enter his/hers LDAP credentials to login into the application:
– create a backup copy of the ${MUSE_HOME}/web/www/logon/ApplicationID/index.html file, where replace ApplicationID with the exact application ID you wish to configure with LDAP authentication.
– edit the ${MUSE_HOME}/web/www/logon/ApplicationID/index.html file, locate the line:

and replace the content from below that line until the line

with







User Name:
Password:
 


where replace the 2 ApplicationID occurrences with the exact application ID you wish to configure with LDAP authentication and ApplicationPassword with the right password.
– the access URL for authenticating with LDAP credentials in this application is:
http://MUSE_SERVER:MUSE_PORT/muse/logon/ApplicationID/
where replace ApplicationID with the exact application ID you wish to configure with LDAP authentication

In Muse, there are 2 types of proxy chaining:

a) “ProxyChaining” happens when the MNM chains with the proxy used for source authentication. In a Muse application where we have configured a MNM_HOST to re-write the record links and a PROXY_HOST to use for authentication we have the following scenarios:

1) If the MNM and PROXY fields have different values then at runtime when the end user navigates on a rewritten link the following happens:
– enduser makes HTTP request to MNM_HOST
– the MNM_HOST makes the HTTP request to PROXY_HOST, thus chaining.
– the PROXY_HOST makes the HTTP request to the native data source.

This scenario is described in the Muse Advanced Configuration.pdf document, chapter “Data Services IP Authentication” and applies in all ASP Muse environments where IP authentications are used. For example, this type of proxy chaining is used in all our hosted Muse instances.

2) If the MNM is the same as the PROXY_HOST then the proxy chaining does not occur anymore.

Note that the proxy chaining feature works only if the com.edulib.muse.proxy.filter.ProxyChain filter is enabled in the $MUSE_HOME/proxy/MuseProxy.xml configuration file.
Also note that the proxy chaining feature works with other proxies than Muse Proxy used for source authentication, e,g, when PROXY_HOST is other proxy than Muse Proxy .

b) Another type of proxy chaining is when the Muse Proxy is configured to use another proxy, meaning that it will forward all HTTP requests to the configured proxy. This happens when the following fields from the "$MUSE_HOME/proxy/MuseProxy.xml" file are configured:

</PROXY_PORT>

Type a) of proxy chaining is the most encountered in the Muse installations.

Categories: General, Muse Proxy

Load More

Latest

To configure an application that uses username/password authentication method to use also IP authentication, one must do some configurations.

A) For Muse version 2500, the admin console can be used to add/edit the IP authentication of a Muse application:

– log into the MCAA console as a mcaa based user;

– select the desired Muse application, then click Login Modules;

– if the IP module is not enabled already, then click Add and then selectcom.edulib.ice.security.authentication.ICELoginModuleIP login module; click Add;

– click Edit to edit the ICELoginModuleIP module;

– click Edit User Access Rules and then Insert one by one the IP rules. They can consist in IP, IP classes or regular expressions that describe the needed range(s);

– click “Update”.

B) For Muse versions before 2500, the modifications to be done are:

$MUSE_HOME/use/ice/jaas.config – locate application’s entry in this file. If not found, then you must add an entry for it. Supposing the application’s ID is appid, then the following entry must be added:

appid {
com.edulib.ice.security.authentication.ICELoginModuleXML required passwords="${ICE_HOME}/profiles/passwords.xml";
com.edulib.ice.security.authentication.ICELoginModuleIP required hosts="${ICE_HOME}/profiles/hosts.xml";
};

Note: if the above entry already exists for the appid application, then only the bold line must be added.

$MUSE_HOME/use/ice/profiles/hosts – an entry like next must be added:

appid
IP or address template

Note: ‘IP or address template’ can be any of the following:
– a regular expression that will be matched against the IP address the connection is coming from. E.g. 217.156.14.* will match IP 217.156.14.2
– a regular expression that will be matched against the domain name of the IP address the connection is coming from. E.g. *.museglobal.ro.
– an address/mask notation that will be matched against the IP address the connection is coming from. The mask can be either a net-work mask or a plain number, specifying the number of 1’s at the left side of the network mask. Thus, a mask of 24 is equivalent to 255.255.255.0.
– E.g. 217.156.14.0/28 will match IP 217.156.14.2 and it is equivalent with 217.156.14.0/255.255.255.240
– E.g. 217.156.14.0/255.255.255.240 will match IP 217.156.14.2
As a consequence of IP authentication, one may want to facilitate IP access to the application without having the user to fill in every time the username/password fields. To do this, one can create a html page located in $MUSE_HOME/web/www/logon/appid/ directory. This page should contain a simple login form that submits itself on page load event. Eg:





The URL to access the autologon page is:

http://Muse_host:PORT/muse/logon/appid/autologon_page.html

where:

  • Muse_host is the hostname of the Muse system;
  • PORT is the port value on which Muse HTTP / Embedded Apache Tomcat server is configured to listen (default 8000);
  • appid is the application ID;
  • autologon_page.html is the page which contains the above HTML form.

Elsevier does not permit HTTP access to their resources through federated search products. For federated search Elsevier provides specialized APIs for which we have the following Source Packages: ScienceDirectRESTXML, ScienceDirectRESTXMLBooks, ScienceDirectRESTXMLJournals and ScopusRESTXML.
Arrangements with Elsevier for this access must be handled by you (the partner), or by your customer, following the steps below:

Install Procedure:

1. You (the partner) or your customer must contact the Elsevier E-Helpdesk (for APAC: sginfo@elsevier.com) and tell helpdesk that MuseGlobal federated search or API needs to be enabled.
2. Helpdesk will be able to find the customer’s account (based on C* numbers), API key based on name (MuseGlobal) and generate appropriate instTokens.
3. Confirm with the representative that they have enabled the MuseGlobal federated search or API (not a different federated search product).
4. After Elsevier staff has enabled access for the customer, they will report this back to the customer or to you, the vendor, and will disclose the appropriate instTokens to the customer.
5. Using the Muse Source Console, upload appropriate the ScopusRESTXML or the ScienceDirectRESTXML Source Packages, as covered by your subscription.
6. Configure the Source Package(s), making sure to fill the API_KEY, INST_TOKEN parameters from “Custom Parameters:” at bottom of the page with the two instTokens provided by Elsevier. Contact Muse Support if this is not the case.
7. Test the Source Package while in the Console.

Categories: Muse Search, Sources

The Client Sessions are used by the Muse Proxy Web Contexts which perform authentication in order to store the client authentication status to that Web Context, as well as other user metadata.

When a request comes to Muse Proxy (as a web server) without a Client Session cookie, a Client Session ID will be generated for it and sent back for storage in the browser in the form of a HTTP cookie. The name of the cookie is ‘MuseClientSessionID’. The Client Session cookie is returned to the Client only for the requests which require an authentication context. If a Client has performed only requests for free or public resources (e.g. static files: *.css, *.js, images etc), no Client Session cookie will be returned in the response.

Categories: Muse Proxy, Usage

Muse Proxy Authentication Token authenticates a rewritten request with an authentication token generated by Muse Proxy.

The authentication tokens are generated in the following cases:

A) when a rewritten link is generated using the ‘Utilities >> Rewrite URL’ section from the Muse Proxy Administrator Console and the ‘Muse Proxy Authentication Token’ option is selected. The authentication token generated is included as the ‘MuseProxyAuthenticationToken’ CGI GET parameter in the ‘Type 1’ rewritten link generated;

When ‘Type 1’ rewritten link request is performed, the value of the MuseProxyAuthenticationToken CGI parameter will be extracted and will be stored in the Navigation Session. If the Authentication Token is valid (it is not null or it is not expired) the request will be authenticated.
Otherwise, the entry associated with the user is searched in ${MUSE_HOME}/proxy/hosts.xml file. If the IP of the request is among the list of the ALLOW rules then the JAAS user group used for ‘Type 1’ rewritten links (by default ‘navigationManager’) is checked to match the GROUP entry associated with the user from ${MUSE_HOME}/proxy/hosts.xml file. If the group is matched then the authentication succeeds and the authentication process is finished;
If not, an authentication page will be returned to the client in order for him/her to enter the authentication details for UserName / Password authentication.

B) when a user logs in a Muse Proxy Application and clicks on a Muse Proxy Source link. The authentication token generated is included inside the Navigation Session associated with the ‘Type 2’ rewritten link generated;

When ‘Type 1’ rewritten link request is performed, the Authentication Token value will be extracted directly from the Navigation Session.
For example, when an user navigates on a source link from a Muse Proxy Application, a Navigation Session will be created dynamically in Muse Proxy. In that Navigation Session there is stored an authentication token to be used for the authentication. Next it is returned to the Client a redirect to a ‘Type 2’ rewritten URL which contains the id of the newly created Navigation Session as value for the MuseSessionID parameter from the path part of the URL. When the Client performs a request to this URL the MuseProxyApplicationSources filter extracts all the needed data from the Navigation Session and prepares the request to be handled by Muse Navigation Manager. The request is next authenticated using the authentication token mechanism and after the Muse Navigation Manager filters are applied the response is returned to the user.

C) when a request to 'http://${PROXY_HOST}:${PROXY_PORT}/ProxyInformation' is performed and only if the ‘com.edulib.muse.proxy.filter.MuseProxyAuthenticationToken’ filter is enabled. The value of the authentication token generated is included in the response of the 'http://${PROXY_HOST}:${PROXY_PORT}/ProxyInformation' request in the ‘AUTHENTICATION_TOKEN’ field.

The lifetime of an authentication token depends the value specified in the Authentication Token configuration file, which has the following full path: ${MUSE_HOME}/proxy/webcontexts/NavigationManager/profiles/filters/MuseProxyAuthenticationToken.xml. The Authentication Token configuration file contains only the authentication token timeout value. This value is present in the "AUTHENTICATION_TOKEN_TIMEOUT" field and it represents the timeout value, in milliseconds, after which an authentication token will be dumped.

Categories: Muse Proxy, Usage

In Muse, there are 2 types of proxy chaining:

a) “ProxyChaining” happens when the MNM chains with the proxy used for source authentication. In a Muse application where we have configured a MNM_HOST to re-write the record links and a PROXY_HOST to use for authentication we have the following scenarios:

1) If the MNM and PROXY fields have different values then at runtime when the end user navigates on a rewritten link the following happens:
– enduser makes HTTP request to MNM_HOST
– the MNM_HOST makes the HTTP request to PROXY_HOST, thus chaining.
– the PROXY_HOST makes the HTTP request to the native data source.

This scenario is described in the Muse Advanced Configuration.pdf document, chapter “Data Services IP Authentication” and applies in all ASP Muse environments where IP authentications are used. For example, this type of proxy chaining is used in all our hosted Muse instances.

2) If the MNM is the same as the PROXY_HOST then the proxy chaining does not occur anymore.

Note that the proxy chaining feature works only if the com.edulib.muse.proxy.filter.ProxyChain filter is enabled in the $MUSE_HOME/proxy/MuseProxy.xml configuration file.
Also note that the proxy chaining feature works with other proxies than Muse Proxy used for source authentication, e,g, when PROXY_HOST is other proxy than Muse Proxy .

b) Another type of proxy chaining is when the Muse Proxy is configured to use another proxy, meaning that it will forward all HTTP requests to the configured proxy. This happens when the following fields from the "$MUSE_HOME/proxy/MuseProxy.xml" file are configured:

</PROXY_PORT>

Type a) of proxy chaining is the most encountered in the Muse installations.

Categories: General, Muse Proxy

Load More