I’m dealing with the OpenAM and its predecessors for a very long time. I remember Sun Directory Server Access Management Edition (DSAME) in early 2000s. After many years and (at least) three rebrandings, the product was finally released as OpenSSO. That’s where Oracle struck and killed the product. ForgeRock picked it up. And that’s where the story starts to be interesting. But we will get to that later.
I was working with DSAME/SunAM/OpenSSO/OpenAM on and off during all that time it existed. A year ago, one of our best partners called and asked for help with OpenAM. They needed to do some customizations. OpenAM is no longer my focus, but you cannot refuse a good partner, can you? So I agreed. The start was easy. Just some custom authentication modules. But then it got a bit complicated. We figured out that the only way forward is to modify OpenAM source code. So we did that. Several times.
That was perhaps the first time in all that long history that I needed to have a close look at OpenAM source code. And I must honestly say that what I have seen scared me:
- OpenAM is formally Java 6. Which is a problem itself. Java 6 does not have any public updates for almost two years. But what is worse, that bulk of the OpenAM code is still efficiently Java 1.4 or even older. E.g. the generics are almost not used at all! Vast majority of OpenAM code looks like it was written before 2004.
- OpenAM is huge. It consists of approx. 2 million lines of source code. It is also quite complicated. There is a component structure. But it does not make much sense on the first sight. OpenAM also does not have any documents describing the system architecture from a developer’s point of view. The only link that I was able to find still points to Sun OpenSSO document. And it’s been 5 years since ForgeRock took over the development!
- OpenAM is in fact (at least) two somehow separate products. There is “AM” part and “FM” part. And these two were not integrated in the cleanest way. The divide is still very obvious. And it gets into the way whenever you want to do something with “federation”. E.g. SAML assertion is available in the “FM” part, but not in the authentication modules. The session is central concept in “AM” part, but it is not available in the code that is processing assertion. So, if you need to do some custom code with the assertion that affects the session you are out of luck (no, the custom attribute mapper will not help either). And the most bizarre thing is that OpenAM sometimes obviously creates two or even three sessions for the same user. The it discards the extra sessions. But whatever you do in the authentication modules is discarded with them. This is a mess.
- OpenAM debugging is a pain. It is almost uncontrollable, it floods log files with useless data and the little pieces of useful information are lost in it. And to understand most of the diagnostic output you just have to look into the source code. This is a 20th century technology. Java logging API was available in Java 1.4 (February 2002). But OpenAM is not using that. This suggests that the OpenAM core may be even older than what I’ve previously thought.
- OpenAM is still using obsolete technologies such as JAX-RPC. JAX-RPC is a really bad API. It was a big mistake. Even the Sun engineers obviously knew that and they have deprecated the API in December 2006. That was more than 8 years ago. But OpenAM is still using it. Unbelievable. But worse than that: this efficiently ruins any attempt to use modern web services. E.g. if you need your authentication handler to invoke a SOAP service which uses WS-Security with SAML token retrieved from STS then you are in trouble. This is pretty much standard thing today. E.g. with recent versions of Apache CXF it takes only a handful of lines of code to do. But not in OpenAM.
Using some software archeology techniques I estimate that the core of current OpenAM originated between 1998 and 2002 (it has collections, but not logging and no generics). And the better part of the code is stuck in that time as well. So, now we have this huge pile of badly structured, poorly documented and obsolete code that was designed at the time when people believed in Y2K. Would you deploy that into your environment?
I guess that most of these problems were caused by the original Sun team. E.g. the JAX-RPC was already deprecated when Sun released OpenSSO, but it was not replaced. Logging API was already available for many years, but they haven’t migrated to it. Anyway, that is what one would expect from a closed-source software company such as Sun. But when ForgeRock took over I have expected that they will do more than just take the product, re-brand it and keep it barely alive on a life support. ForgeRock should have invested in a substantial refactoring of OpenAM. But it obviously haven’t. ForgeRock is the maintainer of OpenAM for 5 years. It is a lot of time to do what had to be done. But the product is technologically still stuck in early 2000s.
I also guess that the support fees for OpenAM are likely to be very high. Maintaining 2M lines of obsolete code is not an easy task. It looks like it takes approx. 40 engineers to do it (plus other support staff). ForgeRock also has a mandatory code review process for every code modification. I have experienced that process first-hand when we were cooperating on OpenICF. This process heavily impacts efficiency and that was one of the reasons why we have separated from OpenICF project. All of this is likely to be reflected in support pricing. My another guess is that the maintenance effort is very likely to increase. I think that all the chances to efficiently re-engineer OpenAM core are gone now. Therefore I believe that OpenAM is a development dead end.
I quite liked the OpenSSO and its predecessors in early 2000s. At that time the product was slightly better than the competition. The problem is that OpenAM is mostly the same as it was ten years ago. But the world has moved on. And OpenAM haven’t. I have been recommending the DSAME, Sun Identity Server, Sun Java System Access Manager, OpenSSO and also OpenAM to our customers. But I will not do it any more. And looking back I have to publicly apologize to all the customers that I have ever recommended OpenAM to them.
Everything in this post are just my personal opinions. They are based on more than a decade long experience with DSAME/SunAM/OpenSSO/OpenAM. But these are still just opinions, not facts. Your mileage may vary. You do not need to believe me. OpenAM is open source. Go and check it out yourself.
UPDATE: There is follow-up: Comparing Disasters
So what would you suggest then? Gluu ? what other alternatives are there, if you don’t want to pay big bucks to the likes or IBM/ORACLE/CA for a sso solution
There are many alternatives: Gluu, Shibboleth, CAS, MitreID Connect, JOSSO, LemonLDAP, SimpleSAMLphp, … and I’m sure there are many more open source projects that are not yet famous and that provide much better perspective for the future. I guess that I cannot recommend just one of these. I will not repeat the mistake that I’ve did with OpenAM. I guess there is no “one size fits all” in the AM field.
@Simon
If you dive into the source code, you’ll see Gluu and Shibboleth code is worlds apart in quality and organization from OpenAM. There’s a reason there are extensive OpenSSO/AM hacking guides on the darknet. No security architect who values his job would be able to recommend OpenAM with a straight face.
So do you have any suggestion for modern projects?
Take a look at the open source Gluu Project (gluu.org). From a features standpoint, the Gluu Server has everything you need to operate a robust, secure, and modern access management infrastructure. In addition, there are no license fees for putting the software into production.
Building infrastructure services for a large project is something that can be a huge investment, especially if you are trailblazing.
Once you are in a reasonable shape, you will need move off to building the killer app and evolve that — but that must not mean that your platform remains a frozen bubble. Your app needs to run on standardized platform. That means either making your infra standardized, or gradually killing it off.
It is hard to provide business justification for continued investment into evolving a platform. It is even harder to provide justification for one-off investment. Your experience shows the long-term effects of not investing into keeping up with outside world.
Totally agree with this post. I’ve seen the code and the nightmare within!
I agreed to using OpenAM for a project. Worst mistake I could have made, and we are still paying for it 🙁
To add customised login screens requires building the full project – theres no simple interface plugin to allow for this. There is no capability for automated configuration, and generally when there is a problem, the log isn’t all that useful!
I would estimate that we have spent tens of thousands of dollars to customise it to fit client needs, when it should have been a painless journey.
Now going to look at the likes of gluu and even mod_auth_pubtkt.
Wow. If I read this months ago when I first was learning about SSO and OATH.
I am a junior developer at a place that uses Forgerock’s products , they work great for us but we have great developers and way more then 40 engineers to keep our security tight. However due to our own desire to refactor old code and applications I for-see us using another product in the future that will keep up with what web applications are becoming and like was said “! in line with 2k internet”
What product can replace OpenAM ? Could someone suggest me.
Kitsda,
As Radovan mentioned, there is no one-size-fits-all solution when it comes to access management. That being said, the Gluu Server provides a very comprehensive platform for building a modern authentication and authorization infrastructure. In addition, all Gluu code is free to use in production. Best of luck with your research!
Congratulations, you made it to the first page of google results for “OpenAM”. I feel like i have to comment on this as I spent most of the last year evaluating identity solutions for a national scale deployment. (Unfortunately i couldn’t publish my results on a blog as it belongs to the companies I worked for :\ )
*****
The authentication solutions:
The opponents to OpenAM are Gluu, Shibboleth, CAS, SimpleSAMLphp, LemonLDAP and WSO2 Identity Server.
Be it clear. I red the documentation for ALL of those. I installed them on some servers, configured them, and performance tested them (the ones I could get working). My first test scenario was 100k users. The actual use case (and final test case) was >10M users with >10k auth/s.
(note: i’m sorry for all the guys who made those and to whom i might come off as very harsh)
* Shibboleth (Java/tomcat) is an abandoned piece of software. The documentation is totally obsolete. The installation procedure was wrong and talking about files/options that don’t even exist. I never managed to get this thing working.
* Gluu is mostly a fork of OpenAM/OpenDJ. (aka. they copy the source code). It doesn’t do anything more and it’s only supported by a bunch of guys (maybe even a SINGLE guy) who are copying the new versions from ForgeRock and trying to keep up to speed. You might as well just pay for the real one.
* SimpleSAMLphp (Php/Apache) is an amateur made software, with limited capabilities, for simple cases. The documentation was okay. Big issue: When doing the initial testing on a low spec server (only 2 cores), it literally peaked at a maximum of 2 auth/s (superior rounding). WSO2 and OpenAM were doing both around 100 auth/s on the same hardware. It’s doesn’t seem to be an option for anything serious. Eventually for testing other software.
* WSO2 (Java/tomcat) is very similar to OpenAM. Professional made software with all the features, backed by a serious company, with good documentation . There are many inconsistencies in the configuration and the settings. Ultimately, it crashes regularly during load testing when a few hundred users are coming in. I don’t want to say that this is a bad piece of software because i know the effort required to make something like that and what they achieved is substantial, (in a way they are on the right track), however i believe that their software team simply doesn’t have the resources/experience to make a reliable software of that magnitude.
* LemonLDAP is an internal software made for the Police force of one country (France maybe?). They open sourced it afterwards. There is limited documentation, no use case, noone using it. I didn’t install it. Future is doubtful at most. Actually, even the present state is unclear. Didn’t perf test it. (Not sure if there is even a documentation to install it. Didn”t care I had better alternatives on hands at this point)
* CAS had good reviews from what i heard (some people i know with had seen it). However it uses its own protocols and everything CAS is CAS specific. It’s not okay in 2016 when we want open authentication (OpenID connect, OAuth, SAML, whatever). So it was not an option. That could be fine depending on your use case.
*****
About all of those software. Only WSO can do SAML + OpenID Connect + OAuth + (optional) custom API. [though it seems to crash at times ^^]
About all of those software. Absolutely NONE can do 2 factor authentication like SMS OTP, Mail OTP, RSA token, geolocation check.
There is only ONE software which has absolutely ALL those features. It is OpenAM. The code is indeed 2.5 million codes, and it is required to do all of that. The other software are 1%-10% of that because they have only 1% of the capabilities. If you need the full package, there are currently no alternative to OpenAM I know of.
There is probably some old code from 1995-2000. (Yes it goes back to around that time) and it does NOT matter. Any software of that complexity will have some legacy. Your car use some parts which were designed 30 years ago. Let ForgeRock handle the development and the legacy. They poached all the seniors & crazy autistic genius from Sun/Oracle, they know what they’re doing and they have the experience to. You stand literally no chance to do better on your own, and neither all those other open source software made by a handful of people. (side note: I tested under OracleJDK 7/Tomcat 7 and OracleJDK 8/Tomcat8 on linux and had no issues whatsoever. Just because old java code is old doesn’t mean it’s not working under the current version)
*****
I red the documentation from OpenAM to write custom modules. I customised the authentication page to have the colours of my company. I did a proof of concept to integrate OpenAM with an external 2 factor authentication system with android/iPhones (used by some banks for 3D secure). I customised the authentication UI page to have the new fields (instead of username/pass). My experience is the total opposite of yours.
Seriously, the OpenAM documentation is one of the BEST i have EVER seen in my ENTIRE LIFE =)
Long story short:
If you have more than 1 million users & need reliability & have a 99.xxx% SLA then OpenAM is the only piece of software on the planet which can do it. [as far as I know].
If you need advanced features (multiple authentication protocols, 2 factor authentication, multi-sites, multi-continent… and much more) then OpenAM is the only piece of software in the solar system which can do it [as far as i know].
Note: I am NOT linked to any company making any the aforementioned software. I worked as an IAM expert at a consulting company, during which I had to evaluate all those solutions.
Why did i write all that: Because in Europe at the moment. The governments and the big companies are redoing their authentication platforms to “open” their identities (following up EU regulations number 910/2014). One day (SOON) you will finally have one unique account to access all the official gov services (health, taxes, whatever). That account can either be a new one given by your country’s government (project in progress in some EU countries ) and/or it can be an existing verified account from your bank/ISP/whatever (verizon, barclays, AT&T, whatever company wants to join in). To go further we could even leverage your idcard/passport/phone for 2nd factor authentication. I did consulting on that topic and currently only OpenAM has the capabilities in terms of features AND reliability AND performances AND integration with others. There is no way I advise that during consulting only to watch the country/company/whoever deciding to go another way which will set them (and every citizen) back 10 FUCKING years because a guy posted a rant on the internet against OpenAM. I’m tired of having 12 accounts to access 12 gov services and i want the future to happen, sooner rather than later. The future of authentication is OpenAM. OpenAM is ONLY THE WAY TO GO. There are no alternatives. [as far as i know]
Thank you for your opinion. And I think that there are many good points. However, I have to comment on some points:
I have different experience with Shibboleth and CAS. Shibboleth is definitely evolving. And CAS can be extended. E.g. we have a successful CAS-based solution with SAML.
“The other software are 1%-10% of that because they have only 1% of the capabilities.”: I cannot agree. I do not know all the projects intimately, but at least CAS and Shibbolets have far better capabilities than just 1%. Especially if you consider optional parts and integration options. These projects just have different strategy how to address user requirements.
“Your car use some parts which were designed 30 years ago.”: Yes, my car probably has some parts that were designed more than 100 years ago. That’s perfectly OK. But my car does not weight 100 tons and does not have wooden frame elegantly covered with the latest fashionable paint. And “Let ForgeRock handle the development and the legacy” may be a way how to look at it. But it will not be forgerock that will pay for this in the end. Customers will pay for this. And it is not going to be cheap.
“Just because old java code is old doesn’t mean it’s not working under the current version”: That’s right. For now. All of this is not about “not working”. It is about product flexibility and maintainability. Product that cannot change and adapt is as good as dead. And changing and adapting 2M lines of ancient Java code is going to be quite challenging.
Yes, OpenAM works now. But will it still work in 5-10 years? And how expensive it is going to be to keep it working?
I would just like to note that Gluu is **not** a fork of OpenAM. The Gluu Server bundles many open source components, none of which are OpenAM.
“Gluu is not a fork of OpenAM” 100% Agree
[Please remove the previous comments. Paragraphs are not in order.]
Let’s have a discussion about it then. It’s not everyday i can find someone who has experience with most of those =)
Shibboleth is used for some big deployments (e.g. national federation of EVERY universities in France, in Switzerland and other countries). I believe that the national-university-administration will give you a full manual with instructions to join the federation, a full application package and specific settings for your university with minimal tweaking required. In these conditions i guess Shibboleth is bearable.
For my work, i had to go from the official Shibboleth sources and documentation to handle EVERYTHING myself. I would be the one to write the manual, package the app, advise on settings. As far as i am concerned it turned out to be a complete disaster (which i didn’t expect at all). I never managed to get the application properly working and integrated. I ended up just marking the project as obsolete and abandoned. I wish it were different and i could benchmark it :\
CAS was put aside partly because we had guys who had experiences on it, they were planning to get away from it (for valid reasons) and to find something more tailored to our needs (which we found in OpenAM). CAS was somewhat ignored and my initial comment doesn’t do it justice. It is a perfectly valid solution, potentially the best alternatives among all the software we named.
*****
Actual requirements (either out of the box or with moderate configuration/customization):
– Multiple authentication protocols (OpenID Connect, OAuth, SAML, other API)
– Password authentication, various 2 factor authentications, others, extendable through API/SDK
– Integration with various identity sources (LDAP, database, nosql, others, extendable through API/SDK)
– Integration with various applications, the ones who require the authentication (standard protocols, API, agents/plugins for common app)
– Consistent performance, reliability, scalability, dependable for critical usage (most other products fail miserably here)
– Predictability to handle strict (and hardcore) SLA. (e.g. 99.99% availability, 50 millions users, 20k auth/s, I remember having a lot of afterthoughts in going full vendor instead of homemade, especially because they cost money and we have developpers in-house who could handle some development . I finally found something to convince me. (That and my clients being like “Why do you even still present the other options ? They sound really really bad, from what you keep saying they’re not even viable. Just drop them.”)
I remember having a lot of afterthoughts in going full vendor instead of homemade, especially because they cost money and we have developers in-house who could handle some development . I finally found something to convince me. (That and my clients being like “Why do you even still present the other options ? They sound really really bad, from what you keep saying they’re not even viable. Just drop them.”)
Let’s say you need most of the capabilities i listed before and they’re not present. You will have to go through the SAML, Open ID connect spec, whichever. You will need to make a high scale, concurrent, reliable system. That’s kinda hard and you can’t find numerous developers on that level easily. Then debug all of this. Debug all the integration with other IAM/IDP systems who have their edge cases and bugs. Well, that will take years to get something out. Then some more to debug everything and reach a good well-working state. But how many years ? I mean i could put a few guys for 1-2 years on that. I have some resources.
In the end, redeveloping every features from (almost) scratch, it’s the same as redeveloping OpenAM from scratch. There’s come the magic! ForgeRock is Open Source, so you can check their source in their repository. There is an estimation method called CoCoMo (Constructive Cost Model, see wikipedia article) which can give you an estimate for the cost to develop a project based on the number of KLOC (thousand lines of code).
For about 2-3 millions lines of code. That would take > 200 people (including all roles, NOT developers only, a full company) and > 6 years to develop. At 500 € cost/day, that’s more than 120 millions €. (Of course after 6 years, your solution would already be obsolete :p)
Everyone knows that KLOC is a rough estimate. That’s good enough to give a valid order of magnitude. You can adjust for project complexity with advanced CocoMo. That would be at least 30% more on the estimate ??
Seriously, who has the resources to even consider doing that in house ? Noone. My clients do not. Yours do not either.
Let ForgeRock handle the development, the maintenance and the support. It’s way cheaper and more maintainable to just buy.
You care about flexibility ? They’re the most flexible on the market at the moment. Just look at the roadmap and the previous release notes. They’re supporting newer protocols and newer features requests at a speed i didn’t even know was possible (and they already have more).
*****
“Yes, OpenAM works now. But will it still work in 5-10 years? And how expensive it is going to be to keep it working?”
Do a background check and risk analysis. I did. It was strongly in favor of going full ForgeRock stack.
Ad Shibboleth: Yes, the documentation is a problem. Unfortunately this is true for too many open source projects. But the code is actively developed. It is not abandoned or obsolete. E.g. there are activities to bring OpenID Connect to Shibboleth. And yes, it is not download-and-install product and you cannot make it work in minutes. But I would not completely give up on Shibboleth. It is a good option for some deployments.
Ad CAS: I think that CAS is generally under-rated project. Yes, the CAS protocol is not standard-based. But it is perfectly good for walled SSO solutions. And what are actually standards good for if they cannot interoperate anyway? And CAS is extensible. It is nice, relatively small and reliable software. It is not for everybody, but I like it.
Your requirements are not exactly easy to meet. If you are looking for a finished product that can handle that, then yes, probably OpenAM is your only quasi-open-source option. But the question is: do you need a product? Or can you take a project, extend and customize it to create a solution? This is a very different way than just deploying COTS product. And from my experience I can say that it is not any worse. Quite the contrary. It is just a different approach. You need to get used to it. And have a slightly different skill set.
And I would not say that this means redeveloping OpenAM from scratch. Our CAS+SAML solution was far from that. Miles far from that. Honestly, it was not even on the same planet. It was many orders of magnitude lower. So doing CAS+SAML+OIDC will definitely take significantly less time than re-developing OpenAM. Much much less time. It may be actually a very cost-efficient solution. I would not be surprised if developing that would be actually cheaper than your OpenAM subscription for a single year.
Honestly, take the time and have a look at OpenAM source code. The source tells the whole story. It does not lie.
It will definitely work if you are going to pay ForgeRock to maintain ancient code for you. And I guess that ForgeRock will be happy to do that. But in that case you have to be a very rich man.
“Or can you take a project, extend and customize it to create a solution?”
As i said before, the development of OpenAM is estimated to be more than 100 million €. It’s the real cost for a project of that scope.
Let’s suppose that you can do similar for 20% of the cost, because you remove lots of features, you have experience in the domain, you can copy most of the design from OpenAM/others, you don’t have to go through the same challenge for the first time, and you have the best guys on the planet. That cuts it down to 20 millions € (which is honestly quite optimistic for a finished product of that magnitude²).
You go from an existing open source solution and extend it. Half the scope is already done, that leaves the other half to do. This is ultimately a 10 million € project. It’s still a truckload of money and it’s an order of magnitude more expensive than buying the ForgeRock stack off the shelf. Going home-made sounds like the bad option after-all.
If you consider the risk of doing it yourself instead of buying, the resources involved (dozens of very experienced people with rare skills in niche domains), all the mistakes that could happens during the project and ruin it, the years lost developing which are simply years late. Then the mere thought of going that way was pure insanity. (It doesn’t even matter if you half or double some numbers among the estimate. The result stays the same.)
[Note: This is still talking about the requirements i had on my projects. For simple ones with minimal needs and some parts already in place. It can definitely be reasonable to pay custom developing/extending and accept some limitations and missing features.]
² Read: The finished product is the state you will reach after years of development and debugging and integration, where your software is mostly complete, hardened and battle tested. That takes many years, no exception. This is not comparable to a testing or proof of concept.
****
On a different topic and to talk about the actual challenges of an IDP/IAM overhaul. The deployment of the software is the easy part (at least with what i’m planning 😉 ). There will be two REAL challenges lying ahead. First, to migrate the existing data into the platform. Second, to modify ALL the existing applications/systems to integrate with the new platform.
Projects are cross-organisations and will affect many people (not necessary friendly or with the same interests than us), some politics to be done, some legacy to be expected, unknown unknowns to be dealt with, it will unravel things which were abandoned and forgotten years ago.
Altogether this means the project scope is already known to need a bunch of people, to be more than a year and to cost multi million €. Success will bring in a lot more than that. The few and best people i have should be focused on those two critical and risky tasks. Not wasting their time redeveloping something we can buy risk-free for reasonable money.
****
“Honestly, take the time and have a look at OpenAM source code. The source tells the whole story. It does not lie.”
I did. I developed things for OpenAM and OpenDJ. Can’t say the source is perfect. There can seem to be a bit of over engineering and over abstraction here and there. Not much, just a bit. The added complexity actually makes a lot of sense when you get the whole pictures and understand how things go together. (e.g. handling translations is annoying yet a necessary evil)
I develop software myself (i’m a software engineer who happened to get into the identity domain). I don’t think i could do significantly better, neither any of the people i know.
In fact, their documentation is one of the best i have ever seen on a software project (and THE VERY BEST of all IDP/IAM product). It has become the new standard I aim for and I expect from others.
Engineering can get quite complex at times, especially given these scope and performance. From the code i’ve seen they’re doing well so far. In fact, judging by many design decisions & subtle trade-offs & technical details, their engineering skills & project execution are actually near perfection. It did set a new standard for the way I approach complex, high scale and high performance problems.
Code is one thing. Code which works flawlessly when you deploy it in multi-site clusters and throws thousands users connecting concurrently at it every second for the next 48 hours. That is another thing entirely. A much better one. Even more so when it’s done 5-10 years before anyone else was doing it.
( Too bad noone cares, because noone needs that except me 😀 )
If any guy from Sun/ForgeRock reads me. I want to say GG guys.
We have a CAS-based solution deployed. It was not 20% of OpenAM cost. It was not even 2% of OpenAM cost. It was not even 0.2%. I know. We have done it. But you have your maths and your arguments. I see that there is no point discussing that any further.
I have had a very positive experience with both CAS and Shibboleth. While the two platforms differ fundamentally in aspects of software development, architecture and tech stack used, both are perfectly functional and suitable for enterprise web-SSO needs. I am deeply and intimately involved with both projects and I can confidently say that most of what is reported on both platforms in this thread is inaccurate. To summarize:
The Shibboleth Identity Provider is an extremely active project. The development is funded by a consortium, and there are 5-6 active developers who continue to release patches, updates and releases to a very very large and active user community. Shibboleth is the defacto implementation of the SAML specification. Nothing else comes close. The IdP comes with an installer that you simply just pass through and you’d have it up within minutes. It works with modern and more recent versions of Tomcat and Jetty, and requires Java 7+. It’s based on Spring and Spring Webflow. It supports the SAML spec in its entirety, supports the CAS protocol and there are effects to bring support for OpenId Connect into the platform none of which is an indicator for a dead or abandoned platform platform. Join the developer mailing list and you can see for yourself. As others have said, it is of course entirely plausible that any OSS platform may lack in adequate documentation and instructions, or that the docs have higher expectations of the deployer to have a fairly decent programming background. That much may be true. The IdP is also able to withstand large volumes of requests, it can entirely be stateless and can grow horizontally for as much and as long as you need. Persistence storage is also available for session management, should you need it, based on technologies such as JPA, Memcached and Hazelcast. The software is completely extensible.
The CAS project is also a very active projects and has much of the same dynamics as the Shibboleth IdP, except that its development is not funded by any specific consortium or community (though there are companies that provide commercial support). It is entirely volunteer-based, and really, you get what you put into it. Patches and pull requests are most certainly welcome and the project is very receptive to all kinds of contributions within reasonable bounds. The CAS project attempts to be a complete platform to provide enterprise web-based SSO. It has support for the CAS protocol, SAML1 Protocol, SAML2 protocol, OAuth2, X509, BASIC, JWT, Kerberos, SPNEGO, RADIUS, LDAP, DB, MongoDb, Apache Shiro, WSFED, Social AuthN (Twitter, Facebook, etc), Stormpath, DuoSecurity/YubiKey MFA, Google Apps. Docker images for releases are available. OpenId Connect is also being worked and is on the roadmap. Hardly “CAS Specific”. There is a very vibrant software community behind it that is, again, entirely made up of volunteers and enthusiasts. The tech stack is based on and moving further towards Spring, Spring Webflow, Gradle, Spring Boot and Thymeleaf. The software is completely extensible, and much like the IdP, is able to withstand very very large volumes of requests (in the millions, as I have deployed several times). Backend storage options that are available are Hazelcast, Memcached, Ehcache, InMemory, Couchbase, Infinispan, Redis, Cassandra, etc. Again, hardly “CAS specific”. It’s a very universal piece of software and is almost accepted and understood, (both the protocol and/or the platform) in every institution and product you find.
I hope you find this useful. Feel free to get involved with either community and you’ll witness this for yourself.
Here I’m, after about three years you wrote this. After reading it, I just want to thank you for sharing your experience with us. Reading the comments are also very useful to me. But I need to ask you something:
I want to use an open source sso to provide access for approximately 100k users simultaneously.
So far, I had in mind 2 options: OpenAM and Simplesamlphp.
Can you tell me if Simplesamlphp can deal with it?
Or maybe, suggest me another options that you think are robust enough to do the job?
Thanks and Best regards!
This is a good question, but I’m afraid I cannot give a definite answer to that. My opinion about OpenAM is clear. But I haven’t tested simplesamlphp in any deployment that was anywhere close to what you are looking for. You can try asking in simplsamlphp community (e.g. mailing list). But what I really recommend is to get professional assistance. Yes, this is open source world. But that does not mean “zero cost”.
Is this valid after almost five years of updates? FR is going to release the 7.0 in Q2 2020, I had the chance to go deep on 5.0 and 6.5 and a lot of changes were done.
Who knows? ForgeRock Access Manager is not open source any more. Have they managed to rebuild such a big and outdated code base in such a short time? I do not know. There is no reliable way to know.
But perhaps the most important question is: does it really matter any more? There is a huge number of access management solutions in the closed-source world. So many products to choose from. It was open source code that made OpenSSO and OpenAM attractive. But that is gone now.