sling-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bertrand Delacretaz (Confluence)" <>
Subject [CONF] Apache Sling > Service Authentication
Date Thu, 04 Jul 2013 09:48:00 GMT
    <base href="">
            <link rel="stylesheet" href="/confluence/s/en/2176/1/1/_/styles/combined.css?spaceKey=SLING&amp;forWysiwyg=true"
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
    <h2><a href="">Service
    <h4>Page <b>edited</b> by             <a href="">Bertrand
        <div id="versionComment">
        mention "service users" early on<br />
                         <h4>Changes (1)</h4>
<div id="page-diffs">
                    <table class="diff" cellpadding="0" cellspacing="0">
            <tr><td class="diff-snipped" >...<br></td></tr>
            <tr><td class="diff-unchanged" >* Don&#39;t use administrative
JCR Sessions or ResourceResolvers all over <br>* Allow services access to JCR Sessions
and ResourceResolvers without requiring to hard-code or configure passwords <br></td></tr>
            <tr><td class="diff-changed-lines" >* Allow services to use <span
class="diff-changed-words">&quot;<span class="diff-added-chars"style="background-color:
#dfd;">service </span>users&quot;</span> which have been specially configured
for service level access <span class="diff-added-words"style="background-color: #dfd;">(as
is usually done on unixish systems)</span> <br></td></tr>
            <tr><td class="diff-unchanged" >* Allow administrators to configure
the assignment of service users to services <br> <br></td></tr>
            <tr><td class="diff-snipped" >...<br></td></tr>
    </div>                            <h4>Full Content</h4>
                    <div class="notificationGreySide">
        <h1><a name="ServiceAuthentication-ServiceAuthentication"></a>Service

<p>Status: PROTOTYPE<br/>
Created: 4. April 2013<br/>
Author: fmeschbe<br/>
Issue: <a href="" class="external-link"

    <li><a href='#ServiceAuthentication-Problem'>Problem</a></li>
    <li><a href='#ServiceAuthentication-Requirements'>Requirements</a></li>
    <li><a href='#ServiceAuthentication-Solution'>Solution</a></li>
    <li><a href='#ServiceAuthentication-NewloginServicemethods'>New loginService
    <li><a href='#ServiceAuthentication-CommunicatingServiceInformationtoResourceProviderFactories'>Communicating
Service Information to ResourceProviderFactories</a></li>
    <li><a href='#ServiceAuthentication-NewServiceUserMapperService'>New ServiceUserMapper
    <li><a href='#ServiceAuthentication-DeprecateloginAdministrative'>Deprecate
    <li><a href='#ServiceAuthentication-PrototypeImplementation'>Prototype Implementation</a></li>

<h2><a name="ServiceAuthentication-Problem"></a>Problem</h2>

<p>Since the early days of Sling we had methods to get an administrative JCR Session
and later an administrative ResourceResolver. These methods were intended to provide services
with access to the repository with less restrictions than regular users and to also allow
those services to access the Resource tree (and JCR Repository) without hard-coding a password
in the code or even having the password as some plain text in configuration.</p>

<p>Over the years, it turned out that these <tt>loginAdministrative</tt>
methods have been abused.</p>

<p>The goal of this proposal is to come up with new API to replace the <tt>loginAdministrative</tt>

<p>One example of a service, which currently uses administrative privileges but which
would benefit from a carefully crafted service user is the <a href=""
class="external-link" rel="nofollow">Tenant Manager</a></p>

<h2><a name="ServiceAuthentication-Requirements"></a>Requirements</h2>

	<li>Don't use administrative JCR Sessions or ResourceResolvers all over</li>
	<li>Allow services access to JCR Sessions and ResourceResolvers without requiring to
hard-code or configure passwords</li>
	<li>Allow services to use "service users" which have been specially configured for
service level access (as is usually done on unixish systems)</li>
	<li>Allow administrators to configure the assignment of service users to services</li>

<h2><a name="ServiceAuthentication-Solution"></a>Solution</h2>

<h3><a name="ServiceAuthentication-NewloginServicemethods"></a>New loginService

<p>Two new methods are introduced to replace <tt>loginAdministrative</tt>

	<li><tt>ResourceResolver getServiceResourceResolver(Map&lt;String, Object&gt;
authenticationInfo) throws LoginException;</tt></li>
	<li><tt>Session loginService(String serviceInfo, String workspace) throws LoginException,

<p>The bundle identifying the actual service is not part of the new API. The bundle
is taken from the call stack by leveraging the OSGi Service Factory mechanism: Each bundle
using the <tt>ResourceResolverFactory</tt> or <tt>SlingRepository</tt>
service actually gets an instance bound to the using bundle. That bundle is used to identify
the service.</p>

<p>The <tt>serviceInfo</tt> parameter or <tt></tt>
property of the <tt>authenticationInfo</tt> map may be used to provide additional
information on the service. See the <em>New ServiceUserMapper Service</em> section
below for information on additional service information.</p>

<h3><a name="ServiceAuthentication-CommunicatingServiceInformationtoResourceProviderFactories"></a>Communicating
Service Information to ResourceProviderFactories</h3>

<p>The <tt>ResourceProviderFactory</tt> interface is not extended for the
new service login. Rather the required information &#8211; using bundle and additional
service information &#8211; is passed to the <tt>getResourceProvider</tt>
method as part of the <tt>authenticationInfo</tt> map:</p>

	<li><tt>ResourceResolverFactory.USER</tt> &#8211; name of the service
user (never <tt>null</tt>)</li>
	<li><tt>ResourceProviderFactory.SERVICE_BUNDLE</tt> &#8211; the service
<tt>Bundle</tt> object (never <tt>null</tt>)</li>
	<li><tt>ResourceResolverFactory.SERVICE_INFO</tt> &#8211; additional
service information (optional; may be <tt>null</tt>)</li>

<p>In case the <tt>ResourceProviderFactory</tt> makes use of another service
to provide the <tt>ResourceProvider</tt> the provided service bundle should be
used to acquire the service to allow the service to support service logins using the <tt>ServiceUserMapper</tt>
service. An example of such an implementation would be the JCR based <tt>ResourceProviderFactory</tt>
which gets the <tt>SlingRepository</tt> service using the service bundle.</p>

<h3><a name="ServiceAuthentication-NewServiceUserMapperService"></a>New
ServiceUserMapper Service</h3>

<p>A service is introduced which allows to map a service to a user name. A service is
identified by a service name related to the OSGi Bundle implementing the service and an additional
service information string. For example a bundle implementing mail support may represent the
<em>MailServer</em> service while the actual mail sender may identify itself with
the <em>sender</em> information and some mail queue handler may identify itself
with the <em>queue</em> information. This allows separate users to be used for
sending messages and handling the message queue or using the same user for both services,
depending on the requirements and needs of the system administrator.</p>

<p>The <tt>ServiceUserMapper</tt> service has two methods:</p>

	<li><tt>String getServiceName(Bundle bundle, String serviceInfo);</tt>
&#8211; Returns the value of the service identification string to use for the bundle providing
the service. In the above example of the message sender service, when call with the mail server
bundle and <tt>serviceInfo="sender"</tt> the returned value might be <tt>MailServer:sender</tt>.</li>
	<li><tt>String getUserForService(Bundle bundle, String serviceInfo);</tt>
&#8211; Returns the name of the user to be used for the given service.</li>

<p>This <a href=""
class="external-link" rel="nofollow"><tt>ServiceUserMapper</tt></a> service
is intended to be used by implementations of the new <tt>loginService</tt> methods
to allow mapping services to user names and to provide for a central point of configuring
the mapping.</p>

<h3><a name="ServiceAuthentication-DeprecateloginAdministrative"></a>Deprecate

<p>The following methods are deprecated:</p>


<p>The implementations we have in Sling's bundle will remain implemented but there will
be a configuration switch to disable support for these methods: If the method is disabled,
a <tt>LoginException</tt> is always thrown from these methods. The JavaDoc of
the methods is augmented with this information.</p>

<h2><a name="ServiceAuthentication-PrototypeImplementation"></a>Prototype

<p>A prototype implementation of this concept is available in the <a href=""
class="external-link" rel="nofollow">deprecate_login_administrative whiteboard</a>.</p>
        <div id="commentsSection" class="wiki-content pageSection">
        <div style="float: right;" class="grey">
                        <a href="">Stop
watching space</a>
            <span style="padding: 0px 5px;">|</span>
                <a href="">Change
email notification preferences</a>
        <a href="">View
        <a href="">View
        <a href=";showCommentArea=true#addcomment">Add

View raw message