Alrighty, first attempt at hooking Beehive up with OID and SSO. I love the fact that Beehive is a standalone product, making it easier to deploy quickly and without scrolling through certification matrices making sure it's compatible with your particular version of OID and SSO and Portal and blah blah....
But, what happens when you actually do have OID as your identity source and want to hook it up. I mean, why wouldn't you, you've spent the last 5 years ensuring OID is the source of identity, now Beehive comes along and says, "yeah you can do it, but you don't have to...", well, I WANT TO!
So lets give it a try. This post will concentrate on OID, I'll fire in another entry for the SSO integration.
You may have seen my Beehive 1.3 install not so long ago...
I also just happen to have a fresh new instance of OID 10.1.4.1 sitting around as well.. it's straight out of the box, nothing fancy.
Only one users has been created so far, nice and original:
firstname: first1
lastname: last1
uid: flast1
email: flast1@acme.com
I'm going to be taking my lead from Chapter 11 - Integrating and Synchronizing LDAP with Oracle Beehive of the Oracle Beehive Installation Guide for Linux
I won't go into the in's and out's of how and why and what happens. You can read the install guide for that. I want to actually do it, you can come along for the ride and watch me get bruised and battered by the experience.
Just quickly, this is what it says I should do:
- Create a map between OID and UDS (Oracle Beehive User Directory Service) users/groups - called a profile
- Plug the profile into Beehive
- Enable it
- Test it.
- Get a coffee and relax.
I admit, that last one I put in, but seriously, if you get Beehive hooked up to OID, the jobs almost done. You'll have all your users able to access Beehive, sweet!. OK, so there's the little issue of trying to import the existing data from email and calendar and chat and discussions and workspaces and stuff like that...
OK breathe... in....out....in....out....Sorry, didn't mean to scare you.
Lets get this OID thing done.
Thankfully, (and as expected), to create the map for UDS - OID, a template is provided. (In fact there's more templates than you can poke a stick at!)
Under $ORACLE_HOME/beehive/template/uds is the file - oidprofile_template.xml
We need to update it with our details, I'm not going to write down what I did, coz it's not going to mean much to you, check the guide to see what needs to change.
Here's a tip for new players, make sure you remove the < and > from comments within the xml file...
ie
...
<user_search_base><enter user search base></user_search_base>
<group_search_base><enter group search base></group_search_base>
...
Sounds obvious doesn't it. Depending on where you accidentally leave one, it'll let you upload no probs, then you sit around scratching your head for a few minutes trying to figure out why
[orabee@radium ~]$ beectl list_directory_profiles --file oidprofile.xml
doesn't return anything.... My accidental > was on
<primary_authentication_attribute>uid></primary_authentication_attribute>
No wonder it didn't work.
Another tip, you require the Enterprise name and Organization name for the map, which you can get via
[orabee@radium ~]$ beectl list_enterprises
and
[orabee@radium ~]$ beectl list_organizations --scope <Identifier returned from above query>
But, for some reason, I was getting errors with this last one.
ErrorCode:[BEES-06000,SEVERE,Unexpected error.]
Effect: The requested operation cannot be performed
Action: Contact system administrator.
I ended up restarting the whole lot and it worked after that... strange.
Hmm, another tip, since I'm here...
If an entry in the XML file is not mandatory (don't ask me how you figure that out :-) you can just remove the line. Don't leave the line in with the default comment, or remove the comment and leave the <field></field> there, neither get past the XML parser. (And yet the added > did...)
Ummm, what else.
You need the obfuscated password for orcladmin in the profile. This is an easy one:
$ beectl obfuscate
--DON'T FORGET, it's the ORCLADMIN password you're obfuscating, not beeadmin's...
Final tip.
Step E: Providing Scope and Membership Mapping Information was a bit confusing at first, until I read the bit below
This excerpt maps the following entries:
* A user that is under the attribute OU=Alpha will be scoped within the organization My_Organization.
* A user that is under the DN dc=us,dc=oracle,dc=com will scoped within the enterprise My_Enterprise. A user that is under the attribute dc=external,dc=us,dc=example,dc=com will scoped within the same enterprise (My_Enterprise). The same user will be a member of the organization My_Organization.
Which, because my OID install is Vanilla, I don't care about, so the first section in the guide can be ignored... might be handy in future when trying to map multiple Organizations.
The whole back half of the map I didn't touch, from <directory_attribute_map> down, as I don't have anything in particular in OID I want mapped across. If you've got something you require mapping, you'll need to look at that bit in more detail.
So after all that, this is how the profile upload should look...
[orabee@radium uds]$ beectl add_directory_profile --file oidprofile_template.xml
Start profile OID_BEEHIVE_PROFILE validation.
Successfully validated the profile OID_BEEHIVE_PROFILE.
Changes to configuration repository are not activated.
Successfully added 1 directory profiles.
Even though it shows it's already ENABLED, I figured why not:
[orabee@radium uds]$ beectl modify_property --component OID_BEEHIVE_PROFILE --name ProfileState --value ENABLE
[orabee@radium uds]$ beectl activate_configuration
Proposed configuration is saved successfully and activated now.
Let's grab the users from OID ready to test the map.
[orabee@radium uds]$ beectl download_ldap_user_data --file UsersFromLdap.xml --profile OID_BEEHIVE_PROFILE
File:$ORACLE_HOME/templates/uds/UsersFromLdap.xml is generated on host:radium
See the log files for this run on machine radium.
LDAP User extraction messages.
Successfully extracted data for 3 users.
Failed to extract data for 0 users.
Total users 3.
User XML generation messages.
Successfully generated xml data for 3 users.
Failed to generate xml data for 0 users.
Total users 3.
Looking at the file generated, I've got orcladmin, PUBLIC, and my flast1 user.
Let's add them to Beehive.
[orabee@radium uds]$ beectl add_user --file UsersFromLdap.xml --ldapbootstrap
Created 1 users.
Failed to create 2 users.
Total users 3.
User : PUBLIC addition failed. Reason: The specified address is invalid
User : orcladmin addition failed. Reason: The specified address is invalid
Sounds about right, neither PUBLIC or orcladmin had email addresses, so why should it add them.
BTW, the reason for adding the users is that since we've got the synchronisation happening between OID and Beehive's UDS (User Directory Service), all future changes will be brought across, it's everything before now that we needed to get.
OK, time to switch across to ldap for the Authentication Service
[orabee@radium uds]$ beectl list_properties --component _AuthenticationService --name AuthStoreType
-----------------+--------------------------------------------------------------
Property name | Property value
-----------------+--------------------------------------------------------------
AuthStoreType | db
-----------------+--------------------------------------------------------------
[orabee@radium uds]$ beectl modify_property --component _AuthenticationService --name AuthStoreType --value ldap
Changes to configuration repository are not activated.
Successfully stored the property for component id 2a7e1102-4ceb-4a14-8815-72503ba958f1.
[orabee@radium uds]$ beectl activate_configuration ; beectl modify_local_configuration_files
BEECTL figured out it needs a restart to move across, so down it goes, and up it comes...
[orabee@radium uds]$ beectl list_properties --component _AuthenticationService --name AuthStoreType
-----------------+--------------------------------------------------------------
Property name | Property value
-----------------+--------------------------------------------------------------
AuthStoreType | ldap
-----------------+--------------------------------------------------------------
Check if the user authenticates...
orabee@radium uds]$ beectl
beectl> login --authuser flast1 --authpassword XXXXXX
User flast1 is successfully authenticated and logged in.
Awesome, now for the big test, create a user in OIDDAS and see how it goes. Yep you guessed it:
firstname: first2
lastname: last2
uid: flast2
email: flast2@acme.com
User created, now, remembering the following entry in the profile...
[orabee@radium uds]$ beectl list_properties --component OID_BEEHIVE_PROFILE --name PollInterval
-----------------+--------------------------------------------------------------
Property name | Property value
-----------------+--------------------------------------------------------------
PollInterval | 600
-----------------+--------------------------------------------------------------
I've got 5 minutes to wait before getting worried, I'm off for a coffee...
Would you look at that. my flast2 user can log in (on the right), but not only that, have a look at where I'm coming from.. my DMZ install.
How easy was that... Next time, SSO.
