On 21 Jun 2010, at 11:47, Felix Meschberger wrote:

> Hi,
> 
> Yes, this is why I just use this mechanism ;-)
> 
> In addition it is also fully transparent down the road with respect to
> setting ACLs etc.

Yes, principals need to be resolvable via a PrincipalManager to be in ACLs.

Does a standard JCR User node get created at first login if one cant be found 
either by searching for a matching open.id.identifier or userID, or do you have 
to create the OpenID JCR node prior to attempting to login with OpenID ?

If its the latter, then much of the benefit of OpenID may be lost ?
Ian
 



> 
> Regards
> Felix
> 
> On 21.06.2010 12:44, Ian Boston wrote:
>> 
>> On 21 Jun 2010, at 11:28, Felix Meschberger (JIRA) wrote:
>> 
>>> 
>>>   [ 
>>> https://issues.apache.org/jira/browse/SLING-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880776#action_12880776
>>>  ] 
>>> 
>>> Felix Meschberger commented on SLING-860:
>>> -----------------------------------------
>>> 
>>> To be able to properly authenticate with OpenID the JCR users must be 
>>> associated with the actual OpenID Identity of the user.
>>> 
>>> Currently there is no easy GUI support to do this, but you may use curl and 
>>> the Sling user management functionality to set this property, e.g.:
>>> 
>>>  curl -u admin:admin -F:name=username -Fpwd= -FpwdConfirm= \
>>>        -Fopen.id.identifier=http://OpenIDIdentity \
>>>        http://localhost:8888/system/userManager/user.create.html
>>> 
>>> WDYT ?
>> 
>> 
>> Wouldn't it make more sense to have an PrincipalManager that resolved and 
>> OpenID principal to a Principal and a User Manager that would create valid 
>> User objects for an open ID principal (or Principal). Unfortunately this 
>> might require changes to the Jackrabbit UserManager which IIRC hard binds to 
>> UserImpl and GroupImpl and changes to GroupImpl which only allows members of 
>> type UserImpl. ?
>> 
>> Having a JCR node as the only way to represent a User object means that all 
>> User have to be inside JCR before they can be used.
>> 
>> I realise that making the existing JR UserManager work for externally 
>> provisioned users is a major task and may simply be out of scope, in which 
>> case the open.id.identifier is a reasonable solution.
>> 
>> 
>>> 
>>> 
>>>> OpenId authenticator problem
>>>> ----------------------------
>>>> 
>>>>               Key: SLING-860
>>>>               URL: https://issues.apache.org/jira/browse/SLING-860
>>>>           Project: Sling
>>>>        Issue Type: Bug
>>>>        Components: Extensions
>>>>          Reporter: Michael Marth
>>>>          Priority: Minor
>>>> 
>>>> this is probably a configuration problem, but I do not know how to get 
>>>> around this:
>>>> Using the OpenId authenticator I cannot write to the repository.
>>>> --
>>>> How to reproduce:
>>>> - install bundle espblog from samples
>>>> - install bundle openid from extensions
>>>> - in system config switch off "allow anon access" as described in 
>>>> openid-authenticator description
>>>> - do openid login (and make sure you have no http basic auth credentials 
>>>> in the request)
>>>> - try to write to repository -> javax.jcr.AccessDeniedException: /: not 
>>>> allowed to modify item
>>>> --
>>>> I believe the openid_user has no write acccess which would explain this 
>>>> behaviour. But how do I get around it? Do I have to write my own 
>>>> AccessManager? Do I miss something?
>>> 
>>> -- 
>>> This message is automatically generated by JIRA.
>>> -
>>> You can reply to this email to add a comment to the issue online.
>>> 
>> 
>> 

Reply via email to