<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta>
      <journal-title-group>
        <journal-title>Feb</journal-title>
      </journal-title-group>
    </journal-meta>
    <article-meta>
      <title-group>
        <article-title>Federated authorization for SaaS applications</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Maarten Decat</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Bert Lagaisse</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Wouter Joosen</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>IBBT-DistriNet, KU Leuven</institution>
          ,
          <addr-line>3001 Leuven</addr-line>
          ,
          <country country="BE">Belgium</country>
        </aff>
      </contrib-group>
      <pub-date>
        <year>2012</year>
      </pub-date>
      <volume>15</volume>
      <issue>2012</issue>
      <abstract>
        <p>With Software-as-a-Service (SaaS), a centrally hosted webbased application is oered to a large number of customer organizations called tenants, each using multiple applications. The tenant and provider each work in their own authoritative and administrative domain, leading to a federated architecture and raising the bar for security and access control. Access control with SaaS applications is about protecting the tenant's data at the provider's side using the tenant's policies and user information. In current practice however, all access control policies are evaluated at the provider's side, distributing and fragmenting the tenant's policies over the multiple applications it uses. Moreover, all necessary user information now has to be shared with the provider, resulting in the disclosure of condential tenant data. Therefore, we propose the concept of federated authorization, a combination of externalized authorization and federated access control techniques whereby the tenant's access control policies are evaluated at the tenant's side using local data.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Introduction</title>
      <p>Software-as-a-Service (SaaS) applications are a part of cloud computing in which
centrally hosted web-based applications are oered to a large number of tenants
(customer organizations each representing multiple end-users), each using
multiple applications. From the point of view of the tenant, cloud computing and SaaS
are a form of outsourcing using a pay-per-use billing scheme. From the point of
view of the provider, SaaS is the next step in Application Service Provider (ASP)
evolution, trying to cut operational costs by sharing resources of the application
and oering it on a larger scale.</p>
      <p>
        Originally, SaaS applications where mainly used by small and medium
enterprises for non-core business applications. Typical examples are Google Apps (an
oce suite, e-mail, calendar etc.) and Salesforce (CRM). Recently however, large
enterprises are increasingly starting to use SaaS for core-business applications.
An example of this is a home patient monitoring system oered to health
institutions like hospitals (the tenants of the application). With regards to the
typical examples, these applications pose new challenges, such as the increased
importance of security. While cloud computing and SaaS can provide large
economical advantages, security is the major hurdle for cloud adoption [
        <xref ref-type="bibr" rid="ref5 ref6 ref8">8,6,5</xref>
        ].
SaaS requires application-level security, of which access control is an important
part. From a high-level point of view, access control limits the actions a subject
(e.g., a user) can take on an object in the system (e.g., a le) applying rules
dened in access control policies. The process of access control is generally
divided into authentication, authorization and audit. Authentication conrms the
stated identity of a subject, authorization conrms the subject is allowed to do
the desired action on the object and audit oers information about the actions
done in the system.
      </p>
      <p>This paper focuses on authentication and authorization. Section 2 denes the
problems we observe with current state of the art for authorization in SaaS
applications. Section 3 sketches our proposed solution and specic objectives. Section
4 lists the challenges we predict in this research. Section 5 describes our research
methodology and section 6 shows our main contributions.
2</p>
    </sec>
    <sec id="sec-2">
      <title>Problem statement</title>
      <p>SaaS applications are a form of outsourcing: the application remotely hosts and
processes data actually belonging to the tenant. Therefore, access control in
SaaS applications is mainly about protecting the tenant’s data located at the
provider’s side. The tenant controls the administration and information about
the users of the application 1 (e.g., employees of the tenant) and the access control
rules and policies.</p>
      <p>
        A rst problem with access control for remote applications is administrative
scalability. From the tenant’s point of view, every application has to be
provided with the necessary user information. Therefore, federated authentication
techniques such as WS-Federation [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ], OpenId [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ] and SAML [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ] have been
developed. These techniques allow users to be authenticated in their home domain,
after which the needed user information is securely exchanged with the
application (see g. 1). This centralizes user management with the tenant and oers
control over the shared information and the authentication means used.
1 There are more complex scenario’s in which former unknown users access the
application (e.g., ad-hoc federations). Here we purposely limit our vision and exclude
this for now.
With the evolution towards core-business SaaS applications, more control over
the application and the data it uses is required, raising the need for
authorization. While federated authentication techniques allow tenants to centralize user
management, similar techniques for authorization currently do not exist and all
access control policies are evaluated at the provider’s side. Because of this, access
control policies are distributed and fragmented over the multiple SaaS
applications the tenant uses. This increases the administrative load, eventually leading
to inconsistencies and security holes.
      </p>
      <p>A second problem with this approach, is the necessary disclosure of
condential tenant information. Because the access control policy is evaluated at the
provider’s side, all necessary information has to be shared with the provider.
While the tenant trusts the provider with the information in the application
itself, it is likely that more information is needed for authorization. For
example, in the patient monitoring system, the list of all patients the physician is
currently treating or the fact that the patient is currently being treated by an
oncologist is condential information. Moreover, it can be the case the tenant
does not want to share the policy itself, for example how the hospital handles
its competitors when requesting access to its data.
3</p>
    </sec>
    <sec id="sec-3">
      <title>Proposed solution</title>
      <p>In this section we present an initial solution we envision to solve the two
problems described above: their limited administrative scalability and the necessary
disclosure of condential information. The solution we envision consists of
externalizing policy evaluation from the SaaS application to the tenant. With each
request, the SaaS application would ask the tenant for an access control decision,
after which the tenant himself evaluates the necessary policies and returns his
decision. This way, tenant policies remain centralized and condential
information does not have to be shared with the application provider. Since this achieves
for authorization what federated authentication did for authentication, we call
this federated authorization.</p>
      <p>
        The objective of this research is to incept and evaluate support for federated
authorization in security middleware. A high-level technical overview of how we
currently envision this middleware is given in g. 2 using XACML [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ]
terminology for the components. When a user sends a request to the SaaS application to
perform an action, the Policy Enforcement Point (PEP) is called from the
application in order to determine whether the user is allowed to do so. It therefore
calls the local Policy Decision Point (PDP), which will evaluate tenant policies
loaded from the Policy Administration Point (PAP) using information stored
in the Policy Information Point (PIP). The provider’s PDP also forwards the
request to the tenant PDP, which in turn evaluates the tenant’s policies using
local data and returns its decision. The requested action is only allowed in case
both parties allow it.
      </p>
      <p>In order to achieve this objective, both the policy language and the execution
environment will have to be extended. The policy has to support the necessary
constructs in order to declare the needed properties of the federated
authorization. Future research will have to show which constructs are minimally needed.
For the execution environment, the communication between the provider and
the tenant will most likely be the crucial part, since the information about the
request, the subject, the object and the system are now distributed over the two
parties.
4</p>
    </sec>
    <sec id="sec-4">
      <title>Challenges</title>
      <p>
        Federated authorization as described above builds upon and extends
externalized authorization, a concept that has been researched in the past (e.g., [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ]).
Moreover, the XACML access control standard already denes a prole for
integration with SAML for transport of both user information and authorization
decisions [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ]. However, no research about the practical feasibility of combining
externalized authorization with federation into federated authorization is present
to the best of our knowledge. An important aspect of this are the security
tradeos implicitly made in federated authorization. For example, externalizing access
control to the tenant increases administrative scalability, but also makes the
system more susceptible to denial of service attacks and trac analysis.
One major challenge we predict is the performance and performance scalability of
the security middleware. This challenge is increased by taking into account
concurrency and distributed data updates. Related research has led to techniques for
improving access control performance (e.g., Wei [
        <xref ref-type="bibr" rid="ref14">14</xref>
        ] proposes decision recycling
and inference, Brucker and Petritsch [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ] focus on the retrieval of the necessary
user information), some of which can also be applied for scalability. However,
SaaS applications frequently use aggressive scalability techniques [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ] and their
applicability on access control still has to be investigated.
5
      </p>
    </sec>
    <sec id="sec-5">
      <title>Research methodology</title>
      <p>In this research, a case-study driven methodology is used. Two major case
studies are used: (i) a home patient monitoring system and (ii) an electronic
document processing system. The security analyses of both case studies oer
requirements and policies to be applied in our prototypes. The former oers insights in
the stringent legal requirements concerning medical data and the complex,
negrained access control policies in e-health, the latter oers a tenant hierarchy, a
concept which should be supported by federated authorization.</p>
      <p>
        Currently, this research is in its early phase. Involvement in the case studies
stated above has shown the need for solving this problem, after which a
literature study of existing authorization techniques was made. As the next step in
this research, our concept of federated authorization will be rened into a
reference architecture. In order to build upon existing work, we will base this on
widely-used standards such as XACML [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ] as much as possible. This reference
architecture will then be instantiated into a proof of concept using the case
studies in order to evaluate the feasibility of federated authorization. The next step
will be to apply and empirically evaluate performance and scalability techniques
on this using metrics such as the impact of the complexity of policies (e.g., the
number of subject and object attributes needed) on the response time of the
whole.
6
      </p>
    </sec>
    <sec id="sec-6">
      <title>Main contributions</title>
      <p>
        Next to SaaS applications, federated access control has been researched in other
domains as well, such as web applications (e.g., OpenId [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ]), grid computing
(e.g., PERMIS [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ]) and web services (e.g., WS-Federation [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ]). These domains
oer relevant techniques, but their purpose diers from SaaS. For example,
access control in grid computing is mainly about access to on-premise resources
from other domains. Moreover, the described techniques still limit themselves to
local policy enforcement based on federated authentication.
      </p>
      <p>
        Some literature has been published about access control for multi-party systems.
Zhang et al. [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ] describe a framework for usage control in collaborative systems,
taking into account access control data updates. Stihler et al. [
        <xref ref-type="bibr" rid="ref13">13</xref>
        ] also describe an
architecture which enables the involved parties to declare access control policies
on the application. However, both still employ provider-side policy enforcement,
resulting into the problems described in section 2.
      </p>
      <p>Existing technologies for access control also do not support federated
authorization. Products such as IBM Tivoli Access Manager allow to centrally enforce
access control policies on multiple applications. Moreover, by acting as an XML
gateway these policies can be applied on external applications. This set-up is
however limited to the level of messages, thereby limiting the complexity of
supported policies. Moreover, this limits the mobility of the users of the external
application, making it inapplicable for SaaS applications.
7</p>
    </sec>
    <sec id="sec-7">
      <title>Conclusions</title>
      <p>This paper presented a new approach to access control for SaaS applications
called federated authorization . In this approach, policy evaluation is
externalized from the SaaS application to the tenant, keeping tenant policies centralized
and its data condential. A major challenge we predict is the performance and
performance scalability of the security middleware. Using a case-study driven
methodology, we will evaluate the feasibility of federated authorization for SaaS
applications.</p>
      <p>Acknowledgements This research is partially funded by the Interuniversity
Attraction Poles Programme Belgian State, by the Belgian Science Policy, by the
Research Fund KU Leuven, by the EU FP7 project NESSoS and by the Agency
for Innovation by Science and Technology in Flanders (IWT).</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <source>Security Assertion Markup Language (SAML) v2.0 (March</source>
          <year>2005</year>
          ), http://www.oasis-open.
          <source>org/standards#samlv2.0</source>
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <source>OpenID Authentication 2</source>
          .
          <fpage>0</fpage>
          -
          <string-name>
            <surname>Final</surname>
          </string-name>
          (
          <year>December 2007</year>
          ), http://openid.net/specs/openid-authentication-
          <volume>2</volume>
          _0.html
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Bajaj</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Della-Libera</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Dixon</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Dusche</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hondo</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hur</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kaler</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lockhart</surname>
            ,
            <given-names>H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Maruyama</surname>
            ,
            <given-names>H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Nadalin</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          , et al.:
          <article-title>Web Services Federation Language (WS-Federation)</article-title>
          . http://specs.xmlsoap.org/ws/2006/12/federation (December
          <year>2006</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Brucker</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Petritsch</surname>
          </string-name>
          , H.:
          <article-title>Idea: Ecient Evaluation of Access Control Constraints</article-title>
          .
          <source>Engineering Secure Software and Systems</source>
          pp.
          <volume>157165</volume>
          (
          <year>2010</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Brunette</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Mogull</surname>
          </string-name>
          , R.:
          <article-title>Security guidance for critical areas of focus in cloud computing v2.1</article-title>
          . Tech. rep., Cloud Security Alliance (december
          <year>2009</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Catteddu</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hogben</surname>
          </string-name>
          , G.:
          <article-title>Cloud Computing: benets, risks and recommendations for information security</article-title>
          .
          <source>Tech. rep.</source>
          ,
          <source>ENISA</source>
          (november
          <year>2009</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <surname>Chadwick</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Otenko</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>The PERMIS X. 509 role based privilege management infrastructure</article-title>
          .
          <source>Future Generation Computer Systems</source>
          <volume>19</volume>
          (
          <issue>2</issue>
          ),
          <volume>277289</volume>
          (
          <year>2003</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <surname>Dean</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Saleh</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          :
          <article-title>Capturing the Value of Cloud Computing</article-title>
          .
          <source>Tech. rep.</source>
          , Boston Consultancy Group (november
          <year>2009</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <surname>Karjoth</surname>
          </string-name>
          , G.:
          <article-title>Access control with ibm tivoli access manager</article-title>
          .
          <source>ACM Transactions on Information and System Security (TISSEC) 6</source>
          (
          <issue>2</issue>
          ),
          <volume>232257</volume>
          (
          <year>2003</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>Lockhart</surname>
            ,
            <given-names>H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Parducci</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rissanen</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lockhart</surname>
          </string-name>
          , H.
          <source>: SAML 2.0 Prole of XACML, Version</source>
          <volume>2</volume>
          .
          <fpage>0</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <surname>Parducci</surname>
          </string-name>
          ,
          <article-title>Bill and Lockhart, Hal and Rissanen, Erik: eXtensible Access Control Markup Language (XACML)</article-title>
          . http://www.oasis-open.org/committees/xacml (
          <year>August 2010</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <surname>Shoup</surname>
          </string-name>
          , R.:
          <source>Scalability Best Practices: Lessons from eBay (May</source>
          <year>2008</year>
          ), http://www.infoq.com/articles/ebay-scalability
          <string-name>
            <surname>-</surname>
          </string-name>
          best-practices
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <string-name>
            <surname>Stihler</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Santin</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Calsavara</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Marcon</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Distributed usage control architecture for business coalitions</article-title>
          .
          <source>In: Communications</source>
          ,
          <year>2009</year>
          . ICC'09. IEEE International Conference on. pp.
          <fpage>16</fpage>
          .
          <string-name>
            <surname>IEEE</surname>
          </string-name>
          (
          <year>2009</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          14.
          <string-name>
            <surname>Wei</surname>
            ,
            <given-names>Q.</given-names>
          </string-name>
          :
          <article-title>Towards improving the availability and performance of enterprise authorization systems</article-title>
          .
          <source>Ph.D. thesis</source>
          , University of British Columbia (
          <year>2009</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          15.
          <string-name>
            <surname>Zhang</surname>
            ,
            <given-names>X.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Nakae</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Covington</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Sandhu</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          :
          <article-title>Toward a usage-based security framework for collaborative computing systems</article-title>
          .
          <source>ACM Transactions on Information and System Security (TISSEC) 11(1)</source>
          ,
          <volume>136</volume>
          (
          <year>2008</year>
          )
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>