Article: SSO and Identity Management

Discussions

News: Article: SSO and Identity Management

  1. Article: SSO and Identity Management (27 messages)

    Justen Stepka has written an article on Single-signon and Identity Management, explaining what SSO is and how identity management factors in. He also goes into some factors covering a decision regarding single signon and some projects that fit into the solution space.

    Read "SSO and Identity Management"

    Threaded Messages (27)

  2. Any chance you could actually go through this..umm.."paper" and let us know when you actually have something finished than a Rough (note the capital 'R') outline?

    Thanx!
  3. Reads more like a blog entry.

    Don't forget the Acegi Security framework that integrates with CAS.
  4. Whoa!!!

    It doesnt help just to have the eye catching title like SSO and Identity Management. I was expecting some good content.

    There is total disconnect in the article between the initial couple of paragraphs and the latter parts. Seems like this was churned out in a hurry.

    The article that talks about some "usual" cliche benfits of SSO and identity management and then shows some code that shows some interfaces for custom authentication, authorization in J2EE !!
    Dont we have JAAS for that (to make it fit in J2EE is another matter - not to mention the new JACC API)..
    Also in the J2EE context, how about using container specific APIs that can be extended to create custom authn providers and so on. or a filter like CAS does it

    At the least, there could have been a paragraph about how SSO is achieved between multiple J2EE web containers using a cookie with pre defined name. That's how all of those web app single sign-on products do it.

    And last but not least - SSO is not J2EE problem. It is enterprise problem. As long as this problem is being addressed at J2EE level, it is NOT going to get any traction and will remain "John Doe's Departmental Web SSO for J2EE timesheet and defect tracking application".

    Web SSO also entails non-J2EE web apps, so a little intro about how web server agents (plugins, modules whatever you call them - as in Apache Modules, IIS Filters) participate in Web SSO wouldnt have been inappropriate.

    Some talk about reverse proxy and using it in the context of SSO would have been nice.

    And What about Identity management. The article doesnt even go beyond defining a interface for identity management.
    To be fair, this interface is not identity management. It is a interface for a user maintenance CRUD application.

    A real Identity management solution entails - User provisioning, adminstration and deprovisioning.
    User provisioning brings the enchilada of identity synchronization, password synchronization issues and solutions like meta directories and virtual directories.

    You got to be kidding to call this article "SSO and Identity Management". Call it what it is - "Benfits of SSO and some interfaces for propreitory authentication, authorization in J2EE apps"

    -- Srikanth Shenoy
  5. What happened to Kerberos?[ Go to top ]

    Every time I see a new single sign on solution I always think the same... what happened to old good Kerberos? As far as I know, Kerberos support is built into Microsoft Explorer and Mozilla Firefox, Windows has been using Kerberos for a while, and you can add Kerberos support to any Linux distribution without any problem, and I even seem to remember a Kerberos authentication module for Apache HTTP server... just adding Kerberos support to the J2EE server would mean you'd get all the benefits of a proven single sign on solution integrated with the rest of your enterprise authentication architecture. Isn't there any J2EE server that is capable of handling a Kerberos authentication? If this is the case, why don't they just add it and solve once and forever the SSO problem instead of trying to reinvent the wheel?
  6. Every time I see a new single sign on solution I always think the same... what happened to old good Kerberos? As far as I know, Kerberos support is built into Microsoft Explorer and Mozilla Firefox, Windows has been using Kerberos for a while, and you can add Kerberos support to any Linux distribution without any problem, and I even seem to remember a Kerberos authentication module for Apache HTTP server... just adding Kerberos support to the J2EE server would mean you'd get all the benefits of a proven single sign on solution integrated with the rest of your enterprise authentication architecture.

    You couldn't be more right. We built a small servlet that authenticates the credentials sent from IE to the server and saves it in the HttpSession - and violla! User is authenticated. Inside these credentials we have the user's groups (Active Dir. based..) and more...

    Combined with small LDAP utils to query the user's phone, name, and other details from Active Directory and a very powerful SSO mechanism was introduced into our organization...we had a couple of very smart advisors implement the authentication part (this is the tricky part - knowing the parse them appropriately via GSS) and that's pretty much it.

    Since then we even moved to a more centralized approach where each webapp delegates the authentication job to a centralized SSO server instead of directly contacting the AD (managability-wise..)
  7. Kerberos and J2EE[ Go to top ]

    Every time I see a new single sign on solution I always think the same... what happened to old good Kerberos? As far as I know, Kerberos support is built into Microsoft Explorer and Mozilla Firefox, Windows has been using Kerberos for a while, and you can add Kerberos support to any Linux distribution without any problem, and I even seem to remember a Kerberos authentication module for Apache HTTP server... just adding Kerberos support to the J2EE server would mean you'd get all the benefits of a proven single sign on solution integrated with the rest of your enterprise authentication architecture.
    You couldn't be more right. We built a small servlet that authenticates the credentials sent from IE to the server and saves it in the HttpSession - and violla! User is authenticated. Inside these credentials we have the user's groups (Active Dir. based..) and more...Combined with small LDAP utils to query the user's phone, name, and other details from Active Directory and a very powerful SSO mechanism was introduced into our organization...we had a couple of very smart advisors implement the authentication part (this is the tricky part - knowing the parse them appropriately via GSS) and that's pretty much it.Since then we even moved to a more centralized approach where each webapp delegates the authentication job to a centralized SSO server instead of directly contacting the AD (managability-wise..)

    Somebody feel free to correct me.
    But, I think there are a couple of issues here with respect to seemless integration between Kerberos and J2EE:

    It seems what you are doing is

    a)Either asking the user to login from browser and then going against the same active directory from your centralized J2EE based auth servlet to which windows user was already authenticated (and using Java GSS API). I guess the GSS in Java 1.4 has some problems with Active Directory Forests.

    b) Or, If you are windows only person, then you are using SPNEGO from IE and firefox to authenticate straight to a Tomcat configured as reverse proxy or a stand alone and having a auth servlet that talks to windows KDC and pulls the PAC and decodes it and then set the info in session (it should be better in HTTP Header - that way other app servers can participate in SSO).

    Here is a problem that I see.
    Suppose I want to configure a Apache web server as reverse proxy to a bunch of other apache web servers. I can then use one of the apache spengo modules (such as http://sourceforge.net/projects/modgssapache).
    Can these modules provide the authenticated user info and PAC info to the J2EE app server in some sort of HTTP headers? I dont know.
    I did not think they are doing it as of now. There are no defined mechanisms how this exchange between web server and app server should happen.

    Also there is no single vendor that supports this kind of exchange. Without seemless support for SPNEGO, Kerberos is as good as any other web based SSO mechanism (namely using a predefined cookie).

    Second:
    A significant number of J2EE production deployments still are on UNIX.

    On Linux, it is possible to hook up OpenLDAP and MIT or Heimdal Kerberos with SASL and other goodies and get them to provide a Acive Directory like functionality.
    I dont know if the Kerberos on Solaris (SEAM) provides this sort of interaction with SunONE LDAP server?
    There are a lot of grey areas.

    Third: with respect to cross realm interoperability between UNIX and windows.
    If UNIX world chooses AD as their directory server,
    Partial extension to Active directory with UNIX schema is provided by Micorsoft, but they dont support it and there are significant upgrade issues when upgrading to Windows 2003.
    Not to mention the turf war between windows camp and UNIX camp within any company on which directory server to use.
    UNIX camp hates to get their groupo info from AD PAC even though it is possible to write a PAM moduel for that.
    (MS didnt even allow it until a while back)

    I completely agree that Kerberos is the right way to do. But with all the above mentioned weaknesses, if I were to implement something to use seemelss Kerberos, I wont bet on it

    If vendors could step up their effort a bit, Kerberos can really provide the enterprise single sign-on, let alone web single sign-on.
    But due to lack of a interoperable vendor support, widesparead adoption will remain a pipedream.
    I hope some respected and stable third party provider steps in and provides a solution to the entire spectrum.
    But then everybody seems to be busy addressing the low hanging fruit - a.k.a cookie based web SSO.

    Cheers,
    Srikanth
  8. Clearly you know a lot more about Kerberos than me :o)

    Some time ago I made a small trip into the sys admin area, trying to create a Linux server that could handle our small Linux based development office. One of may main objectives was to have SSO in the whole system, and with a bit of effort I was able to have up and running an LDAP/Kerberos authentication/authorization server (OpenLDAP/Heimdal) with an integrated mail server (Postfix/Cyrus) and SSH access (OpenSSH) with everything working in SSO mode thanks to Kerberos. So the support seems to be there, at least in some products, and there seems to be the interest to include it as long as there are enough users that ask for it: as an example, Thunderbird has recently added support for Kerberos authentication in their 1.5 release.

    The cookie based approach will always be a partial solution, only suitable for web based applications... if we go that way we´ll end up having compartments of applications with their SSO server, so in the end instead of having to learn 50 passwords, maybe we'll have to learn five, just as many as kind of applications and SSO servers we have.

    So instead of reinventing the SSO wheel maybe we could just make pressure on vendors, or at least on related open source projects, to get Kerberos integrated in the platform. Let's start opening issues in JIRAs and Bugzillas :)
  9. Purely within the company, Kerberos in general and ActiveDirectory in specific is fine for SSO. I would even go so far as to say that it's the best solution I know of for SSO, and that includes things like logging into Unix workstations. You can certainly do it with RedHat, as some basic googling will show. (Full disclosure, I'm going through such a rollout right now, so I am becoming intimately familiar with these realities.)

    Once you step outside the company, either in an Extranet context or perhaps in an B2B SOA context, it gets a lot harder to figure out.

    --James
  10. Purely within the company, Kerberos in general and ActiveDirectory in specific is fine for SSO. I would even go so far as to say that it's the best solution I know of for SSO, and that includes things like logging into Unix workstations. You can certainly do it with RedHat, as some basic googling will show. (Full disclosure, I'm going through such a rollout right now, so I am becoming intimately familiar with these realities.)Once you step outside the company, either in an Extranet context or perhaps in an B2B SOA context, it gets a lot harder to figure out.--James

    Would client certificates and SSL (HTTPS) work here? For intranet users simply install them into the browser, and for external users they can use either installed certificates (if they own the computer) or use USB dongles with certificates, or something like that. No problem with different nets, no firewall issues, no proxy issues, no multi-directory issues. It's plain web.

    What am I missing?
  11. Purely within the company, Kerberos in general and ActiveDirectory in specific is fine for SSO. I would even go so far as to say that it's the best solution I know of for SSO, and that includes things like logging into Unix workstations. You can certainly do it with RedHat, as some basic googling will show. (Full disclosure, I'm going through such a rollout right now, so I am becoming intimately familiar with these realities.)Once you step outside the company, either in an Extranet context or perhaps in an B2B SOA context, it gets a lot harder to figure out.--James
    Would client certificates and SSL (HTTPS) work here? For intranet users simply install them into the browser, and for external users they can use either installed certificates (if they own the computer) or use USB dongles with certificates, or something like that. No problem with different nets, no firewall issues, no proxy issues, no multi-directory issues. It's plain web.What am I missing?

    I think that for most setups this is too much work. Once you get into the position at a corporate environment where development cycles are pushed as fast as possible, or something other that IE is used, just having something tied into Active Directory seems to be what people want.

    Taking it even further, just having a centralized authentication would be a huge step for most people.
  12. Purely within the company, Kerberos in general and ActiveDirectory in specific is fine for SSO. I would even go so far as to say that it's the best solution I know of for SSO, and that includes things like logging into Unix workstations. You can certainly do it with RedHat, as some basic googling will show. (Full disclosure, I'm going through such a rollout right now, so I am becoming intimately familiar with these realities.)Once you step outside the company, either in an Extranet context or perhaps in an B2B SOA context, it gets a lot harder to figure out.--James
    Would client certificates and SSL (HTTPS) work here? For intranet users simply install them into the browser, and for external users they can use either installed certificates (if they own the computer) or use USB dongles with certificates, or something like that. No problem with different nets, no firewall issues, no proxy issues, no multi-directory issues. It's plain web.

    What am I missing?
    I agree.
    As of today, certificates are probably the only way to provide fine grained access to either partner users or B2B apps.

    I think most SAML vendors are still on 1.1 and it is the 2.0 spec that provides the XACML or Liberty like user info and role forwarding capability. Until then every B2B app will need a certificate. I may be wrong though.

    For now however, I think certificate based authn/SSO makes perfect sense for B2B SOA whereas SAML based authN makes sense for partner users since partner users only require coarse grained access at a smaller level since they all fit into one profile (Think employer to benefit provider cross domain SSO), while the partner B2B apps require access to logic and data deployed and access at a granular level.

    If SOA solution is deployed on J2EE Application Servers then out-of-the-box/custom authenticators can be set up transparently for certificates and SAML as well, so applications can still remain transparent - which is good.

    I also agree with Justen that implmenting this multi-pronged approach is expensive and time consuming.
    I guess if there are only a handful of partners, then it is overkill.

    I however think that external facing customer (there would be a large number of them) identity repository should be separated from internal (employee) identity repository instead of centralizing.

    -Srikanth
  13. Certificates and Load balancers[ Go to top ]

    Would client certificates and SSL (HTTPS) work here? For intranet users simply install them into the browser, and for external users they can use either installed certificates (if they own the computer) or use USB dongles with certificates, or something like that. No problem with different nets, no firewall issues, no proxy issues, no multi-directory issues. It's plain web.

    What am I missing?

    I guess I have more of a question here.

    Hardware SSL accleerators and Load Balancers provide SSL facility and strip off the client certificate.
    How can then the identity be transmitted to Web Servers or deep into the network upto the App Servers?

    I dont have a clue. Can somebody shed light?

    Thanks,
    Srikanth
  14. Certificates and Load balancers[ Go to top ]

    In a minimal B2B environment where you have a small number of partners, client SSL certs might be workable, if the app server layer ever sees the cert (I agree that this is a problem in the case where you've deployed SSL acceleration, a problem I don't know how to solve personally).

    For many situations, client SSL certs are simply too complex to deploy to all of an organization's customers. In my case, we have a wide range of employees at customer sites using our portal, and I seriously doubt we could ever roll out client certs to all of them.

    --James

    p.s. I'm still not convinced that there isn't a solution which involves ActiveDirectory running in Kerberos mode. But that's probably wishful thinking on my part.
  15. Certificates and Load balancers[ Go to top ]

    In a minimal B2B environment where you have a small number of partners, client SSL certs might be workable, if the app server layer ever sees the cert (I agree that this is a problem in the case where you've deployed SSL acceleration, a problem I don't know how to solve personally).

    I may need to be more precise about the suggested solution. The certificate and SSL would only be necessary for ONE single request: when the user is authenticated. After that it can be plain HTTP and just regular session handling. So, if the user comes in and is not yet authenticated, do a redirect to an authentication server with https:, let it use the certificate to authenticate the user and create a session, and then redirect back to the actual application. This can be done using reverse proxy techniques so that the actual application never even sees this. There are a number of pretty decent products on the market which solve this problem.

    In my view the actual applications are fine as long as they have either form based logins or basic authentication, which the reverse proxy can submit to them. If they support global session handling, even better, but it's not strictly necessary.
  16. Certificates and Load balancers[ Go to top ]

    In a minimal B2B environment where you have a small number of partners, client SSL certs might be workable, if the app server layer ever sees the cert (I agree that this is a problem in the case where you've deployed SSL acceleration, a problem I don't know how to solve personally).
    I may need to be more precise about the suggested solution. The certificate and SSL would only be necessary for ONE single request: when the user is authenticated. After that it can be plain HTTP and just regular session handling. So, if the user comes in and is not yet authenticated, do a redirect to an authentication server with https:, let it use the certificate to authenticate the user and create a session, and then redirect back to the actual application. This can be done using reverse proxy techniques so that the actual application never even sees this. There are a number of pretty decent products on the market which solve this problem.In my view the actual applications are fine as long as they have either form based logins or basic authentication, which the reverse proxy can submit to them. If they support global session handling, even better, but it's not strictly necessary.

    Rickard,

    Hmm.. That seams feasible if the hardware SSL accelerator lets me do scripting. I definitely know that Big IP load balancer with SSL accelerator lets me do some scripting.
    I guess others do too.

    Conceptually, I think I can do something like this based on what you said:

    1) The script running on the ssl accelerator will decrypt the https everytime

    2) If a named cookie (like SMSessionID - SiteMinder cookie) is missing then, it will re-encrypt and "forward" the HTTPS to reverse proxy

    3) For the HTTPS request, reverse proxy will contact authenticating server that pulls the identity corresponding to the certificate

    4)This is pretty standard step everytime: Reverse Proxy or Web Server Agent internally associates the SMSessionId with that identity and also attaches a HTTP header containing that identity which can be used by App servers down the line

    5)For HTTPS requests containing SMSessionId Cookie, the SSL accelerator does the decryption and sends HTTP request to reverse proxy (proxies), which promptly attaches the identity based on step 4.

    The "double" encryption happens for two requests. The first user request for a protected resource and the second request with credential submission - either with a client certificate or user password.

    Sounds like a solution to me :-).

    -Srikanth
  17. Hi Srikanth Shenoy
    Before you get red-faced when you read what I write next, splash some coooold water on your face, and then read. Coooold yet? Ok.

    As a minimum, Justen took the initiative to write something. Did you take that sort of initiative before, Shenoy? Plus, your name is 'Shenoy' - that name is not a white name.
    Additionally, Justen will be speaking at the up coming 2006 TheServerSide Java Symposium (http://javasymposium.techtarget.com) as part of the industry security panel.

    Everything so far is against you, Srikanth Shenoy. What are you blowing off your steam for? You are STRUTS-talented. But, did that talent help us in any way other than your book? It did not.

    So, Justen Stepka is the winner here. What a big step he/she took, you see!

    Last of all, Srikanth Shenoy makes grammatical errors when he posts. We are not interested in reading anything that has such errors. I, at least, cannot read (incorrect syntax).

    Learn.
  18. White skin. Brown skin.[ Go to top ]

    Dumb white skin: thinks "great! good to see a brown-skin-sounding name kicking butt of another brown-skin-sounding name".

    Smart white skin: thinks "hmm, there is a point in what this Sujan says".

    Dumb brown skin: thinks "let me weep as usual and say, this Sujan is doing disservice to our names". Cries out loud.

    Smart brown skin: thinks "hmm, there is a point in what this Sujan says". (but brown point is different from white point).

    Think yourself. Ok.
  19. White skin. Brown skin.[ Go to top ]

    Dumb white skin: thinks "great! good to see a brown-skin-sounding name kicking butt of another brown-skin-sounding name".Smart white skin: thinks "hmm, there is a point in what this Sujan says".Dumb brown skin: thinks "let me weep as usual and say, this Sujan is doing disservice to our names". Cries out loud.Smart brown skin: thinks "hmm, there is a point in what this Sujan says". (but brown point is different from white point).Think yourself. Ok.

    Seems like you are a lunatic with one agenda on your brain.
    That being: Hijack every possible thread in this forum and turn into a ethnic and skin color fight.
    Get over it dude...
    Grow up and Learn to talk from the right end.
  20. Agenda-driven I am, you say.[ Go to top ]

    Dumb. And opportunistic. Both you are.

    Respond to my earlier message instead.

    Dumb. You are. Weep.

    me definitely sad for you. uh oh!!
  21. Before you get red-faced when you read what I write next, splash some coooold water on your face, and then read. Coooold yet? Ok.As a minimum, Justen took the initiative to write something.

    I have got nothing against Justen. Initiatives are good and I appreciate it.
    What are you blowing off your steam for?

    Have you heard something called Freedom of Expression?
    You are STRUTS-talented. But, did that talent help us in any way other than your book? It did not.

    People living in glasshouses should not throw stones at others.
    I'd be curious to know what your contributions are?
    (apart from making racist and skin color based remarks on this forum)

    Also, please refrain from measuring anybody's talent by the books they have written. The converse is also true.

    There are a hundreds of folks who have not written books but are more qualified than me and have made more contributions to Struts and elsewhere.
    So, Justen Stepka is the winner here. What a big step he/she took, you see!

    Looks like you always enjoy taking the fight to a personal level. I have nothing against Justen Stepka.
    Last of all, Srikanth Shenoy makes grammatical errors when he posts. We are not interested in reading anything that has such errors. I, at least, cannot read (incorrect syntax).

    I agree that I make grammatical errors and typos due to oversight and writing as I think.
    I also know it can be irritiating for many to read them.
    But if you dont want read my posts then dont read...
    Nobody is forcing you to do so.
    But you do seem to be reading my posts and firing caustic remarks. Hahaha
    Learn.
    Yeah right...
    Look who is speaking about learning

    --Srikanth
  22. You again wept. Here's a tissue for you. Wipe your eyes.

    I wish, you didn't weep, rather replied in a more humble way.

    me again definitely sad for you. Go, have your bread now. Really sad. For God's sake, don't reply now, you're spreading color, nothing else. Sad.
  23. Hi Srikanth Shenoy
    Plus, your name is 'Shenoy' - that name is not a white name.
    I'm confused. What does a white name have to do with anything?
  24. What does a white name have to do with anything?
    Do not pose a question like the one you did. Instead, we prefer you say the following in a simple positive no-nonsense sentence:

    A white name does not have to do with anything. Period.

    That would have been better, Chris.
  25. A white name does not have to do with anything. Period.

    Repeat one hundred times. Say again -
    A white name does not have to do with anything. Period.

    That's better than a question and the confusion in your mind, Chris.

    (That Shenoy will again jump on to reply to this message. Tiring he certainly is...)

    Repeat.
  26. Kerberos really sufficient?[ Go to top ]

    I don't see how Kerberos can be used in the following scenario:

    Imagine a company with a portal that customers have access to. The company purchases 3rd party software which is also web-based, running on separate systems (either on-premise or off, the problem is the same). The company wants customers to have transparent access to this software once they are authenticated with the portal.

    Kerberos would work fine for the company's employees, they had to auth against the company's domain when they logged in that morning, so the GSS API will be able to fetch their credentials. Right?

    However, the customer, even if they're AD, will not be joined to the company's domain. They will have their own domain, or be logging in from a public web terminal, or any number of other scenarios. How will the GSS API help them?

    I see this is a terribly common scenario, and if you can't provide SSO there, then the technology is not nearly as helpful in a web applications context.

    --James
  27. Hi all!

    I believe that most big international companies cannot afford to put external users in their active directory deployment.

    Let's say a company has around 50000 internal users, and 500000 registered partners, customers, and just people who registered in various marketing sites. If the Windows Domain Controllers (Active Directory) has been scaled for 50000, changing user population to a different order of magnitue will not be popular with the Windows admins!

    Furthermore, since external users are not logged on to the company's Windows Active Directory Forrest, they wont havea Windows session when they access the web site, which means silent authentication will not be possible... I don't know if that was the original intent with using Kerberos with JAAS, but it is nice when working with protecting intranet sites.

    Again JAAS is not enterprise, at least not at the large companies where I have consulted where server environments are very homogeneous.

    I really do believe that at large companies you need (and usually have) some form of enterprise Web Access Management product, such as RSA ClearTrust, CA Siteminder etc. These products provide agents for all sorts of different servers (WebLogic, WebSphere, SAP, IIS etc etc).

    A product of having an enterprise Web Access Management solution is SSO, as there are agents on all protected sites that are part of the same framework.

    What this also means is that any authentication mechanism integrated in the WAM framework can be utilised on any server, resulting in an "authentication broker".... Use the appropriate authentication mechanism (authentication token, client certificate, basic username password, IWA etc) for the level of confidentiality your web app hosts. Use OR statements and stuff if your company has a history of issuing multiple types of strong authentication to clients :)

    Finally, I think that there are a lot of problems for using client side certificates for large groups of external users. One major problem with them is that they are difficult to move around (say you want to access a web site from an airport Internet café etc). Another problem is, how do you actually go about issuing the certificates? Send them on a floppy disk to the customer's snailmail address?

    Hard certificates can also be a nuisance, as a lot of them require client side software to be installed. Even if they don't, they still impose requirements on what type of client platform that can be utilised.

    I believe there are a lot of merits to using hardware authentication tokens such as Safeword or SecurID as they are completely decoupled from the computer. The problem with them are of course that you cannot digitally sign stuff in the way you can with X509 certs...

    Sorry for babbling, this topic is q:)

    /Dave
  28. don't forget about SAML[ Go to top ]

    I was surprised to find no mention of SAML (http://www.oasis-open.org/specs/index.php#samlv2.0) in this article. This technology is used today for the cross-domain SSO. It may be used within a single security domain as well. The SAML is an OASIS standard that defines an interoperable XML framework, where a Service Provider relies on the assertion made by the Identity Provider regarding the Principal. Such assertions may be requested or pushed in a number of different scenarios called profiles. In addition to pure SAML profiles, there are two other specifications that introduce their own SAML-based profiles: Liberty Alliance and WS-Federation.