Enterprise Content Management

Armedia Blog

A tale of Alfresco Share with CSRF and bad information

May 2nd, 2016 by Susan Ladwig

Background
Our company is currently engaged in a series of projects that require us to secure and harden our solutions based on requirements put forth by various organizational and recognized standards ranging from the Department Of Defense (DOD) Secure Technical Implementation Guides (STIGs), National Institute of Standards and Technology (NIST) publication 800-53, FedRAMP Security Assessment Framework (SAF), Health Information Technology for Economic and Clinical Health Act (HITECH), and the Open Web Application Security Project (OWASP) Community Top 10 Best Security Practices.

The Problem
We want to secure our ArkCase offerings for FedRAMP, a DOD implementation, and for a healthcare client; Alfresco is one of the components in the overall solution.

We set about implementing Alfresco with Cross-Site Request Forgery filtering (CSRF) enabled – bye, bye to the days of modifying a few lines in the share-custom-config.xml to disable CSRF, especially when you have a proxy in front of Alfresco.

The Approach
We followed the instructions posted on the Alfresco documentation site (http://docs.alfresco.com/5.1/concepts/csfr-policy.html) since we have a proxy on another server and wish to consume Alfresco only through the proxy.

The Configuration
For our configuration, we have Apache on arkcasedir2.armediatest.net (accessible using https://arkcasedir2.armediatest.net), Alfresco on arkcasedev1.armediatest.net (directly accessible using https://arkcasedev1.armediatest.net:18443/share). The proxy configuration for Alfresco forwards requests coming on https://arkcasedir2.armediatest.net/alfresco to https://arkcasedev1.armediatest.net:18443/alfresco through the use of Apache’s SSLProxyEngine that enables forwarding of requests to an internal server accessible using https. A corresponding configuration is in place for Share.

Applying the Instructions
Following the instructions, we added the following rule as the first for the filter:

POST
/page/trusted/call/1|/page/trusted/call/2

false
https://arkcasedir2.armediatest.net/.*

false
https://arkcasedir2.armediatest.net

Testing the CSRF Filter
We restarted Alfresco, tried accessing Share through https://arkcasedir2.armediatest.net/share, and upon entering login credentials, saw the following in the Tomcat log:
2016-04-28 03:39:52,605 INFO [web.site.EditionInterceptor] [http-bio-18443-exec-3] Successfully retrieved license information from Alfresco.
2016-04-28 03:40:04,891 INFO [site.servlet.CSRFFilter] [http-bio-18443-exec-4] Possible CSRF attack noted when asserting referer header ‘https://arkcasedir2.armediatest.net/share/page/’. Request: POST /share/page/dologin
Apr 28, 2016 3:40:04 AM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet [Spring Surf Dispatcher Servlet] in context with path [/share] threw exception [Possible CSRF attack noted when asserting referer header ‘https://arkcasedir2.armediatest.net/share/page/’. Request: POST /share/page/dologin, FAILED TEST: Assert referer POST /share/page/dologin :: referer: ‘https://arkcasedir2.armediatest.net/share/page/’ vs server & context: https://arkcasedev1.armediatest.net:18443/ (string) or (regexp)] with root cause
javax.servlet.ServletException: Possible CSRF attack noted when asserting referer header ‘https://arkcasedir2.armediatest.net/share/page/’. Request: POST /share/page/dologin, FAILED TEST: Assert referer POST /share/page/dologin :: referer: ‘https://arkcasedir2.armediatest.net/share/page/’ vs server & context: https://arkcasedev1.armediatest.net:18443/ (string) or (regexp)
at org.alfresco.web.site.servlet.CSRFFilter$AssertRefererAction.run(CSRFFilter.java:1017)
at org.alfresco.web.site.servlet.CSRFFilter.doFilter(CSRFFilter.java:312)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.alfresco.web.site.servlet.SSOAuthenticationFilter.doFilter(SSOAuthenticationFilter.java:447)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.alfresco.web.site.servlet.MTAuthenticationFilter.doFilter(MTAuthenticationFilter.java:74)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:504)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:421)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1074)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:314)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)

2016-04-28 03:40:05,255 ERROR [alfresco.web.site] [http-bio-18443-exec-4] javax.servlet.ServletException: Possible CSRF attack noted when asserting referer header ‘https://arkcasedir2.armediatest.net/share/page/’. Request: POST /share/page/dologin, FAILED TEST: Assert referer POST /share/page/dologin :: referer: ‘https://arkcasedir2.armediatest.net/share/page/’ vs server & context: https://arkcasedev1.armediatest.net:18443/ (string) or (regexp)

We double checked the instructions, looked online at a few resources, and didn’t find anything that helped us fix the issue.
The Resolution
Eventually, we started reading through the CSRFPolicy configuration that we pasted into share-config-custom.xml and noted that the values assigned for referrer and origin were empty:
Alfresco-CSRFToken

We added the referrer and origin values in there; https://arkcasedir2.armediatest.net/.*and https://arkcasedir2.armediatest.net respectively, and restarted Alfresco.

Once the Tomcat log indicated that Alfresco had completed a successful startup, we tried accessing Share through https://arkcasedir2.armediatest.net/share, and upon entering login credentials everything worked as expected…

Since then, we commented out the rule that we added per the instructions, and it works fine – no CSRF errors when logging into Share and using it.

The irony with this effort is that we saw nothing online that suggested this fix approach and had instructions for this effort.

We have included the share-custom-config.xml below for your amusement.

Next task in our list will be to add an Iframe policy; we’ll see how that goes.

Hopefully, this article will help those of you implementing a CSRF filter save you time, effort, and frustration.


<?xml version="1.0"?>

-<alfresco-config>

<!-- Global config section -->



-<config replace="true">


-<flags>

<!-- Developer debugging setting to turn on DEBUG mode for client scripts in the browser -->


<client-debug>false</client-debug>

<!-- LOGGING can always be toggled at runtime when in DEBUG mode (Ctrl, Ctrl, Shift, Shift). This flag automatically activates logging on page load. -->


<client-debug-autologging>false</client-debug-autologging>

</flags>

</config>


-<config condition="WebFramework" evaluator="string-compare">


-<web-framework>

<!-- SpringSurf Autowire Runtime Settings -->


<!-- Developers can set mode to 'development' to disable; SpringSurf caches, FreeMarker template caching and Rhino JavaScript compilation. -->



-<autowire>

<!-- Pick the mode: "production" or "development" -->


<mode>production</mode>

</autowire>

<!-- Allows extension modules with <auto-deploy> set to true to be automatically deployed -->



-<module-deployment>

<mode>manual</mode>

<enable-auto-deploy-modules>true</enable-auto-deploy-modules>

</module-deployment>

</web-framework>

</config>

<!-- Disable the CSRF Token Filter -->


<!-- <config evaluator="string-compare" condition="CSRFPolicy" replace="true"> <filter/> </config> -->


<!-- To run the CSRF Token Filter behind 1 or more proxies that do not rewrite the Origin or Referere headers: 1. Copy the "CSRFPolicy" default config in share-security-config.xml and paste it into this file. 2. Replace the old config by setting the <config> element's "replace" attribute to "true" like below: <config evaluator="string-compare" condition="CSRFPolicy" replace="true"> 3. To every <action name="assertReferer"> element add the following child element <param name="referer">http://www.proxy1.com/.*|http://www.proxy2.com/.*</param> 4. To every <action name="assertOrigin"> element add the following child element <param name="origin">http://www.proxy1.com|http://www.proxy2.com</param> -->



-<config replace="true" condition="CSRFPolicy" evaluator="string-compare">

<!-- Properties that may be used inside the rest of the CSRFPolicy config to avoid repetition but also making it possible to provide different values in different environments. I.e. Different "Referer" & "Origin" properties for test & production etc. Reference a property using "{propertyName}". -->



-<properties>

<!-- There is normally no need to override this property -->


<token>Alfresco-CSRFToken</token>

<!-- Override and set this property with a regexp that if you have placed Share behind a proxy that does not rewrite the Referer header. -->


<referer>https://arkcasedir2.armediatest.net/.*</referer>

<!-- Override and set this property with a regexp that if you have placed Share behind a proxy that does not rewrite the Origin header. -->


<origin>https://arkcasedir2.armediatest.net</origin>

</properties>

<!-- Will be used and exposed to the client side code in Alfresco.contants.CSRF_POLICY. Use the Alfresco.util.CSRFPolicy.getHeader() or Alfresco.util.CSRFPolicy.getParameter() with Alfresco.util.CSRFPolicy.getToken() to set the token in custom 3rd party code. -->



-<client>

<cookie>{token}</cookie>

<header>{token}</header>

<parameter>{token}</parameter>

</client>

<!-- The first rule with a matching request will get its action invoked, the remaining rules will be ignored. -->



-<filter>

<!-- Certain webscripts shall not be allowed to be accessed directly form the browser. Make sure to throw an error if they are used. -->


<!-- JS: commented out since it's not needed anymore <rule> <request> <method>POST</method> <path>/page/trusted/call/1|/page/trusted/call/2</path> </request> <action name="assertReferer"> <param name="always">false</param> <param name="referer">https://arkcasedir2.armediatest.net/.*</param> </action> <action name="assertOrigin"> <param name="always">false</param> <param name="origin">https://arkcasedir2.armediatest.net</param> </action> </rule> END: JS: commented out since it's not needed anymore -->



-<rule>


-<request>

<path>/proxy/alfresco/remoteadm/.*</path>

</request>


-<action name="throwError">

<param name="message">It is not allowed to access this url from your browser</param>

</action>

</rule>

<!-- Certain Repo webscripts should be allowed to pass without a token since they have no Share knowledge. TODO: Refactor the publishing code so that form that is posted to this URL is a Share webscript with the right tokens. -->



-<rule>


-<request>

<method>POST</method>

<path>/proxy/alfresco/api/publishing/channels/.+</path>

</request>


-<action name="assertReferer">

<param name="referer">{referer}</param>

</action>


-<action name="assertOrigin">

<param name="origin">{origin}</param>

</action>

</rule>

<!-- Certain Surf POST requests from the WebScript console must be allowed to pass without a token since the Surf WebScript console code can't be dependent on a Share specific filter. -->



-<rule>


-<request>

<method>POST</method>

<path>/page/caches/dependency/clear|/page/index|/page/surfBugStatus|/page/modules/deploy|/page/modules/module|/page/api/javascript/debugger|/page/console</path>

</request>


-<action name="assertReferer">

<param name="referer">{referer}</param>

</action>


-<action name="assertOrigin">

<param name="origin">{origin}</param>

</action>

</rule>

<!-- Certain Share POST requests does NOT require a token -->



-<rule>


-<request>

<method>POST</method>

<path>/page/dologin(\?.+)?|/page/site/[^/]+/start-workflow|/page/start-workflow|/page/context/[^/]+/start-workflow</path>

</request>


-<action name="assertReferer">

<param name="referer">{referer}</param>

</action>


-<action name="assertOrigin">

<param name="origin">{origin}</param>

</action>

</rule>

<!-- Assert logout is done from a valid domain, if so clear the token when logging out -->



-<rule>


-<request>

<method>POST</method>

<path>/page/dologout(\?.+)?</path>

</request>


-<action name="assertReferer">

<param name="referer">{referer}</param>

</action>


-<action name="assertOrigin">

<param name="origin">{origin}</param>

</action>


-<action name="clearToken">

<param name="session">{token}</param>

<param name="cookie">{token}</param>

</action>

</rule>

<!-- Make sure the first token is generated -->



-<rule>


-<request>


-<session>

<attribute name="_alf_USER_ID">.+</attribute>

<attribute name="{token}"/>

<!-- empty attribute element indicates null, meaning the token has not yet been set -->


</session>

</request>


-<action name="generateToken">

<param name="session">{token}</param>

<param name="cookie">{token}</param>

</action>

</rule>

<!-- Refresh token on new "page" visit when a user is logged in -->



-<rule>


-<request>

<method>GET</method>

<path>/page/.*</path>


-<session>

<attribute name="_alf_USER_ID">.+</attribute>

<attribute name="{token}">.+</attribute>

</session>

</request>


-<action name="generateToken">

<param name="session">{token}</param>

<param name="cookie">{token}</param>

</action>

</rule>

<!-- Verify multipart requests from logged in users contain the token as a parameter and also correct referer & origin header if available -->



-<rule>


-<request>

<method>POST</method>

<header name="Content-Type">multipart/.+</header>


-<session>

<attribute name="_alf_USER_ID">.+</attribute>

</session>

</request>


-<action name="assertToken">

<param name="session">{token}</param>

<param name="parameter">{token}</param>

</action>


-<action name="assertReferer">

<param name="referer">{referer}</param>

</action>


-<action name="assertOrigin">

<param name="origin">{origin}</param>

</action>

</rule>

<!-- Verify that all remaining state changing requests from logged in users' requests contains a token in the header and correct referer & origin headers if available. We "catch" all content types since just setting it to "application/json.*" since a webscript that doesn't require a json request body otherwise would be successfully executed using i.e."text/plain". -->



-<rule>


-<request>

<method>POST|PUT|DELETE</method>


-<session>

<attribute name="_alf_USER_ID">.+</attribute>

</session>

</request>


-<action name="assertToken">

<param name="session">{token}</param>

<param name="header">{token}</param>

</action>


-<action name="assertReferer">

<param name="referer">{referer}</param>

</action>


-<action name="assertOrigin">

<param name="origin">{origin}</param>

</action>

</rule>

</filter>

</config>

<!-- Remove the default wildcard setting and use instead a strict whitelist of the only domains that shall be allowed to be used inside iframes (i.e. in the WebView dashlet on the dashboards) -->


<!-- <config evaluator="string-compare" condition="IFramePolicy" replace="true"> <cross-domain> <url>http://www.trusted-domain-1.com/</url> <url>http://www.trusted-domain-2.com/</url> </cross-domain> </config> -->


<!-- Turn off header that stops Share from being displayed in iframes on pages from other domains -->


<!-- <config evaluator="string-compare" condition="SecurityHeadersPolicy"> <headers> <header> <name>X-Frame-Options</name> <enabled>false</enabled> </header> </headers> </config> -->


<!-- Prevent browser communication over HTTP (for HTTPS servers) -->


<!-- <config evaluator="string-compare" condition="SecurityHeadersPolicy"> <headers> <header> <name>Strict-Transport-Security</name> <value>max-age=31536000</value> </header> </headers> </config> -->



-<config condition="Replication" evaluator="string-compare">


-<share-urls>

<!-- To discover a Repository Id, browse to the remote server's CMIS landing page at: http://{server}:{port}/alfresco/service/cmis/index.html The Repository Id field is found under the "CMIS Repository Information" expandable panel. Example config entry: <share-url repositoryId="622f9533-2a1e-48fe-af4e-ee9e41667ea4">http://new-york-office:8080/share/</share-url> -->


</share-urls>

</config>

<!-- Document Library config section -->



-<config replace="true" condition="DocumentLibrary" evaluator="string-compare">


-<tree>

<!-- Whether the folder Tree component should enumerate child folders or not. This is a relatively expensive operation, so should be set to "false" for Repositories with broad folder structures. -->


<evaluate-child-folders>false</evaluate-child-folders>

<!-- Optionally limit the number of folders shown in treeview throughout Share. -->


<maximum-folder-count>1000</maximum-folder-count>

<!-- Default timeout in milliseconds for folder Tree component to recieve response from Repository -->


<timeout>7000</timeout>

</tree>

<!-- Used by the "Manage Aspects" action For custom aspects, remember to also add the relevant i18n string(s) cm_myaspect=My Aspect -->



-<aspects>

<!-- Aspects that a user can see -->



-<visible>

<aspect name="cm:generalclassifiable"/>

<aspect name="cm:complianceable"/>

<aspect name="cm:dublincore"/>

<aspect name="cm:effectivity"/>

<aspect name="cm:summarizable"/>

<aspect name="cm:versionable"/>

<aspect name="cm:templatable"/>

<aspect name="cm:emailed"/>

<aspect name="emailserver:aliasable"/>

<aspect name="cm:taggable"/>

<aspect name="app:inlineeditable"/>

<aspect name="cm:geographic"/>

<aspect name="exif:exif"/>

<aspect name="audio:audio"/>

<aspect name="cm:indexControl"/>

<aspect name="dp:restrictable"/>

<aspect name="smf:customConfigSmartFolder"/>

<aspect name="smf:systemConfigSmartFolder"/>

</visible>

<!-- Aspects that a user can add. Same as "visible" if left empty -->


<addable> </addable>

<!-- Aspects that a user can remove. Same as "visible" if left empty -->


<removeable> </removeable>

</aspects>

<!-- Used by the "Change Type" action Define valid subtypes using the following example: <type name="cm:content"> <subtype name="cm:mysubtype" /> </type> Remember to also add the relevant i18n string(s): cm_mysubtype=My SubType -->



-<types>


-<type name="cm:content">

<subtype name="smf:smartFolderTemplate"/>

</type>

<type name="cm:folder"> </type>


-<type name="trx:transferTarget">

<subtype name="trx:fileTransferTarget"/>

</type>

</types>

<!-- If set, will present a WebDAV link for the current item on the Document and Folder details pages. Also used to generate the "View in Alfresco Explorer" action for folders. -->


<repository-url>https://arkcasedir2.armediatest.net/alfresco</repository-url>

<!-- Google Docs™ integration -->



-<google-docs>

<!-- Enable/disable the Google Docs UI integration (Extra types on Create Content menu, Google Docs actions). -->


<enabled>false</enabled>

<!-- The mimetypes of documents Google Docs allows you to create via the Share interface. The I18N label is created from the "type" attribute, e.g. google-docs.doc=Google Docs™ Document -->



-<creatable-types>

<creatable type="doc">application/vnd.openxmlformats-officedocument.wordprocessingml.document</creatable>

<creatable type="xls">application/vnd.openxmlformats-officedocument.spreadsheetml.sheet</creatable>

<creatable type="ppt">application/vnd.ms-powerpoint</creatable>

</creatable-types>

</google-docs>

<!-- File upload configuration -->



-<file-upload>

<!-- Adobe Flash™ In certain environments, an HTTP request originating from Flash cannot be authenticated using an existing session. See: http://bugs.adobe.com/jira/browse/FP-4830 For these cases, it is useful to disable the Flash-based uploader for Share Document Libraries. -->


<adobe-flash-enabled>true</adobe-flash-enabled>

</file-upload>

</config>

<!-- Custom DocLibActions config section -->



-<config condition="DocLibActions" evaluator="string-compare">


-<actionGroups>


-<actionGroup id="document-browse">

<!-- Simple Repo Actions -->


<!-- <action index="340" id="document-extract-metadata" /> <action index="350" id="document-increment-counter" /> -->


<!-- Dialog Repo Actions -->


<!-- <action index="360" id="document-transform" /> <action index="370" id="document-transform-image" /> <action index="380" id="document-execute-script" /> -->


</actionGroup>

</actionGroups>

</config>

<!-- Global folder picker config section -->



-<config condition="GlobalFolder" evaluator="string-compare">


-<siteTree>


-<container type="cm:folder">

<!-- Use a specific label for this container type in the tree -->


<rootLabel>location.path.documents</rootLabel>

<!-- Use a specific uri to retreive the child nodes for this container type in the tree -->


<uri>slingshot/doclib/treenode/site/{site}/{container}{path}?children={evaluateChildFoldersSite}&max={maximumFolderCountSite}</uri>

</container>

</siteTree>

</config>

<!-- Repository Library config section -->



-<config replace="true" condition="RepositoryLibrary" evaluator="string-compare">

<!-- Root nodeRef or xpath expression for top-level folder. e.g. alfresco://user/home, /app:company_home/st:sites/cm:site1 If using an xpath expression, ensure it is properly ISO9075 encoded here. -->


<root-node>alfresco://company/home</root-node>


-<tree>

<!-- Whether the folder Tree component should enumerate child folders or not. This is a relatively expensive operation, so should be set to "false" for Repositories with broad folder structures. -->


<evaluate-child-folders>false</evaluate-child-folders>

<!-- Optionally limit the number of folders shown in treeview throughout Share. -->


<maximum-folder-count>500</maximum-folder-count>

</tree>

<!-- Whether the link to the Repository Library appears in the header component or not. -->


<visible>true</visible>

</config>

<!-- Kerberos settings -->


<!-- To enable kerberos rename this condition to "Kerberos" -->



-<config replace="true" condition="KerberosDisabled" evaluator="string-compare">


-<kerberos>

<!-- Password for HTTP service account. The account name *must* be built from the HTTP server name, in the format : HTTP/<server_name>@<realm> (NB this is because the web browser requests an ST for the HTTP/<server_name> principal in the current realm, so if we're to decode that ST, it has to match.) -->


<password>secret</password>

<!-- Kerberos realm and KDC address. -->


<realm>ALFRESCO.ORG</realm>

<!-- Service Principal Name to use on the repository tier. This must be like: HTTP/host.name@REALM -->


<endpoint-spn>HTTP/repository.server.com@ALFRESCO.ORG</endpoint-spn>

<!-- JAAS login configuration entry name. -->


<config-entry>ShareHTTP</config-entry>

<!-- A Boolean which when true strips the @domain sufix from Kerberos authenticated usernames. Use together with stripUsernameSuffix property in alfresco-global.properties file. -->


<stripUserNameSuffix>true</stripUserNameSuffix>

</kerberos>

</config>

<!-- Uncomment and modify the URL to Activiti Admin Console if required. -->


<!-- <config evaluator="string-compare" condition="ActivitiAdmin" replace="true"> <activiti-admin-url>https://arkcasedev1.armediatest.net:18443/alfresco/activiti-admin</activiti-admin-url> </config> -->



-<config condition="Remote" evaluator="string-compare">


-<remote>


-<endpoint>

<id>alfresco-noauth</id>

<name>Alfresco - unauthenticated access</name>

<description>Access to Alfresco Repository WebScripts that do not require authentication</description>

<connector-id>alfresco</connector-id>

<endpoint-url>https://arkcasedev1.armediatest.net:18443/alfresco/s</endpoint-url>

<identity>none</identity>

</endpoint>


-<endpoint>

<id>alfresco</id>

<name>Alfresco - user access</name>

<description>Access to Alfresco Repository WebScripts that require user authentication</description>

<connector-id>alfresco</connector-id>

<endpoint-url>https://arkcasedev1.armediatest.net:18443/alfresco/s</endpoint-url>

<identity>user</identity>

</endpoint>


-<endpoint>

<id>alfresco-feed</id>

<name>Alfresco Feed</name>

<description>Alfresco Feed - supports basic HTTP authentication via the EndPointProxyServlet</description>

<connector-id>http</connector-id>

<endpoint-url>https://arkcasedev1.armediatest.net:18443/alfresco/s</endpoint-url>

<basic-auth>true</basic-auth>

<identity>user</identity>

</endpoint>


-<endpoint>

<id>alfresco-api</id>

<parent-id>alfresco</parent-id>

<name>Alfresco Public API - user access</name>

<description>Access to Alfresco Repository Public API that require user authentication. This makes use of the authentication that is provided by parent 'alfresco' endpoint.</description>

<connector-id>alfresco</connector-id>

<endpoint-url>https://arkcasedev1.armediatest.net:18443/alfresco/api</endpoint-url>

<identity>user</identity>

</endpoint>

</remote>

</config>

<!-- Overriding endpoints to reference an Alfresco server with external SSO enabled NOTE: If utilising a load balancer between web-tier and repository cluster, the "sticky sessions" feature of your load balancer must be used. NOTE: If alfresco server location is not localhost:8080 then also combine changes from the "example port config" section below. *Optional* ssl-config contains: keystore for managing client key and certificate. truststore for managing trusted CAs. Used to authenticate share to an external SSO system such as CAS or to make share talk to SSL layers that require client certificates. Remove the ssl-config section if not required i.e. for NTLM. NOTE: For Kerberos SSO rename the "KerberosDisabled" condition above to "Kerberos" NOTE: For external SSO, switch the endpoint connector to "alfrescoHeader" and set the userHeader value to the name of the HTTP header that the external SSO uses to provide the authenticated user name. NOTE: For external SSO, Share now supports the "userIdPattern" mechanism as is available on the repository config for External Authentication sub-system. Add the following element to your "alfrescoHeader" connector config: <userIdPattern>^ignore-(\w+)-ignore</userIdPattern> This is an example, ensure the Id pattern matches your repository config. NOTE: For external SSO, Share now supports stateless (no Http Session or sticky session) connection to the repository when using the alfrescoHeader remote user connector. e.g. You can change endpoint config to use the faster /service URL instead of the /wcs URL if you are using External Authentication and then remove sticky session config from your proxy between Share and Alfresco. Note that this is also faster because Share will no longer call the /touch REST API before every remote call to the repository. -->


<!-- Security warning -->


<!-- For production environment set verify-hostname to true.-->


<!-- <config evaluator="string-compare" condition="Remote"> <remote> <ssl-config> <keystore-path>alfresco/web-extension/alfresco-system.p12</keystore-path> <keystore-type>pkcs12</keystore-type> <keystore-password>alfresco-system</keystore-password> <truststore-path>alfresco/web-extension/ssl-truststore</truststore-path> <truststore-type>JCEKS</truststore-type> <truststore-password>password</truststore-password> <verify-hostname>true</verify-hostname> </ssl-config> <connector> <id>alfrescoCookie</id> <name>Alfresco Connector</name> <description>Connects to an Alfresco instance using cookie-based authentication</description> <class>org.alfresco.web.site.servlet.SlingshotAlfrescoConnector</class> </connector> <connector> <id>alfrescoHeader</id> <name>Alfresco Connector</name> <description>Connects to an Alfresco instance using header and cookie-based authentication</description> <class>org.alfresco.web.site.servlet.SlingshotAlfrescoConnector</class> <userHeader>SsoUserHeader</userHeader> </connector> <endpoint> <id>alfresco</id> <name>Alfresco - user access</name> <description>Access to Alfresco Repository WebScripts that require user authentication</description> <connector-id>alfrescoCookie</connector-id> <endpoint-url>https://arkcasedev1.armediatest.net:18443/alfresco/wcs</endpoint-url> <identity>user</identity> <external-auth>true</external-auth> </endpoint> <endpoint> <id>alfresco-feed</id> <parent-id>alfresco</parent-id> <name>Alfresco Feed</name> <description>Alfresco Feed - supports basic HTTP authentication via the EndPointProxyServlet</description> <connector-id>alfrescoHeader</connector-id> <endpoint-url>https://arkcasedev1.armediatest.net:18443/alfresco/wcs</endpoint-url> <identity>user</identity> <external-auth>true</external-auth> </endpoint> <endpoint> <id>alfresco-api</id> <parent-id>alfresco</parent-id> <name>Alfresco Public API - user access</name> <description>Access to Alfresco Repository Public API that require user authentication. This makes use of the authentication that is provided by parent 'alfresco' endpoint.</description> <connector-id>alfrescoHeader</connector-id> <endpoint-url>https://arkcasedev1.armediatest.net:18443/alfresco/api</endpoint-url> <identity>user</identity> <external-auth>true</external-auth> </endpoint> </remote> </config> -->


<!-- Cookie settings -->


<!-- To disable alfUsername2 cookie set enableCookie value to "false" -->


<!-- <plug-ins> <element-readers> <element-reader element-name="cookie" class="org.alfresco.web.config.cookie.CookieElementReader"/> </element-readers> </plug-ins> <config evaluator="string-compare" condition="Cookie" replace="true"> <cookie> <enableCookie>false</enableCookie> <cookies-to-remove> <cookie-to-remove>alfUsername3</cookie-to-remove> <cookie-to-remove>alfLogin</cookie-to-remove> </cookies-to-remove> </cookie> </config> -->


</alfresco-config>

ArkCase 3.1 – An Overview

February 29th, 2016 by Ronda Ringo

In this video post, the ArkCase experts show you the features available in the new ArkCase 3.1

For more information, email our team for a full demo. Contact us today.

D2 Starter Project

October 29th, 2015 by Scott Roth

As you know from a previous post, I bothers me that out-of-the-box, D2 does NOTHING.  In an effort to help validate D2 v4.5 installations and provide a test environment for my DQL Editor widget, I developed a simple “starter” application that I named “D-Top”.  D-Top provides simple, unrestricted navigation of a Docbase, shows default dm_sysobject properties, versions, audit trails, renditions, object locations, and workflow tasks.  It provides search capabilities, virtual document support, and bookmarks for checked out objects and subscribed objects.  You can create and import documents, as well as check them in and out.  Nothing has been “customized” for specific users, roles, object types, ACLs, or lifecycles.

I had several goals in mind while developing this application:

  • First, to provide a way for developers and users to quickly  validate a D2 installations.  If this application works and allows you to perform basic repository functions, you can conclude that D2 is installed correctly and is ready for you to develop your own applications.
  • To provide a “starter application” (more generic than the HR Sample configuration provided with D2 v4.2) upon which to build other applications.
  • Lastly, so that D2 now does something useful out-of-the box (more or less).

D-Top-1

Default view

D-Top-2

View showing relationships, history, and an attribute dump

If you are interested in the “D-Top” D2 starter project, you can download it here.  Once downloaded, import it into D2-Config like you would import any other D2 configuration.  See the EMC Documentum D2 v4.5 Administration Guide for instructions regarding importing D2 configurations.

If you are interested in what else Armedia can do with D2, leave us a comment.

This software is provided “as-is,” without any express or implied warranty. In no event shall Armedia be held liable for any damages arising from its use.

Access Activiti Through an Apache Reverse Proxy with SSL

October 19th, 2015 by Paul Combs

Activiti is a light-weight workflow and Business Process Management (BPM) Platform.  There seems to be sufficient documentation to get a copy up and running for older versions of this offering.  Documentation for the newer versions could use a rewrite.  After setting up instance of Activiti (version 5.18.0) in one environment, the goal shifted to running it behind an Apache Reverse Proxy (RP) with SSL.  A  configuration file for the Apache RP was created like so.

# http://mycoolsite.com/activiti-explorer
 #####################################################
        ProxyPass /activiti-explorer http://10.10.10.10:8080/activiti-explorer
        ProxyPassReverse /activiti-explorer http://10.10.10.10:8080/activiti-explorer

Sparse support may be found for modifications that are needed to the server.xml file. That support plus using bits and pieces from other application installs resulted in a server.xml that looks like this.

    <Connector port="8080"
             maxThreads="150"
             minSpareThreads="25"
             connectionTimeout="20000"
             enableLookups="false"
             maxHttpHeaderSize="8192"
             protocol="HTTP/1.1"
             useBodyEncodingForURI="true"
             redirectPort="8443"
             acceptCount="100"
             scheme="https"
             secure="true"
             proxyName="mycoolsite.com"
             proxyPort="443"
             disableUploadTimeout="true"/>

The key to successfully implementing the SSL is the added line of secure=”true”. Without that one line, the site didn’t load properly.  This is a line that I hadn’t implemented in configuring other applications of a similar configuration. Hopefully this little nugget will prove useful to your installation and configuration of Activiti.

Activiti

 


 

VIDEO – ArkCase and Ephesoft Integration

October 7th, 2015 by Allison Cotney

In this video, ArkCase demonstrates how to seamlessly integrate Ephesoft’s document capture solution with the ArkCase Case Management solution.

 

Contact our expert ArkCase team today to learn how we can help you!

VIDEO – How to Create and Manage Legal Holds

July 30th, 2015 by Deja Nichols

In this video Deja Nichols walks you through creating a legal hold within Alfresco Records Management.

For more information about Alfresco Records Management, contact our experts today.

VIDEO – How to Use Alfresco Records Management Search Features

July 28th, 2015 by Deja Nichols

In this video, Armedia Records Management expert Deja Nichols will show you how to use various search features within Alfresco Records Management.

Looking for help with your Alfresco Records Management solution? Contact our experts today to learn how we can help!

VIDEO – How to use Alfresco’s Un-filed Record Features

July 23rd, 2015 by Deja Nichols

In this video, Armedia Records Management specialist, Deja Nichols, will walk you through the Un-filed Record features within Alfresco Record Management.

Interested in learning more about how Armedia can help you with Alfresco Record Management? Contact us today to learn how we can help!

VIDEO – How to Create a Rule within Alfresco

July 21st, 2015 by Deja Nichols

In today’s video blog, Deja Nichols will walk you through how to create a rule within Alfrecso.

Copyright © 2002–2011, Armedia. All Rights Reserved.