Archive for the ‘Users’ Category

Oh boy. it’s late and I’ve been working quite hard lately, both on the current day job and lately with my side project which is what I wanted to share with everyone here and now.
I’ve started writing some training course material about the CSSDK in all its glory in the hope that someone out there would take me up on the offer and sign up for a training session.
It’s early stages yet, although I’ve already written 5 sections out of what I think will be about 10. This means I’m half way there (Hurray!) and that means I need to start broadcasting this to the whole wide world and start generating some interest. An interesting point is Interwoven Autonomy HP (?) does not seem to cover it in any great detail.
Up until now, I have written (besides the training plan):
  • a succinct introduction,
  • a chapter on how to configure the IDE with the TeamSite jars and JavaDocs,
  • a chapter on the CSFactory and getting connected to teamsite (locally and via SOAP, if you please),
  • a chapter on the common package, the CSClient and other assorted bits
  • a chapter on users, groups and roles and operations.

Impressions to this date on the work has been fairly positive. I’ve enjoyed writing it and I was surprised at how much there is to actually say about users and group, the biggest chapter to date. I’ve learnt a fair bit about the new features of the latest release and discovered a couple of tricks along the way. I can’t wait to share them!

I’ll post progress reports in the blog. That’ll keep me motivated to keep writing and also this will whet your appetite to want to learn more about what I’m currently doing. Some of you may think you don’t need this kind of training and you might be right, but can you answer this question quickly off the top of your head?

“Which objects would you use to add a user to a branch with the editor role using the CSSDK?”

The answer, as it happens, is in the training course so I wont actually give you it straight away. Oh, and if anyone from HP is reading this, you can buy my company any day of the week and improve your offering (ooh, controversial)!

Advertisements

LDAP configuration

Posted: 22 January 2010 in Architecture, Security, Teamsite, Users

To enable LDAP authentication for the teamsite environment, you need to look in the file

conf/roles/user_databases.xml

This file details each ldap server to connect to to authenticate the users. The root element is iwuser_databases and it contains iwldap elements defining each ldap direfctory you would like to use. The iwldap element contains the following sub elements:

  • server: the ip address or host name of the ldap server
  • port: the port number where the ldap server is linstening on. This is usually 389.
  • search_key: when searches are performed, what teamsite user field is being passed to the ldap server. This is where the account name is stored in the ldap. Leave this at uid in most cases.
  • dnBase: which ldap directory part contains the list of users.
  • attr_email: The ldap field that teamsite can use as the email address.
  • attr_display_name: the ldap field that teamsite will use to display user information on.
  • Additional elements are present to connect to the ldap and pass authentication to it:
  • ssl_port: to connect to the secure ldap server
  • CAFile: the path to the certificate authority file.
  • account: the username to connect to the ldap with (for non anonymous queries)
  • password: the ecrypted password to pass along with the username to connect to the ldap.

To retrieve the encrypted version of the password you want to pass, follow the following procedure:

IWCLT_PASSWORD="passwordIWantToEncrypt"
export IWCLT_PASSWORD
iwuseradm encrypt-userdatabase-pwd

This outputs a string to the standard output. Copy this as the value of the password element.

The iwldap element also has the following attributes:

  • id: internally unique identifyer to this ldap entry.
  • display_name: what the user administrator sees when querying the ldap, to select in the drop-down list when adding users for example.
  • os: either “t” or “f”, respectively for true or false. t indicates that a valid os account must also be associated with this ldap entry. f indicates that this ldap contains entries not associated with os accounts.

users can be synchronised with the ldap automatically (possibly the wrong choice of wording here from iwov!). That means that in that case, users get added to the ldap – not to teamsite. and it’s the ldap that manages the users on teamsite’s behalf. This is done by adding an attr_sync element. The ldap entry will in this case also contain which access is granted to a user in teamsite. The ldap field can contain the values

  • master,
  • tsuser,
  • ccpro,
  • ccstd,
  • ccpro_only,
  • ccstd_only,
  • or a comma-separated combination of the above, provided it makes sense (e.g. master|tsuser, ccpro|ccstd,ccpro_only|ccstd_only).

Which ldap field you use for this information is up to you. All you need to do is reference it in the name attribute of the attr_sync element. If you want to have the users added to teamsite manually with reference to the ldap, simply do not include the attr_sync element.

The allowed element inside text, textarea, select, radio, checkbox, readonly and hidden works fine on datacapture forms within forms publisher. Whenever a workflow instantiation form uses the allowed element, it’s not using it to use the instance designed by it.

<item pathid=”somepath” name=”somepath”>
<text>
<allowed><cred role=”master” /></allowed>
</text>
<readonly />
</item>

This snippet of XML should have allowed masters to edit the field and anyone else would just be able to look at it without modifying it. Though this works fine in forms publisher, the workflow engine’s rendition does not concern itself with such authorisation.

Instead, formAPI has to be used. To find out the current user’s name, group and roles, we can use the IWDatacapture’s getUser(), getGroups() and getRoles() methods and show or hide the fields as we please.

getUser() returns the short username (not “Laurent Picquet” but “lpiquet”), getGroups() returns an array of group names the current user belongs to and getRoles() returns an array of roles the current user has in the the current branch (“admin,master” in my case).

var roles = IWDatacapture.getRoles();
 var isMaster=false;
 for (var i in roles){
 if (roles[i]=='master'){
 isMaster=true;
 }
 }
 prompt("isMaster",isMaster);

Getting a connection to the TeamSite server is not a complicated story. The process has 2 steps. First, we get a Factory object which is responsible for returning a client given a transport layer. CSLocalFactory works with JNI and CSSOAPFactory works with SOAP.

Factories

By default, connection properties are defined in a configuration file and you can find one directly in the cssdk subdirectory of the TeamSite installation directory, named cssdk.cfg. We’ll use that file to create a factory of the right type.

String configFilePath = "/apps/interwoven/teamsite/cssdk/cssdk.cfg";
Properties localProperties = new Properties();
localProperties.setProperty("cssdk.cfg.path", configFilePath);
CSLocalFactory csLocalFactory = (CSLocalFactory) CSLocalFactory.getFactory(localProperties);

Clients

Once the factory has been created, we can use it to create a client for us. The client must be authenticated so here we really have 2 choices: we can either give the factory a username and password, or we can tell it to find out who we are from the operating system and log us in directly.

CSClient client = csLocalFactory.getClientForCurrentUser(Locale.ENGLISH, "MyAppName", "localhost");

The CSPrincipalManager is the class responsible with creating users and groups. If we want to create a user, we call the createTSUser() method and likewise, we call the createTSGroup() method to create a group.

CSPrincipalManager principalManager=client.getPrincipalManager();
String name="johndoe";
int kind=CSUser.TS_OS_USER;
String password=null;
String displayName="John Doe";
String description="We don't really know who John Doe really is.";
String emailAddress="john.doe@acme.com";
String preferredUI=CSUser.PREFERRED_UI_CCSTD_ONLY;
boolean isMaster=false;

CSUser someUser=principalManager.createTSUser(name, kind, password, displayName, description, emailAddress, preferredUI,isMaster);

the kind referes to the type of users. As of 6.7.2, users can be non-OS users. This is entered as an  int represented by class constants such as CSUser.TS_OS_USER. For the prefered interface, the CSUser class also provides some constants such as CSUser.PREFERRED_UI_CCSTD_ONLY.

CSPrincipalManager principalManager=client.getPrincipalManager();

String name="marketing";
CSUser[] users=new CSUser[0];
CSGroup[] groups=new CSGroup[0];
CSUser[] admins={client.getcurrentUser()};
String displayName="The marketing team";
String description="The marketing team provides leadership, sales support, promotions and market relations";

CSGroup someGroup = principalManager.createTSGroup(name, users, groups, admins, displayName,description);

Deleting a user or a group is simply done by invoking the delete() method on the object

if (someUser!=null){
    someUser.delete();
}
if (someGroup!=null){
    someGroup.delete();
}