Banks ignore crypto checks in credit card transactions. Standards are not enough!

English on January 23rd, 2016 No Comments

The newspapers “Zeit” and “c’t” revealed that credit cards with new chip-and-pin based security (EMV) can be cloned and used for payments.

At first glance very surprising as EMV credit cards are smartcards with crypto graphic measures, which allow a bank to recognize modifications to cards or transaction data. These cards are per se more secure than older cards which only rely on data stored in an easily copied magnetic stripe.

So what happened? The answer is simple: Although the EMV standard is well designed and secure, some banks did not implement the cryptographic checks. As a result, the system falls back to the less secure standard and approves the payment transaction.

What do we learn from that story? It is not enough to trust in blind faith, if someone says they rely on secure standards. Whether it is a credit card or a single sign on network, you better CHECK it. At least if you can! For SAML service providers SSOCircle provides you with SSOCheck to verify the crypto security of your “trusted” SaaS provider. More about SSOCheck is here

If you are interested to read more about the MacGyver credit card fraud, here are the links to the original articles in German:
Zeit Article
c’t Article

Tags: , , ,

Session Timeout – another useless Security Brainchild?

English on January 7th, 2016 No Comments

A synonym for “timeout” is “break” or “pause”. Sounds like a good thing – in principle. When it comes to “session timeout” perception might be different. What exactly do we mean with “session timeout”? At OWASP you might find explanations similar to:

Session timeout defines an action window which represents the time span in which an attacker can try to steal and use an existing user session.

For the end user timeouts are just annoying and ideally shouldn’t exist or at least should be “infinite”. Finding a balance between security and usability is a challenge that we already know from authentication by passwords: Password protected applications shouldn’t exist either or the password should be at least simple and easy to remember. That translates to: Short, the same everywhere and intuitive like “password”, “aaaaa” or the name of my dog.
Back to OWASP and their definition about the action window for stealing identities. Session expiration is mandatory unless you want to give an attacker unlimited time to guess or brute-force a valid session token. You definitively need to acknowledge that a session token, for example a cookie, represents your credentials for accessing protected content. During the time of its validity the token is as confidential and worth protecting as username and password itself. This becomes particularly critical if the transport of tokens is in clear, only secured by weak encryption, in shared environments or if you take into account that session tokens can potentially be logged by servers or proxy servers.

Sounds unrealistic? Think of the situation when you go for a meeting and leave you laptop unlocked. Someone can easily access your browser, retrieve cookie information, and go back to his own computer impersonating you. In that case the best prevention would be locking the screen or manually logging out before leaving. But, in the rare case we forgot to lock the screen, an idle timeout would mitigate the risk of cookie theft. If the attacker steals the cookie, say 20 min after you left your desk, an idle timeout of 15 min would have saved you and your data.

If you argue that you don’t need an idle timeout since you can deal with that by reasonable diligence: Remember the Odd Job Trojan in 2011. OddJob infected Firefox and Internet Explorer stealing session identifiers of online banking applications, intercepting manual logout commands from the user, hijacking sessions and keeping them alive by sending periodic requests to the server. Ending up with access to banking account information and transactions for a long time.

Consider weak encryption: The Freak Attack ( published on March 3, 2015 allows attackers to intercept HTTPS connections and force the use of export-grade cryptography leaving most Windows, Android, Apple devices and Macs with OS-X vulnerable. And what is the impact to session timeouts? Forcing the use of export-grade crypto means a downgrade in key length to a 512-bit. Nadia Heininger (University of Pennsylvania) was able to factor 512-bit RSA keys in 7.5h on a cluster of EC2 servers for a cost of $104. If your session lasts longer than 7.5h not only the traffic could be decrypted but also your session cookie could be read and USED. An absolute timeout shorter than 7.5h would mitigate the risk to be “freak attacked “.

Coming back to the point: Session expiration should be used to make your systems more secure. More secure, in the context here, means giving the attacker less time to break your safeguards. Please note: Invalidating sessions after timeout or logouts must be done on the client and server side. The latter is the most relevant and mandatory from a security perspective. Removing the session identifier (e.g. cookie) only on the client side is not considered safe.

The safeguards related to session validity are:

Manual session expiration: Provide an easily accessible logout button, so that the user has the ability to logout and end the session whenever his work is finished or paused. Unfortunately nowadays in many social applications the logout button is hidden somewhere to keep the users logged in.
Idle Timeout: Most applications implement idle timeouts which terminate a session after a certain amount of inactivity. The length of an idle timeout heavily depend on the kind of application. According to OWASP common idle timeouts for high-value applications are 2-5 minutes, medium critical applications 15-30 minutes and low risk applications approx. 3 hours.
Absolute Timeout: A timeout after which a session is closed no matter there is user activity or not. The absolute timeout limits the time a hijacked session can be used. Banking and shopping applications typically implement an absolute timeout of 30 – 60 minutes. The absolute timeout heavily depends on application use cases. For some applications a timeout of 8 – 24h does make sense.
Renewal Timeout: Some applications define renewal timeouts, which probably are the most difficult from implementation view point. After the renewal timeout a session identifier is exchanged to a new one, leaving the session itself valid. Technically the renewing of session identifiers limits the time a hijacked session could be used by an attacker without impacting the usability of the normal user as the session remains still valid. But with that approach problems can occur, if the client is still using the old session id when it is already set to invalid. The change of session id can also imply race conditions in which the attacker, not the legitimate user, is able to obtain the new session id.

Some words about session synchronization: In loosely coupled single sign on systems (via SAML, OpenID Connect …) there is no single overarching session. Individual applications create their own local session without revalidating the session on subsequent requests. This constitutes an important difference in behavior from classical web access management systems, which typically maintain a central session and applications verify session validity periodically.

Session expirations, manually or through timeouts, pose challenges to these SSO environments. A manual logout from one system should be propagated to other systems (although there might be good reasons for not doing that). If there is no global logout, the user experience might be a little confusing, since logging off a system might not show the expected effect as you are transparently signed in again through the existing identity provider session – at least if everything is working fine and the session at the identity server is still valid.

And what about timeouts? Does it make sense to propagate idle timeouts? Being idle in one application doesn’t mean you are idle in another application as well. What about idle timeouts at the IDP? Consider the case in which you are surfing one application and then you access another application. If the IDP expired your local session because of inactivity at the IDP, single sign on will not work and users have to reenter their credentials. Is that what you expect from a working SSO system?

SSO integrations are normally more difficult than expected. Session synchronizations are even worse and often do not work in real life deployments. SAML 2.0 specification describes several profiles for single logout. OpenID Connect session management specification is still in draft (as of 03/2015). There are some people in the identity community advocating to abandon single logout. Their argument: It is better to know there is no single logout and deal with it (for example by closing the browser window) than relying on a working single logout which in reality might be incomplete or even nonexistent.

Final remark: There is no such thing like a “gold standard” for timeouts. As often in security topics, it is all about risk management. Risk based considerations may help to find a good balance between user experience and security.

Tags: , , , ,

Impressions from European Identity & Cloud Conference 2015

English on May 17th, 2015 No Comments

It is always around May when KuppingerCole Analysts call together the Who’s Who of identity management. From 5th – 8th May over 600 participants and 45 exhibitors gathered at the 9th European Identity & Cloud Conference in Munich to present and discuss the risks and newest trends of the “Digital Transformation”. As every year the conference was accompanied by several pre-conference workshops in which organizations like Kantara Initiative, OpenID Foundation or the FIDO Alliance gave insight into their latest work. The first workshop already started on Monday, giving the conference an effective duration of 5 days. In good conference tradition the organizers prepared a fully packed agenda with the new concept of “expert talks” making the conference a perfect way to saturate your hunger for IAM knowledge. Actually a tough endeavor to go through all tracks – but the conference was, as always, perfectly organized by the KuppingerCole team which made it a pleasant experience.

Getting to the nitty-gritty:

Kantara Initiative announced that the UMA Standard achieves V1.0 status on 5th May.
The OpenID Foundation presented several new working groups like the Health Relationship Trust (HEART) working group specifying several profiles and the FHIR-API (pronounce “fire”) dealing with patient centric health data sharing focused on the individual.
Another working group is the Native Applications Working Group (NAPPS) which has the goal to enable OAuth and OpenID Connect enabled native applications to do Single Sign On without calling the embedded browser. Why that? Because Apple nowadays blocks apps in the appstore which do a call out to the system browser. An example use case for native SSO was given: An airline whose flight attendants use 8 different apps each of them having a timeout of 2h. As a result the attendants are required to relogin 20 times during one shift – not the best user experience.
An update on the Account Chooser project was given, which centers on UX best practice for user account discovery. Yes, this is what you know from Gmail … They are targeting a release of a new draft at IIW. For demos and more information:
A demo:
Draft specs:

A new working group is RISC (Risk and incident sharing and coordination) with the objective of determining ways for providers to share security event information to prevent cross app attacks and help users regain access to lost accounts.
In the OpenID Workshop a new term circulated: “Scope Design”, there is a need to define interoperable and standardized scopes. In OAuth it is not exactly clear what exactly is meant by “scope”.

An update on OpenID Connect whose protocol underpinning specifications (JWT family) are in the last “48h” round of the IETF RFC process. OAuth will get a Form Post response mode as an alternative of the HTML fragment usage. For session management / logout there is no specification available for the back-channel logout which is considered the most reliable logout process. Specs are only available for the GITK based HTML5 state change message propagation and the http based logout (using iframe or hidden images).

The actual conference kicked off at 2pm on Tuesday as always with a trend setting keynote of Martin Kuppinger, founder of KuppingerCole, on the new role of identity access management and security in the age of digital transformation. He proposed 8 fundamentals:
1. The Digital Transformation affects every organization – think of smart watches, connected vehicles, smart homes, smart grids, ebooks, digital music, online retail, online payment, manufacturing
2. Digital Transformation is here to stay – it is not a temporary phenomenon
3. Digital Transformation is more than just IoT – It will affect many industries even without any connected things. Industry 4.0: Connecting things for the sake of connectivity does not create business: it is the change in business models and the services that make the business. Most services will earn more with services than with things (shipping boxes vs. subscription models)
4. Digital Transformation mandates organizational change – no success without agility. Rapid go to market … No room for silos … DevOps mostly ignore security aspects – DevSecOps is needed and a Chief Business Development Officer …
5. Everything and everyone becomes connected – “Cloud + social + mobile” – the troika is still valid but will now be more complex: devices + organizations + people + things. The new “ABC”: Agile Business connected.
6. Security & Safety: not a dichotomy – operational technology security vs. information technology security
7. Security is a risk … and an opportunity
8. Identity is the glue – access control is what we need – see: the seven fundamentals for future identity and access management

The presentations continued with keynotes from well-known speakers and sponsors. Common denominator of most speeches: The threats imposed by the Internet of Things are omnipresent. IT and OT must come together. The firewall protecting the perimeter is still needed but is not sufficient. Identity is the new watch guard and will replace (better say: complement) the security infrastructure.

OT an acronym which came up on many slides was defined as follows: Operational Technologies (OT) is what drives the everyday technology – it is insecure because it was designed, architecture and developed years ago.

Ian Glazer, Salesforce, pointed out differences in employee-centric and customer-centric IAM, particularly in the user lifecycle which is not a “join-move-leave” but a “join-move-move (anonymous-pseudonymous-known) process with long relationships and hopefully no “leave” step having implications on privacy and the technologies used – value is not in the data but in the relationship. He concluded: “stop using employee-centric IAM for your customers”.

Eve Maler, Forgerock, on user-managed identity and access for the digital transformation: “In the age of IoT you will need a single place to organize access rights of your 31 lightbulbs in your house …” that is Forgerock’s OpenUMA.
André Durand, Ping Identity, asked “How can we defend what we don’t control?” Controlling SaaS, Cloud and the Coffee House IT with IDSec (Identity defined security) putting identity as the new perimeter: It is about letting the right people in, enabling your business and playing offense not just defense
Some of the catchy quotations in the keynotes:

Goal of security is not total security. You just want your company having a data breach to be less likely than that of your competitor – Ravi Bindra

We don’t make hammers soft so that people don’t harm other people with them” – Scott David on risk mitigation

If we have quantum computers in 5 years today’s crypto will all be broken” – Jan Carmenisch

“We created a dream – whilst simultaneously creating a nightmare” – André Durand on digital transformation

As every year the highlight of the second conference day was the European Identity & Cloud Award ceremony which honors projects and initiatives in several categories for unique ideas when dealing with complexity and new leaner, faster, better approaches in IAM.

This year’s winners:

Best Innovation New Standard: AllJoyn – an open source software framework for IoT (see

Best Innovation in eGovernment and eCitizen: SkIdentity – a cloud service project that helps to use the technology which is already in place in order to come “closer” to SSO.

Best B2B Identity Project: DNA Ltd. – A Telco from Finland with more than 3 Mio customers which built an IAM system for internal and external users.

Best Approach on Improving Governance and Mitigating risk: University of Nantes –
IAM based on the biggest deployment of Evidian.

Best Access Governance/Intelligence Project: Nord Landesbank IAM project

Best IAM Project: dm-Drogerie Markt

Best Cloud Security: PostNL: a project implementing the 100% cloud strategy of the company.

Special Award I: A life management platform

Special Award II: Dialog Axiata & Sri Lanka Mobitel: Project mobile connect based on WSO2 infrastructure.

The third day’s agenda mainly split into 4 parallel tracks. It is always difficult to choose between the offerings. Nevertheless I want to point out some of the sessions here:

In the “Bring your own Privacy” track Katryna Dow, the CEO of award winning Australian company Meeco and a new face in the sometimes a little too much seasoned identity community, presented the life management platform is a new platform which beta launched in 2014 and officially started in the beginning of 2015. Meeco is a place to organize your digital life with privacy in mind. Some people say it is a mixture of a Facebook-like platform to communicate and share data with friends, family and businesses combined with a Google-like information repository about you and your intents. An example use case: You might decide to share the information that you want to buy a new car with specific companies in order to get information and offers. But you choose the companies you want to share that intent, you choose to publish the information either anonymously or personalized and you limit that for a time span of, say, 12 months. The value for the businesses is that the information provided is accurate, in real time, in context and with intention. Katryna Dow on the question about Meeco’s competitors: “Google is our biggest competitor”. And what when Google comes up with a similar platform? “If Google change the way they deal with their users, that’s great. Then we (Meeco) just existed to make this happen”.

In the “Internet Scale Encryption, Authentication, Authorization” track a session on privacy ABCs (Attribute Based Credentials) centered on idemix, uProve and Qiy. Jan Carmenisch described the idemix concept of key binding and pseudonyms: Similar to PKI, but better. There is one secret identity (secret key) but many public (pseudonyms public keys) which follow the concept of minimal disclosure constructing certificates which contain only the necessary attributes needed to get access to a service (e.g. age > 12y). Ronny Bjones gave an overview on uProve a similar concept but based on different technology: blind signatures (ISO 18370) aiming for untraceability, unlinkability and minimal disclosure in authentication. Marcel van Galen discussed the Qiy approach of adding an extra trust layer based on a standard making cookies obsolete.
Read more:

A date to remember: Next year the European Identity and Cloud Conference EIC 2015 will be at 10.-13.May 2015 in Munich at the Dolce-Ballhaus-Forum. Don’t miss it.

Tags: , ,

Termination of Google Apps SSOCircle Accounts

English on March 10th, 2015 No Comments

Google Apps integration into the SSOCircle of Trust was started in 2007 and has been one of the first active Google SAML integration in that time. Our intention was to showcase a working demo for SAML single sign on.

We have now received an email from Google which states that the Google Apps ISP Partner Edition, that we are using with the domain, will be terminated. See the email extract below:

Google >>>
As part of Google’s integration plans, we have elected to discontinue providing the Partner Edition Services going forward. As provided in the Agreement between Google Inc. and, this letter serves as your formal notice that the Services will not be renewed, and our Agreement with you will terminate …
<<< What this means to you: Your email account is closing on 10th April 2015. After this date, you will no longer have access to this mail account nor will you be able to send or receive email with this account. In addition, if you are using other Google/ Google Apps services (e.g. Calendar, Drive, Documents …) with this account, action is required from you.

Please note: The termination of service does not impact your account at SSOCircle. The account at the IDP will still be available and can be used for SSO to other services.

We see currently no option to provide free mail or calendar services and we therefor have no plans to to migrate to other Google products or other service providers. We will not migrate emails, calendar data or other content nor do we plan to forward emails. Please download or migrate your content before 10th April 2015.

We regret any inconvenience this may cause. If you have questions or have other ideas please contact us.

Your SSOCircle Team

Tags: , ,

Enterprise Identity Bus Part 1

English on February 19th, 2015 No Comments

With the latest Identity Server 5.0.0 release WSO2 promotes the product as an “Enterprise Identity Bus” hinting at its flag ship product the “Enterprise Service Bus” (WSO2 ESB). The Identity Server (WSO2 IS), whose strength has always been the entitlement engine with decent XACML support and the availability of thrift interfaces together with WSO2′s 100% open source strategy, might be considered as an identity and access management product by companies and internet communities.

In this article we would like to leverage recent project experience with WSO2 IS to discuss how exactly the identity bus feature of WSO2 looks like and how you could use WSO2 to replace an existing web access management (WAM) product and leverage the recently hyped Social Login feature.

From application centric identity silo to the identity bus: The following diagrams visualize the different architectures for two example applications, SHOP and CRM, with edges simulating authentication proofing relations (e.g user submits his credentials to Application which verifies the credentials of the user).




Let us consider the following scenario and requirements: Company X wants to have single sign on between their in-house web applications, employees use cloud based services and appreciate convenient access to applications like Office365 or Zendesk. The company also wanted to provide controlled access to their own services for customers and they are building a growing internet community, which should attract users with easy registration and login processes powered by social login via Google, Facebook and the like.
Sounds like interesting requirements? That’s not all. The company is a modern and innovative technology firm. In identity tech speak that means that applications offer and use APIs protected by OAuth 2.0. But how can all this requirements be composed to an overall picture?

Breaking up the requirements:

A. Single Sign On for in-house applications: A classical WAM discipline involving policy agents installed into application servers, web servers and/or reverse proxies. These agents act as a policy enforcement point (PEP) which check for authentication, redirect to a central login application for authentication, validate sessions and access policies (authorization). Read more in part 2.

B. Account federation to cloud services and to identity providers provided by the companies customers allowing SSO to cloud services like Office365 or the in-house applications. Read more in part-3.

C. Enable community users to register and sign in with their own social login (Google, Facebook …) to internet accessible in-house applications and probably to cloud services integrated into the community environment (e.g. Zendesk for customer services). Read more in part-4.

Going with the approach described here, we need to look into the integration details. Adhering to standards might be a good way to reduce efforts and integration pain. In today’s identity world the following protocols need to be considered: SAML the de facto standard for SSO in the enterprise as well as for many cloud services and OpenID Connect, based on OAuth 2.0. The latter becoming more and more prevalent in the consumer/social login context. For API access OAuth 2.0 is the first choice.

We broke up the article into different parts, each describing the solution for one of the requirements. If you like a sneak preview, watch the demo video:

Tags: , , , ,

Enterprise Identity Bus Part 2

English on February 19th, 2015 No Comments

The first step: Integrating in-house applications into a SSO system leveraging WSO2 as the identity server.

In the last article we introduced the project requirements to get rid of an application identity silo environment and to introduce an identity hub infrastructure. In this blog we are going to tackle requirement A.

A. Single Sign On for in-house applications: A classical WAM discipline involving policy agents installed into application servers, web servers and/or reverse proxies. These agents act as a policy enforcement point (PEP) which check for authentication, redirect to a central login application for authentication, validate sessions and access policies (authorization).

Searching through the WSO2 web site and documentation, you will quickly realize that WSO2 does not provide much help here. There are SAML agents written in Java which can be used with all WSO2 products and other J2EE web applications. But using access policies powered by the WSO2 Identity Server XACML entitlement engine is only available as something like an experimental feature. And you will be totally left out in the rain integrating content running on web servers or in reverse proxy architectures. That being said there is definitively the need to surf the internet and have a look for other options available.

If you are looking for SAML there are some community Apache modules available. In our use case we decided to go with OpenID Connect for in-house applications because it is based on OAuth 2.0 and as such can be easily used to provide OAuth access tokens to applications protected by a reverse proxy (e.g. through headers). We found open source mod_auth_openidc, developed by Hans Zandbelt / Ping Identity, licensed under Apache license.

Let’s continue the road: All we needed to do was to let the Apache module speak OpenID Connect to the WSO2 Identity Server. Sounds like a quick thing – we are using standards – but turned out to be work mainly due to the incomplete and buggy OpenID Connect implementation in WSO2 Identity Server 5.0.0. Several code modifications were necessary at the server side and as a side effect in the Apache module. Having done that we had a working SSO between the Apache proxies and the WSO2 IS but no authorization. We added the option to configure a “Require entitlement” in addition to the “Require valid-user” and “Require claim” directives already available in mod_auth_openidc. When this directive was activated the agent queries the WSO2 SOAP XACML entitlement interface checking the authorization for specific resources.
With that in place we were able to do single sign on between the in-house applications and protect the URLs with XACML formulated policies, centrally managed at the WSO2 Identity Server.

Requirement A accomplished. Read part 3 of this article for other requirements.

Tags: , , , ,

Enterprise Identity Bus Part 3

English on February 19th, 2015 No Comments

The second step: Account federations with cloud services and identity providers run by customers

In the first article we introduced the project requirements to get rid of an application identity silo environment and to introduce an identity hub infrastructure. The second part dealt with building a Single Sign On infrastructure leveraging WSO2 Identity Server and OpenID Connect apache agents. In this blog we describe the approach for requirement B:

B. Account federation to cloud services and to identity providers provided by the companies customers allowing SSO to cloud services like Office365 or the in-house applications.


Interoperating with cloud services and especially with services provided by customers is different from handling in-house applications: You barely have a choice and need to work with what the services offers or the customer wishes. As a result you will need to cope with different standard protocols or derivatives of it. In our scenario we had to integrate mainly leveraging SAML 2.0 with varying details: different attributes exchanged, signed elements, etc – facets SAML 2.0 generously allows.

That point of the story turned out to be quite easy to do. SAML is a well-established protocol and obviously old enough so that involved identity providers and service providers are compatible. The challenge arises if you want to dynamically (just-in-time) provision users into your system or establish dynamic account linking on profile attributes. Fortunately WSO2 IS 5.0.0 introduced flexibility with several configuration options.

Making attributes available via OpenID Connect UserInfo endpoint requires some puzzling with claim mappings but at the end it worked.

Requirement B accomplished. Read part 4 of the story for solving requirement C.

Tags: , , , ,

Enterprise Identity Bus Part 4

English on February 19th, 2015 No Comments

The third step: Enabling easy community registration and sign-on.

In the first article we introduced the project requirements to get rid of an application identity silo environment and to introduce an identity hub infrastructure. The second part dealt with building a Single Sign On infrastructure leveraging WSO2 Identity Server and OpenID Connect Apache agents. The third part described account federations with cloud services and identity providers run by customers. In this blog we approach the requirement C:

C. Enable community users to register and sign in with their own social login (Google, Facebook …) to internet accessible in-house applications and probably to cloud services integrated into the community environment (e.g. Zendesk for customer services).


Social authentication or sign-in allows users to access a service by using their Facebook, Google … accounts. No need to remember a new password or user name for the service. Also dynamic user creations eliminates or simplifies the annoying registration process filling out user profile forms, remembering password reset questions etc. Sounds like a good idea – integrating social logins had been a little cumbersome as most services used proprietary protocols or OAuth 2.0 for that. OAuth 2.0 flows are good for authorizing access to user data, but lack processes for transferring identity information. As a result the services implemented their proprietary add-on to the OAuth standard.

In the last months more and more of these services switched to OpenID Connect which builds on OAuth 2.0 but adds an extra identity layer. WSO2 Identity Server has predefined authentication options called “Federated Authenticators” for OpenID Connect, SAML and the derivatives from Facebook, Google, Yahoo Microsoft and some other possibly outdated standards. Making the Identity Bus reality: translating the in-house SSO protocol to the different languages of the multi-protocol-speaking real world.

Requirement 3 accomplished.

One word about provisioning. WSO2 Identity Server has support for SCIM provisioning. Currently not many services support that protocol but in the future a provisioning standard SCIM might play an important role especially when user life cycle processes involving de-provisioning will be tackled.

If you have questions do not hesitate to contact us. And don’t forget to watch the video showcasing the identity bus in action:

Tags: , , , ,

Do you speak SAML? Google Apps, Salesforce and SAP Hana Cloud tested

English on December 23rd, 2014 No Comments

In this article we compare the SAML service provider implementation of three popular cloud services:

  • Google Apps (which includes GMail, Google Drive and Docs, Calendar)
  • Salesforce
  • SAP Hana Cloud

Our testing procedure includes verification of the service provider compliance to the SAML 2.0 specification and checking the handling of signature validations.

Secure Assertion Markup Language (SAML) today is the main standard used for signing in to Cloud Services with a single authentication procedure (typically username/password). A correct implementation of the standard is crucial for security. Failing to do so may compromise security and lead to information loss.
Unfortunately SAML 2.0 is very complex and probably over-engineered. Leaving the developer too many degrees of freedom to implement only parts of the security measures envisaged by the standard. The risk even aggravates as the implementation might look like they are functioning correctly: single sign on works and some of the checks against signature or timestamps are processed. But on diving a little deeper security issues or nonconformity will become evident.
In our research we tested Google Apps, Salesforce CRM and SAP Hana Cloud as representatives of modern Cloud Service providers which provide Single Sign On integration with SAML 2.0.

Research method: Tool to run automated tests leveraging the SSOCheck API.

Test cases were divided into different testing areas:

  1. Replay
  2. General XML
  3. SAML Response Message
  4. SAML Assertion
  5. Digital Signature

Whereas the tests of area 3 and 4 typically refer to the components of the SAML documents as illustrated in the following picture.

SAP performed best in all categories. Salesforce ranked second. Google was vulnerable to assertion replay and almost completely ignored the response part of the SAML message and several attributes of the assertion.

We informed the security teams of the tested companies about the results before publishing the article. All companies replied in acceptable time. Some involved their development departments which tried to reproduce the tests and some were arguing with risk based approaches. Salesforce being the fastest and most communicative respondent. SAP’s answer was the slowest but the most meticulous. Google took some time to respond but over time a very interesting discussion evolved with participation of several members of the security and product team which leads to the enrollment of product patches. Most parties leveraged SSOCheck tool to understand and reproduce the findings.

The following table summarizes the results found.
Summary Table (% passed tests)

Test Google Apps Salesforce CRM SAP Hana Cloud
Replay 0 100 100
General XML 100 100 100
SAML Response 16.7 66.7 83.3
SAML Assertion 50.0 69.2 76.9
Digital Signature 100 100 100 (*)
Total 48.5 82.7 88.5

*) SAP Hana Cloud was the only service provider who accepted a SAML response with an evil assertion inserted before the valid assertion. We rated the test as passed since the SAP implementation seemed to totally ignore the evil assertion and therefore could not be used to attack the service.

Total results were calculated as a weighted average of the group results. Giving the SAML assertion tests a weight of 2, general XML tests a weight of 0.5 and the rest a weight of 1.

Detailed test result table:

Test Google Apps Salesforce CRM SAP Hana Cloud
1 Unmodified SAML – as a positive protocol test
2 Replay Attack – SAML protocol message replayed
3 Invalid SAML Protocol Namespace
4 Invalid SAML Assertion Namespace
5 SAML Response Status Code is set to RequestDenied
6 SAML Response Issuer is invalid
7 SAML Response IssueInstant is set to a value in the future
8 SAML Response InResponseTo is invalid
9 SAML Response Destination is invalid
10 SAML Response Version is invalid
11 SAML Assertion Issuer invalid
12 SAML Assertion IssueInstant is set to a value in the future
13 SAML Assertion Version is invalid
14 SAML Assertion Subject without NameID
15 SAML Assertion subject NameId format set to an unknown value
16 SAML Assertion SubjectConfirmation Method invalid
17 No SubjectConfirmationData element in the SAML Assertion sent
18 SAML Assertion InResponseTo is invalid
19 Recipient in SAML Assertion SubjectConfirmationData is invalid
20 Address in SAML Assertion SubjectConfirmationData is invalid
21 NotOnOrAfter in SAML Assertion SubjectConfirmationData is set to a value 1h into the past
22 Two Assertion SubjectConfirmationData elements whereas the first is the valid one and the second is a wrong value.
23 Two Assertion Subject Confirmation Data elements whereas the first is the wrong one and the second has the correct value.
24 SAML Assertion Condition is inserted which is unknown to the service provider
25 SAML Assertion Condition NotBefore is set to a value of 1h in advance.
26 SAML Assertion Condition NotOnOrAfter set to 1h in the past.
27 Syntax test to check that the SP supports the OneTimeUse element.
28 AudienceRestriction element in SAML Assertion Condition is empty
29 AudienceRestriction element in SAML Assertion Condition is set to a wrong value
30 Two values in one SAML Assertion AudienceRestriction element. The wrong value is the first
31 Two values in one SAML Assertion AudienceRestriction element. The wrong value is second.
32 Two AudienceRestriction elements in SAML Assertion. The first elment holds the wrong value
33 Two AudienceRestriction elements in SAML Assertion. The second elment holds the wrong value
34 Two AudienceRestriction elements in SAML Assertion. Both hold two audience values in different ordering
35 AuthnStatement is missing in SAML Assertion
36 Sets the SubjectLocality of AuthnStatement to a non valid IP address
37 AuthnInstant timstamp of Assertion AuthNStatement is moved one day into the future.
38 AuthnInstant timstamp of Assertion AuthNStatement is moved one day back in time.
39 SessionNotOnOrAfter timstamp of Assertion AuthNStatement is set one day in the past.
40 AuthnContextClassRef of Assertion AuthNStatement is set to “unsepcified” and should be declined by the service provider.
41 Multiple Signature tests: signature exclusion
42 Multiple Signature tests: mangled signature
43 Multiple Signature tests: wrong signature key
44 signature wrapping variants

All tested Cloud Services did not fully comply with the SAML standard.

SAP and Salesforce did not disclose any severe problems which could lead to a significant exploit. Non conformity to the specification might lead to the non-functioning of specific use cases but can be justified in order to achieve broader compatibility with IDP products or might be argued with risk based approaches.
Google Apps SAML implementation revealed several issues which could be leveraged by an attack scenario. The good news is that Google has rolled out fixes for these findings which we were able to verify.
We especially thank the Google team for a valuable interaction and cooperation.

If you have questions or comments please let me know. We are also looking for other SaaS services, which might be of general interest to run the tests against.

Tags: , , , ,

Terms Of Use updated

English on August 24th, 2014 No Comments

This is to announce a change in the SSOCircle Terms of Use which might affect both existing accounts and new user registrations to the public IDP. From now on we might block registrations with specific email addresses (for example disposable email addresses)  and we will limit (currently 3 – subject to change) the number of user accounts registered to a single contact address.

Why the change? In the last months we are seeing growing numbers of registrations either used for regular training classes and/or large scale quality assurance test runs. Although we advocate these kind of usage, we consider it a matter of fairness for these companies to purchase either our hosted IDPee offering or to subscribe to SSOCheck API private. Both are offering a hosted tenant where any number of users might be created. SSOCheck Private API even adds the opportunity of running additional compliance and security tests against SAML service provider deployments.

This decision was made to protect the investment of our paying customers and to keep the public IDP running as a free service – without annoying advertising.

Please note: Existing accounts not corresponding to the Terms of Use should be changed to be compliant. Non-compliant user accounts will be inactivated in the next days.

If you have questions or comments, please contact us.