Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
From Wikipedia:
Commentators regard multitenancy as an important feature of cloud computing.
https://en.wikipedia.org/wiki/Multitenancy
For an overview of how fortress multitenancy works:
Fortress Realm uses the tenant id inside the context.xml file:
<Context path="/commander" reloadable="true"> <Realm className="org.apache.directory.fortress.realm.tomcat.Tc7AccessMgrProxy" defaultRoles="" containerType="TomcatContext" realmClasspath="" contextId="HOME" /> </Context>
The operations for this particular instance will be on behalf of the home contextId.
Fortress Web uses the tenant id inside the fortress.properties file:
contextId=acme123
The operations for this instance will be scoped to acme123 tenant.
Why are there are two locations for setting the tenant id, context.xml and fortress.properties?
Expedience in loading the realm tenant id with the context.xml file and the spring beans using fortress.properties because that is where properties for those components are usually set.
Security Control. It is necessary to allow the realm to use one tenant context, e.g. HOME, and the web app instance another, e.g. acme123. For the why consider a use case. One where many customer web app instances run from within one or more instances of a container (like Tomcat). Only corporate employees may administer security policies within the customer‘s web app instances, not the customers themselves. On the contrary, we may want to allow the customer to administer their own security data in which case we’d set both to acme123.