You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Felix Meschberger <fm...@adobe.com> on 2013/07/04 11:01:32 UTC
Service Authentication
Hi all
It has been noted that our SlingRepository.loginAdministrative and ResourceResolverFactory.getAdministrativeResourceResolver solve a problem but are suboptimal in that they provide administrative privileges. To solve this dilemma I have created the Service Authentication concept [1] and implemented a prototype [2].
I am now ready to reintegrate this prototype into the main code base tracked by SLING-2944 [3]. The proposed changes to the code base are attached as a patch (of existing code) and a package of the new Service User Mapper bundle.
I would like you to review that code before I go ahead integrating it into the code base sometime next week. Thank you very much.
Regards
Felix
[1] https://cwiki.apache.org/confluence/display/SLING/Service+Authentication
[2] http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/deprecate_login_administrative
[3] https://issues.apache.org/jira/browse/SLING-2944
Re: Service Authentication
Posted by Dominik Süß <do...@gmail.com>.
Hi Felix,
I just did wonder if this really can replace loginAdministrative().
Although I'd really like to get rid of the adminSession due to various
(mostly securitybased) reasons, I don't see all usecases covered by this
solution. The one I have explicitly in mind is the impersonation to users.
Just think of asynchronous processing of content by a service _in the name
and under the restrictions of a user_ Nowadays you'd get an adminsession
and then impersonate it since the adminsession is the only session
implicitly allowed to impersonate any user.
Beside the fact that impersonation is a problematic feature in sense of
tracibility (not being identified as impersonated session in the logs) this
seems to be the only way to fullfill such a task.
Cheers
Dominik
On Fri, Jul 5, 2013 at 8:20 PM, Felix Meschberger <fm...@adobe.com>wrote:
> Hi Angela,
>
> Thanks alot for the extensive feedback. Very much appreciated !
>
> Am 05.07.2013 um 11:01 schrieb Angela Schreiber:
>
> > hi felix
> >
> > i had a closer look at the patch in SLING-2944. here some
> > additional comments:
> >
> > SlingRepository.java:
> > --------------------------------------------------------------------
> > - lacks whitespace in the javadoc of #loginService:
> > + * Returns a sessionto the given workspace with privileges
> > + * Returns a session to the given workspace with privileges
> >
> ACK
>
> > - IMO the param description of @param serviceInfo is not self
> > explaining. i would suggest that you either quickly describe what
> > the serviceInfo is or link to another location for further
> > information.
> >
>
> ACK
>
> >
> > JcrResourceProviderFactory:
> > --------------------------------------------------------------------
> > - typo in the name of the repository constant
> > + private static final String REPOSITORY_REFERNENCE_NAME =
> > "repository";
> > + private static final String REPOSITORY_REFERENCE_NAME =
> > "repository";
> > => and fixing accordingly in the @Reference annotation for
> > the repositoryReference field and in the active method.
> >
>
> ACK
>
> >
> > Regarding deprecation of loginAdministrative et al
> > --------------------------------------------------------------------
> > on the wiki page you state that there will be a configuration flag
> > to disable those methods. is that still outstanding or did i miss it?
> > IMO that would be really cool to have as we definitely want to
> > get rid of the admin-logins.
>
> Oops, missed that. Yes, that makes perfect sense. I will add it with
> values "enabled" (will write a warn log message) and "disabled" (will throw
> a LoginException and log an error message explaining the case)
>
> For backwards compatibility I would think that initially this will default
> to "enabled" with. Later we can change that default.
>
> WDYT ?
>
> >
> > related to this: i got the impression that the deprecated methods are
> > still used in AbstractSlingRepository and JcrResourceProviderFactory.
> > wouldn't it be better to replace them with an internal call such
> > that the API method can really be disabled?
>
> Yes, absolutely.
>
> >
> >
> > Regarding implementation of #loginService
> > --------------------------------------------------------------------
> > this is currently achieved by loginAdministrative followed by an
> > impersonation. as of oak where we plan to have pluggable and
> > osgi aware principal mgt exposed on the OAK layer. this could
> > potentially be used to simplify the call and replace it by a
> > single pre-authenticated login where the subject for the service
> > user is created upfront by retrieve the principal set for the
> > specified service userId.
>
> We could split the loginService(Bundle, ...) method to allow plugging a
> different implementation for the actual session creation once the user has
> been defined.
>
> The default implementation would be the impersonation based one and an
> improved one based on Oak could implenent that.
>
> >
> >
> > ServiceUserMapper
> > --------------------------------------------------------------------
> > if we agree that userId was better than user name, the javadoc of
> > the ServiceUserMapper should be adjusted to consistently use userId.
>
> Absolutely
>
> >
> > what i am missing in the documentation is a short note about what
> > a service user is and if/how that service users should/could be
> > different from regular users. since that service user mapper goes
> > along with a modification in jackrabbit that allows to create user
> > accounts without password it might we worth mentioning somewhere
> > in the documentation that service users are not necessarily intended
> > to perform a regular SlingRepository#login (which in combination with
> > jackrabbit and oak can be achieved by creating those special users
> > without password).
>
> Good point.
>
> >
> >
> > Mapping
> > --------------------------------------------------------------------
> > here again 'userName' should be replaced by userId.
>
> ACK
>
> >
> >
> > ServiceUserMapperImpl
> > --------------------------------------------------------------------
> > same here: references to the user's name should be replaced by user Id.
> >
>
> ACK
>
> > regarding the configuration property PROP_DEFAULT_USER:
> > while is see the benefit of having it, there is IMHO just
> > one reasonable default value, which is again the id of the
> > administrator.
> > so, i am a bit undecided if it is really a good thing... if it stays
> > i would suggest to add some more information indicating the security
> > impact of the default value.
>
> The default for the default is user is none, hence if there is no user
> defined for a service, the service will by default have no access. But I
> agree, there is a risk for lazily define admin as the default user and thus
> basically circumvent the mechanism.
>
> Yet, this would be an administrative, deployment decision as opposed to a
> developer decision using loginAdministrative. Hence the system must
> explicitly be made vulnerable.
>
> What do others think ?
>
> >
> > apart from those things i am convinced that the service user concept
> > is really great leap forward in making sling secure by default.
> >
> > thanks again, i really appreciate this effort!
>
> Thanks. Your input is really appreciated !
>
> Regards
> Felix
>
> > angela
> >
> >
> >
> >
> > On 7/4/13 11:01 AM, Felix Meschberger wrote:
> >> Hi all
> >>
> >> It has been noted that our SlingRepository.loginAdministrative and
> ResourceResolverFactory.getAdministrativeResourceResolver solve a problem
> but are suboptimal in that they provide administrative privileges. To solve
> this dilemma I have created the Service Authentication concept [1] and
> implemented a prototype [2].
> >>
> >> I am now ready to reintegrate this prototype into the main code base
> tracked by SLING-2944 [3]. The proposed changes to the code base are
> attached as a patch (of existing code) and a package of the new Service
> User Mapper bundle.
> >>
> >> I would like you to review that code before I go ahead integrating it
> into the code base sometime next week. Thank you very much.
> >>
> >> Regards
> >> Felix
> >>
> >> [1]
> https://cwiki.apache.org/confluence/display/SLING/Service+Authentication
> >> [2]
> http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/deprecate_login_administrative
> >> [3] https://issues.apache.org/jira/browse/SLING-2944
>
>
Re: Service Authentication
Posted by Felix Meschberger <fm...@adobe.com>.
Hi Angela,
Thanks alot for the extensive feedback. Very much appreciated !
Am 05.07.2013 um 11:01 schrieb Angela Schreiber:
> hi felix
>
> i had a closer look at the patch in SLING-2944. here some
> additional comments:
>
> SlingRepository.java:
> --------------------------------------------------------------------
> - lacks whitespace in the javadoc of #loginService:
> + * Returns a sessionto the given workspace with privileges
> + * Returns a session to the given workspace with privileges
>
ACK
> - IMO the param description of @param serviceInfo is not self
> explaining. i would suggest that you either quickly describe what
> the serviceInfo is or link to another location for further
> information.
>
ACK
>
> JcrResourceProviderFactory:
> --------------------------------------------------------------------
> - typo in the name of the repository constant
> + private static final String REPOSITORY_REFERNENCE_NAME =
> "repository";
> + private static final String REPOSITORY_REFERENCE_NAME =
> "repository";
> => and fixing accordingly in the @Reference annotation for
> the repositoryReference field and in the active method.
>
ACK
>
> Regarding deprecation of loginAdministrative et al
> --------------------------------------------------------------------
> on the wiki page you state that there will be a configuration flag
> to disable those methods. is that still outstanding or did i miss it?
> IMO that would be really cool to have as we definitely want to
> get rid of the admin-logins.
Oops, missed that. Yes, that makes perfect sense. I will add it with values "enabled" (will write a warn log message) and "disabled" (will throw a LoginException and log an error message explaining the case)
For backwards compatibility I would think that initially this will default to "enabled" with. Later we can change that default.
WDYT ?
>
> related to this: i got the impression that the deprecated methods are
> still used in AbstractSlingRepository and JcrResourceProviderFactory.
> wouldn't it be better to replace them with an internal call such
> that the API method can really be disabled?
Yes, absolutely.
>
>
> Regarding implementation of #loginService
> --------------------------------------------------------------------
> this is currently achieved by loginAdministrative followed by an
> impersonation. as of oak where we plan to have pluggable and
> osgi aware principal mgt exposed on the OAK layer. this could
> potentially be used to simplify the call and replace it by a
> single pre-authenticated login where the subject for the service
> user is created upfront by retrieve the principal set for the
> specified service userId.
We could split the loginService(Bundle, ...) method to allow plugging a different implementation for the actual session creation once the user has been defined.
The default implementation would be the impersonation based one and an improved one based on Oak could implenent that.
>
>
> ServiceUserMapper
> --------------------------------------------------------------------
> if we agree that userId was better than user name, the javadoc of
> the ServiceUserMapper should be adjusted to consistently use userId.
Absolutely
>
> what i am missing in the documentation is a short note about what
> a service user is and if/how that service users should/could be
> different from regular users. since that service user mapper goes
> along with a modification in jackrabbit that allows to create user
> accounts without password it might we worth mentioning somewhere
> in the documentation that service users are not necessarily intended
> to perform a regular SlingRepository#login (which in combination with
> jackrabbit and oak can be achieved by creating those special users
> without password).
Good point.
>
>
> Mapping
> --------------------------------------------------------------------
> here again 'userName' should be replaced by userId.
ACK
>
>
> ServiceUserMapperImpl
> --------------------------------------------------------------------
> same here: references to the user's name should be replaced by user Id.
>
ACK
> regarding the configuration property PROP_DEFAULT_USER:
> while is see the benefit of having it, there is IMHO just
> one reasonable default value, which is again the id of the
> administrator.
> so, i am a bit undecided if it is really a good thing... if it stays
> i would suggest to add some more information indicating the security
> impact of the default value.
The default for the default is user is none, hence if there is no user defined for a service, the service will by default have no access. But I agree, there is a risk for lazily define admin as the default user and thus basically circumvent the mechanism.
Yet, this would be an administrative, deployment decision as opposed to a developer decision using loginAdministrative. Hence the system must explicitly be made vulnerable.
What do others think ?
>
> apart from those things i am convinced that the service user concept
> is really great leap forward in making sling secure by default.
>
> thanks again, i really appreciate this effort!
Thanks. Your input is really appreciated !
Regards
Felix
> angela
>
>
>
>
> On 7/4/13 11:01 AM, Felix Meschberger wrote:
>> Hi all
>>
>> It has been noted that our SlingRepository.loginAdministrative and ResourceResolverFactory.getAdministrativeResourceResolver solve a problem but are suboptimal in that they provide administrative privileges. To solve this dilemma I have created the Service Authentication concept [1] and implemented a prototype [2].
>>
>> I am now ready to reintegrate this prototype into the main code base tracked by SLING-2944 [3]. The proposed changes to the code base are attached as a patch (of existing code) and a package of the new Service User Mapper bundle.
>>
>> I would like you to review that code before I go ahead integrating it into the code base sometime next week. Thank you very much.
>>
>> Regards
>> Felix
>>
>> [1] https://cwiki.apache.org/confluence/display/SLING/Service+Authentication
>> [2] http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/deprecate_login_administrative
>> [3] https://issues.apache.org/jira/browse/SLING-2944
Re: Service Authentication
Posted by Angela Schreiber <an...@adobe.com>.
hi felix
i had a closer look at the patch in SLING-2944. here some
additional comments:
SlingRepository.java:
--------------------------------------------------------------------
- lacks whitespace in the javadoc of #loginService:
+ * Returns a sessionto the given workspace with privileges
+ * Returns a session to the given workspace with privileges
- IMO the param description of @param serviceInfo is not self
explaining. i would suggest that you either quickly describe what
the serviceInfo is or link to another location for further
information.
JcrResourceProviderFactory:
--------------------------------------------------------------------
- typo in the name of the repository constant
+ private static final String REPOSITORY_REFERNENCE_NAME =
"repository";
+ private static final String REPOSITORY_REFERENCE_NAME =
"repository";
=> and fixing accordingly in the @Reference annotation for
the repositoryReference field and in the active method.
Regarding deprecation of loginAdministrative et al
--------------------------------------------------------------------
on the wiki page you state that there will be a configuration flag
to disable those methods. is that still outstanding or did i miss it?
IMO that would be really cool to have as we definitely want to
get rid of the admin-logins.
related to this: i got the impression that the deprecated methods are
still used in AbstractSlingRepository and JcrResourceProviderFactory.
wouldn't it be better to replace them with an internal call such
that the API method can really be disabled?
Regarding implementation of #loginService
--------------------------------------------------------------------
this is currently achieved by loginAdministrative followed by an
impersonation. as of oak where we plan to have pluggable and
osgi aware principal mgt exposed on the OAK layer. this could
potentially be used to simplify the call and replace it by a
single pre-authenticated login where the subject for the service
user is created upfront by retrieve the principal set for the
specified service userId.
ServiceUserMapper
--------------------------------------------------------------------
if we agree that userId was better than user name, the javadoc of
the ServiceUserMapper should be adjusted to consistently use userId.
what i am missing in the documentation is a short note about what
a service user is and if/how that service users should/could be
different from regular users. since that service user mapper goes
along with a modification in jackrabbit that allows to create user
accounts without password it might we worth mentioning somewhere
in the documentation that service users are not necessarily intended
to perform a regular SlingRepository#login (which in combination with
jackrabbit and oak can be achieved by creating those special users
without password).
Mapping
--------------------------------------------------------------------
here again 'userName' should be replaced by userId.
ServiceUserMapperImpl
--------------------------------------------------------------------
same here: references to the user's name should be replaced by user Id.
regarding the configuration property PROP_DEFAULT_USER:
while is see the benefit of having it, there is IMHO just
one reasonable default value, which is again the id of the
administrator.
so, i am a bit undecided if it is really a good thing... if it stays
i would suggest to add some more information indicating the security
impact of the default value.
apart from those things i am convinced that the service user concept
is really great leap forward in making sling secure by default.
thanks again, i really appreciate this effort!
angela
On 7/4/13 11:01 AM, Felix Meschberger wrote:
> Hi all
>
> It has been noted that our SlingRepository.loginAdministrative and ResourceResolverFactory.getAdministrativeResourceResolver solve a problem but are suboptimal in that they provide administrative privileges. To solve this dilemma I have created the Service Authentication concept [1] and implemented a prototype [2].
>
> I am now ready to reintegrate this prototype into the main code base tracked by SLING-2944 [3]. The proposed changes to the code base are attached as a patch (of existing code) and a package of the new Service User Mapper bundle.
>
> I would like you to review that code before I go ahead integrating it into the code base sometime next week. Thank you very much.
>
> Regards
> Felix
>
> [1] https://cwiki.apache.org/confluence/display/SLING/Service+Authentication
> [2] http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/deprecate_login_administrative
> [3] https://issues.apache.org/jira/browse/SLING-2944
Re: Service Authentication
Posted by Angela Schreiber <an...@adobe.com>.
hi felix
agreed. i would prefer getServiceUserId.
angela
On 7/4/13 11:24 AM, Felix Meschberger wrote:
> Hi
>
> Am 04.07.2013 um 11:20 schrieb Angela Schreiber:
>
>> hi felix
>>
>> thanks a lot for getting this started. this really sounds promising.
>> i would like to give it closer look later this week and in order
>> to provide feedback.
>>
>> one thing that i noticed right away: the ServiceUserMapper
>> defines a method 'getUserForService' which returns what the API
>> calls a 'user name'.
>>
>> 1) is this intended to be equivalent to the userID. such as e.g. exposed
>> by Session#getUserID if Sling runs on top of a JCR content
>> repository?
>
> Yes.
>
>> if this was the case i would like to suggest to consistently
>> use userId both in the API and the implementation as the name
>> of a user might be quite different from it's ID (for example in
>> the CQ context).
>
> Good point. Reconsidering "getUserForService" sounds strange anyway.
>
> How about: getServiceUserId ?
>
>>
>> 2) irrespective on name vs Id i would suggest to avoid 'getUser*'
>> if the method call returns a String. getUserName* or getUserId*
>> would be more appropriate from my point of view.
>
> My proposal of getServiceUserId would capture this as well, right ?
>
> Regards
> Felix
>
>>
>> kind regards
>> angela
>>
>>
>>
>> On 7/4/13 11:01 AM, Felix Meschberger wrote:
>>> Hi all
>>>
>>> It has been noted that our SlingRepository.loginAdministrative and ResourceResolverFactory.getAdministrativeResourceResolver solve a problem but are suboptimal in that they provide administrative privileges. To solve this dilemma I have created the Service Authentication concept [1] and implemented a prototype [2].
>>>
>>> I am now ready to reintegrate this prototype into the main code base tracked by SLING-2944 [3]. The proposed changes to the code base are attached as a patch (of existing code) and a package of the new Service User Mapper bundle.
>>>
>>> I would like you to review that code before I go ahead integrating it into the code base sometime next week. Thank you very much.
>>>
>>> Regards
>>> Felix
>>>
>>> [1] https://cwiki.apache.org/confluence/display/SLING/Service+Authentication
>>> [2] http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/deprecate_login_administrative
>>> [3] https://issues.apache.org/jira/browse/SLING-2944
>
Re: Service Authentication
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Am 04.07.2013 um 11:20 schrieb Angela Schreiber:
> hi felix
>
> thanks a lot for getting this started. this really sounds promising.
> i would like to give it closer look later this week and in order
> to provide feedback.
>
> one thing that i noticed right away: the ServiceUserMapper
> defines a method 'getUserForService' which returns what the API
> calls a 'user name'.
>
> 1) is this intended to be equivalent to the userID. such as e.g. exposed
> by Session#getUserID if Sling runs on top of a JCR content
> repository?
Yes.
> if this was the case i would like to suggest to consistently
> use userId both in the API and the implementation as the name
> of a user might be quite different from it's ID (for example in
> the CQ context).
Good point. Reconsidering "getUserForService" sounds strange anyway.
How about: getServiceUserId ?
>
> 2) irrespective on name vs Id i would suggest to avoid 'getUser*'
> if the method call returns a String. getUserName* or getUserId*
> would be more appropriate from my point of view.
My proposal of getServiceUserId would capture this as well, right ?
Regards
Felix
>
> kind regards
> angela
>
>
>
> On 7/4/13 11:01 AM, Felix Meschberger wrote:
>> Hi all
>>
>> It has been noted that our SlingRepository.loginAdministrative and ResourceResolverFactory.getAdministrativeResourceResolver solve a problem but are suboptimal in that they provide administrative privileges. To solve this dilemma I have created the Service Authentication concept [1] and implemented a prototype [2].
>>
>> I am now ready to reintegrate this prototype into the main code base tracked by SLING-2944 [3]. The proposed changes to the code base are attached as a patch (of existing code) and a package of the new Service User Mapper bundle.
>>
>> I would like you to review that code before I go ahead integrating it into the code base sometime next week. Thank you very much.
>>
>> Regards
>> Felix
>>
>> [1] https://cwiki.apache.org/confluence/display/SLING/Service+Authentication
>> [2] http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/deprecate_login_administrative
>> [3] https://issues.apache.org/jira/browse/SLING-2944
Re: Service Authentication
Posted by Angela Schreiber <an...@adobe.com>.
hi felix
thanks a lot for getting this started. this really sounds promising.
i would like to give it closer look later this week and in order
to provide feedback.
one thing that i noticed right away: the ServiceUserMapper
defines a method 'getUserForService' which returns what the API
calls a 'user name'.
1) is this intended to be equivalent to the userID. such as e.g. exposed
by Session#getUserID if Sling runs on top of a JCR content
repository?
if this was the case i would like to suggest to consistently
use userId both in the API and the implementation as the name
of a user might be quite different from it's ID (for example in
the CQ context).
2) irrespective on name vs Id i would suggest to avoid 'getUser*'
if the method call returns a String. getUserName* or getUserId*
would be more appropriate from my point of view.
kind regards
angela
On 7/4/13 11:01 AM, Felix Meschberger wrote:
> Hi all
>
> It has been noted that our SlingRepository.loginAdministrative and ResourceResolverFactory.getAdministrativeResourceResolver solve a problem but are suboptimal in that they provide administrative privileges. To solve this dilemma I have created the Service Authentication concept [1] and implemented a prototype [2].
>
> I am now ready to reintegrate this prototype into the main code base tracked by SLING-2944 [3]. The proposed changes to the code base are attached as a patch (of existing code) and a package of the new Service User Mapper bundle.
>
> I would like you to review that code before I go ahead integrating it into the code base sometime next week. Thank you very much.
>
> Regards
> Felix
>
> [1] https://cwiki.apache.org/confluence/display/SLING/Service+Authentication
> [2] http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/deprecate_login_administrative
> [3] https://issues.apache.org/jira/browse/SLING-2944
Re: Service Authentication
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Felix,
On Thu, Jul 4, 2013 at 4:27 PM, Felix Meschberger <fm...@adobe.com> wrote:
> Am 04.07.2013 um 12:01 schrieb Bertrand Delacretaz:
>> ...Maybe
>> getServiceResourceResolver(ServicerUserURI uri, Bundle
>> serviceBundle, String optionalServiceInfo)
>
> I thougt about having a signature with just the serviceInfo. But the map may contain more fields,
> which are not available in the single signature....
Ok - as long as javadoc and tests clarifiy what the Map parameter
should contain, I'm fine with that.
>> ...I would suggest having
>> ServicerUserURI - identifies a service, like "service:MailSender:server"...
> I don't really see the need to define this as a URI. After all calling this a "resource" is kind of esoteric ;-)
> How about calling this the service ID comprised of the bundle-derived service name and the optional service Info.
>
> Hence how about: ServiceUserMapper.getServiceID ?
Works for me!
-Bertrand
Re: Service Authentication
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Am 04.07.2013 um 12:01 schrieb Bertrand Delacretaz:
> Hi Felix,
>
>> ... have created the Service Authentication concept [1]..
>
> I like it - here are some comments on the proposed APIs.
>
> 1) getServiceResourceResolver
> In ResourceResolver getServiceResourceResolver(Map<String, Object>
> authenticationInfo), authenticationInfo MUST contain some attributes,
> wouldn't it be better to use a more specific argument than Map<String,
> Object> ?
>
> Maybe
>
> getServiceResourceResolver(ServicerUserURI uri, Bundle
> serviceBundle, String optionalServiceInfo)
I thougt about having a signature with just the serviceInfo. But the map may contain more fields, which are not available in the single signature.
Plus: the only "required" property is the service Info which is optional. The bundle is available implicitly and the service base is derived from the bundle which is available as the bundle using the ResourceResolverFactory. There is no such thing as a freely definable ServiceUserURI: The ServiceUserMapper.getServiceName just exists for informational purposes or to configure the ServiceUserMapper.
The service name is either the value of the Sling-Service bundle header or the bundle symbolic name.
>
> 2) ServiceUserMapper
> Like Angela I think the naming is a bit confusing, I would suggest having
>
> ServicerUserURI - identifies a service, like "service:MailSender:server"
> userId - a User ID as used by the Sling security services
I don't really see the need to define this as a URI. After all calling this a "resource" is kind of esoteric ;-)
How about calling this the service ID comprised of the bundle-derived service name and the optional service Info.
Hence how about: ServiceUserMapper.getServiceID ?
Regards
Felix
>
> You could then have, IIUC
>
> interface ServiceUserMapper {
> ServicerUserURI getServiceURI(Bundle b, String serviceName)
> String getServiceUserID(ServicerUserURI URI, Bundle serviceBundle)
> }
>
> The main idea is to clearly define what's a service name
> ("mail.sender"), service URI ("service:someBundle:mail.sender") and
> User ID ("mailsender").
>
> -Bertrand
>
>> [1] https://cwiki.apache.org/confluence/display/SLING/Service+Authentication
Re: Service Authentication
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Felix,
> ... have created the Service Authentication concept [1]..
I like it - here are some comments on the proposed APIs.
1) getServiceResourceResolver
In ResourceResolver getServiceResourceResolver(Map<String, Object>
authenticationInfo), authenticationInfo MUST contain some attributes,
wouldn't it be better to use a more specific argument than Map<String,
Object> ?
Maybe
getServiceResourceResolver(ServicerUserURI uri, Bundle
serviceBundle, String optionalServiceInfo)
2) ServiceUserMapper
Like Angela I think the naming is a bit confusing, I would suggest having
ServicerUserURI - identifies a service, like "service:MailSender:server"
userId - a User ID as used by the Sling security services
You could then have, IIUC
interface ServiceUserMapper {
ServicerUserURI getServiceURI(Bundle b, String serviceName)
String getServiceUserID(ServicerUserURI URI, Bundle serviceBundle)
}
The main idea is to clearly define what's a service name
("mail.sender"), service URI ("service:someBundle:mail.sender") and
User ID ("mailsender").
-Bertrand
> [1] https://cwiki.apache.org/confluence/display/SLING/Service+Authentication