Muse Proxy FAQ
Muse Proxy
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.
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 Hmac
SHA1).
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.
Load More
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:
Type a) of proxy chaining is the most encountered in the Muse installations.
For authenticating the end-users into a Muse Proxy Application the following authentication modules are available:
–ProxyLoginModuleUserPassword.
Performs User Name/Password authentication.
–ProxyLoginModuleIP.
Performs IP authentication based on client machine IP.
–ProxyLoginModuleLDAP.
Performs authentication against a LDAP Server.
–ProxyLoginModuleFTP.
Performs authentication against a FTP Server. The FTP authentication module supports NONE, SSL or TLS connection encryptions.
– ProxyLoginModuleIMAP. Performs authentication against a IMAP Server. The IMAP authentication module supports NONE, SSL or TLS connection encryptions.
–ProxyLoginModuleSQL.
Performs authentication against an SQL Server through Java Database Connectivity (JDBC). The SQL authentication module supports NONE, SSL or TLS connection encryptions.
–ProxyLoginModuleReferer.
Performs authentication against the client’s referer URL.
You can read more about the authentication in a Muse Proxy Application in the “Muse Proxy.pdf” manual, chapter “Authentication of a Muse Proxy Application”.
The PERSISTENT-URL
(sometimes also called durable URLs or durable links) is a url to a detailed native record and it is specifically not rewritten by Muse Navigation Manager. The PERSISTENT-URL
link was created as an URL for which the users will use their own authentication to access the native data. The PERSISTENT-URL
was specifically designed to not be tied to a search session and to provide a persistent link outside of Muse applications. They are not intended to take the place of a normal URL link in Muse records.
It is normal to be prompted to enter access details after following the PERSISTENT-URL
to get to the record page. If the end-user is IP-authenticated to an account containing the required database, then the record page will appear without entering additional credentials.
In conclusion:
– use the regular DATA/URL
to access the native data directly without having to enter user/password details
– use the DATA/PERSISTENT-URL
when you want to provide your users an URL for which they should use their individual access details and only after that they will be able to go to that native record.