I’ve been working with VAS for quite a while, and have gone through all the versions since 2.6, and this has to be the biggest thing I’ve seen in over 4 years of working with the prodct. And the big thing is not VAS (or QAS, as its now known) itself, but a free add-on call Identity Manager for Unix (IMU). You can download your copy from here.

And the cool thing is that you can use the product without buying VAS.  What is it?  Its a free, web-based console for managing unix, linux and mac users & groups.  Obviously, if you buy VAS, you get a lot more functionality, but just the core functionality alone makes it a cool download.  If you have more than 2 unix boxes, this makes life a lot easier.  You can now assess all your *nix boxes, get a list of all your users and groups, and make changes right there, in a browser window.

And how do I know its cool?  Because I was on-site with a customer that had been evaluating VAS 3.5 for about a month, and they confirmed it.  They were going to have me go through and show them all the commands, tips & tricks and refresh them on all the things I’d shown them the month before.  Well, after installing IMU, and running through how it worked, they simply replied with “we got everything we need.  You answered all the questions we had with this console, and we feel pretty good that we can drive everything through this instead of the command line.” And that was the goal . . . make unix account management easy to drive from a single point, with no need to script or even log onto multiple boxes. Everything is dead easy . . . and did I mention its free?!?!?

I haven’t posted in a while, but came across this, and found it very, very amusing.  I’m not sure that I’d buy a trucker hat, no matter it says, but the mugs are cool – I like mugs.  And “word has it” that more things will be added . . . I’ll be watching.

From: Joe at Acme
Sent: Thursday, July 08, 2010 16:10
Subject: SSO for Java

Dmitry,

[...] sorry to be duplicating my questions but I lost my notes from our June 8 conversation.  As I read the SSO For Java specs, it describes an integration of JBoss and JAAS environments with AD content.  I don’t know the Java world that well any more, but will the java environments have the security context information that is supposedly in the Windows “Claims Aware Programming” environment for Windows developers?

Information like what LOA was used in authentication, what identity credential was used, what is the user’s rank that was passed in the identity federation profile, was the rank passed via an encrypted path, was the encryption network level or was it an end-to-end message-level approach, etc etc.

Thanks.
Joe

________________________________________
From: Dmitry Kagansky at Quest
Sent: Friday, July 09, 2010 12:00 AM
To: Joe at Acme
Subject: RE: SSO for Java

Joe,

Let’s do a quick summary, and also send you some additional information since our discussion.
1. VSJ has lots of flavours.  Of note:

* The ‘Standard Edition’ is the most common one, and is usable in all comercial app servers (WebLogic, WebSphere, Tomcat, JBoss, Oracle App Server, JRun, etc).  Its most common uses is as a servlet filter or as a JAAS authentication module.

* There is a ‘JBoss Edition’ which allows VSJ to be installed as a valve.  A valve is specific to Tomcat and JBoss, and if you have an app that requires a valve for authentication, then you’ll need to use this edition.  Otherwise, you can make use of the standard one.

* There are other editions that provide custom connectors for the specific platforms, just like the JBoss one.  For example, with the WebSphere edition, you can install VSJ as a TAI (Trusted Association Interceptor) and be able to consume LTPA (Lightweight Third Party Tokens) which are proprietary to Websphere.  Just like the JBoss edition, if you don’t need a TAI, then you can use the standard edition.

2. In all of the editions, except for the one below, a user comes in with Kerberos, NTLM or Basic Auth credentials (depending on the config), gets authenticated against Active Directory, and then has a Java Security Principal created within the application.  The authentication mechanism (servlet filter, valve, TAI) dictates which version you need to use.

3. Now, for the oddball, which is for Federation and claims. There is a ‘Federation Edition’ which ships with the Standard Edition, but is a separate set of jar files, and supports ADFS 1.0.  ADFS 1.0 is SAML (1.x) claims and tokens.  Should you want SAML 2.0 support, then MS provides a SAML 2.0 to 1.x adapter allowing you to use VSJ with your java apps to receive either SAML 1.x or 2.x tokens.  With SAML 1.x, your encryption is using SSL, and the schemes used are whatever you specify in securing the site with an SSL cert.  The web server is the one responsible for providing the security.

With SAML 2.x, the payload itself is encrypted before it is sent out.  It is still encrypted using a cert, and what type you select determines the encryption level which then allows you to send everything over port 80.  While the data may seem like its in the clear, because the encryption happens before the transmission starts, it is still jibberish going across the wire.

That should cover a good amount of the conversation we had last month.

Now, for some new information.  We have since released a version of Webthority, and that version supports using VSJ in both the front and back end.  What is Webthority?  It is a reverse proxy which can secure your applications but proxying the content, rewriting URLs and managing a session, as well as providing Single Sign On to numerous apps, using numerous authenticators.  What that means is that you can use it to log in with LDAP credentials, a smart card or certificate (PKI), a Kerberos ticket, a database login, or a SAML token, and establish a session across multiple applications through a common ‘gateway.’  Its a way to consolidate your URLs as well, where you can go from:

http://expenses.internal.acme.org

http://dev.acme.org

http://external.partner.gov/federate

to something like:

http://webapps.acme.org/expenses

http://webapps.acme.org/dev

http://webapps.acme.org/partner

You can consolidate those URLs, consolidate SSL certificates and use something called ‘protocol transition’ (which is built into VSJ) to go from one set of credentials to a set of Kerberos credentials.  This is all within Webthority, and can be used in conjunction with VSJ as well.

We have also made our own STS which not only provides SAML (Federation) support, but also supports something called ‘JIT Provisioning.’  The best thing to do is to check out these blog entries by the Product Manager for ActiveRoles Server where he describes this new functionality here:
http://www.bobbobel.com/just-in-time-access-provisioning/

I’m sure its all a lot to take in, so feel free to shoot back any questions you may have.

Dmitry

________________________________________
From: Joe at Acme
Sent: Friday, July 09, 2010 07:11
To: Dmitry Kagansky at Quest
Subject: RE: SSO for Java

Dmitry,
Thanks for the write-up.

I still am fixated on claims-aware programming.  It sounds like it is nothing more that providing a set of APIs for the application developer to use in making (access) decisions about a user?  Some of the claims will come to the application directly via a security token like SAML, and others are a part of the OS environment that one uses the APIs to get to?  If ADFS 2.0 is in use for abstracting the Identity Federation away from the app developer, I would think that the application would not see any SAML security tokens?

So then does the Java Security Principal (when VSJ is in use) provide all the claims a developer could want, including all the security context information?  No difference then between what a Windows developer (with ADFS 2.0 handling the Identity Federation for the enterprise) has access to and what a Linux Java developer has access to?

If XXXX is on a track for QAS with Oracle’s OIM suite (OAM, OIF, OES, OVD, etc), and if they are also a Windows AD shop with ADFS 2.0 also available, then maybe QAS + VSJ would make more sense than going the Webthority route?

Thanks.
Joe at Acme
________________________________________
From: Dmitry Kagansky at Quest
Sent: Friday, July 09, 2010 18:06
To: Joe at Acme
Subject: RE: SSO for Java

Here are the short answers, and you can read the write-up below for more details:
- With SAML, the operation is pretty binary.  Claims are put into a token, and the app can either access the claims or ignore them.  Its not flexible enough to make decisions like you describe.

- The app itself should not know or care about SAML; it is another abstraction, just like VSJ is a Kerberos “authenticator” that is put in front of the application.  Once the user gets past VSJ, it shouldn’t matter to the app how the user got there.

——
I actually think you’re expecting way more of claims than they really are.  You’re buying into ‘the dream’ and some of the ‘marketecture.’ And that’s not a bad thing, but lets look at what this means practically.

First, let’s level set, and define some terminology so we’re on the same page. What you have today is:
- Federation: This is an abstract term.  In my mind, this is just a way to separate management of resources from management of accounts that can access those resources.  In most cases, this comes as a result of two different organizations wanting to share resources, and allow accounts from one org to access resources from another org.  The caveat is that the org with the resources trusts (in some way) the account org, and accepts statements (or ‘claims’) made about a user by the account org.**

- SAML: This is a generic term that is used to describe anything from the notion of Federation down to the actual token sent during the authentication/authorization action.  It can be a protocol, a mark up language, the actual token, and a standard.  I get way too many questions about “do you support SAML?” which goes into a very long winded discussion.  So let’s discuss the key point, which is the protocol – there are 2 main flavours; 1.x and 2.x.  They are not complementary, and are competitive.  There are subtle differences in the syntax, but the big difference is what I outlined below. SAML 1.x is “in the clear” and its up to you (the sys admins/app managers) to secure it.  So you have to encrypt the channel, typically with SSL. SAML 2.x, on the other hand, encrypts the content –before– it is transmitted.  So even if the channel is wide open, and visible, everything is still jibberish and decrypted at the other end.***

- Certificates: These are used for all sorts of things, but in the context of this conversation, they are used to trust the organizations discussed above.  Obviously, there’s a public and private key set up, and the 2 orgs that are federating perform a key exchange at some point early on in the agreement.  This key exchange forms the Federation Trust between the two orgs, and validates a user from one org to the other.  So when you ask about encryption, the answer is almost always “whatever types of certificates you chose to use.”  There are some limitations, but most certs use standard encryption types.

So what does a Federated transaction actually look like?  Here’s a high level example.  Let’s pretend for a minute that Acme has some website called ‘partners.Acme.org’ and on that site, trusted partners can log in, and access information that Acme provides to their partners.  At the same time, Acme does not want to manage and maintain lists of users to access the site.  Job changes, turnover, and other factors lead to Acme telling their partners – “anyone that works for you that has a certain role (say, Marketing Manager) will be allowed into the site.  It is up to you, Mr Partner, to properly provision and deprovision your employees, and we trust anyone you send over that you claim to be a Marketing Manager.”

And now let’s say Quest is such a partner.  Because I work for Quest, I may (I stress –may–) have access to that site.  As long as I come from the Quest network (which can be confirmed by the certificates exchanged earlier) and the claim that Quest sends on my behalf reads ‘Dmitry Kagansky, Marketing Manager,’ I will be allowed into the site.  That’s all we’re really talking about here.  Quest makes some claims about me, and Acme trusts Quest’s claims.  If I leave, then Quest deletes my account, and I no longer have access to the Acme site.

That’s a high level overview.  Now, looking at what happens in a Java server, when someone authenticates, a “thing” (an object, a constructor, etc) gets created for the user called a Java Security Principal.  In that Principal are all sorts of information about the user that just logged in.  As you say, its the security context, and how it is generated should be irrelevant to the app developer.  And part of the information in the Principal is a list of all the roles the user has.  What VSJ provides is the ability to take the claims from someone’s SAML token during a Federated exchange, and put them into that list of roles.  So as a developer, you can now write code that says “if the user has a role of ‘Marketing Manager’ you are allowed to open this file.”  From an app standpoint, it should not care whether the person authenticated with a SAML token, a Kerberos ticket, or through carrier pigeon.  Somehow, the user got in, through a trusted access method, and they are here.  So you are right that the application should not know or care about the SAML token.  But the part about being able to ‘blend’ claims from the token versus the OS environment, that’s still a bit difficult and is not something that can be easily with SAML.

Which leads to what people want Federation to become.  There’s talk that SAML and claims are not enough, especially because the org with the resources wants to do more than just accept or reject claims. They want conditional things to happen.  They want ‘extensible APIs’ as you mention.  They want lots of things that are not yet part of SAML.  And if you search around, you’ll find something called XACML (eXtensible Access Control Markup Language) which, like SAML, is both a construct/token as well as a protocol and (sort of) an API.  Personally, what I see happening is that SAML will assume authentication responsibilities and XACML will take over the authorization duties but right now its a very, very hazy area.  SAML is here now, and ready for use (albeit somewhat limited) and XACML is still a few years off, but plenty of vendors are starting to support it and its starting to pick up some steam.

Finally, where does Webthority fit into all this?  Well, Webthority is a reverse proxy.  And it allows for multiple authentication sources.  And given that Federation is in such a state of flux, VSJ (with ADFS support) may not be enough to do it all.  You may still have cases where people need to log in using LDAP credentials.  Or they have a login in some database somewhere.  Webthority can provide SSO for those users, along with the Federated user.  And it actually provides a managable interface to control all these settings rather than writing lots of authentication code.

Whew – that’s quite a lot to take in on Friday.  Hopefully, this wasn’t too much for you, and it wasn’t too pedantic.  The short of it is that VSJ can provide the same SAML functionality for Java applications that Microsoft provides for their Windows apps.  And we do this using the same Microsoft plumbing, so there’s very little to add if you are already using ADFS (1.x or 2.x) and want the same functionality for your Java apps.  And, if you have (web) apps that you don’t want to overhaul, or that don’t use a Java Security Principal, Webthority may be a pretty good alternative as well.  Plus, VSJ can be used with Webthority so you can support the new (Federation, SAML, Kerberos) with the old (DB logins, LDAP, NTLM, etc).

——-
** Note that Federation often happens internal to an organization, and can be used just to segregate resource from user management.  It does not have to be 2 different orgs, but that is where the origins come from.

*** as an aside, when SAML 1.x came out, was adopted by Microsoft (and IBM to some degree) in ADFS 1.0.  SAML 2.0 was published a few years later, and was supported by the ‘anything but Microsoft’ crowd (The Liberty Alliance).  Since then, Microsoft has put out Geneva, which is their codename for ADFS 2.0, and now support both SAML 1.x and 2.x.

—
Dmitry

It looks like everything succeeded (as far as I can tell) except for the last step. I upgraded to 3.0 with no incident, but then I had some goofy theme that I should probably just remove, and it bit me in the backside. It turns out that WordPress now has an automatic ‘maintenance mode’ which is enabled by dropping a file called .maintenance into the WordPress root. With this file, no one can do anything on the site (including get into the admin site).

Thankfully, Google saved the day, but, man . . . what a nuisance. I had to log into the web site file management system, and then delete that .maintenance file.  Not a big deal, I know, but it shouldn’t work like this.  I should be able to do it from the WordPress Dashboard.  And, yes, I should have read the release notes and such. But who does that? Seriously? I do it for a living, and the last thing I need is for my personal software.

I really wish more people read About Face by Alan Cooper.

However, as we put everything into place, nothing happened.  And it turned out that the URL re-writing that they wanted (which is to put in the session id into the URL) wasn’t available until the user authenticated.  That sort of ‘URL mangling’ only happened when an authentication agent was used!  I’ve never used Webthority without one, which makes sense since it often used for Web SSO, and you always want to authenticate, right?

In any case, after a lot of stumbling and bumbling around, Paul H clued me into how the Custom Authentication Agent was used.  The documentation is pretty scant on it, so I created this 2.5 minute video outlining the changes I had to make in order to get the user to automatically authenticate and establish a session.

This is where I came up with the term ‘promiscuous authenticator.’  In a perfect world, this would be another option, just like LDAP or Database.  But for the time being, this will work.

http://www.idmwizard.com/quest/WebthorityCustomAuth/index.html

Hopefully, this will help others that are looking to configure Webthority’s Custom Authentication Agent.