Death of the Service Account?

I love a good metaphor. In a previous post, I compared a provisioning system that does notifications only to a pickup truck that you push around instead of drive.

So what is a service account ? It's like your mom who does the laundry for everybody in the house, and all she expects is a bouquet on Mother's Day and a card, you ungrateful bastard. You log into your browser-based GUI, pull up a page, fill in some fields, and click submit to make an access request.

Then a web service takes over, and makes the appropriate entries in the database and directory on your behalf, with its own context. You have no account on the database necessarily, and if you did, you wouldn't have enough rights to do the job anyway,

There are benefits to this architecture. Fewer accounts to manage that access the database, and it's not a simple thing to propagate identity from the GUI all the way to the tail end.

BUT ... there are also drawbacks. If you want to truly examine the entirety of a transaction as it relates to a particular user, you need to correlate that user's activity against the portion of the service account's activity for that user's id. Messy, especially when you need to do it across all users and their transactions.  And the accounts that do the actual work are obviously created with more limited abilities than an omniscient service account that can affect ALL users.

So then the issue becomes, how do I get my id from the web page all the way through the service and ultimately to the database?

I've seen people do a handle swap, so that their id gets pasted on to the database transactions. But it's not always easy.

Well, now there's a way to do it within the Oracle stack.

Oracle now has as part of its security bag the Oracle Enterprise Gateway, or OEG. I can't wait for them to put OEG R1 on a piece of lit, and then we'll be calling it Ogre).

It has the ability to take that user session, re-authenticate it across services and even different protocols, and pass the proper context all the way through to the database and/or directory. If necessary, you don't even have to create ALL those accounts in the database, but actually use a separate directory, such as Active Directory, to authenticate against the DB. But now you've got straight-through auditability (f that's a word).

But wait … your DBAs have better things to do than manage user accounts. Icky. Creating and managing them. Resetting passwords. Handling the compliance aspects. So how to do it? Enterprise User Security, or EUS. The best part about this acronym is that it doesn’t have an O in front of it. It’s a way of provisioning to databases, handling policies, and managing passwords. You can map enterprise roles in it, and provide users with those roles simply by adding them to an AD group. The details are a post for another day.

OEG does a whole lot more than what I just said, of course, which I'll also discuss soon. But now instead of always bugging Mom, you can do your own damn laundry. And you'd still better remember the flowers.