MuseKnowledge™ Proxy 5.5 is Available

The MuseKnowledge team is proud to announce the availability of MuseKnowledge™ Proxy version 5.5, coming after a period of prolific development of new and exciting features.

The most significant addition is the support for the Learning Tools Interoperability® (LTI®), version 1.3 standard. New features were implemented for the end-user interface template like a Tools section with useful action forms for URL encoding and prefixing, necessary for crafting entry point URLs and unrewriting an already rewritten Muse Proxy URL.

The Muse Proxy Administrator Console received new features and enhancements as well, the most important ones being the authentication using 2FA (TOTP - time based one time password) for the administrator user and a global search functionality in all Muse Proxy Applications for a resource.
New security related features were introduced, like being able to specify the list of disabled SSL ciphers to keep the pace with the security requirements for the Muse Proxy front-end service and still be able to use some weak algorithms to communicate with vendors in the back-end.

Many useful features were introduced for the rewriting engine too. For example, new configuration elements are available like MIME_MAPPING, to solve cases where the provided content type is unknown to Muse Proxy and would not be interpreted. The performance was improved in the case of CSS content processing and the pattern matching can now use the more efficient regular expressions API from the JDK, from stack and processor point of view.

The new MuseKnowledge™ Proxy version is available for trial, purchase or upgrade. We recommend all our partners and customers to upgrade to this latest release.

The detailed list of changes is available in the MuseKnowledge™ Proxy Release Notes PDF Document, some items are provided below.

  • The Learning Tools Interoperability® (LTI®), version 1.3 standard can now be used to include a MuseKnowledge Proxy Application or proxified source directly within the Learning Management System (LMS) platform as a Tool in a new window. LTI version 1.3 improves upon older versions by moving away from the use of OAuth 1.0a-style signing for authentication and towards a new security model, using OpenID Connect, signed JWTs, and OAuth2.0 workflows for authentication. LTI 1.3 still acts as a half way SSO, in the sense that starting from the platform (LMS system) the access to the MuseKnowledge Proxy Application is seamlessly. The LTI 1.3 standard does not allow for callbacks URLs so accessing directly the same MuseKnowledge Proxy Application as standalone requires a distinct authentication group defined with a distinct authentication method. Hence, once a user is authenticated to the platform (LMS) (s)he can access a MuseKnowledge Proxy application or source being defined as a Tool.
    Because the new version comes with extra security and this also implies a greater complexity for configuration than previous LTI versions, extensive instructions are given in Muse Proxy Administrator console, in the new page Configuration / LTI 1.3 Authentication.
  • In Muse Proxy Administrator Console, Manage Applications section one can now search for a source in all the applications and perform modifications to it. The fields to query can be chosen from Source ID, Source Name and Source Description or a mix of them. The comparison type can be selected as Exact match / Contains / Wildcard.
    Another extension in the console is that Quick Filter for Applications screen and for Application/Sources screen can now be applied selectively on ID and Name, because some-times searching just through the IDs is more helpful.
  • The front-end MKPF application interface features a new Tools section where "URL Encode and Prefix" and "Un-Rewrite URL and Prefix" are possible. The prefix bit refers to creating an URL as an entry point to Muse Proxy, for the current application either from a normal vendor link, or back from an URL that results in the process of navigating a certain proxy source (Rewrite by Host or Rewrite by Path), and which should, actually, never be bookmarked or advertised as such.
  • Authentication using 2FA (TOTP - time based one time password) for the administrator user is available. This is working with 2FA Time base OTP applications such as Google Authenticator, Authy, TOTP Authenticator. Follow the instruction from Muse Proxy Administrator Console, for the admin users (use the new key icon in the users table). Note that Muse Administrator accounts are also required to be IP authenticated as well, so what is achieved now by TOTP is actually a 3FA.
  • Implemented post-authentication logic for the HMAC login module via SCRIPT section similar to what is available for SAML and LDAP cases.
  • To have a finer-grained control (when the global redirect setting is off) ENFORCE_HTTPS is now available to be set selectively for Root, Administrator and Public web modules in their corresponding web.xml files.
  • Custom HTTP headers defined in the WebContexts.xml file can now be reloaded without a full proxy restart. This can be done via Muse Proxy Admin using the Refresh Custom HTTP Headers button within the page Advanced/Operations.
  • Also, related to Custom Http Headers, the WebModuleSAML in Root/web.xml is now having two new boolean parameters, DISABLE_CUSTOM_HEADERS_RELAY and DISABLE_CUSTOM_HEADERS_LOCAL in order to avoid passing the custom headers for resources relayed from the ssoRWP* servlets as well as potential error pages generated by Muse Proxy when accessing these servlets. These will allow, for example, for security headers to be set for Root context, but not inferred for the LTI authentication responses steps.
  • Reloading non-application Web Contexts configurations is now possible without an entire server restart by using the Refresh Non-Application Web Contexts button within the page Advanced/Operations from Muse Proxy Administrator Console.
  • Pattern matching is now achieved, by default, through the new flag
    <JDK_REGEX>true</JDK_REGEX> in MuseProxy.xml, based on the regular expression API from JDK, which is more efficient in the usage of the stack and processor than the legacy ones.
  • A new source configuration element, MIME_MAPPING will solve cases where the provided content type is unknown to Muse Proxy and would not be interpreted, or when it is wrongly advertised or even missing and we need to direct the rewriting engine to interpret it differently. The structure of the configuration in the source profile is given below:
    <MIME_MAPPING from="Content-Type header value from Reply (can be empty for cases when there is no Content-Type)" to="a defined category" patterns="Optional - URL Patterns for this source for when this mapping is applied.">
  • A new boolean flag, KEEP_HEADER_ORDER, for global and individual source configuration is available. If the flag is true for a certain source best efforts are made to keep the request headers order when relaying as a rewriting proxy. Normally, according to the HTTP RFC, the order of distinct header fields shouldn't matter but request fingerprinting started to be used more often for security reasons on vendors side. If using a reverse proxy/load balancer it should as well preserve the order, otherwise the effects will not be achieved.
  • A new global option, SSL_DISABLED_CIPHERS, is available. Its purpose is for Muse Proxy instances facing directly the internet to score grade A (hence this is not needed for SSL Termination scenarios) and at the same time use weak ciphers against vendors still requiring weak ciphers. This was needed because JVM jre/lib/java.security does not differentiate between server and client disabled ciphers, and for the other end, client, Muse Proxy should still be able to use some weak algorithms to communicate with vendors not keeping the pace with the security requirements.
  • There are reverse proxies / load balancers that cannot remove the existent X-Forwarded-For headers from the request. They just add one, or one value to it in the end. In order to make sure the correct value for client IP is detected in such cases the processor mode attribute for XForwarded-For field can now be specified. It defaults to "right". It tells what will the client address be in case there are more IPs separated by ',' (in case there are more X-Forwarded-For fields they are equivalent to a comma separated list, so "right" will assume the last one).
  • TRUST_X_FORWARDED_PROTO is set to false in MuseProxy.xml. If a load balancer/reverse proxy is used and this is not using the HAProxy PROXY Protocol then set it to true.
  • SAML Discovery for IDP Selection was extended in order to add support to specify friendly names for the configured IDP's, as well as, leaving room for setting other properties. If, in securityContext-metadata.xml you configured the <bean id="aliases" class="java.util.HashMap"> for Local Discovery (this was provided in an XML comment section), for this new version the bean structure must be updated according to the newest securityContext-metadata.xml from a fresh install - the structure is between the comments <!--START_LOCAL_DISCOVERY --> and <!-- END_LOCAL_DISCOVERY -->. This includes referencing beans for IDPs where more properties entries, such as friendly Name are specified.
  • HTTP headers to avoid browser caching were added for more Muse Proxy responses cor responding to non-static resources, such as the action=sources response for the application interface.
  • Added the requested URL scheme information in the Debug log (on NOTICE level) on the line "Received request for" as [scheme=https] or [scheme=http]. It is useful to have it especially as browsers are discontinuing plain http:// (step by step) and now in FireFox one cannot mix https:// with http:// due to cookie visibility.
  • Login Modules are also logging the application.id besides the connection.id in the same log line in the Debug log. This is helpful to identify login failures for a certain application in a multi-tenant environment without using a stateful parser.
  • The MKPF template contains a workaround for SAML/SSO authenticated proxy to have proxified links/sources or just the application interface included in IFrame, if the IFrames implementation is mandatory required (assuming third-party cookies are enabled). IFrame is not recommended for in tegrations because of the browser security enforced and even vendor protection for this. IDPs are usually denying frame inclusion, and, in case multiple proxified iframes are in the same page, concurrent authentication to SAML/SSO can result in errors because the HTTP session needs to be created by a single flow.
  • Parameters from the source profile are now resolved in the value attribute in the HEADER rules in the Replacer FILTER via ${PARAM_NAME} style. The source parameters can also be bound to SCRIPT for HEADER rule if SCRIPT's attribute useParameters="true" is present - they can be accessed as the parameters map - access them only as read only to read parameters values. Also, logUserID is now bound to the HEADER SCRIPT in order to process it.
  • The processing of CSS content type was optimized offering better CPU times, especially for large CSS.

Since the beginning of the COVID-19 global crisis, the MuseKnowledge™ Proxy Trial periods are extended from 30 days to 90 days. Request your Trial License Key by simply filling in the trial form.

You are receiving this email because you are in a contractual relation with MuseGlobal, the developers and maintainers of MuseKnowledge™ Proxy. If you do not want to receive such notifications anymore, please reply to this email with your request and we won't send you emails anymore.