Page tree
Skip to end of metadata
Go to start of metadata

Your Rating: Results: 1 Star2 Star3 Star4 Star5 Star 111 rates

Draft for 4.5.6

Improvements of current issues around sites and security

Rationale

Multi site feature often seconds as multi-tenancy feature in Magnolia. For multi tenancy purposes it is absolutely crucial to separate each client and make sure their content is available only through their designated domain names.
One of the main features and benefits of Site support in Magnolia is shortening the URLs. While this is very useful, this feature makes it difficult for admins to specify different protected URLs for each site since it is quite possible to have same URI in different sites.

Solution

The problem described above should be treated as two separate issues and solve separately.

Cross-site content access

While in most cases cross site content access (accessing content of one site from another) is not desirable, it is possible in Magnolia at the moment and should be possible in the future. To prevent such access, new filter - SiteSecurityFilter should be introduced in filter chain after site resolving filters. The sole purpose of this filter would be to check if cross site access. If detected, filter should then either allow such access (when both involved sites allow it) or deny when cross site access is not allowed by one of the involved sites.

Site specific URLs protection

Option 1

Use full path (including the site root) to define URLs.

  • Advantage of this approach is supposed simplicity - state.getCurrentURI() would get prepended home handle before the check.
  • This solution would require modification of URISecurityFilter and/or AccessManagerImpl.
  • The result might be bit confusing since admin would have to write site specific URLs including the handle to home page which is not part of the actual rendered URL and would work only as long as the site home was not renamed.

Option 2

Allow use of domain or site name directly in the URL.

  • Already tested this approach in 4.4, but was not so successful in first implementation
  • If implemented with domain name, it would mean that such permission has to be configured for each domain defined in a site
  • If implemented with site name, some sort of markup needs to be introduced to distinguish between site name and real path, e.g. <mySite>/path/to/protect
  • This would be relatively easy to understand and would require no modification of ACL dialog
  • If implemented with domain names and full protocol it would also allow to distinguish access for different ports or even deny some for http, but allow for https
  • This solution would require modification of URISecurityFilter and/or AccessManagerImpl.

Option 3

Add site name combo to URI selection ACL dialog

  • Needs modification of dialog
  • Nice and comfy solution for users, no need to remember domain names or site names
  • Allows only one config per site
  • This solution would require modification of ACLDialog and URISecurityFilter and/or AccessManagerImpl.

Other considerations

Obstacles

ExtendedAggregationState and Site that are both necessary for any site based security checks done in URISecurityFilter are still part of STK and would need to move to core for this to work w/o replacing the filter.

Merged solution

In case it is possible to solve site specific access issue in the Filter, both SiteSecurityFilter and changes to URISecurityFilter can be merged in one filter extending URISecurityFilter that would be set only in case EE installation (Multi site support).

Refactoring and opening possibilities for more improvements

UriSecurityFilter is long pending some refactoring. This filter currently handles not only access via specified URI, but also checks for IP Security access and http method. Refactoring this single filter into chain of security filters - One for IP Access, one for Method checks, one for Site security, and one for URI access might be also beneficial at this point, however such refactoring should probably not happen for minor release.

  • No labels

5 Comments

  1. I really like the suggestion for "Cross-Site content access"

    I think it would be a big improvement in security and an important step to enabling multi-tenancy in EE.

    As a proposal, I would use the existing "mappings" configuration in the site-definitions to configure this, and basically make the rule: if it isn't explicitly configured, it isn't allowed.

    So the site would be determined by the domain (or the first element of the path for non-matching domains), and after that the mappings of that site would determine whether access to another site would be allowed, or not.

    I think combining this with the mappings is a "natural" way of doing it. Putting it elsewhere will be very confusing in combination with URL-shortening.

    Eg: something like the following would allow access to mysiteA (the main site) with no URI-Prefix, and access to content from /mysiteB/sharedcontent using the URL-Prefix /siteB

    • mappings
      • website
        • URIPrefix=
        • handlePrefix=/mysiteA
        • repository=website
      • anotherwebsite
        • URIPrefix=/siteB
        • handlePrefix=/mysiteB/sharedcontent
        • repository=website

    The same logic should be applied to DMS mappings.

    The mappings should also be taken into consideration by the imaging module, to handle security for URLs beginning with /.imaging/

    Regards from Vienna,
    Richard

    1. Oh, didn't think of it that way, but makes sense.
      One problem we might run into is that those mappings are used backwords to recognize to which site content belongs when accessed from unmapped instance (e.g. on the author instance) and such multiple mappings would definitively confuse the algorithm responsible for it.
      Also in a sense it duplicates what you can do with virtual URI mappings.
      But it's anyway interesting proposal and I'll test feasibility of implementing it for cross site access management.

  2. For the site-specific URL-protection, I strongly favour option 1: specify all URLs using the full website or DMS paths. Anything else would be confusing.

    It should not be so hard to convert a shortened URL into its long form before checking against the URL-Security rules. By always converting to the full form of the path, rules need only be set up once, and not potentially one per site and language version.

    A possible downside of this approach would be that you can't configure different security settings for the same node depending on the site or the language it is being accessed in. IMHO that is not a big problem, since it is not possible to configure such rules in the normal (JCR) ACLs either. The JCR ACLs apply to a specific node, and always "count" regardless of language or site. The URI-Security would just be working the same way.

    Regards from Vienna,

    Richard

    1. For the site-specific URL-protection, I strongly favour option 1: specify all URLs using the full website or DMS paths. Anything else would be confusing.

      On the contrary testing with small sample of other devs, they found this as most confusing. First it's not the url anymore. The url is shortened one. What you show then is something akin to path or handle to the content, but is not completely it, just for the first chunk. It is also confusing if you want to use it to deny some virtual mappings on given site since such path would not exists at all.

      For those reasons we decided to support for now patterns like <siteName>/path/to/protect. Such pattern still allows to specify URL to the page or to documents in DMS and should be agnostic to language setting (that one test is still pending).

      In the future version the ACL dialog would be adopted to allow you to select site and the path so you don't have to write pattern at all, but this would come later with all the other things that are up for improvement as listed in the concept page linked by Gregory.

  3. Also consider Concept Security and ACLs - there are ideas there (incl. comments(wink)) that could benefit this feature.