Josh,

Is there a method to add a user with a specified role to the system, or is that 
done ONLY by editing the DB directly, or writing a front-end to do that?

--Steven.

--
Steven Lichti
Academic Technologies
Northwestern University
[email protected]
(847) 467-7805



On May 2, 2011, at 9:47 AM, Josh Holtzman wrote:

> By default, we have two UserProviders registered in the OSGI service 
> registry.  The security framework scans each user provider that belongs to 
> the current org, and offers each a chance to return a valid User object.  The 
> two UserProviders are:
> 
> InMemoryUserAndRoleProvider [1] : Provides two demo accounts, as defined in 
> config.properties.  One is for logging in to the admin UI, and the other is 
> for JVMs to communicate over HTTP via digest auth.
> 
> JpaUserAndRoleProvider [2] : Provides accounts for each of the entries in the 
> join between the mh_user and mh_role database tables.  Keep in mind that, if 
> building a Matterhorn instance that has no database connection (e.g. a 
> capture agent), the users defined in mh_user and mh_role will not be able to 
> log in to that system.
> 
> You can add more users by either:
> 
> a) adding rows to the mh_user and mh_role tables, or
> b) registering another UserProvider in OSGI.  See the LdapUserProvider [3] as 
> an example of one such custom UserProvider.
> 
> [1] 
> https://opencast.jira.com/svn/MH/trunk/modules/matterhorn-kernel/src/main/java/org/opencastproject/kernel/userdirectory/InMemoryUserAndRoleProvider.java
> [2] 
> https://opencast.jira.com/svn/MH/trunk/modules/matterhorn-userdirectory-jpa/src/main/java/org/opencastproject/userdirectory/jpa/JpaUserAndRoleProvider.java
> [3] 
> https://opencast.jira.com/svn/MH/trunk/modules/matterhorn-userdirectory-ldap/src/main/java/org/opencastproject/userdirectory/ldap/LdapUserProvider.java
> 
> Josh
> 
> On Mon, May 2, 2011 at 7:17 AM, Markus Ketterl <[email protected]> 
> wrote:
> Thanks Josh,
> where do you store this demo user info currently?
> 
> Markus
> 
> > As we move toward 1.2, we'll need to start testing authorization in the UI. 
> >  To facilitate this, I've enabled a demo data loader on startup, so you may 
> > now log in to trunk builds as:
> >
> > user1/pass1
> > user2/pass2
> > ...
> > user999/pass999
> >
> > Each user is a members of one series (series_0 through series_99), so once 
> > the admin UI has the ability to set access control on series, you can test 
> > which users have access to which mediapackages.
> >
> > There are (at least) two major changes to the authentication system.  
> > First, I've encrypted the passwords that we store in the database.  This 
> > means that regular user accounts can *not* log in via digest 
> > authentication, since digest relies on having clear text passwords to 
> > compare hashes.  I believe this to be a positive step forward in terms of 
> > security, but it might break some scripts out there.  By default, the 
> > matterhorn_system_account/CHANGE_ME account is still operational, so all 
> > HTTP remoting via the TrustedHttpClient will function like it always has.
> >
> > Second, I've added a configuration for setting the default welcome page, 
> > based on the user's role.  So if an administrator attempts to access "/", 
> > s/he will be redirected to /welcome.html upon successful login.  Other 
> > users will be sent directly to /engage/ui/index.html.  If a user attempts 
> > to access something specific, other than "/", s/he will be redirected to 
> > that URI once again after successful login.  The configuration looks like 
> > this:
> >
> >       <map>
> >         <entry key="ROLE_ADMIN" value="/welcome.html" />
> >         <entry key="ROLE_USER" value="/engage/ui/index.html" />
> >         <entry key="*" value="/engage/ui/index.html" /> <!-- Any role not 
> > listed explicitly will redirect here -->
> >       </map>
> >
> >
> > Please be sure to copy the latest config files to $FELIX/config.properties 
> > and $FELIX/conf/security/mh_default_org.xml, and let me know if you have 
> > any questions.  If everything works smoothly, and folks are happy (or at 
> > least quiet), I'll promote this mini-doc to the wiki.
> >
> > Thanks,
> > Josh
> > _______________________________________________
> > Matterhorn mailing list
> > [email protected]
> > http://lists.opencastproject.org/mailman/listinfo/matterhorn
> >
> >
> > To unsubscribe please email
> > [email protected]
> > _______________________________________________
> 
> _______________________________________________
> Matterhorn mailing list
> [email protected]
> http://lists.opencastproject.org/mailman/listinfo/matterhorn
> 
> 
> To unsubscribe please email
> [email protected]
> _______________________________________________
> 
> _______________________________________________
> Matterhorn mailing list
> [email protected]
> http://lists.opencastproject.org/mailman/listinfo/matterhorn
> 
> 
> To unsubscribe please email
> [email protected]
> _______________________________________________

_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn


To unsubscribe please email
[email protected]
_______________________________________________

Reply via email to