Getting OpenID Connect, Microsoft Accounts and Azure AD working with mod_auth_openidc

I've been very busy lately working on lots of very geeky things.  I've been doing quite a bit of work with Hans Zandbelts Apache mod_auth_openidc getting it to work with various and sundry Open ID Connect providers or OP's.  In this post, I'll be describing the steps I used to get the new preview version of Microsoft consolidated Open ID Connect implementation for single signon or SSO.

I won't go into how to configure Open ID Connect in detail, this post assumes you either have or have the knowledge to set up a basic mod_auth_openidc deployment.

The first thing you need to do is to register your app at  https://apps.dev.microsoft.com.

Use the "Application ID" for your client_id in the mod_auth_openidc configuration, then click on "Generate New Password" and save this off to use as your client_secret.

If you want the nitty gritty of Microsoft's implementation, have a look at: https://azure.microsoft.com/en-us/documentation/articles/active-directory-appmodel-v2-overview/

Everything should be configured per the normal mod_auth_openidc documentation.  I'm using the OIDCMetaDataDir directive so that I can specify multiple open ID connect providers as described in the README file for mod_auth_openidc.

If you want to see the configuration directives that map to the Apache Conf file, look in  the auth_openidc.conf file in the source tree.

There are 3 files included in a meta setup for each OP.  xxx.provider, xxx.conf and xxx.client.

The contents of the .provider file can be gleaned from the following URL:

https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration

The Microsoft documentation is incorrect and has .well-known/configuration, which returns a 404 error.

Now here's where the secret sauce comes in.  When you name your xxx.provider, .conf and .client files, name them like the following with the following contents:



login.microsoftonline.com%2F%7Btenantid%7D%2Fv2.0.client

{
        "client_id" : "app/client id from apps.dev.microsoft.com",
        "client_secret" : "generated password from apps.dev.microsoft.com"
}

login.microsoftonline.com%2F%7Btenantid%7D%2Fv2.0.conf

{
        "scope" : "openid",
        "response_type" : "id_token",
        "response_mode" : "form_post"
}

login.microsoftonline.com%2F%7Btenantid%7D%2Fv2.0.provider

Copy and paste from https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration

Now restart your Apache server.  Load a protected URL, on said server, so that you get the discovery page that shows links to your configured OP's.  You should see one for login.microsoftonline.com%2F%7Btenantid%7D%2Fv2.0.

Click on the link from your discover page and login with a Microsoft Online account.

At this point your Web Server will throw an error.  If you look in your Apache error log you should see something like the following, if everything else is configured correctly:

oidc_proto_validate_jwt: requested issuer (login.microsoftonline.com/{tenantid}/v2.0/) does not match received "iss" value in id_token (login.microsoftonline.com/xxxxyyyyzzzz/v2.0)


The problem is that {tenantid} is a placeholder and will not work to authenticate. xxxxyyyyzzzz above should be your valid tenantid. This to appears to be a bug/missing documentation on Microsofts part.  To finish making this work do the following:

1. Edit login.microsoftonline.com%2F%7Btenantid%7D%2Fv2.0.provider and change login.microsoftonline.com/{tenantid}/v2.0/ to be login.microsoftonline.com/xxxxyyyyzzzz/v2.0
2. Now change the names of your meta files to be:
   
   login.microsoftonline.com%2Fxxxxyyyyzzzz%2Fv2.0.client
   login.microsoftonline.com%2Fxxxxyyyyzzzz%2Fv2.0.conf
   login.microsoftonline.com%2Fxxxxyyyyzzzz%2Fv2.0.

Now the big caveat to all of this is that this is a preview version, and is not meant for production.  Microsoft may make changes to the above and break any implementation you might care to deploy, according to the Microsoft documentation.  That being said, the above seems to work great for logging in to your web app using Microsoft as an OP and mod_auth_openidc as the Relying Party (RP).

Minecraft Exploding Sheep Java Bukkit Server Mod

Among other various and sundry things I've been working on, Java has been one.  If you haven't learned, it you should probably pick it up at some point.  Along with Python, C, Perl, C++, C#, PHP and other flavors of the day.

I picked this particular language as it's been very popular, has lots of community support and lots of plugins, and tools available to help you write code.  I use some of the Eclipse Java Development tools and it almost feels like my program gets written for me.  That's a post for another day.

This is just a short shameless promotion for my Minecraft Bukkit Server mod, Exploding Sheep.  Currently, it just makes sheep explode when you shear them.  I'll be adding explosion adjustment configuration and and sheep wool color configuration.  I've also had Feature request include exploding pigs, when shot with arrows.

The main point was to start an open source project in Java and using the Bukkit API seemed like a fun way to do a real Java project.  It's a dipping my toe in the water of open source so to speak.  Source is available on github, it's pretty simple so far, an event handler and some initialization.  I'll be accepting patches and updates and exploring some of the more esoteric features of github.

Be the envy of all the other servers, install the Exploding Sheep Mod today!

Agile Project Development Best Practices with Pivotal Tracker.

Pivotal Tracker and Project Management

I've been through quite a few live updates recently, and haven't dropped in with any posts for awhile, but I hope to get some updates soon.  I'm still working on the book, and maybe it will even be out before the technology described in it becomes obsolete.  That's a story for another day.

So I'm just about done with the 30 day free trial of Pivotal Tracker and I thought I'd share some of my opinions an insights into getting the best use out of this project management/issue tracking tool.  I'll start by saying that this tool might not be for everyone.  If your still stuck in the old MS project days of Gantt charts and project items that take two weeks or more, then this might be a steep transition.  You have to think in smaller pieces to get a more realistic picture of what's actually going on, and how much work a given team of people can accomplish over the course of a week, month, or quarter.

Points

The first thing you must decide, when using Pivotal Tracker, is how are you going to assign points.  You have multiple ways that points can be assigned, the default is 1, 2 or 3 points for small, medium and large.  The idea being that you decouple the number of hours that are associated with a given task, and the people doing the work can scope projects without worrying about nit-picking over hours.  Being as little old school, I prefer to have some linkage to hours, so I use the Fibonacci numbers 0,1,3,5 and 8.  I figure a point at roughly two hours, and if a task will take more than 16 hours, it probably needs to be split into multiple tasks, or stories.

Velocity

The overall goal of a good project manager is given X amount of work and Y amount of resources how long will it take to get X done?  In pivotal this is accomplished with Velocity.  Velocity is generated by averaging the number of points the Team/Project has completed over the last 3 weeks.  Pivotal Tracker assumes that the team will be consistent, taking into account strength in a given week and it will show what can be accomplished by that team week by week.

Stories

The idea behind a story is that it is a task that can be started and completed within the same week.  The key here is to keep the stories small.  Stories can have sub-tasks, but be careful of putting too much in a story.  Being consistent in sizing stories will help in getting to the goal of figuring out what, can realistically be accomplished by when.

Story Types

There are 4 different types of stories.  Bugs, Features, Chores, and Releases.  In the default configuration, only the points in Features count towards velocity.  The idea being that it is features that drive the product forward and bug fixes and chores are overhead.  Releases are milestones that show up in the overall schedule and do not have points associated with them.  Releases are the only types of stories that can have dates associated with them.  A release will show up in Red when there are too many stories that have to be finished (are higher in the list than) the Release story.  I use Pivotal in more of a support environment so fixing bugs and chores are considered moving the product forward.  Allowing points on all story types can be changed in the project settings.

Epics

If you have multiple stories and want to track them from a higher level, you can create what is called an "Epic".  Epic's give you a way to group multiple stories together into a higher level project.  An epic is like a tag for grouping, but additional reporting features are available when stories are linked together with an Epic.

Project = Team

This is probably one of the most important things I discovered about using Pivotal Tracker.  I didn't see the ability to see a roll-up of Stories and Epics across multiple Projects.  For usability, tracking purposes, reporting and overall sanity, Project should be synonymous with Team.  If you assign your people to tasks across multiple projects, you won't be able to use the milestone scheduling features.

Current, Backlock and Icebox

When work is started, by clicking the "Start" button in a story, it's moved over to the "Current" column.  I used back-log for stories that have been estimated and prioritized.  Things that need to be done, but haven't been prioritized are put into the Icebox.  Priority can be adjusted by clicking and dragging items.

3rd Party Applications

I like to use Eclipse and there is a Mylyn - Pivotal Plugin for Eclipse to allow integration with Pivotal Tracking and Eclipse Team .  There are also quite a few third party programs that allow tracking and reporting on the Web, and a variety of mobile devices.

How to Generate a Public Key With ssh

Useful ssh tricks

I don't like to let people log in to sensitive servers with passwords.  I generally disable this feature on servers I maintain.  I will explain.  ssh is used for many things.  I use the openssh flavor of ssh, but there are many other flavors.  For Windows, Putty is a popular ssh client.

 There are many things that you can do with ssh besides just establish a login session on a remote server.  scp and sftp are programs that allow you to connect to a server and copy files securely.  When you use plain old ftp to copy files, you are sending your passwords across the Internet in clear text, bad, mmkay.

One of the more useful things about a good ssh client is that it takes advantage of the features of a good ssh server (sshd).  A good ssh client will allow you do tunneling.  An example would be using ssh to connect securely into a Virtual Private Network, then using the tunnel created to secure a Windows Remote Desktop connection between the client and another machine on the VPN. A good ssh client can be used by other programs to connect to the ssh server, like in the case of svn, where you can include svn+ssh://yourhost/yourrepo instead of just svn://yourhost/yourrepo, which will also use the same ssh client.

There are lots of cool things you can do with ssh, but it all depends on getting the username and password set up properly so that authorized user (A), well call him "Joe",  can get into the server and copy files and check out things with subversion and tunnel remote desktop connections.  In a default kind of setup, you would create a user account on the server for Joe, then assign Joe a password.  Joe would then connect to the server, it would ask for his password, and he would enter it.  That's all good, unless, someone else had Joe's password.

Brute Force and Dictionary Attacks

When you use only usernames and passwords to protect your server, you are vulnerable to these types of attacks.  This type of attack involves attacker (X), well call him "Snidely", gaining access to your system by trying as many passwords as he can until one lets him in.  Snidely doesn't have to type these passwords in, he can just get passwords from the dictionary, or from a cracker library, and have an automated program keep trying until one works.   Your only protection against this type of attack, when you are using passwords, is to assign a "Login Limit".  This causes the account to be locked after a pre-defined number of unsuccessful login attempts, and shuts Snidely's little game down.

Public and Private Keys

Lucky for us, there is an even more secure method, Public/Private key exchange.  First I should explain what a public and private key is.  If Joe wants to send user (B), well call her "Sally", a secret  message, Sally can receive this message secretly by generating a public and private key.  Sally generates her public and private key, then she gives her public key to Joe.  Joe then writes the message and locks it up with Sally's public key.  Once the message is locked with Sally's public key, only Sally, with her private key can unlock it.  For an added level of Security ,  Sally was smart, and she also locked up her private key with a password, known only to Sally, when she generate the "Key Pair".

How to generate ssh  Public/Private Keys

Now let's say that Joe is the System administrator, and Sally wants in to the server.  What needs to happen is sally first needs to generate a public/private key pair.  If Sally has openssh, either in Cygwin (Under Windows), or openssh in Linux/Mac OS X, the ssh-keygen utility can be used as follows:

$ ssh-keygen -t dsa

If you do not add the "-t dsa" part, it will generate an rsa key.  Either will work, but I like DSA as RSA keys are not exportable outside the US, DSA keys are.  Also the default length of the key is 1024.  The length of the key determines how secure the key is.  The longer the key the more secure it is.  Theoretically nothing is "secure", when you talk about key lengths and whether or not it's secure you get into the whole argument about, is there enough computing power available to Snidely so that he can easily crack your key and gain access.  The longer the key, the more computing power Snidely will have to use to crack the key.  You can also specify a longer key (Up to 2048) if you use type RSA with "-t rsa".

After you hit enter, it will prompt you for where you want to store your files, it will look something like:


Generating public/private dsa key pair.
Enter file in which to save the key (/home/scott/.ssh/id_dsa):

You can enter a different filename, but I usually press enter, as the default is usually sufficient.  After you hit enter here, you will be prompted for a password.  This is important, you can choose to have no password (not recommended), or you can pick a password that locks up use of your private key.   As explained before, secret message locked up with this public key, will only be able to be read by using the private key.  Anyone in possession of the private key can de-crypt Sally's secret messages.  Any time you use this private key you will have to re-type this password.  This is important to note because when Sally tries to connect to the server, after Joe has installed her public key there, Sally will enter the same password she used to lock up her private key, NOT a password that is stored on the server.

Enter passphrase (empty for no passphrase):

After Sally has entered her passphrase, she will be prompted again:

Enter same passphrase again:

Then A nice little message with some additional randomart will display


Your identification has been saved in /home/scott/.ssh/id_dsa
Your public key has been saved in /home/scott/.ssh/id_dsa.pub
The key fingerprint is:
66:27:fc:27:8e:1d:43:ab:25:2b:3c:b7:8f:7b:16:69

If you look inside the id_dsa.pub file, you will see your public key.  It will look something like:

ssh-dss AAAAB3NzaC1kc3MAAACBAO2A0f//TUz1cx/23vRk7kfqEt81pQz6s0qbbjBaKPAn1eIbe7xHVogZNPdVhqWBMJ4xAWH5Fldayy4tJp5oDY0QqxsBVEvx81PUkmTD3cWMtysTaKqS6jjSNrGimRvL+xZf2jt4FvN1LQhFfeKI0Q1+MkoJ8GWD7ggmWC4/2GWhAAAAFQCJ2DgZMyN6AUTt+rW9Me2TZf4JhQAAAIAy2ehqfts19c+SNqKiIpII8kFI/u8N1tjKAV9sw2BDC5aJinqcoGGFXCI8J43ni4g/GPu+vAxWi2MPiGbw6MFnFvQRWdOPAjM5FJFU3mKqM3Vhk+29Qr25x/0cdDKh7hSPcmRRPTPTHwVEZwTErp8hG8JqFRlc0iSx/kMmLL6HCAAAAIEAiXy69U6zdYQitJfIMrc6dG61l/R7Rs+7Z9zsGpW5MmgyMMzAXU3gKO+0NEpUv9lMyDOqEYwEviU/0lyeesFmIl0T1/c/TOTtlgqpv9S5KAparVfkVXL3U4Gq7tNyzeGncbOd5u1tYdLh8dKgLPMtgmoHNzw+5m/Mc70TpVwLzZA= scott@monstro

All Sally needs to do is to e-mail the above text to Joe, and he'll know what to do.

What's a Joe to do? - Installing the public key on the server.

Now for Joe's part, he needs to take Sally's key, and if the /etc/ssh/ssh_client file has things in the standard place, and assuming home directories are in the standard place, and assuming that Sally's username is "sally".  Joe will put the above key (without any line-feeds or carriage returns) into:

/home/sally/.ssh/authorized_keys2

or

/home/sally/.ssh/authorized_keys

(Depending on how old your server installation is.  NOTE: I've seen both filenames needed in certain instances)

It is important that the ".ssh" directory in /home/sally be readable and writable, only by Sally.  In addition the authorized_keys file can only be readable and writable by Sally.  Just to be sure you can do the following commands as root.

$ sudo chmod 700 /home/sally/.ssh
$ sudo chown sally /home/sally/.ssh

$ sudo chmod 600 /home/sally/.ssh/authorized_keys2
$ sudo chown sally /home/sally/.ssh/authorized_keys2

If you leave out the above and the permissions are not correct, then Sally will not be able to log in, and Joe's authorized_keys file will be ignored.

How the ssh Authentication Handshake Works

I like this story, because it's the same way that Friend or Foe identification works in fighter aircraft.  So Sally want's to connect to the server.  Joe has done his part as administrator, and put Sally's public key into her authorized_keys2 file and Joe has also updated permissions on said files, using chmod and chown.  Sally can now use the command

$ ssh sally@joeserver.com

What happens next is that the ssh server, generates some random data.  It then uses Sally's public key, put on the server by Joe earlier, to lock up that random data.  It then sends the data to Sally.  Sally is prompted for a password, and she puts in the password she used to lock up her private key, when she generated the keypair.  Sally then unlocks the random data sent by the server, and sends it back, unlocked.  The server compare the unlocked version with it's pre-locked version and if they match, the server let's Sally in.

I get asked about the above quite a bit, and there is always consternation from the users when they have to generate keys, but it's a necessary evil.  Security, or convenience, pick one :)

Is the stock market a dinosaur?

Yes, yes and yes.  I was reading an article about a recent incursion into the US stock market.  And it occurred to me that the stock market has, for years just been Las Vegas for rich people.  With High Frequency Trading coming on the scene over the last several years, it has turned the stock market into a ticking time bomb.

It is quite possible, and most likely occurring daily, that automated programs could/have been written on the scale that directly effects our economy.  Think about that for a minute.  Some random, single person, on the Internet, that has access to the on-line trading system has the potential to affect and impact the economy of an entire country.   Just like the recording industry, the stock markets of the world are realizing the impact of taking out of date systems and marrying them with technology.

Even if you take technology out of the picture, the stock market is a dinosaur.  The stock market was intended as a place where companies could raise capital to expand their business, what it actually does is hurt business.  I will tell you a story of a company that I once worked for.  The company was privately held, about 2000 employees or so, worldwide footprint, up and coming.  Then they went public.

What happened afterwards was a long spiral downward of moral killing layoffs and decisions made by the executives which hurt the company, but helped the stock price.  After going public, we had one of the best years ever, sold more product and made more revenue than ever.  We had shipped the best product we had ever shipped, things were looking great.  Then the layoffs came.  We were all scratching our heads, wait a minute, what just happened?

What happened was Marketing.  The way it works is,  a few wonks from marketing get together.  They project what they think the company will make, over the next quarter and next year, in other words, they pull numbers out of their arse.  The rub here is that, the Marketing people projected that we would make more than we actually did.  When the revenue numbers came in and they were less than the projections, it drove the stock price down.  In order to bring the stock price back up, the company has to reduce their expenses to bring the stock back up, which in turn results in people losing their jobs.

At the end of the day, good qualified people are losing their jobs because marketing people want to play poker with computer programs in a rigged game, which is also referred to as "The Stock Market".

Excerpt from New Mr. Tech Book on Telecommuting

As I promised, more techiness for your geeking enjoyment.   I've been head down in a book for some time.  Hoping to release it by the end of this year, early next year.  I'll be talking about how to be a telecommuter.  There are so many great tools out there that are free or inexpensive that enable the average person working in an office to work from home, full or part time.

According to one survey, 62% of firms have remote workers and 34% of employees surveyed, work away from the office.  For those job seekers, being telecommute prepared can allow you to save money and time in commute and gas.  Following is a short excerpt from Mr. Tech's, upcoming,  book on telecommuting. 

How to work from Home - Introduction

I work from home, set my own schedule, except for meetings during the daytime.  Us telecommuters have to make some concessions to those that still have to work in flourescent light jail.  Sorry guys, but there is a better way, and you don’t have to get on the freeway every day, and you don’t have to go siteat a boring desk under flourescent lights like some bad nightmare from a comedy about working in such a place.

People ask me all the time, “How do you do it”?  I got tired of telling everyone, so I decided to write a book.  That way, next time someone asks, how I did it, I can hand them a business card with my number and a link to the website where they can purchase my book.  If it works for them, it only cost the price of a book.  If it doesn’t, they bought me  a couple of martini’s at a decent establishment, and someday maybe I can return the favor.

I have been doing this for around 20 years now and salaries have varied, but I make a decent living, live where I want the only requirement being decent Internet access.  Other than that, the beach, the mountains, another country, all are fair game.  As long as your work gets done, you are available when needed, and you can do it consistently, you’re in.  All you need is a few tips a plan and some elbow grease.

This is not a get rich quick manual, this plan will involve hard work.  I will also say this type of work is not for everyone.  You have to be a “motivated self starter”.  You have to be able to work on your own with little direction, and most importantly, you have to put in your time.  It’s very easy to fall into the trap of not putting in a full work week.  The flexibility to be able to take a day off when you want, and a long weekend every once in awhile, can quickly turn into a job-ruining slack fest.

This book will delve into all of those issues.  From humble beginnings to a full fledged telecommuting machine.  This book will give you the tools to succeed as a telecommuter and point you in the right direction in the types of training you will need, and the types of jobs that are available to telecommuters.

The future is now, throw away your commuter mug, and get one of those nice fat cups that takes up a large area of your desk, and prepare to join the growing ranks of the remote workforce.


I'll post more juicy tidbits soon.  The following is from the Introduction and gives a bit of background on the author and his qualifications on the topic of telecommuting.

My Worlds on Fire How about yours?

That's the way I like it and I'll never get bored. Words from a slightly overplayed song a few years ago, but truer words were never spoken. With everything going on, good and bad, and the challenges we face and rewards we are reaping, it's a very exciting time. In my personal life there is much to talk talk about, and soon there will be much to show. I've been working on several artistic pursuits including, some musical, some visual and some technology. For you my faithful readers, I will soon be posting more how-to's and technology information and opinions, as it's my bread and butter. This post will be a bit of a digression from that, as I feel there are important topics at hand that need to be considered by all in this country.

 I recently watched Rumble 2012 with John Steward and Bill O'Reilly. I understand that both of these men are performers, and there was most likely a, not un-substantial, amount of money paid to each of them from appearing. There were a couple of big take-aways from that video. Opinions, if you will, but ones that I share.  They are:

1. This nations problems are complex
2. There is a lot of "fear mongering" going on as it relates to said problems.
3. Simple answers are being offered as solutions to these complex problems.

The above would say that, as John Steward put "Our problem solving mechanism is broken".   We are asking the wrong questions.  It's not whether or not Democrat is better than republican.  The question we should be asking ourselves, is how do we fundamentally change our government so that it represents the 99%, not the 1%.

Let's look at the recent "real" debate of the issues between Mitt Romney and President Obama.  Mitt Romney was declared the winner by using a debate tactic known as the "Gish Gallop".  The tactic is that you spew so much BS at your opponent, so fast, and so furiously that there just isn't any sane response that doesn't make you look aggressive and/or contradictory.

Mitt Romney was declared the winner of that debate by using an underhanded debate tactic.  If we choose our leader based on theatrical performance, rather than facts and information, we are in sad shape indeed.  This election is our opportunity, in the US, to make a statement that we are concerned about real issues and not overblown hype and theatrics.  We don't have a good track record on this one, but maybe the tide is changing.  I have to agree with John Stewart's comments about this generation, that there has never been a better prepared generation to face the challenges that lay ahead.  We as the older generation need to remember, we just rent this place from our children.  Let's leave it at least as livable as we found it.