I get a lot of emails each day (as I'm sure most people do nowadays). Most of it is rubbish and can be binned immediately, some of it is from people I already know quite well and then some of it is from people who are introducing themselves to me. These new people could be people who want to hook up on LinkedIn or Facebook and tend to have job offers for me or are looking for a job.
My first reaction these days is to ask my good friend Google to do a background check on these people. That way, I'll get to maybe see a photo of them - putting a face to a name is always a good thing - and I'll get to see what they are up to, what their interests are and whether there is any point in responding to their introduction.
And so it came to pass that I did precisely this yesterday but with the result that I found someone's Twitter account and their last tweet was asking for payment from another Twitterer via bank transfer. Astonishingly, this tweet also contained my new acquaintance's account details - Sort Code & Account Number.
I pondered this information for only a short time. I had this person's name, address, sort code, account number, list of friends and interests within just a couple of minutes. If I was so inclined, I could have some fun with the information as I'm sure others would dearly like to do.
We should always be mindful that the information we release on to our computers then in to the WWW is accessible by others. Not only can the information be damaging to our reputation, but in the case above, our bank accounts could come under threat. That's not to say that we should stop releasing information, of course. We just need to be a little more careful about what we say, to whom and choose the medium to communicate wisely!
Thursday, January 13, 2011
Friday, December 31, 2010
Happy New Year
2010 is drawing to a close. Indeed, it is not long to go before I can open the Champagne and welcome in 2011! So it should be a good time to reflect on the past twelve months. The pagans used to burn the yule log for 12 days and some like to think that each day was devoted to reflecting on one of the preceding months. The first day of yule would be spent reflecting on January; the second on February and so on.
Fortunately for those of you who happen upon this blog, my memory isn't so good and I am incapable of remembering what happened yesterday never mind dream up something interesting to remark upon for each month of the year!
What I do remember, however, is this:
January
I felt very alone in January as I managed to get stuck in Oxford during some very heavy downfalls of snow. That said, I used the time wisely by visiting Rauls cocktail bar for something to warm the tummy!
February
My time in Oxford drew to a close. In a way, I miss the friends I made there. Matt and Fizzy-pop will be hard to forget!
March
I managed to finalise a new adapter for IBM Tivoli Identity Manager with some considerable input from RACF guru, Alan Harrison. The adapter is an extension of the IBM RACF Adapter but it reconciles additional information from the zSecure suite of utilities to give a complete view of RACF data from within ITIM. ITIM was enhanced to provide reporting functionality which allowed ITIM users to see vital RACF information and security breaches.
April
I know it was my birthday during this month. But for the life of me, I can't seem to remember too much about it. I do know that I was working on an HR Feeder mechanism for a Tier One bank. But, let's be honest, in the world of Identity Management, this is pretty much step 1! Been there. Done that. Countless times, even.
May
Nothing to say about May. Did it happen? Actually, I did knock together a website for a friend of mine one weekend.
June
I spent some time extending the OPAL-based APIScript for IBM Tivoli Identity Manager with functionality that should make the building of future ITIM environments a lot simpler!
July
My first forays into the world of IBM Tivoli Directory Integrator and Twitter integration. I was mildly excited by the possibilities even if the enterprise world is not!
August
Continuing my extra-curricular activities with TDI, I decided to see how Active MQ could be used to pull together a high-availabilty solution for TDI messaging. Results were positive though Active MQ isn't something I've actually come across in use by the customers I deal with. I got into some bother with some ladies this month! Owls Ladies Hockey Club wanted their website updated and I said I'd do it for free (as I do have a connection with Owls, albeit tenuous). So, another weekend lost, but the result seemed to please the girls: http://www.owlsladies.com/
September
I finalised TDI connectors for Google and Salesforce and even wrapped them in to ITIM Adapters. These are now being actively marketed by my employers, Pirean, and further details can be found on their website. My wife also coaxed me in to putting together a simple website for her one weekend... she wanted to showcase some of her artwork. Here's a plug for her work: http://www.jackiespence.com/
October
October was spent enjoying the sights and sounds of London on an engagement with one of the big universities in the city. Productivity seemed to be at an all-time high as integration guides for Tivoli Access Manager seemed to materialise with great rapidity! Lotus Connections, Quickr, MySource Matrix and Moodle integration were defined, tested and deployed at such a rate that I got called a Legend. I like that name. I like customers calling me Legend. I didn't realise how much I'd like it until it happened. It may never happen again, so I need to make sure that this particular episode is recorded for future posterity! For reference, it was dilftechnical who called me that.
November
I finally got round to posting an article about my Twitter connector for IBM Tivoli Directory Integrator based on an open-source OAuth library and JTwitter. I can only imagine that it was this article that prompted the great Eddie Hartman to phone me and also send me a Metamerge pen as a thank you. I shall treasure the pen always - or at least until it runs out of ink.
December
More snow. Thankfully, I spent most of the month working from home and rarely had to get out of my slippers never mind brave the 10 inches of snow outside my window!
So that was the year that was. Here's looking forward to a fabulous 2011. Happy New Year.
Fortunately for those of you who happen upon this blog, my memory isn't so good and I am incapable of remembering what happened yesterday never mind dream up something interesting to remark upon for each month of the year!
What I do remember, however, is this:
January
I felt very alone in January as I managed to get stuck in Oxford during some very heavy downfalls of snow. That said, I used the time wisely by visiting Rauls cocktail bar for something to warm the tummy!
February
My time in Oxford drew to a close. In a way, I miss the friends I made there. Matt and Fizzy-pop will be hard to forget!
March
I managed to finalise a new adapter for IBM Tivoli Identity Manager with some considerable input from RACF guru, Alan Harrison. The adapter is an extension of the IBM RACF Adapter but it reconciles additional information from the zSecure suite of utilities to give a complete view of RACF data from within ITIM. ITIM was enhanced to provide reporting functionality which allowed ITIM users to see vital RACF information and security breaches.
April
I know it was my birthday during this month. But for the life of me, I can't seem to remember too much about it. I do know that I was working on an HR Feeder mechanism for a Tier One bank. But, let's be honest, in the world of Identity Management, this is pretty much step 1! Been there. Done that. Countless times, even.
May
Nothing to say about May. Did it happen? Actually, I did knock together a website for a friend of mine one weekend.
June
I spent some time extending the OPAL-based APIScript for IBM Tivoli Identity Manager with functionality that should make the building of future ITIM environments a lot simpler!
July
My first forays into the world of IBM Tivoli Directory Integrator and Twitter integration. I was mildly excited by the possibilities even if the enterprise world is not!
August
Continuing my extra-curricular activities with TDI, I decided to see how Active MQ could be used to pull together a high-availabilty solution for TDI messaging. Results were positive though Active MQ isn't something I've actually come across in use by the customers I deal with. I got into some bother with some ladies this month! Owls Ladies Hockey Club wanted their website updated and I said I'd do it for free (as I do have a connection with Owls, albeit tenuous). So, another weekend lost, but the result seemed to please the girls: http://www.owlsladies.com/
September
I finalised TDI connectors for Google and Salesforce and even wrapped them in to ITIM Adapters. These are now being actively marketed by my employers, Pirean, and further details can be found on their website. My wife also coaxed me in to putting together a simple website for her one weekend... she wanted to showcase some of her artwork. Here's a plug for her work: http://www.jackiespence.com/
October
October was spent enjoying the sights and sounds of London on an engagement with one of the big universities in the city. Productivity seemed to be at an all-time high as integration guides for Tivoli Access Manager seemed to materialise with great rapidity! Lotus Connections, Quickr, MySource Matrix and Moodle integration were defined, tested and deployed at such a rate that I got called a Legend. I like that name. I like customers calling me Legend. I didn't realise how much I'd like it until it happened. It may never happen again, so I need to make sure that this particular episode is recorded for future posterity! For reference, it was dilftechnical who called me that.
November
I finally got round to posting an article about my Twitter connector for IBM Tivoli Directory Integrator based on an open-source OAuth library and JTwitter. I can only imagine that it was this article that prompted the great Eddie Hartman to phone me and also send me a Metamerge pen as a thank you. I shall treasure the pen always - or at least until it runs out of ink.
December
More snow. Thankfully, I spent most of the month working from home and rarely had to get out of my slippers never mind brave the 10 inches of snow outside my window!
So that was the year that was. Here's looking forward to a fabulous 2011. Happy New Year.
Friday, December 17, 2010
The Perils Of Privilieged Identities
It seems that Privileged Identity Management is the long-slumbering beast that has finally awoken and organisations are now scratching their heads wondering what it means to them and (more crucially) how they are going to address the problems posed by the it.
The issue of privileged accounts is certainly not a new one. Operating Systems have always had the concept of a root or administrator account, for example. These super accounts are not the kind of accounts that people should be using on a business as usual basis (though I suspect this "rule" is a case of Do As I Say, Not As I Do). Sometimes, though, there is just no way of getting around the need to access a system or application with a privileged account.
Rogue insider employees are on the increase, if press reports are to be believed. Indeed, it is probably a fair comment given that staff turnover has increased dramatically in recent years! So it makes a lot of sense to ensure that employees don't have permanent access to credentials that can cause damage to your IT infrastructure. And so... Privileged Identity Management has finally come of age.
Or has it?
IBM, earlier this year, announced an initiative based on the integration of Tivoli Access Manager for Enterprise Single Sign On and Tivoli Identity Manager to address the needs of privileged access and details of their solution can be found in their Redguide publication: "Centrally Managing and Auditing Privileged User Identities by Using the IBM Integration Services for Privileged Identity Management".
It works on the basis of being able to elevate your privileges upon request and having TAM ESSO check-out the elevated privileges from an ITIM vault and inject the credentials into the target platform/application login sequence without the end user ever having to know the privileged account's password. Sounds like genius, right? Maybe. It certainly a neat way of taking the best bits of two fairly solid applications to cater for a gap in both products. And in the main it ought to work... at least for those applications that TAM ESSO can integrate with.
Most software applications that claim to provide a solution to the privileged access rights problem only seem to do so for either the Windows administrator accounts or the Unix administrator accounts and almost forget about those other special accounts that reside inside of applications. TAM ESSO can therefore help resolve that. However, this is only true for accessing a system with elevated privileges. What about changing passwords on a frequent basis and changing passwords after account use?
One of the reasons why privileged accounts have been causing so much pain is because organisations are scared to change the passwords for these accounts for fear that their systems will break! That's certainly a fair comment, in my opinion. We all know that applications shouldn't bind to a Directory Server with the cn=root account, but I bet they do. And when that account's password is changed, what will happen? Where within the application is the password for cn=root stored? In a properties file? In a database? How should the password be updated? Do we have to stop the application first? What if there are multiple applications using that account? Do we need a major outage of our systems? Maybe we should do it at a weekend, what do you think?
So the solution described in the Redguide publication goes a long way to plug a gap. The supposed industry leading solutions for Privileged Identity Management also go a long way to help alleviate the problem. But it seems to me that there are still issues needing addressing!
Ultimately, the right answer for delivering a solution will be dependent on:
The issue of privileged accounts is certainly not a new one. Operating Systems have always had the concept of a root or administrator account, for example. These super accounts are not the kind of accounts that people should be using on a business as usual basis (though I suspect this "rule" is a case of Do As I Say, Not As I Do). Sometimes, though, there is just no way of getting around the need to access a system or application with a privileged account.
Rogue insider employees are on the increase, if press reports are to be believed. Indeed, it is probably a fair comment given that staff turnover has increased dramatically in recent years! So it makes a lot of sense to ensure that employees don't have permanent access to credentials that can cause damage to your IT infrastructure. And so... Privileged Identity Management has finally come of age.
Or has it?
IBM, earlier this year, announced an initiative based on the integration of Tivoli Access Manager for Enterprise Single Sign On and Tivoli Identity Manager to address the needs of privileged access and details of their solution can be found in their Redguide publication: "Centrally Managing and Auditing Privileged User Identities by Using the IBM Integration Services for Privileged Identity Management".
It works on the basis of being able to elevate your privileges upon request and having TAM ESSO check-out the elevated privileges from an ITIM vault and inject the credentials into the target platform/application login sequence without the end user ever having to know the privileged account's password. Sounds like genius, right? Maybe. It certainly a neat way of taking the best bits of two fairly solid applications to cater for a gap in both products. And in the main it ought to work... at least for those applications that TAM ESSO can integrate with.
Most software applications that claim to provide a solution to the privileged access rights problem only seem to do so for either the Windows administrator accounts or the Unix administrator accounts and almost forget about those other special accounts that reside inside of applications. TAM ESSO can therefore help resolve that. However, this is only true for accessing a system with elevated privileges. What about changing passwords on a frequent basis and changing passwords after account use?
One of the reasons why privileged accounts have been causing so much pain is because organisations are scared to change the passwords for these accounts for fear that their systems will break! That's certainly a fair comment, in my opinion. We all know that applications shouldn't bind to a Directory Server with the cn=root account, but I bet they do. And when that account's password is changed, what will happen? Where within the application is the password for cn=root stored? In a properties file? In a database? How should the password be updated? Do we have to stop the application first? What if there are multiple applications using that account? Do we need a major outage of our systems? Maybe we should do it at a weekend, what do you think?
So the solution described in the Redguide publication goes a long way to plug a gap. The supposed industry leading solutions for Privileged Identity Management also go a long way to help alleviate the problem. But it seems to me that there are still issues needing addressing!
Ultimately, the right answer for delivering a solution will be dependent on:
- the customer's appetite for solving the problem completely
- the customer's appetite for risk
- the customer's financial muscle when it comes to licensing software solutions
Thursday, November 25, 2010
Twitter and TDI - Part 3
A while back, I wrote myself a Twitter connector for Tivoli Directory Integrator. I was bored one weekend and it seemed like an interesting exercise. After all, it was a good opportunity to find out about Twitter's migration to OAuth.
I didn't want a complicated Twitter connector. It only had to perform a handful of functions:
I didn't want to bother with direct messaging or retweeting or geo-location or anything fancy. After all, my intention was to show how I could get TDI respond to events posted on Twitter and repond to other events by posting an update on Twitter. (In short, use Twitter as a less-enterprise like MQ system!)
I'm glad to say that the experiment worked and I provide it to the populace at large to take a look at. For a sneak preview, here's the main connector:
In the example above, I'm processing Twitter Object Types of "Tweets: Other" and looking at Stephen Fry's tweets. The Consumer Key/Secret and Access Key/Secret are not displayed for obvious reasons! Indeed, obtaining the key/secret combinations is a little fiddly though there is plenty of documentation out there to help you obtain that info from Twitter.
Running an AL with the connector in iterator mode pointed at "stephenfry" results in the following work entries being dumped in my log:
CTGDIS087I Iterating.
CTGDIS003I *** Start dumping Entry
Operation: generic
Entry attributes:
date (replace): 'Thu Nov 25 09:24:58 GMT 2010'
tweet (replace): 'Damnably chilly on the Sherlock Holmes set this morning. Frost forming on the supporting artists' moustaches...'
CTGDIS004I *** Finished dumping Entry
CTGDIS003I *** Start dumping Entry
Operation: generic
Entry attributes:
date (replace): 'Thu Nov 25 07:06:52 GMT 2010'
tweet (replace): 'Lordy. 260 all out. Knew we shouldn't write Australia off. A wounded wallaby us a dangerous thing. Ho hum. Business as usual. #theashes'
CTGDIS004I *** Finished dumping Entry
CTGDIS003I *** Start dumping Entry
Operation: generic
Entry attributes:
date (replace): 'Wed Nov 24 17:40:50 GMT 2010'
tweet (replace): '@AWOLTom Already have...'
CTGDIS004I *** Finished dumping Entry
CTGDIS003I *** Start dumping Entry
Operation: generic
Entry attributes:
date (replace): 'Wed Nov 24 16:55:24 GMT 2010'
tweet (replace): 'The fine is taken care of, but there is a fighting fund @TwJokeTrialFund http://bit.ly/cTK2Li A fiver from you to help the appeal?'
CTGDIS004I *** Finished dumping Entry
Wow, you may be thinking. But why would I want to do that?
Indeed. I guess, as I have alluded to in this blog before, you could have your assembly lines "tweet" upon component failure so that an out-of-hours support person can respond. After all, tweets can easily be delivered to smartphones at no cost to the organisation.
Alternatively, you could remotely control assembly lines using this mechanism. Just think, I could tweet "Start HR Feed" to my personal twitter-stream and I could have an assembly line iterating through my twitter-stream just waiting for the instruction to start processing that feed! (NOTE: I wouldn't necessarily advocate that this is a great way of managing your production schedule!)
The connector and supporting JAR files can be retrieved from here:
NOTE: jtwitter.jar and signpost-core.1.2.1.1.jar are open source code provided elsewhere on the net. I've added these versions here as they are known to work with my connector.
Drop the twitterConnector.jar into TDI_HOME/jars/connectors. Drop the other JARs into TDI/HOME/jars/3rdparty.
If you need help getting your keys/secrets, I may be able to sort you out, though you will probably appreciate figuring it out for yourself in the long run.
For those interested in the underlying code, it is really very simple. A bind to Twitter using OAuth can be achieved in two lines of code:
// Make an oauth client
OAuthSignpostClient oauthClient = new OAuthSignpostClient(
this.twitterConsumerKey,
this.twitterConsumerSecret,
this.twitterAccessKey,
this.twitterAccessSecret
);
// Make a Twitter object
this.twitterBind = new Twitter(this.twitterUser, oauthClient);
Sending a tweet is a single line of code:
And iterating through tweets is a matter of invoking one of four methods, like this:
You can look through TwitterConnector.java to get a feel for the full source code.
I've had fun building the connector and it can certainly ease the pain of putting together Assembly Lines that need to make calls to Twitter by having such a neat interface. I hope you have fun too.
I didn't want a complicated Twitter connector. It only had to perform a handful of functions:
- Send a tweet
- Iterate through my tweets
- Iterate through my friends' tweets
- Iterate through the public timeline
- Iterate through a specific person's tweets (other than mine)
I didn't want to bother with direct messaging or retweeting or geo-location or anything fancy. After all, my intention was to show how I could get TDI respond to events posted on Twitter and repond to other events by posting an update on Twitter. (In short, use Twitter as a less-enterprise like MQ system!)
I'm glad to say that the experiment worked and I provide it to the populace at large to take a look at. For a sneak preview, here's the main connector:
In the example above, I'm processing Twitter Object Types of "Tweets: Other" and looking at Stephen Fry's tweets. The Consumer Key/Secret and Access Key/Secret are not displayed for obvious reasons! Indeed, obtaining the key/secret combinations is a little fiddly though there is plenty of documentation out there to help you obtain that info from Twitter.
Running an AL with the connector in iterator mode pointed at "stephenfry" results in the following work entries being dumped in my log:
CTGDIS087I Iterating.
CTGDIS003I *** Start dumping Entry
Operation: generic
Entry attributes:
date (replace): 'Thu Nov 25 09:24:58 GMT 2010'
tweet (replace): 'Damnably chilly on the Sherlock Holmes set this morning. Frost forming on the supporting artists' moustaches...'
CTGDIS004I *** Finished dumping Entry
CTGDIS003I *** Start dumping Entry
Operation: generic
Entry attributes:
date (replace): 'Thu Nov 25 07:06:52 GMT 2010'
tweet (replace): 'Lordy. 260 all out. Knew we shouldn't write Australia off. A wounded wallaby us a dangerous thing. Ho hum. Business as usual. #theashes'
CTGDIS004I *** Finished dumping Entry
CTGDIS003I *** Start dumping Entry
Operation: generic
Entry attributes:
date (replace): 'Wed Nov 24 17:40:50 GMT 2010'
tweet (replace): '@AWOLTom Already have...'
CTGDIS004I *** Finished dumping Entry
CTGDIS003I *** Start dumping Entry
Operation: generic
Entry attributes:
date (replace): 'Wed Nov 24 16:55:24 GMT 2010'
tweet (replace): 'The fine is taken care of, but there is a fighting fund @TwJokeTrialFund http://bit.ly/cTK2Li A fiver from you to help the appeal?'
CTGDIS004I *** Finished dumping Entry
Wow, you may be thinking. But why would I want to do that?
Indeed. I guess, as I have alluded to in this blog before, you could have your assembly lines "tweet" upon component failure so that an out-of-hours support person can respond. After all, tweets can easily be delivered to smartphones at no cost to the organisation.
Alternatively, you could remotely control assembly lines using this mechanism. Just think, I could tweet "Start HR Feed" to my personal twitter-stream and I could have an assembly line iterating through my twitter-stream just waiting for the instruction to start processing that feed! (NOTE: I wouldn't necessarily advocate that this is a great way of managing your production schedule!)
The connector and supporting JAR files can be retrieved from here:
NOTE: jtwitter.jar and signpost-core.1.2.1.1.jar are open source code provided elsewhere on the net. I've added these versions here as they are known to work with my connector.
Drop the twitterConnector.jar into TDI_HOME/jars/connectors. Drop the other JARs into TDI/HOME/jars/3rdparty.
If you need help getting your keys/secrets, I may be able to sort you out, though you will probably appreciate figuring it out for yourself in the long run.
For those interested in the underlying code, it is really very simple. A bind to Twitter using OAuth can be achieved in two lines of code:
// Make an oauth client
OAuthSignpostClient oauthClient = new OAuthSignpostClient(
this.twitterConsumerKey,
this.twitterConsumerSecret,
this.twitterAccessKey,
this.twitterAccessSecret
);
// Make a Twitter object
this.twitterBind = new Twitter(this.twitterUser, oauthClient);
Sending a tweet is a single line of code:
this.twitterBind.setStatus(tweet);
And iterating through tweets is a matter of invoking one of four methods, like this:
this.tweetList = this.twitterBind.getUserTimeline(this.twitterUser);
You can look through TwitterConnector.java to get a feel for the full source code.
I've had fun building the connector and it can certainly ease the pain of putting together Assembly Lines that need to make calls to Twitter by having such a neat interface. I hope you have fun too.
Wednesday, November 17, 2010
ITIM - Java Version, Password Reset and SAP JCo
It's not very often that I wrapper a combination of topics together into a single post, but these are short snippets that would look a bit strange in a posting all of their own. They are trivial to the point of being unworthy of their own posting!
Java Versions
In the good old days, the version of Java you had installed on your client machine would play havoc with ITIM's applets: Workflow Designer; Form Designer; Join Rules Definition. It used to be that an upgrade of Java would immediately wreck your ability to use these applets. That all changed, though, and for quite some time I've enjoyed the ability to upgrade Java as and when I saw fit and everything still worked. Until yesterday.
Java 1.6.0_18 afforded me the luxury of using the ITIM applets. Java 1.6.0_22 does not! At least, 1.6.0_22 won't allow me to save my workflow! At least, not using ITIM v5.1 FP1.
You have been warned!
Password Resets
This is more of a reminder than anything else. Sometimes, it isn't enough to change a password in ITIM. What happens if the account on the target system has been locked due to authentication failures? A change password may not unlock the account and indeed this is the case when it comes to many systems - SAP springs to mind as my most recent example.
What can be done? Well, in simplistic terms, the changePassword operation for the account type could be updated to perform an account restore function after the password has been changed. The resulting workflow could look like this:
Of course, you may want to put a significant amount of logic around this restore process. You may want to invoke that only if the requestor of the change password operation is a specific person, for example.
SAP JCo
The SAP Java Connector that is used by the TDI SAP NetWeaver connector can, periodically, through an error message like this: "max no of 100 conversations exceeded".
The "fix", apparently, is to set an environment variable called CPIC_MAX_CONV and set the variable to a value of at least 500. I'm sure you can figure out how to set the environment variable for your Operating System and I'm sure you can work out that your TDI service will need to be restarted for the variable to have any effect.
And so ends today's collection of snippets. I told you they were trivial. I do hope you aren't too bored as a result of reading the above. Until the next adventure!
Java Versions
In the good old days, the version of Java you had installed on your client machine would play havoc with ITIM's applets: Workflow Designer; Form Designer; Join Rules Definition. It used to be that an upgrade of Java would immediately wreck your ability to use these applets. That all changed, though, and for quite some time I've enjoyed the ability to upgrade Java as and when I saw fit and everything still worked. Until yesterday.
Java 1.6.0_18 afforded me the luxury of using the ITIM applets. Java 1.6.0_22 does not! At least, 1.6.0_22 won't allow me to save my workflow! At least, not using ITIM v5.1 FP1.
You have been warned!
Password Resets
This is more of a reminder than anything else. Sometimes, it isn't enough to change a password in ITIM. What happens if the account on the target system has been locked due to authentication failures? A change password may not unlock the account and indeed this is the case when it comes to many systems - SAP springs to mind as my most recent example.
What can be done? Well, in simplistic terms, the changePassword operation for the account type could be updated to perform an account restore function after the password has been changed. The resulting workflow could look like this:
Of course, you may want to put a significant amount of logic around this restore process. You may want to invoke that only if the requestor of the change password operation is a specific person, for example.
SAP JCo
The SAP Java Connector that is used by the TDI SAP NetWeaver connector can, periodically, through an error message like this: "max no of 100 conversations exceeded".
The "fix", apparently, is to set an environment variable called CPIC_MAX_CONV and set the variable to a value of at least 500. I'm sure you can figure out how to set the environment variable for your Operating System and I'm sure you can work out that your TDI service will need to be restarted for the variable to have any effect.
And so ends today's collection of snippets. I told you they were trivial. I do hope you aren't too bored as a result of reading the above. Until the next adventure!
Wednesday, October 27, 2010
ITIM Spooky Password Behaviour
TIM and TAM experts will already be aware of how to provision TAM accounts from TIM and you will probably already be aware of how to provision GSO credentials from TAM to TIM. If so, this article may bore you but I did come across some rather odd behaviour that I wasn't really expecting.
In my provisioning policy for my TAM account, I was attempting to set my GSO credentials using Javascript and for some reason I decided to use the ersynchpassword attribute.
All was well when creating TAM accounts for existing PERSON objects in TIM. However, when I created a new PERSON object, I was presented with a failure in the provisioning of my TAM account:
My suspicions were that the ersynchpassword was not "available" at provisioning time so I dropped the following code into the provisioning policy:
Enrole.log("SSO", "uid is " + subject.getProperty("uid")[0]);
Enrole.log("SSO", "ersynchpassword is " + subject.getProperty("ersynchpassword"));
Enrole.log("SSO", "personpassword is " + subject.getAndDecryptPersonPassword());
The result wasn't terribly surprising in that ersynchpassword was null or empty. At least, that's what it seemed like at first glance when I noticed the following log messages:
Error: uid is account01
Error: ersynchpassword is
Error: personpassword is passw0rd
The real surprise, however, came when I read on through the log. Within milliseconds of the above messages, the following messages were presented:
So what do I make of this?
Well, it's best to use the getAndDecryptPersonPassword() method within this particular provisioning policy, that's for sure. But ONLY on account creation. Password changes need to be evaluated using the ersynchpassword. Luckily, there is a catch-all:
if (subject.getProperty("ersynchpassword")[0] == null) {
return "sapGSO (Web Resource)"
+ "|" + subject.getProperty("uid")[0]
+ "|{clear}" + subject.getAndDecryptPersonPassword();
} else {
return "sapGSO (Web Resource)"
+ "|" + subject.getProperty("uid")[0]
+ "|{clear}" + subject.getProperty("ersynchpassword")[0];
}
There are still some questions left unanswered here, though. Why was the policy evaluated TWICE and why did the first failure drive the CTGIMA617E message (rather than the second successful evaluation). Maybe someone in the land of the development team can explain it. And also explain why the ersynchpassword didn't manage to appear until the second evaluation just a 100 milliseconds after the first evaluation.
Then again... maybe it's because it is almost Halloween and it's the time of year for strangeness!
NOTES:
The above scenario was produced using ITIM v5.1 (Fix Pack 1) running on WebSphere 6.1 on a Windows 2003 Server. I'm quite sure I've used ersynchpassword in the past on ITIM v5.0 instances and did not see this behaviour!
In my provisioning policy for my TAM account, I was attempting to set my GSO credentials using Javascript and for some reason I decided to use the ersynchpassword attribute.
All was well when creating TAM accounts for existing PERSON objects in TIM. However, when I created a new PERSON object, I was presented with a failure in the provisioning of my TAM account:
CTGIMA617E The account {account} cannot be created either because the account is disallowed for the user or one or more attributes are not compliant with provisioning policy.Odd. Because when I manually requested the account to be created... it appeared without fuss.
My suspicions were that the ersynchpassword was not "available" at provisioning time so I dropped the following code into the provisioning policy:
Enrole.log("SSO", "uid is " + subject.getProperty("uid")[0]);
Enrole.log("SSO", "ersynchpassword is " + subject.getProperty("ersynchpassword"));
Enrole.log("SSO", "personpassword is " + subject.getAndDecryptPersonPassword());
The result wasn't terribly surprising in that ersynchpassword was null or empty. At least, that's what it seemed like at first glance when I noticed the following log messages:
Error: uid is account01
Error: ersynchpassword is
Error: personpassword is passw0rd
The real surprise, however, came when I read on through the log. Within milliseconds of the above messages, the following messages were presented:
Error: uid is account01
Error: ersynchpassword is passw0rd
Error: personpassword is passw0rd
CTGIMA617E The account account01 cannot be created either because the account is disallowed for the user or one or more attributes are not compliant with provisioning policy.
Error: ersynchpassword is passw0rd
Error: personpassword is passw0rd
CTGIMA617E The account account01 cannot be created either because the account is disallowed for the user or one or more attributes are not compliant with provisioning policy.
So what do I make of this?
Well, it's best to use the getAndDecryptPersonPassword() method within this particular provisioning policy, that's for sure. But ONLY on account creation. Password changes need to be evaluated using the ersynchpassword. Luckily, there is a catch-all:
if (subject.getProperty("ersynchpassword")[0] == null) {
return "sapGSO (Web Resource)"
+ "|" + subject.getProperty("uid")[0]
+ "|{clear}" + subject.getAndDecryptPersonPassword();
} else {
return "sapGSO (Web Resource)"
+ "|" + subject.getProperty("uid")[0]
+ "|{clear}" + subject.getProperty("ersynchpassword")[0];
}
There are still some questions left unanswered here, though. Why was the policy evaluated TWICE and why did the first failure drive the CTGIMA617E message (rather than the second successful evaluation). Maybe someone in the land of the development team can explain it. And also explain why the ersynchpassword didn't manage to appear until the second evaluation just a 100 milliseconds after the first evaluation.
Then again... maybe it's because it is almost Halloween and it's the time of year for strangeness!
NOTES:
The above scenario was produced using ITIM v5.1 (Fix Pack 1) running on WebSphere 6.1 on a Windows 2003 Server. I'm quite sure I've used ersynchpassword in the past on ITIM v5.0 instances and did not see this behaviour!
Tuesday, October 12, 2010
MASSL Between WebSEAL And Apache On Windows
Every now and again I get faced with Windows infrastructure. As I've previously stated on this blog, I'm not "religious" about my Operating Systems but Windows does present one or two slightly different challenges and SSL enabling Apache (though very easy) does have a gotcha!
Here's how to generate the certificates necessary to create a Mutually Authenticated SSL junction between a WebSEAL and an Apache instance on Windows.
Let's assume that Apache (v2.2) has been installed at c:\Apache2.2 and that OpenSSL (v1.0.0a) has been installed at c:\openssl-win32 using the Win32 binary installer.
Setting Up The Environment
The environment setup for OpenSSL requires some directories to be created:
The openssl.cfg file should be updated so that the "dir" directive within the CA_default stanza reads:
Within the req_distinguished_name stanza, add the following:
xx can be set to anything you want, but it is important that a stateOrProvinceName is provided during certificate generation.
Creating a Certificate Authority
openssl genrsa -out TAM\cacert.key 1024
openssl req -new -key TAM\cacert.key -out TAM\cacert.csr
openssl x509 -req -days 365 -in TAM\cacert.csr -out TAM\cacert.crt -signkey TAM\cacert.key
openssl x509 -in TAM\cacert.crt -text
That was painless, wasn't it? We now have a certificate authority which can be used for the signing of other certificates. Our next step is to create certificates for the Apache and WebSEAL instances. Note, we have no need for Apache or WebSEAL to generate the certificate requests, we can do that with OpenSSL:
Create Apache Certificate
This is a four step process which involves the generation of a key, a request, a certificate and a conversion of the key to unencrypted format because Apache on Windows "hissy-fits" when attempting to use an encrypted key.
openssl genrsa -des3 -out TAM\keys\apache.key 1024
openssl req -new -key TAM\keys\apache.key -out TAM\requests\apache.csr
openssl ca -days 365 -in TAM\requests\apache.csr -cert TAM\cacert.crt -keyfile TAM\cacert.key -out TAM\certificates\apache.crt -config openssl.cfg
openssl rsa -in TAM\keys\apache.key -out TAM\keys\apache_unenc.key
We can now move these certificates to the correct location:
mkdir c:\Apache2.2\certs
copy TAM\cacert.crt c:\Apache2.2\certs\cacert.pem
copy TAM\certificates\apache.crt c:\Apache2.2\certs\apache.crt
copy TAM\keys\apache_unenc.key c:\Apache2.2\certs\apache.key
Configuring Apache
The c:\Apache2.2\conf\httpd.conf file should have the handful of references to SSL uncommented:
The c:\Apache2.2\conf\extras\httpd-ssl.conf should be updated as such:
Create WebSEAL Certificate
The generation of the key, request and certificate for WebSEAL is also a four step process though the final step isn't the conversion of the key to unencrypted format but rather the generation of a #PKCS12 format certificate:
openssl genrsa -des3 -out TAM\keys\webseald.key 1024
openssl req -new -key TAM\keys\webseald.key -out TAM\requests\webseald.csr
openssl ca -days 365 -in TAM\requests\webseald.csr -cert TAM\cacert.crt -keyfile TAM\cacert.key -out TAM\certificates\webseald.crt -config openssl.cfg
openssl pkcs12 -export -clcerts -in TAM\certificates\webseald.crt -inkey TAM\keys\webseald.key -out TAM\certificates\webseald.p12
Importing the webseald.p12 file into the pdsrv.kdb keystore can be tricky unless your Java Policy Files allow the level of encryption that will have been applied to the p12. So, update the Java Policy Files on the WebSEAL by visiting https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?source=jcesdk. Download the Policy Files for Java 1.4.2 or above and copy the two policy files to {java_home}/jre/lib/security
The #PKCS12 file can now be imported with the following commands:
java -cp {gsk7_location}/classes/gsk7cls.jar;{gsk7_location}/classes/cfwk.zip com.ibm.gsk.ikeyman.ikeycmd -cert -add -file cacert.pem -format ascii -db pdsrv.kdb -pw pdsrv -type cms -label TAMCA -trust enable
java -cp {gsk7_location}/classes/gsk7cls.jar;{gsk7_location}/classes/cfwk.zip com.ibm.gsk.ikeyman.ikeycmd -cert -import -file webseald.p12 -type pkcs12 -target pdsrv.kdb -target_pw pdsrv -target_type cms -pw {p12 password}
You should now determine the label that has been assigned to the certificate:
java -cp {gsk7_location}/classes/gsk7cls.jar;{gsk7_location}/classess/cfwk.zip com.ibm.gsk.ikeyman.ikeycmd -cert -list -db pdsrv.kdb -pw pdsrv -type cms
The label will look like something like this: "2cn=webseald, o=x,st=x,c=x, etc"
Create a WebSEAL Junction
The WebSEAL junction can now be created with the -K option (plus the above label) which should result in a "Created junction" message with no other warnings.
Notes & Observations
The certificates used to created a MASSL connection between WebSEAL and Apache won't ever be seen by any client - remember, WebSEAL acts as the client to the Apache server. As such, there is no strong need for these certificates to be generated by the likes of a Verisign. There is no need for these certificates to make any reference to the actual host names at all - the names Apache and WebSEAL seem like good names to me for the Common Name of the certificate. In reality, using the above method for generating the certificates is as good than any other (if not better as it has been tried and tested).
Here's how to generate the certificates necessary to create a Mutually Authenticated SSL junction between a WebSEAL and an Apache instance on Windows.
Let's assume that Apache (v2.2) has been installed at c:\Apache2.2 and that OpenSSL (v1.0.0a) has been installed at c:\openssl-win32 using the Win32 binary installer.
Setting Up The Environment
The environment setup for OpenSSL requires some directories to be created:
cd c:\openssl-win32\bin
mkdir TAM
mkdir TAM\keys
mkdir TAM\requests
mkdir TAM\certificates
mkdir TAM\newcerts
> TAM\index.txt
echo "01" > TAM\serial
mkdir TAM
mkdir TAM\keys
mkdir TAM\requests
mkdir TAM\certificates
mkdir TAM\newcerts
> TAM\index.txt
echo "01" > TAM\serial
The openssl.cfg file should be updated so that the "dir" directive within the CA_default stanza reads:
dir = ./TAM
Within the req_distinguished_name stanza, add the following:
stateOrProvinceName_default = xx
xx can be set to anything you want, but it is important that a stateOrProvinceName is provided during certificate generation.
Creating a Certificate Authority
openssl genrsa -out TAM\cacert.key 1024
openssl req -new -key TAM\cacert.key -out TAM\cacert.csr
openssl x509 -req -days 365 -in TAM\cacert.csr -out TAM\cacert.crt -signkey TAM\cacert.key
openssl x509 -in TAM\cacert.crt -text
That was painless, wasn't it? We now have a certificate authority which can be used for the signing of other certificates. Our next step is to create certificates for the Apache and WebSEAL instances. Note, we have no need for Apache or WebSEAL to generate the certificate requests, we can do that with OpenSSL:
Create Apache Certificate
This is a four step process which involves the generation of a key, a request, a certificate and a conversion of the key to unencrypted format because Apache on Windows "hissy-fits" when attempting to use an encrypted key.
openssl genrsa -des3 -out TAM\keys\apache.key 1024
openssl req -new -key TAM\keys\apache.key -out TAM\requests\apache.csr
openssl ca -days 365 -in TAM\requests\apache.csr -cert TAM\cacert.crt -keyfile TAM\cacert.key -out TAM\certificates\apache.crt -config openssl.cfg
openssl rsa -in TAM\keys\apache.key -out TAM\keys\apache_unenc.key
We can now move these certificates to the correct location:
mkdir c:\Apache2.2\certs
copy TAM\cacert.crt c:\Apache2.2\certs\cacert.pem
copy TAM\certificates\apache.crt c:\Apache2.2\certs\apache.crt
copy TAM\keys\apache_unenc.key c:\Apache2.2\certs\apache.key
Configuring Apache
The c:\Apache2.2\conf\httpd.conf file should have the handful of references to SSL uncommented:
LoadModule ssl_module modules/mod_ssl.so
Include conf/extra/httpd-ssl.conf
The c:\Apache2.2\conf\extras\httpd-ssl.conf should be updated as such:
- Update SSLCertificateFile to point at c:\Apache2.2\certs\apache.crt
- Update SSLCertificateKeyFile to point at c:\Apache2.2\certs\apache.keyUpdate
- SSLCACertificateFile to point at c:\Apache2.2\certs\cacert.pem
Create WebSEAL Certificate
The generation of the key, request and certificate for WebSEAL is also a four step process though the final step isn't the conversion of the key to unencrypted format but rather the generation of a #PKCS12 format certificate:
openssl genrsa -des3 -out TAM\keys\webseald.key 1024
openssl req -new -key TAM\keys\webseald.key -out TAM\requests\webseald.csr
openssl ca -days 365 -in TAM\requests\webseald.csr -cert TAM\cacert.crt -keyfile TAM\cacert.key -out TAM\certificates\webseald.crt -config openssl.cfg
openssl pkcs12 -export -clcerts -in TAM\certificates\webseald.crt -inkey TAM\keys\webseald.key -out TAM\certificates\webseald.p12
Importing the webseald.p12 file into the pdsrv.kdb keystore can be tricky unless your Java Policy Files allow the level of encryption that will have been applied to the p12. So, update the Java Policy Files on the WebSEAL by visiting https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?source=jcesdk. Download the Policy Files for Java 1.4.2 or above and copy the two policy files to {java_home}/jre/lib/security
The #PKCS12 file can now be imported with the following commands:
java -cp {gsk7_location}/classes/gsk7cls.jar;{gsk7_location}/classes/cfwk.zip com.ibm.gsk.ikeyman.ikeycmd -cert -add -file cacert.pem -format ascii -db pdsrv.kdb -pw pdsrv -type cms -label TAMCA -trust enable
java -cp {gsk7_location}/classes/gsk7cls.jar;{gsk7_location}/classes/cfwk.zip com.ibm.gsk.ikeyman.ikeycmd -cert -import -file webseald.p12 -type pkcs12 -target pdsrv.kdb -target_pw pdsrv -target_type cms -pw {p12 password}
You should now determine the label that has been assigned to the certificate:
java -cp {gsk7_location}/classes/gsk7cls.jar;{gsk7_location}/classess/cfwk.zip com.ibm.gsk.ikeyman.ikeycmd -cert -list -db pdsrv.kdb -pw pdsrv -type cms
The label will look like something like this: "2cn=webseald, o=x,st=x,c=x, etc"
Create a WebSEAL Junction
The WebSEAL junction can now be created with the -K option (plus the above label) which should result in a "Created junction" message with no other warnings.
Notes & Observations
The certificates used to created a MASSL connection between WebSEAL and Apache won't ever be seen by any client - remember, WebSEAL acts as the client to the Apache server. As such, there is no strong need for these certificates to be generated by the likes of a Verisign. There is no need for these certificates to make any reference to the actual host names at all - the names Apache and WebSEAL seem like good names to me for the Common Name of the certificate. In reality, using the above method for generating the certificates is as good than any other (if not better as it has been tried and tested).
Subscribe to:
Posts (Atom)