Test your SAML Service Provider from the Command Line

English on March 14th, 2016 No Comments

cURL and wget – these tools tend to be of great value when a developer starts programming against a new API. With OAuth, you need to get an access token from one API and query another API for the actual data. Seeing the requests at the command line helps understanding the protocols and errors that might occur.

With SAML things are more complex. The most frequent usage scenarios in SAML assume the use of a browser. SAML messages are often sent through HTTP-POST, mainly because the content can become lengthy. Technically the POSTing of the SAML message to another server is done via auto-posting of a HTML form. Running a SAML SSO flow from the command line imposes challenges, which go beyond the simple use of cURL or wget.

When we first launched our SAML Testing API “SSOCheck”, we also provided a tool, implemented as a Firefox extension, to make running SAML flows leveraging the test API easier. Despite that we constantly receive requests to provide cURL samples which can be used to run tests. Thanks to our user’s suggestions, we have no prepared a tutorial about how to run SAML Tests with cURL from the command line. It is composed of two parts. The first part will create a script to run a SAML browser profile SSO flow. And the second part builds upon the script from part one and adds testing functionality using the SAML test API. Please start reading the tutorial.


[Update: 20/03/2016: Tutorial part II published]

Tags: , , , ,

New Premium Feature: Debugging IDP Integration

English on February 29th, 2016 No Comments

SAML Integration is easy? If you start to get your hands dirty and undertake the first steps in implementing the standard, you will most likely get an error when running your initial tests.


You simply might have missed to import your service provider metadata into the SSOCircle of Trust or have something wrong with the different encodings that the standard mandates. Although we provide error messages, many users missed more detailed trouble shooting help. Enabling debug information is a feature which was requested very often. We are happy to announce that it is no available. Read more at the knowledge base.

Tags: , , ,

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 (https://freakattack.com) 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 http://openid.net/specs/openid-connect-session-1_0.html (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: hipstabank.com
Draft specs: https://bitbucket.org/openid/ac

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 https://allseenalliance.org/)

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: Meeco.me. 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 meeco.me. Meeco.me 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 SSOCircle.com 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 ssocircle.com, 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 @ssocircle.com 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: , , , ,