You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Francisco Carriedo Scher <fc...@gmail.com> on 2011/09/15 12:41:47 UTC

Creating users

Hi there,

finally setting permissions through resource-based ACLs is achieved. Now i
am trying to create users and test ACLs with them, but i found problems.
First of all, creating users (that will be affected by the set ACLs for
them) should be straight forward isn't it? If there are previous
configuration or key files i should check, please tell me instead of keeping
reading the details of my issues below,

i create users with no exceptions:

    public boolean createUser(String name, String pass) throws
AuthorizableExistsException, RepositoryException{
        User u;
        PrincipalImpl p = new PrincipalImpl(name);
        String usersPath = "/" + name;
        u = um.createUser(name, pass, p, null);
        u.setProperty("homeFolder",
session.getValueFactory().createValue(usersPath));
        // "HOME" folder for the brand new user
        createUsersFolder(name, session);
        // Assign permissions to the "HOME" folder of the just created
user
        assignInitialPermissions(u,u.getPrincipal(), usersPath, session);
        session.save();
        return true;
    }

but, when trying to log in using them i receive always the following
exception:

Caused by: javax.security.auth.login.FailedLoginException: LoginModule
ignored Credentials
    at
org.apache.jackrabbit.core.security.authentication.LocalAuthContext.login(LocalAuthContext.java:87)
    at
org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1474)

I went down the source code and reached the previous code to throwing the
exception:

DefaultLoginModule.java (line88):  Authorizable authrz =
userManager.getAuthorizable(userId);

No Authorizable is recovered from the userId.

I tried the same code running in my test program (it creates users, folders,
sets permissions and so on...) and it recovers correctly the user in the
line above:

    public Principal getPrincipal(Credentials credentials) {
        User user;
        Principal principal = null;
        String userId = getUserID(credentials);
        try {
            *Authorizable authrz = um.getAuthorizable(userId);*
            if (authrz != null && !authrz.isGroup()) {
                user = (User) authrz;
                if (user.isDisabled()) {
                    // log message and return null -> login module returns
false.
                    System.out.println("User " + userId + " has been
disabled.");
                } else {
                    principal = user.getPrincipal();
                }
            }
        } catch (RepositoryException e) {
            // should not get here
            System.out.println("Error while retrieving principal.");
        }
        return principal;
    }

    private String getUserID(Credentials credentials) {
        String userId = null;
        if (credentials != null) {
            if (credentials instanceof GuestCredentials) {
                //userId = anonymousId;
            } else if (credentials instanceof SimpleCredentials) {
                *userId = ((SimpleCredentials) credentials).getUserID();*
            } else {

              [...this code is not run so far in my case...]

        // still no userId -> anonymousID if its has been defined.
        // TODO: check again if correct when used with 'extendedAuth'
        if (userId == null) {
            userId = anonymousId;
        }
        return userId;
    }

Finally the test for me to know if the users are correctly created is to try
creating the same user twice and the corresponding exception is throwin
saying that such user already exists.

Thanks for your attention!

Re: Creating users

Posted by Francisco Carriedo Scher <fc...@gmail.com>.
That's it... Neither user management nor access control are currently
available through RMI or Webdav. As you probably already have read from
previous emails such functionalities are only available when operating JR as
embeded repository (starting it through your Java code).


2011/10/11 Lahiru Gunathilake <gl...@gmail.com>

> Hi Francisco,
>
> So can some user assume that creating a new user for a remote client is
> currently impossible in JR without changing JR 2.2.7 release ?
>
> Regards
> Lahiru
>
> On Thu, Sep 29, 2011 at 9:59 AM, Francisco Carriedo Scher <
> fcarriedos@gmail.com> wrote:
>
>> Hi Angela,
>>
>> I am checking now the planning board to find Access Control issue. I will
>> have a look to it to find out if i find developing it obtainable.
>>
>> And what about wrapping the UM and AC with webservices? Would that mean
>> performing
>> all the operations through WS? Let me explain: since the UM and AC
>> operations require the repository to be started locally, my doubt is:
>> would work enabling the desired modules (jackrabbit-webdav for Webdav or
>> jackrabbit-jcr-rmi for RMI) to have AC and UM working through WS and
>> other functionalities through Webdav / RMI?
>>
>> Thank you very much for your comments once more.
>>
>>
>> 2011/9/29 Angela Schreiber <an...@adobe.com>
>>
>> > hi francisco
>> >
>> >
>> > On 9/29/11 12:33 PM, Francisco Carriedo Scher wrote:
>> >
>> >> Hi Angela,
>> >>
>> >> then, taking into account the other options (please tell me if i am
>> >> wrong) if i obtain the repository object through:
>> >>
>> >> - Webdav: user management and access control is not available.
>> >> - RMI: user management and access control is not available either.
>> >> - JNDI: idem as the same point (since the repository object is located
>> >> through JNDI tree but it is finally remotely operated using RMI, isn't
>> >> it?)
>> >>
>> >> I have checked the JIRA for Jackrabbit (until 2008) and i did not find
>> >> any attemp to implement access control nor user management through RMI
>> >> nor Webdav. Anyway i found "RFC 3744 (Access Control Protocol)" support
>> >> mention inside README file in the jackrabbit-webdav project. Would this
>> >> last option fit my purposes?
>> >>
>> >
>> > the issue related to access control and jcr-remoting is
>> > https://issues.apache.org/**jira/browse/JCR-2113<
>> https://issues.apache.org/jira/browse/JCR-2113>
>>
>> >
>> > the RFC 3733 referred to in the webdav-library means that
>> > the library provides some initial utilities, dav properties,
>> > methods etc. that would be suited to implement the rfc in
>> > any of the server implementations present. up to now this didn't
>> > get enough priority, i regret so say.
>> >
>> >
>> >  Finally, right now i consider the following alternatives:
>> >>
>> >> - extending JR remoting through RMI or Webdav to support UM and AC. I
>> >> would like to contribute back to JR project but i am not sure if i am
>> >> the appropiate one to implement such extension.
>> >>
>> >
>> > why not. give it a try...
>> > the dev list would be the right place for discussions and providing
>> > patches is always welcome.
>> >
>> > the implementation in jackrabbit-jcr-server specifically for
>> > the server that is intended to expose jcr api via http, should
>> > rather straight forward at least as far as the basic jcr ac
>> > functionality is concerned... i don't remember the very details of
>> > rfc 3733 but it could give some ideas on how to start.
>> >
>> > regards
>> > angela
>> >
>> >
>> >  - wrap the UM and AC with webservices but, would that mean performing
>> >> all the operations through WS? Let me explain: since the UM and AC
>> >> operations require the repository to be started locally, my doubt is:
>> >> would work enabling the desired modules (jackrabbit-webdav for Webdav
>> or
>> >> jackrabbit-jcr-rmi for RMI) to have AC and UM working through WS and
>> >> other functionalities through Webdav / RMI?
>> >>
>> >> Thank you very much for your attention, it helps a lot!
>> >>
>> >>
>> >>
>> >>
>> >> 2011/9/28 Angela Schreiber <anchela@adobe.com <mailto:
>> anchela@adobe.com>>
>> >>
>> >>    hi francisco
>> >>
>> >>
>> >>        your observation was fully right. I have just tested it and now
>> i
>> >> am
>> >>        able now to deal with users and permissions in the
>> >>        dummy-locally-accessed repository i used to learn about access
>> >>        control
>> >>        in JR. But now i am trying to extrapolate it to my previously
>> >>        working
>> >>        repositories, which are accessed through Webdav and the class of
>> >> the
>> >>        obtained session object (Session session =
>> >>        JcrUtils.getRepository("http:/**__/localhost:8080/server
>> >>        <http://localhost:8080/server>**")) is not a
>>
>> >>        JackrabbitSession class, but a SessionImpl class object (which
>> >>        did not
>> >>        work in my previous tests).
>> >>
>> >>
>> >>        Is there a way to get working access control  (as in my tests)
>> >>        when the
>> >>        repository is obtained through Webdav?
>> >>
>> >>
>> >>    unfortunately neither access-control nor user management is
>> >>    available when using jcr-remoting via webdav.
>> >>
>> >>    sorry
>> >>    angela
>> >>
>> >>        Thanks in advance for your attention!
>> >>
>> >>
>> >>        2011/9/21 Angela Schreiber <anchela@adobe.com
>> >>        <ma...@adobe.com> <mailto:anchela@adobe.com
>> >>
>> >>        <ma...@adobe.com>>>
>> >>
>> >>
>> >>            hi francisco
>> >>
>> >>            it seems to me that the principal resolution doesn't work
>> >>            properly. that's why you get an access control exception
>> >>            upon editing ACLs and cannot login to the repo.
>> >>
>> >>            i assume that you are using a default repository setup
>> >>            without specifying custom principal providers. is that
>> >>            correct?
>> >>
>> >>
>> >>                The object um is a UserManagerImpl object obtained
>> >>        through an
>> >>                admin session:
>> >>                new UserManagerImpl((SessionImpl) session, "admin")
>> >>
>> >>
>> >>            that's probably the culprit.
>> >>
>> >>            you should use
>> >>
>> >>            if (session instanceof JackrabbitSession) {
>> >>               UserManager umgr = ((JackrabbitSession)
>> >>        session).getUserManager();
>> >>            }
>> >>
>> >>            instead of manually creating the user manager instance and
>> >>            relying on a specific implementation.
>> >>
>> >>            the explanation was as simple as that:
>> >>            unless specified otherwise the DefaultSecurityManager builds
>> a
>> >>            security setup that stores users in a separate workspace.
>> all
>> >>            the depending modules (login, ac evaluation etc) then rely
>> on
>> >>            that setup... however, if you create the user manager
>> instance
>> >>            manually you simply store the users in the workspace of the
>> >>            editing session -> the user nodes exist but the principal
>> >>            provider (and the user-manager you would obtain from the
>> >>            session) look for them in a different place/workspace.
>> >>
>> >>            if you wish to keep the users separate for each workspace
>> >>        instead
>> >>            of keeping them in a dedicated workspace you can use the
>> >>        alternative
>> >>            implementation (-> UserPerWorkspaceSecurityManage**____r).
>>
>> >>
>> >>            but still you should refrain from creating the user manager
>> >>        instance
>> >>            manually and use the API instead.
>> >>
>> >>            hope that helps
>> >>            angela
>> >>
>> >>
>> >>
>> >>
>>
>
>
>
> --
> System Analyst Programmer
> PTI Lab
> Indiana University
>
>

Re: Creating users

Posted by Lahiru Gunathilake <gl...@gmail.com>.
Hi Francisco,

So can some user assume that creating a new user for a remote client is
currently impossible in JR without changing JR 2.2.7 release ?

Regards
Lahiru

On Thu, Sep 29, 2011 at 9:59 AM, Francisco Carriedo Scher <
fcarriedos@gmail.com> wrote:

> Hi Angela,
>
> I am checking now the planning board to find Access Control issue. I will
> have a look to it to find out if i find developing it obtainable.
>
> And what about wrapping the UM and AC with webservices? Would that mean
> performing
> all the operations through WS? Let me explain: since the UM and AC
> operations require the repository to be started locally, my doubt is:
> would work enabling the desired modules (jackrabbit-webdav for Webdav or
> jackrabbit-jcr-rmi for RMI) to have AC and UM working through WS and
> other functionalities through Webdav / RMI?
>
> Thank you very much for your comments once more.
>
>
> 2011/9/29 Angela Schreiber <an...@adobe.com>
>
> > hi francisco
> >
> >
> > On 9/29/11 12:33 PM, Francisco Carriedo Scher wrote:
> >
> >> Hi Angela,
> >>
> >> then, taking into account the other options (please tell me if i am
> >> wrong) if i obtain the repository object through:
> >>
> >> - Webdav: user management and access control is not available.
> >> - RMI: user management and access control is not available either.
> >> - JNDI: idem as the same point (since the repository object is located
> >> through JNDI tree but it is finally remotely operated using RMI, isn't
> >> it?)
> >>
> >> I have checked the JIRA for Jackrabbit (until 2008) and i did not find
> >> any attemp to implement access control nor user management through RMI
> >> nor Webdav. Anyway i found "RFC 3744 (Access Control Protocol)" support
> >> mention inside README file in the jackrabbit-webdav project. Would this
> >> last option fit my purposes?
> >>
> >
> > the issue related to access control and jcr-remoting is
> > https://issues.apache.org/**jira/browse/JCR-2113<
> https://issues.apache.org/jira/browse/JCR-2113>
> >
> > the RFC 3733 referred to in the webdav-library means that
> > the library provides some initial utilities, dav properties,
> > methods etc. that would be suited to implement the rfc in
> > any of the server implementations present. up to now this didn't
> > get enough priority, i regret so say.
> >
> >
> >  Finally, right now i consider the following alternatives:
> >>
> >> - extending JR remoting through RMI or Webdav to support UM and AC. I
> >> would like to contribute back to JR project but i am not sure if i am
> >> the appropiate one to implement such extension.
> >>
> >
> > why not. give it a try...
> > the dev list would be the right place for discussions and providing
> > patches is always welcome.
> >
> > the implementation in jackrabbit-jcr-server specifically for
> > the server that is intended to expose jcr api via http, should
> > rather straight forward at least as far as the basic jcr ac
> > functionality is concerned... i don't remember the very details of
> > rfc 3733 but it could give some ideas on how to start.
> >
> > regards
> > angela
> >
> >
> >  - wrap the UM and AC with webservices but, would that mean performing
> >> all the operations through WS? Let me explain: since the UM and AC
> >> operations require the repository to be started locally, my doubt is:
> >> would work enabling the desired modules (jackrabbit-webdav for Webdav or
> >> jackrabbit-jcr-rmi for RMI) to have AC and UM working through WS and
> >> other functionalities through Webdav / RMI?
> >>
> >> Thank you very much for your attention, it helps a lot!
> >>
> >>
> >>
> >>
> >> 2011/9/28 Angela Schreiber <anchela@adobe.com <mailto:anchela@adobe.com
> >>
> >>
> >>    hi francisco
> >>
> >>
> >>        your observation was fully right. I have just tested it and now i
> >> am
> >>        able now to deal with users and permissions in the
> >>        dummy-locally-accessed repository i used to learn about access
> >>        control
> >>        in JR. But now i am trying to extrapolate it to my previously
> >>        working
> >>        repositories, which are accessed through Webdav and the class of
> >> the
> >>        obtained session object (Session session =
> >>        JcrUtils.getRepository("http:/**__/localhost:8080/server
> >>        <http://localhost:8080/server>**")) is not a
> >>        JackrabbitSession class, but a SessionImpl class object (which
> >>        did not
> >>        work in my previous tests).
> >>
> >>
> >>        Is there a way to get working access control  (as in my tests)
> >>        when the
> >>        repository is obtained through Webdav?
> >>
> >>
> >>    unfortunately neither access-control nor user management is
> >>    available when using jcr-remoting via webdav.
> >>
> >>    sorry
> >>    angela
> >>
> >>        Thanks in advance for your attention!
> >>
> >>
> >>        2011/9/21 Angela Schreiber <anchela@adobe.com
> >>        <ma...@adobe.com> <mailto:anchela@adobe.com
> >>
> >>        <ma...@adobe.com>>>
> >>
> >>
> >>            hi francisco
> >>
> >>            it seems to me that the principal resolution doesn't work
> >>            properly. that's why you get an access control exception
> >>            upon editing ACLs and cannot login to the repo.
> >>
> >>            i assume that you are using a default repository setup
> >>            without specifying custom principal providers. is that
> >>            correct?
> >>
> >>
> >>                The object um is a UserManagerImpl object obtained
> >>        through an
> >>                admin session:
> >>                new UserManagerImpl((SessionImpl) session, "admin")
> >>
> >>
> >>            that's probably the culprit.
> >>
> >>            you should use
> >>
> >>            if (session instanceof JackrabbitSession) {
> >>               UserManager umgr = ((JackrabbitSession)
> >>        session).getUserManager();
> >>            }
> >>
> >>            instead of manually creating the user manager instance and
> >>            relying on a specific implementation.
> >>
> >>            the explanation was as simple as that:
> >>            unless specified otherwise the DefaultSecurityManager builds
> a
> >>            security setup that stores users in a separate workspace. all
> >>            the depending modules (login, ac evaluation etc) then rely on
> >>            that setup... however, if you create the user manager
> instance
> >>            manually you simply store the users in the workspace of the
> >>            editing session -> the user nodes exist but the principal
> >>            provider (and the user-manager you would obtain from the
> >>            session) look for them in a different place/workspace.
> >>
> >>            if you wish to keep the users separate for each workspace
> >>        instead
> >>            of keeping them in a dedicated workspace you can use the
> >>        alternative
> >>            implementation (-> UserPerWorkspaceSecurityManage**____r).
> >>
> >>            but still you should refrain from creating the user manager
> >>        instance
> >>            manually and use the API instead.
> >>
> >>            hope that helps
> >>            angela
> >>
> >>
> >>
> >>
>



-- 
System Analyst Programmer
PTI Lab
Indiana University

Re: Creating users

Posted by Francisco Carriedo Scher <fc...@gmail.com>.
Hi Angela,

I am checking now the planning board to find Access Control issue. I will
have a look to it to find out if i find developing it obtainable.

And what about wrapping the UM and AC with webservices? Would that mean
performing
all the operations through WS? Let me explain: since the UM and AC
operations require the repository to be started locally, my doubt is:
would work enabling the desired modules (jackrabbit-webdav for Webdav or
jackrabbit-jcr-rmi for RMI) to have AC and UM working through WS and
other functionalities through Webdav / RMI?

Thank you very much for your comments once more.


2011/9/29 Angela Schreiber <an...@adobe.com>

> hi francisco
>
>
> On 9/29/11 12:33 PM, Francisco Carriedo Scher wrote:
>
>> Hi Angela,
>>
>> then, taking into account the other options (please tell me if i am
>> wrong) if i obtain the repository object through:
>>
>> - Webdav: user management and access control is not available.
>> - RMI: user management and access control is not available either.
>> - JNDI: idem as the same point (since the repository object is located
>> through JNDI tree but it is finally remotely operated using RMI, isn't
>> it?)
>>
>> I have checked the JIRA for Jackrabbit (until 2008) and i did not find
>> any attemp to implement access control nor user management through RMI
>> nor Webdav. Anyway i found "RFC 3744 (Access Control Protocol)" support
>> mention inside README file in the jackrabbit-webdav project. Would this
>> last option fit my purposes?
>>
>
> the issue related to access control and jcr-remoting is
> https://issues.apache.org/**jira/browse/JCR-2113<https://issues.apache.org/jira/browse/JCR-2113>
>
> the RFC 3733 referred to in the webdav-library means that
> the library provides some initial utilities, dav properties,
> methods etc. that would be suited to implement the rfc in
> any of the server implementations present. up to now this didn't
> get enough priority, i regret so say.
>
>
>  Finally, right now i consider the following alternatives:
>>
>> - extending JR remoting through RMI or Webdav to support UM and AC. I
>> would like to contribute back to JR project but i am not sure if i am
>> the appropiate one to implement such extension.
>>
>
> why not. give it a try...
> the dev list would be the right place for discussions and providing
> patches is always welcome.
>
> the implementation in jackrabbit-jcr-server specifically for
> the server that is intended to expose jcr api via http, should
> rather straight forward at least as far as the basic jcr ac
> functionality is concerned... i don't remember the very details of
> rfc 3733 but it could give some ideas on how to start.
>
> regards
> angela
>
>
>  - wrap the UM and AC with webservices but, would that mean performing
>> all the operations through WS? Let me explain: since the UM and AC
>> operations require the repository to be started locally, my doubt is:
>> would work enabling the desired modules (jackrabbit-webdav for Webdav or
>> jackrabbit-jcr-rmi for RMI) to have AC and UM working through WS and
>> other functionalities through Webdav / RMI?
>>
>> Thank you very much for your attention, it helps a lot!
>>
>>
>>
>>
>> 2011/9/28 Angela Schreiber <anchela@adobe.com <ma...@adobe.com>>
>>
>>    hi francisco
>>
>>
>>        your observation was fully right. I have just tested it and now i
>> am
>>        able now to deal with users and permissions in the
>>        dummy-locally-accessed repository i used to learn about access
>>        control
>>        in JR. But now i am trying to extrapolate it to my previously
>>        working
>>        repositories, which are accessed through Webdav and the class of
>> the
>>        obtained session object (Session session =
>>        JcrUtils.getRepository("http:/**__/localhost:8080/server
>>        <http://localhost:8080/server>**")) is not a
>>        JackrabbitSession class, but a SessionImpl class object (which
>>        did not
>>        work in my previous tests).
>>
>>
>>        Is there a way to get working access control  (as in my tests)
>>        when the
>>        repository is obtained through Webdav?
>>
>>
>>    unfortunately neither access-control nor user management is
>>    available when using jcr-remoting via webdav.
>>
>>    sorry
>>    angela
>>
>>        Thanks in advance for your attention!
>>
>>
>>        2011/9/21 Angela Schreiber <anchela@adobe.com
>>        <ma...@adobe.com> <mailto:anchela@adobe.com
>>
>>        <ma...@adobe.com>>>
>>
>>
>>            hi francisco
>>
>>            it seems to me that the principal resolution doesn't work
>>            properly. that's why you get an access control exception
>>            upon editing ACLs and cannot login to the repo.
>>
>>            i assume that you are using a default repository setup
>>            without specifying custom principal providers. is that
>>            correct?
>>
>>
>>                The object um is a UserManagerImpl object obtained
>>        through an
>>                admin session:
>>                new UserManagerImpl((SessionImpl) session, "admin")
>>
>>
>>            that's probably the culprit.
>>
>>            you should use
>>
>>            if (session instanceof JackrabbitSession) {
>>               UserManager umgr = ((JackrabbitSession)
>>        session).getUserManager();
>>            }
>>
>>            instead of manually creating the user manager instance and
>>            relying on a specific implementation.
>>
>>            the explanation was as simple as that:
>>            unless specified otherwise the DefaultSecurityManager builds a
>>            security setup that stores users in a separate workspace. all
>>            the depending modules (login, ac evaluation etc) then rely on
>>            that setup... however, if you create the user manager instance
>>            manually you simply store the users in the workspace of the
>>            editing session -> the user nodes exist but the principal
>>            provider (and the user-manager you would obtain from the
>>            session) look for them in a different place/workspace.
>>
>>            if you wish to keep the users separate for each workspace
>>        instead
>>            of keeping them in a dedicated workspace you can use the
>>        alternative
>>            implementation (-> UserPerWorkspaceSecurityManage**____r).
>>
>>            but still you should refrain from creating the user manager
>>        instance
>>            manually and use the API instead.
>>
>>            hope that helps
>>            angela
>>
>>
>>
>>

Re: Creating users

Posted by Angela Schreiber <an...@adobe.com>.
hi francisco

On 9/29/11 12:33 PM, Francisco Carriedo Scher wrote:
> Hi Angela,
>
> then, taking into account the other options (please tell me if i am
> wrong) if i obtain the repository object through:
>
> - Webdav: user management and access control is not available.
> - RMI: user management and access control is not available either.
> - JNDI: idem as the same point (since the repository object is located
> through JNDI tree but it is finally remotely operated using RMI, isn't it?)
>
> I have checked the JIRA for Jackrabbit (until 2008) and i did not find
> any attemp to implement access control nor user management through RMI
> nor Webdav. Anyway i found "RFC 3744 (Access Control Protocol)" support
> mention inside README file in the jackrabbit-webdav project. Would this
> last option fit my purposes?

the issue related to access control and jcr-remoting is
https://issues.apache.org/jira/browse/JCR-2113

the RFC 3733 referred to in the webdav-library means that
the library provides some initial utilities, dav properties,
methods etc. that would be suited to implement the rfc in
any of the server implementations present. up to now this didn't
get enough priority, i regret so say.

> Finally, right now i consider the following alternatives:
>
> - extending JR remoting through RMI or Webdav to support UM and AC. I
> would like to contribute back to JR project but i am not sure if i am
> the appropiate one to implement such extension.

why not. give it a try...
the dev list would be the right place for discussions and providing
patches is always welcome.

the implementation in jackrabbit-jcr-server specifically for
the server that is intended to expose jcr api via http, should
rather straight forward at least as far as the basic jcr ac
functionality is concerned... i don't remember the very details of
rfc 3733 but it could give some ideas on how to start.

regards
angela


> - wrap the UM and AC with webservices but, would that mean performing
> all the operations through WS? Let me explain: since the UM and AC
> operations require the repository to be started locally, my doubt is:
> would work enabling the desired modules (jackrabbit-webdav for Webdav or
> jackrabbit-jcr-rmi for RMI) to have AC and UM working through WS and
> other functionalities through Webdav / RMI?
>
> Thank you very much for your attention, it helps a lot!
>
>
>
>
> 2011/9/28 Angela Schreiber <anchela@adobe.com <ma...@adobe.com>>
>
>     hi francisco
>
>
>         your observation was fully right. I have just tested it and now i am
>         able now to deal with users and permissions in the
>         dummy-locally-accessed repository i used to learn about access
>         control
>         in JR. But now i am trying to extrapolate it to my previously
>         working
>         repositories, which are accessed through Webdav and the class of the
>         obtained session object (Session session =
>         JcrUtils.getRepository("http:/__/localhost:8080/server
>         <http://localhost:8080/server>")) is not a
>         JackrabbitSession class, but a SessionImpl class object (which
>         did not
>         work in my previous tests).
>
>
>         Is there a way to get working access control  (as in my tests)
>         when the
>         repository is obtained through Webdav?
>
>
>     unfortunately neither access-control nor user management is
>     available when using jcr-remoting via webdav.
>
>     sorry
>     angela
>
>         Thanks in advance for your attention!
>
>
>         2011/9/21 Angela Schreiber <anchela@adobe.com
>         <ma...@adobe.com> <mailto:anchela@adobe.com
>         <ma...@adobe.com>>>
>
>
>             hi francisco
>
>             it seems to me that the principal resolution doesn't work
>             properly. that's why you get an access control exception
>             upon editing ACLs and cannot login to the repo.
>
>             i assume that you are using a default repository setup
>             without specifying custom principal providers. is that
>             correct?
>
>
>                 The object um is a UserManagerImpl object obtained
>         through an
>                 admin session:
>                 new UserManagerImpl((SessionImpl) session, "admin")
>
>
>             that's probably the culprit.
>
>             you should use
>
>             if (session instanceof JackrabbitSession) {
>                UserManager umgr = ((JackrabbitSession)
>         session).getUserManager();
>             }
>
>             instead of manually creating the user manager instance and
>             relying on a specific implementation.
>
>             the explanation was as simple as that:
>             unless specified otherwise the DefaultSecurityManager builds a
>             security setup that stores users in a separate workspace. all
>             the depending modules (login, ac evaluation etc) then rely on
>             that setup... however, if you create the user manager instance
>             manually you simply store the users in the workspace of the
>             editing session -> the user nodes exist but the principal
>             provider (and the user-manager you would obtain from the
>             session) look for them in a different place/workspace.
>
>             if you wish to keep the users separate for each workspace
>         instead
>             of keeping them in a dedicated workspace you can use the
>         alternative
>             implementation (-> UserPerWorkspaceSecurityManage____r).
>
>             but still you should refrain from creating the user manager
>         instance
>             manually and use the API instead.
>
>             hope that helps
>             angela
>
>
>

Re: Creating users

Posted by Francisco Carriedo Scher <fc...@gmail.com>.
Hi Angela,

then, taking into account the other options (please tell me if i am wrong)
if i obtain the repository object through:

- Webdav: user management and access control is not available.
- RMI: user management and access control is not available either.
- JNDI: idem as the same point (since the repository object is located
through JNDI tree but it is finally remotely operated using RMI, isn't it?)

I have checked the JIRA for Jackrabbit (until 2008) and i did not find any
attemp to implement access control nor user management through RMI nor
Webdav. Anyway i found "RFC 3744 (Access Control Protocol)" support  mention
inside README file in the jackrabbit-webdav project. Would this last option
fit my purposes?

Finally, right now i consider the following alternatives:

- extending JR remoting through RMI or Webdav to support UM and AC. I would
like to contribute back to JR project but i am not sure if i am the
appropiate one to implement such extension.

- wrap the UM and AC with webservices but, would that mean performing all
the operations through WS? Let me explain: since the UM and AC operations
require the repository to be started locally, my doubt is: would work
enabling the desired modules (jackrabbit-webdav for Webdav or
jackrabbit-jcr-rmi for RMI) to have AC and UM working through WS and other
functionalities through Webdav / RMI?

Thank you very much for your attention, it helps a lot!




2011/9/28 Angela Schreiber <an...@adobe.com>

> hi francisco
>
>
>  your observation was fully right. I have just tested it and now i am
>> able now to deal with users and permissions in the
>> dummy-locally-accessed repository i used to learn about access control
>> in JR. But now i am trying to extrapolate it to my previously working
>> repositories, which are accessed through Webdav and the class of the
>> obtained session object (Session session =
>> JcrUtils.getRepository("http:/**/localhost:8080/server<http://localhost:8080/server>"))
>> is not a
>> JackrabbitSession class, but a SessionImpl class object (which did not
>> work in my previous tests).
>>
>

>
>> Is there a way to get working access control  (as in my tests) when the
>> repository is obtained through Webdav?
>>
>
> unfortunately neither access-control nor user management is
> available when using jcr-remoting via webdav.
>
> sorry
> angela
>
>  Thanks in advance for your attention!
>>
>>
>> 2011/9/21 Angela Schreiber <anchela@adobe.com <ma...@adobe.com>>
>>
>>
>>    hi francisco
>>
>>    it seems to me that the principal resolution doesn't work
>>    properly. that's why you get an access control exception
>>    upon editing ACLs and cannot login to the repo.
>>
>>    i assume that you are using a default repository setup
>>    without specifying custom principal providers. is that
>>    correct?
>>
>>
>>        The object um is a UserManagerImpl object obtained through an
>>        admin session:
>>        new UserManagerImpl((SessionImpl) session, "admin")
>>
>>
>>    that's probably the culprit.
>>
>>    you should use
>>
>>    if (session instanceof JackrabbitSession) {
>>       UserManager umgr = ((JackrabbitSession) session).getUserManager();
>>    }
>>
>>    instead of manually creating the user manager instance and
>>    relying on a specific implementation.
>>
>>    the explanation was as simple as that:
>>    unless specified otherwise the DefaultSecurityManager builds a
>>    security setup that stores users in a separate workspace. all
>>    the depending modules (login, ac evaluation etc) then rely on
>>    that setup... however, if you create the user manager instance
>>    manually you simply store the users in the workspace of the
>>    editing session -> the user nodes exist but the principal
>>    provider (and the user-manager you would obtain from the
>>    session) look for them in a different place/workspace.
>>
>>    if you wish to keep the users separate for each workspace instead
>>    of keeping them in a dedicated workspace you can use the alternative
>>    implementation (-> UserPerWorkspaceSecurityManage**__r).
>>
>>    but still you should refrain from creating the user manager instance
>>    manually and use the API instead.
>>
>>    hope that helps
>>    angela
>>
>>
>>

Re: Creating users

Posted by Angela Schreiber <an...@adobe.com>.
hi francisco

> your observation was fully right. I have just tested it and now i am
> able now to deal with users and permissions in the
> dummy-locally-accessed repository i used to learn about access control
> in JR. But now i am trying to extrapolate it to my previously working
> repositories, which are accessed through Webdav and the class of the
> obtained session object (Session session =
> JcrUtils.getRepository("http://localhost:8080/server")) is not a
> JackrabbitSession class, but a SessionImpl class object (which did not
> work in my previous tests).
>
> Is there a way to get working access control  (as in my tests) when the
> repository is obtained through Webdav?

unfortunately neither access-control nor user management is
available when using jcr-remoting via webdav.

sorry
angela

> Thanks in advance for your attention!
>
>
> 2011/9/21 Angela Schreiber <anchela@adobe.com <ma...@adobe.com>>
>
>     hi francisco
>
>     it seems to me that the principal resolution doesn't work
>     properly. that's why you get an access control exception
>     upon editing ACLs and cannot login to the repo.
>
>     i assume that you are using a default repository setup
>     without specifying custom principal providers. is that
>     correct?
>
>
>         The object um is a UserManagerImpl object obtained through an
>         admin session:
>         new UserManagerImpl((SessionImpl) session, "admin")
>
>
>     that's probably the culprit.
>
>     you should use
>
>     if (session instanceof JackrabbitSession) {
>        UserManager umgr = ((JackrabbitSession) session).getUserManager();
>     }
>
>     instead of manually creating the user manager instance and
>     relying on a specific implementation.
>
>     the explanation was as simple as that:
>     unless specified otherwise the DefaultSecurityManager builds a
>     security setup that stores users in a separate workspace. all
>     the depending modules (login, ac evaluation etc) then rely on
>     that setup... however, if you create the user manager instance
>     manually you simply store the users in the workspace of the
>     editing session -> the user nodes exist but the principal
>     provider (and the user-manager you would obtain from the
>     session) look for them in a different place/workspace.
>
>     if you wish to keep the users separate for each workspace instead
>     of keeping them in a dedicated workspace you can use the alternative
>     implementation (-> UserPerWorkspaceSecurityManage__r).
>     but still you should refrain from creating the user manager instance
>     manually and use the API instead.
>
>     hope that helps
>     angela
>
>

Re: Creating users

Posted by Francisco Carriedo Scher <fc...@gmail.com>.
Hi Angela,

your observation was fully right. I have just tested it and now i am able
now to deal with users and permissions in the dummy-locally-accessed
repository i used to learn about access control in JR. But now i am trying
to extrapolate it to my previously working repositories, which are accessed
through Webdav and the class of the obtained session object (Session session
= JcrUtils.getRepository("http://localhost:8080/server")) is not a
JackrabbitSession class, but a SessionImpl class object (which did not work
in my previous tests).

Is there a way to get working access control  (as in my tests) when the
repository is obtained through Webdav?

Thanks in advance for your attention!


2011/9/21 Angela Schreiber <an...@adobe.com>

> hi francisco
>
> it seems to me that the principal resolution doesn't work
> properly. that's why you get an access control exception
> upon editing ACLs and cannot login to the repo.
>
> i assume that you are using a default repository setup
> without specifying custom principal providers. is that
> correct?
>
>
>  The object um is a UserManagerImpl object obtained through an admin
>> session:
>> new UserManagerImpl((SessionImpl) session, "admin")
>>
>
> that's probably the culprit.
>
> you should use
>
> if (session instanceof JackrabbitSession) {
>   UserManager umgr = ((JackrabbitSession) session).getUserManager();
> }
>
> instead of manually creating the user manager instance and
> relying on a specific implementation.
>
> the explanation was as simple as that:
> unless specified otherwise the DefaultSecurityManager builds a
> security setup that stores users in a separate workspace. all
> the depending modules (login, ac evaluation etc) then rely on
> that setup... however, if you create the user manager instance
> manually you simply store the users in the workspace of the
> editing session -> the user nodes exist but the principal
> provider (and the user-manager you would obtain from the
> session) look for them in a different place/workspace.
>
> if you wish to keep the users separate for each workspace instead
> of keeping them in a dedicated workspace you can use the alternative
> implementation (-> UserPerWorkspaceSecurityManage**r).
> but still you should refrain from creating the user manager instance
> manually and use the API instead.
>
> hope that helps
> angela
>

Re: Creating users

Posted by Angela Schreiber <an...@adobe.com>.
hi francisco

it seems to me that the principal resolution doesn't work
properly. that's why you get an access control exception
upon editing ACLs and cannot login to the repo.

i assume that you are using a default repository setup
without specifying custom principal providers. is that
correct?

> The object um is a UserManagerImpl object obtained through an admin session:
> new UserManagerImpl((SessionImpl) session, "admin")

that's probably the culprit.

you should use

if (session instanceof JackrabbitSession) {
    UserManager umgr = ((JackrabbitSession) session).getUserManager();
}

instead of manually creating the user manager instance and
relying on a specific implementation.

the explanation was as simple as that:
unless specified otherwise the DefaultSecurityManager builds a
security setup that stores users in a separate workspace. all
the depending modules (login, ac evaluation etc) then rely on
that setup... however, if you create the user manager instance
manually you simply store the users in the workspace of the
editing session -> the user nodes exist but the principal
provider (and the user-manager you would obtain from the
session) look for them in a different place/workspace.

if you wish to keep the users separate for each workspace instead
of keeping them in a dedicated workspace you can use the alternative
implementation (-> UserPerWorkspaceSecurityManager).
but still you should refrain from creating the user manager instance
manually and use the API instead.

hope that helps
angela

Re: Creating users

Posted by Francisco Carriedo Scher <fc...@gmail.com>.
Dear Angela,

i can create users but not logging in with them (javax.jcr.LoginException:
LoginModule ignored Credentials) neither setting ACEs to them
(javax.jcr.security.AccessControlException: Principal dummyusername does not
exist).

First of all, i am using the DefaultSecurityManager, DefaultAccessManager,
DefaultLoginModule). About the first issue, as you said in a previous
response to one of my mails, i would like to rely on Jackrabbit's user
management instead of asking an external database for it. What is your
recommendation? Extending DefaultLoginModule and overriding
getAuthentication method? Should this mean extending as well
DefaultSecurityManager and / or DefaultAccessManager? Any orientation will
be helpful!!!

About the second issue (exception when adding an ACE for an existing user),
the line which causes the second exception in my code is:

acl.addAccessControlEntry(p, privileges);

and the method where the exception is effectively thrown is:

    protected void checkValidEntry(Principal principal, Privilege[]
privileges,
                                 boolean isAllow, Map<String, Value>
restrictions)
            throws AccessControlException {
        // validate principal
        if (principal instanceof UnknownPrincipal) {
            log.debug("Consider fallback principal as valid: {}",
principal.getName());
        } else if (!principalMgr.hasPrincipal(principal.getName())) {
            throw new AccessControlException("Principal " +
principal.getName() + " does not exist.");
        }
    }

I obtain a valid object p (Principal) like this (but internally Jackrabbit
doesn't achieve it):

User u = um.getUser(username);
u.getPrincipal();

The object um is a UserManagerImpl object obtained through an admin session:

new UserManagerImpl((SessionImpl) session, "admin")

and i create users with this single line:

u = um.createUser(name, pass, p, null);

Finally a conceptual question just to be sure whether i got it or not:

Authorizable class: any object which might be granted with permissions over
nodes, such as users and groups
Principal: a kind of role, so to say an identity card shown when trying to
perform operations inside JR. Every brand new user has a Principal object
asociated to him and it is recoverable through user.getPrincipal() (for
example it get them so in my code) method and through input credentials (for
example JR tries it so, and in my case it throws the mentioned exception).

Thank you very much for your attention and help!













2011/9/20 Angela Schreiber <an...@adobe.com>

>
>
> On 9/15/11 12:41 PM, Francisco Carriedo Scher wrote:
>
>> Hi there,
>>
>> finally setting permissions through resource-based ACLs is achieved. Now i
>> am trying to create users and test ACLs with them, but i found problems.
>> First of all, creating users (that will be affected by the set ACLs for
>> them) should be straight forward isn't it?
>>
>
> yes... jackrabbit provides user management API in it's own
> extensions of the JCR API. this allow you to create users,
> groups, add members to groups etc...
>
> since access control such as defined by the JCR API deals
> with principals rather than users, jackrabbit also defines
> principal management API, where the default implementation
> is backed by the user management.
>
> not sure how your repository configuration looks like.
> but if you have something else than the simplesecuritymanager
> you should get everything for free.
>
> angela
>

Re: Creating users

Posted by Angela Schreiber <an...@adobe.com>.

On 9/15/11 12:41 PM, Francisco Carriedo Scher wrote:
> Hi there,
>
> finally setting permissions through resource-based ACLs is achieved. Now i
> am trying to create users and test ACLs with them, but i found problems.
> First of all, creating users (that will be affected by the set ACLs for
> them) should be straight forward isn't it?

yes... jackrabbit provides user management API in it's own
extensions of the JCR API. this allow you to create users,
groups, add members to groups etc...

since access control such as defined by the JCR API deals
with principals rather than users, jackrabbit also defines
principal management API, where the default implementation
is backed by the user management.

not sure how your repository configuration looks like.
but if you have something else than the simplesecuritymanager
you should get everything for free.

angela