Two Security Patches Issued Publicly for WSO2 Identity Server 5.0.0
Wolfgang Ettlinger (discovery, analysis, coordination) from the SEC Consult Vulnerability Lab contacted WSO2 security team on 19th March and reported following three vulnerabilities in WSO2 Identity Server 5.0.0.
1) Reflected cross-site scripting (XSS, IDENTITY-3280)
Some components of the WSO2 Identity Server are vulnerable to reflected cross-site scripting vulnerabilities. The effect of this attack is minimal because WSO2 Identity Server does not expose cookies to JavaScript.
2) Cross-site request forgery (CSRF, IDENTITY-3280)
On at least one web page, CSRF protection has not been implemented. An attacker on the internet could lure a victim, that is logged in on the Identity Server administration web interface, on a web page e.g. containing a manipulated tag. The attacker is then able to add arbitrary users to the Identity Server.
3) XML external entity injection (XXE, IDENTITY-3192)
An unauthenticated attacker can use the SAML authentication interface to inject arbitrary external XML entities. This allows an attacker to read arbitrary local files. Moreover, since the XML entity resolver allows remote URLs, this vulnerability may allow to bypass firewall rules and conduct further attacks on internal hosts. This vulnerability was found already before being reported by Wolfgang Ettlinger and all our customers were patched. But the corresponding patch was not issued publicly. Also this attack is not harmful as it sounds to be since in all our production deployments, WSO2 Identity Server is run as a less privileged process, which cannot be used to exploit or gain access to read arbitrary local files.
WSO2 security team treats all the vulnerabilities that are reported to security@wso2.com, top most important and we contacted the reporter immediately and started working on the fix. The fixes were done on the reported components immediately - but we wanted to make sure we build a generic solution where all the possible XSS and CSRF attacks are mitigated centrally.
Once that solution is implemented as a patch to the Identity Server 5.0.0 - we tested the complete product using OWASP Zed Attack Proxy and CSRFTester. After testing almost all the Identity Server functionality with the patch - we released it to all our customers two weeks prior to the public disclosure date. The patch for XXE was released few months back. Also I would like to confirm that none of the WSO2 customers were exploited/attacked using any of theses vulnerabilities.
On 13th May, parallel to the public disclosure, we released both the security patches publicly. You can download following patches from http://wso2.com/products/identity-server/.
- WSO2-CARBON-PATCH-4.2.0-1194
- WSO2-CARBON-PATCH-4.2.0-1095
WSO2 security team is dedicated to protect all its customers and the larger community around WSO2 from all sort of security vulnerabilities. We appreciate your collaboration and please report any of the security issues you discover related to WSO2 products to security@wso2.com.
MQTT Security Fundamentals
- MQTT Essentials http://www.hivemq.com/mqtt-essentials-wrap-up/
- Introducing the MQTT Security Fundamentals http://www.hivemq.com/introducing-the-mqtt-security-fundamentals/
- Authentication with Username and Password http://www.hivemq.com/mqtt-security-fundamentals-authentication-username-password/
- Advanced Authentication Mechanisms http://www.hivemq.com/mqtt-security-fundamentals-advanced-authentication-mechanisms/
- Authorization http://www.hivemq.com/mqtt-security-fundamentals-authorization/
- SSL/TLS http://www.hivemq.com/mqtt-security-fundamentals-tls-ssl/
Identity Mediation Language (IML) - Requirements Specification
A recent research done by the analyst firm Quocirca confirms that many businesses now have more external users than internal ones: in Europe 58 percent transact directly with users from other businesses and/or consumers; for the UK alone the figure is 65 percent. If you look at the history, most enterprises grow today via acquisitions, mergers and partnerships. In U.S only, mergers and acquisitions volume totaled to $865.1 billion in the first nine months of 2013, according to Dealogic. That’s a 39% increase over the same period a year ago — and the highest nine-month total since 2008.
Gartner predicts by 2020, 60% of all digital identities interacting with enterprises will come from external identity providers.
I have written two blog posts in detail highlighting the need for an Identity Bus.
The objective of this blog post is to define the high-level requirements for the Identity Mediation Language. Your thoughts/suggestions are extremely valuable and highly appreciated to evolve this into a language where the global identity management industry will benefit.
1. Transform identity tokens from one protocol to another.
For example, the Identity Mediation Language should have the provision to the transform an incoming SAML request into an OpenID Connect request, and then the OpenID Connect response from the Identity Provider into a SAML response.
2. The language should have the ability define a handler chain in inbound-authentication-request flow, outbound-authentication-request flow, outbound-authentication-response flow, inbound-authentication-response flow and any of the major channels identified as this specification evolves.
3. The language should define a common syntax and semantics, independent from any of the protocols.
Having a common a common syntax and semantics for the language, independent from any of the specific protocols will make it extensible. Support for specific protocols should be implemented as handlers. Each handler should be aware of how to translate the common syntax defined by the language to its own on syntax - and how to process them in a protocol specific manner.
Following is a sample configuration (which must evolve in the future). Language is not coupled to any implementations. There can be global handlers for each protocol, but then again, should be able to override in each request flow if needed.
{
"inbound-authentication-request" :
{ "protocol": "saml",
"handler" : "org.wso2.SAMLAuthReqRespHandler"
},
"outbound-authentication-request" :
{ "protocol": "oidc",
"handler" : "org.wso2.OIDCAuthReqRespHandler"
}
}
4. The language should have the provision to define a common request/response path as well as override it per service provider.
5. The language should have the provision to identify the service provider by a unique name or by any other associate attributes. These attributes can be read from incoming transport headers or from the Identity Token itself. If read from the ID token, the way to identify that attribute must be protocol agnostic. For example, if the incoming ID token is a SAML token, then - if we need to identify the issuer from an attribute in the SAML token, the language should define it as an XPATH, with out using any SAML specific semantics.
6. The language should have the provision to define, whether an incoming request is just a pass-through.
7. The language should have the provision to define, which transport headers should be passed-through to outbound-authentication-request path.
8. The language should have the provision to define, which transport headers needs to be added to the outbound-authentication-request path.
9. The language should have the provision to log all the requests and responses. Should be able to configure logging per service providers. Log handler should be configurable, per service provider. Due to PCI compliance requirements we may not be able to log the complete message, all the time.
10. The language should have provision to retrieve attributes and attribute metadata, required by a given service provider, via an attribute handler. Also - it should have the provision to define attribute requirements inline.
11. The language should have provision to define, authentication requirements per service providers. The authentication can be using one more - local authenticators, federated authenticators or federated authenticators. The local authenticators will authenticate the end user, using a local credential store. The federated authenticators will talk to an external identity provider to authenticate users. The request path authenticators will authenticate users from the credentials attached to request itself.
12. The language should have the provision to define, multiple-option and multiple-steps authentication, per service provider. In multiple-option scenario, the relationship between in authenticators is an OR. That means, user needs to authenticate only using a single authenticator. With multiple-steps, the relationship between steps is an AND. User must authenticate in successfully in each step.
13. The language should have the provision to define, multiple-option and multiple-steps authentication, per user. The user can be identified by the username or by any other attribute of the user. For example, if user belongs to the 'admin' role, then he must authenticate with multi-factor authentication.
14. The language should have the provision to define, multiple-option and multiple-steps authentication, per user, per service provider. The user can be identified by the username or by any other attribute of the user. For example, if user belongs to the 'admin' role and if he accesses a high-privileged application then he must authenticate with multi-factor authentication, if the same person accesses the user profile dashboard, then multi-factor authentication is not required.
15. The language should not define any authenticators by itself.
16. The language should have the provision to define, authenticator sequences independently and then associate them to an authentication request path, just by a reference. Also should have the ability to define them inline.
17. The language should support defining requirements for adaptive authentication. A service provider may have a concrete authenticator sequence attached to it. At the same time, the language should have the provision to dynamically pick authenticator sequences in a context aware manner.
18. The language should have the provision to define, per service provider, authorization policies. Authorization policy may define the criteria under which an end-user can access the given service provider. Only if its satisfied by the authenticated user, the identity provider should send back the authentication response.
19. The language should have the provision to define how to transform a claim set obtained from an identity provider to a claim dialect specific to a give service provider. This can be a simple one to one claim transformation, for example http://claims.idp1.org/firstName --> http://claims.sp1.org/firstName, or a complex claim transformation like, http://claims.idp1.org/firstName + http://claims.idp1.org/lastName --> http://claims.sp1.org/fullName. The language should have the provision to do this claim transformation from inboudAuthenticationRequest flow to outboundAuthenticationRequest/localAuthenticationRequest flow and from outboundAuthenticationResponse/localAuthenticationResponse flow to inboundAuthenticationResponse flow.
20. The language should have the provision to authenticate service providers, irrespective of the protocol used in the inboundAuthenticationRequest.
21. The language should have the provision to accept, authentication requests, provisioning requests, authorization requests, attribute requests and any other types of requests from the service provider. The language should not be just limited to above four types of requests and must have the provision to extend.
22. The language should define a way to retrieve identity provider and service provider metadata.
23. The language should have the provision to define rule-based user provisioning per service provider, per identity provider or per user - and per attributes associated with any of the above entities. For example, if the user is provisioned to the system via foo service provider and if his role is sales-team, provision the user to salesforce. Another example could be, provision everyone authenticated against the Facebook identity provider to a internal user store.
24. The language should have the provision to indicate to a policy decision point (for access controlling), from which service provider the access controlling request is initiated from and also with the other related metadata.
25. The language should have the provision to the specify just-in-time provisioning requirements per service provider, per identity provider or per user - and and per attributes associated with any of the above entities.
26. The language should have the provision to specify, per service provider - the user
store and the attribute store for local authentication and to retrieve user attributes locally.
27. The language should have the provision to specify an algorithm and a handler for force authentication for users already logged into the identity provider. There can be a case where user is already authenticated to the system with a single factor - when the same user tries to log into a service provider which needs two-factor authentication, then the algorithm handler should decide whether to force user authentication - and if so at which level. There can be an algorithm handler defined at the global level and also per service provider request flow.
28. The language should have the provision to specify a home-realm-discovery handler, per service provider. This handler should know how to read the request to find out relevant attributes that can be used to identify the authentication options for that particular request.
29. The language should have the provision to define attribute requirements for out-bound provisioning requests.
30. The language should have the provision to define claim transformations prior to just-in-time provisioning or out-bound provisioning.
31. The language must have the provision to define how to authenticate to external endpoints. The language should not be coupled into any specific authentication protocol.
Gartner predicts by 2020, 60% of all digital identities interacting with enterprises will come from external identity providers.
I have written two blog posts in detail highlighting the need for an Identity Bus.
- Connected Identity : Benefits, Risks & Challenges
- Borderless Identity: Managing Identity in a Complex World
The objective of this blog post is to define the high-level requirements for the Identity Mediation Language. Your thoughts/suggestions are extremely valuable and highly appreciated to evolve this into a language where the global identity management industry will benefit.
1. Transform identity tokens from one protocol to another.
For example, the Identity Mediation Language should have the provision to the transform an incoming SAML request into an OpenID Connect request, and then the OpenID Connect response from the Identity Provider into a SAML response.
2. The language should have the ability define a handler chain in inbound-authentication-request flow, outbound-authentication-request flow, outbound-authentication-response flow, inbound-authentication-response flow and any of the major channels identified as this specification evolves.
Having a common a common syntax and semantics for the language, independent from any of the specific protocols will make it extensible. Support for specific protocols should be implemented as handlers. Each handler should be aware of how to translate the common syntax defined by the language to its own on syntax - and how to process them in a protocol specific manner.
Following is a sample configuration (which must evolve in the future). Language is not coupled to any implementations. There can be global handlers for each protocol, but then again, should be able to override in each request flow if needed.
{
"inbound-authentication-request" :
{ "protocol": "saml",
"handler" : "org.wso2.SAMLAuthReqRespHandler"
},
"outbound-authentication-request" :
{ "protocol": "oidc",
"handler" : "org.wso2.OIDCAuthReqRespHandler"
}
}
4. The language should have the provision to define a common request/response path as well as override it per service provider.
5. The language should have the provision to identify the service provider by a unique name or by any other associate attributes. These attributes can be read from incoming transport headers or from the Identity Token itself. If read from the ID token, the way to identify that attribute must be protocol agnostic. For example, if the incoming ID token is a SAML token, then - if we need to identify the issuer from an attribute in the SAML token, the language should define it as an XPATH, with out using any SAML specific semantics.
6. The language should have the provision to define, whether an incoming request is just a pass-through.
7. The language should have the provision to define, which transport headers should be passed-through to outbound-authentication-request path.
8. The language should have the provision to define, which transport headers needs to be added to the outbound-authentication-request path.
9. The language should have the provision to log all the requests and responses. Should be able to configure logging per service providers. Log handler should be configurable, per service provider. Due to PCI compliance requirements we may not be able to log the complete message, all the time.
10. The language should have provision to retrieve attributes and attribute metadata, required by a given service provider, via an attribute handler. Also - it should have the provision to define attribute requirements inline.
11. The language should have provision to define, authentication requirements per service providers. The authentication can be using one more - local authenticators, federated authenticators or federated authenticators. The local authenticators will authenticate the end user, using a local credential store. The federated authenticators will talk to an external identity provider to authenticate users. The request path authenticators will authenticate users from the credentials attached to request itself.
12. The language should have the provision to define, multiple-option and multiple-steps authentication, per service provider. In multiple-option scenario, the relationship between in authenticators is an OR. That means, user needs to authenticate only using a single authenticator. With multiple-steps, the relationship between steps is an AND. User must authenticate in successfully in each step.
13. The language should have the provision to define, multiple-option and multiple-steps authentication, per user. The user can be identified by the username or by any other attribute of the user. For example, if user belongs to the 'admin' role, then he must authenticate with multi-factor authentication.
14. The language should have the provision to define, multiple-option and multiple-steps authentication, per user, per service provider. The user can be identified by the username or by any other attribute of the user. For example, if user belongs to the 'admin' role and if he accesses a high-privileged application then he must authenticate with multi-factor authentication, if the same person accesses the user profile dashboard, then multi-factor authentication is not required.
15. The language should not define any authenticators by itself.
16. The language should have the provision to define, authenticator sequences independently and then associate them to an authentication request path, just by a reference. Also should have the ability to define them inline.
17. The language should support defining requirements for adaptive authentication. A service provider may have a concrete authenticator sequence attached to it. At the same time, the language should have the provision to dynamically pick authenticator sequences in a context aware manner.
18. The language should have the provision to define, per service provider, authorization policies. Authorization policy may define the criteria under which an end-user can access the given service provider. Only if its satisfied by the authenticated user, the identity provider should send back the authentication response.
19. The language should have the provision to define how to transform a claim set obtained from an identity provider to a claim dialect specific to a give service provider. This can be a simple one to one claim transformation, for example http://claims.idp1.org/firstName --> http://claims.sp1.org/firstName, or a complex claim transformation like, http://claims.idp1.org/firstName + http://claims.idp1.org/lastName --> http://claims.sp1.org/fullName. The language should have the provision to do this claim transformation from inboudAuthenticationRequest flow to outboundAuthenticationRequest/localAuthenticationRequest flow and from outboundAuthenticationResponse/localAuthenticationResponse flow to inboundAuthenticationResponse flow.
20. The language should have the provision to authenticate service providers, irrespective of the protocol used in the inboundAuthenticationRequest.
21. The language should have the provision to accept, authentication requests, provisioning requests, authorization requests, attribute requests and any other types of requests from the service provider. The language should not be just limited to above four types of requests and must have the provision to extend.
22. The language should define a way to retrieve identity provider and service provider metadata.
23. The language should have the provision to define rule-based user provisioning per service provider, per identity provider or per user - and per attributes associated with any of the above entities. For example, if the user is provisioned to the system via foo service provider and if his role is sales-team, provision the user to salesforce. Another example could be, provision everyone authenticated against the Facebook identity provider to a internal user store.
24. The language should have the provision to indicate to a policy decision point (for access controlling), from which service provider the access controlling request is initiated from and also with the other related metadata.
25. The language should have the provision to the specify just-in-time provisioning requirements per service provider, per identity provider or per user - and and per attributes associated with any of the above entities.
26. The language should have the provision to specify, per service provider - the user
store and the attribute store for local authentication and to retrieve user attributes locally.
27. The language should have the provision to specify an algorithm and a handler for force authentication for users already logged into the identity provider. There can be a case where user is already authenticated to the system with a single factor - when the same user tries to log into a service provider which needs two-factor authentication, then the algorithm handler should decide whether to force user authentication - and if so at which level. There can be an algorithm handler defined at the global level and also per service provider request flow.
28. The language should have the provision to specify a home-realm-discovery handler, per service provider. This handler should know how to read the request to find out relevant attributes that can be used to identify the authentication options for that particular request.
29. The language should have the provision to define attribute requirements for out-bound provisioning requests.
30. The language should have the provision to define claim transformations prior to just-in-time provisioning or out-bound provisioning.
31. The language must have the provision to define how to authenticate to external endpoints. The language should not be coupled into any specific authentication protocol.
The Mobile Connect implementation by Dialog Axiata and Sri Lanka Telecom Mobitel gets a special award at the EIC 2015
Dialog Axiata and Sri Lanka Telecom Mobitel won a special award at the European Identity Conference 2015, for the Mobile Connect implementation with the WSO2 Identity Server. It was my pleasure to accept the award on behalf of all three companies - and credit goes to the fantastic teams behind this whole effort from all three companies.
The combined WSO2-Dialog-Mobitel Mobile Connect solution is a fast, secure log-in system for mobile authentication that enables people to access their online accounts with just one click. There are different levels of security from low-level website access to highly secure bank-grade authentication. People who have subscribed to a participating operator know that when they click on a website’s Mobile Connect button they are making passwords a thing of the past.
It is the world’s first multi-operator Mobile Connect solution that provides an out-of-band medium for authenticating a user to any service provider without requiring a password. The GSM/UMTS network is used to send a USSD prompt, which can be simple ‘click OK’ or a request for a PIN, at the point of authentication. The response then verifies the user’s authenticity. For users accessing the site via a mobile network, seamless login can be enabled, removing the need for the USSD interactions and further simplifying the user experience.
The WSO2-Dialog-Mobitel solution fully conforms to the GSMA CPAS5 OpenID Connect OpConnect Profile 1.0. This is based on the OpenID Connect 1.0 core specification. Additional details on this are included in the answer to question 6 regarding the technologies implemented.
Mobile Connect was initially launched on trial basis to a significant user base as a combined effort between Dialog Axiata, Mobitel and WSO2 in July 2014.
Based on the success of the trial, Dialog Axiata and Mobitel are running this service live for the entire customer base of both operators totaling more than 14 million subscribers.
The combined WSO2-Dialog-Mobitel Mobile Connect solution is a fast, secure log-in system for mobile authentication that enables people to access their online accounts with just one click. There are different levels of security from low-level website access to highly secure bank-grade authentication. People who have subscribed to a participating operator know that when they click on a website’s Mobile Connect button they are making passwords a thing of the past.
It is the world’s first multi-operator Mobile Connect solution that provides an out-of-band medium for authenticating a user to any service provider without requiring a password. The GSM/UMTS network is used to send a USSD prompt, which can be simple ‘click OK’ or a request for a PIN, at the point of authentication. The response then verifies the user’s authenticity. For users accessing the site via a mobile network, seamless login can be enabled, removing the need for the USSD interactions and further simplifying the user experience.
The WSO2-Dialog-Mobitel solution fully conforms to the GSMA CPAS5 OpenID Connect OpConnect Profile 1.0. This is based on the OpenID Connect 1.0 core specification. Additional details on this are included in the answer to question 6 regarding the technologies implemented.
Mobile Connect was initially launched on trial basis to a significant user base as a combined effort between Dialog Axiata, Mobitel and WSO2 in July 2014.
Based on the success of the trial, Dialog Axiata and Mobitel are running this service live for the entire customer base of both operators totaling more than 14 million subscribers.
Connected Identity : Benefits, Risks & Challenges
It was a day in August 2012. Mat Honan - a reporter for the Wired magazine, San Francisco, returned home and was playing with his little daughter. He had no clue, what was going to happen next. Suddenly his iPhone was powered down. He was expecting a call - so he plugged it into a wall power socket and rebooted back. What he witnessed next blew him away. Instead of the iPhone home screen with all the apps - now it asks for him to set up a new phone with a big Apple logo and a welcome screen. Honan thought his iPhone was misbehaving - but was not that worried since he backed up daily to the iCloud - restoring everything from iCloud could simply fix this. Honan tried to login to iCloud. Tried once - failed. Tried again - failed. Again - failed. Thought he was excited. Tried once again… and failed. Now he knew something weird has happened. His last hope was his MacBook. Thought at least he could restore everything from the local backup. Booted up the MacBook - nothing in it - and prompted him to enter a four digit passcode - that he has never set up before.
Honan never gives up. He called Apple tech support to reclaim his iCloud account. Then he learnt he has called Apple, 30 minutes before, to reset his iCloud password. Only information required at that time to reset an iCloud account were, the billing address and the last four digits of the credit card. The billing address was readily available under the Whois internet domain record Honan had for his personal website. The attacker was good enough to get the last four digits of Honan’s credit card by talking to Amazon helpdesk - he already had Honan’s email address and the full mailing address - those were more than enough for a social engineering attack.
Honan lost almost everything. The attacker was still desperate - next he broke into Honan’s GMail account. Then from there to his Twitter account. One by one - Honan’s connected identity fall into the hands of the attacker.
Something we all know by heart - the principle of the weakest link. Any computer system is as strong as the strength of the weakest link in it. No matter you have biometrics to log in to your iPhone or to the MacBook - someone gaining access to your iCloud account can wipe off both of them.
Today, the global Internet economy is somewhere in the neighborhood of $10 trillion US dollars. By 2016, almost half the world’s population - about 3 billion people - will use the internet. Not just humans - during 2008 – the number of things connected to Internet exceeded the number of people on earth. Over 12.5 billion devices were connected to the Internet in 2012. It is estimated that 25 billion devices will be connected to the Internet by the end of 2015 - and by the end of 2020, 50 billion devices will be connected.
Connected devices have existed in one form or another since the introduction of the first computer networks and the consumer electronics. However, it wasn’t until the Internet emerged, that the idea of a globally connected planet started to take off. In 1990s researchers theorized how human and machine could weave together a completely new form of communication and interaction via machines. That reality is now unfolding before our eyes.
The word ‘Identity’ is no more just about humans. It represents both humans and ‘things’.
The Identity of Things (IDoT) is an effort that involves assigning unique identifiers (UID) with associated metadata to devices and objects (things), enabling them to connect and communicate effectively with other entities over the Internet.
The metadata associated with the unique identifier collectively defines the identity of an endpoint. Identity of things is an essential component of the Internet of Things (IoT), in which almost anything imaginable can be addressed and networked for exchange of data online. In this context, a thing can be any entity -- including both physical and logical objects -- that has a unique identifier and the ability to transfer data over a network.
The definition of Identity has evolved with the Internet of Things. Identity cannot be defined just by by attributes or claims. It can be further refined by patterns or behaviors. The Fitbit you wear while you sleep, knows your sleeping patterns. The sensors attached to your connected car knows your driving patterns. The sensors attached to your refrigerator knows your daily food consumption patterns. None of the identity stores out there can build a complete image of a given entity’s identity. Forget about the aggregated view - another challenge we face today in the connected world is the data migration and the ownership.
Connected cars collect and store a vast amount of data. This data goes well beyond a vehicle owner's personal preferences and settings. Connected cars collect driver data such as travel routes, travel destinations, car speeds, driver behavior, commute patterns and much more.
Connected cars are only a fraction of the millions and millions of Internet-connected devices that enable users to set their personal preferences and that collect vast amounts of user data. All of these IoT devices are helping to create a "virtual identity" for each and every user.
While this user-generated data will most likely last forever, connected cars and all the other Internet-connected devices will not. This leads to several important questions concerning connected car owners and their data:
Identity silos create a lot of friction in the connected business. One way to reduce friction - but still keeping data in silos - and of course the ownership of data - is by exposing Identity data via APIs. That would help end users to build and understand a better picture of their own identity. Now they can relate driving patterns with sleeping patterns. The daily food consumption patterns with sleeping patterns and many more. The BMW Connected Drive, which connects to your Fitbit, now knows if you haven’t slept well last night - and possibly, present you the options that helps you for a safe drive.
Propagating end user identity across these APIs is the next challenge. Building a protocol agnostic security model is the key for connected identity. If we build BMW Connected Drive to be compliant with the security model of Fitbit, then, when it talks to Yelp to find the best nearby restaurant, that’s mostly rated by your friends in Facebook, BMW Connected Drive should then also be compatible with the security model of Facebook and Yelp. In other words, we are just starting to build a point to point security model, that would lead to the spaghetti identity - antipattern.
Identity silos and spaghetti identity anti-patterns are not only present in the IoT world.
If you look at the history, most enterprises grow today via acquisitions, mergers and partnerships. In U.S only, mergers and acquisitions volume totaled to $865.1 billion in the first nine months of 2013, according to Dealogic. That’s a 39% increase over the same period a year ago — and the highest nine-months total since 2008.
A research done by the analyst firm Quocirca confirms that many businesses now have more external users than internal ones: in Europe 58 percent transact directly with users from other businesses and/or consumers; for the UK alone the figure is 65 percent. Another analyst firm predicts by 2020, 60% of all digital identities interacting with enterprises will come from external IdPs.
Each external Identity Provider can be treated as an Identity silo. The way identity data are shared, is through APIs. The Identity consumer, or the service provider, must trust the identity provider to accept a given user identity. Beyond the trust, both the service provider - and the identity provider must speak the same language to bootstrap the trust relationship, and then transport identity data. How about a service provider, which is incompatible with the Identity token sharing protocol supported by the Identity provider? Either you need to fix the Identity provider end to speak the same language of the service provider, or the otherway around.
Under today’s context connected business is a very dynamic and complex environment. Your desire is to reach out to your customers, partners, distributors and suppliers and create more and more business interactions and activities, that will generate more revenue. The goal here is not just integrate technological silos, in your enterprise – but also make your business more accessible and reactive.
Having friction to build connections between your business entities - is something that cannot be tolerated. The cost of provisioning a service provider or an identity provider into the system could be high, due to the protocol incompatibilities. Also, building point-to-point trust relationships between service providers and identity providers - does not scale well.
With the Identity Bus or the Identity Broker pattern, a given service provider is not coupled to a given identity provider - and also not coupled to a given federation protocol. The broker maintains the trust relationships between each entity and also mediates identity tokens between multiple heterogeneous security protocols. It can further centrally enforce access controlling, auditing and monitoring.
With ever evolving standards for identity federation - and having no proper standard to manage and propagate device identities, Identity Broker will play a key role in building a common, connected identity platform in a protocol agnostic manner.
Following highlights some of the benefits of the Identity Broker pattern.
1. The Internet of Things (The MIT Press Essential Knowledge series), http://www.amazon.com/Internet-Things-Press-Essential-Knowledge/dp/0262527731
2. Future Crimes: Everything Is Connected, Everyone Is Vulnerable and What We Can Do About It, http://www.amazon.com/Future-Crimes-Everything-Connected-Vulnerable/dp/0385539002
3. http://www.programmableweb.com/news/identity-and-access-management-iam-will-greatly-impact-future-connected-car-sales/analysis/2014/08/20
Honan lost almost everything. The attacker was still desperate - next he broke into Honan’s GMail account. Then from there to his Twitter account. One by one - Honan’s connected identity fall into the hands of the attacker.
Something we all know by heart - the principle of the weakest link. Any computer system is as strong as the strength of the weakest link in it. No matter you have biometrics to log in to your iPhone or to the MacBook - someone gaining access to your iCloud account can wipe off both of them.
Today, the global Internet economy is somewhere in the neighborhood of $10 trillion US dollars. By 2016, almost half the world’s population - about 3 billion people - will use the internet. Not just humans - during 2008 – the number of things connected to Internet exceeded the number of people on earth. Over 12.5 billion devices were connected to the Internet in 2012. It is estimated that 25 billion devices will be connected to the Internet by the end of 2015 - and by the end of 2020, 50 billion devices will be connected.
Connected devices have existed in one form or another since the introduction of the first computer networks and the consumer electronics. However, it wasn’t until the Internet emerged, that the idea of a globally connected planet started to take off. In 1990s researchers theorized how human and machine could weave together a completely new form of communication and interaction via machines. That reality is now unfolding before our eyes.
The word ‘Identity’ is no more just about humans. It represents both humans and ‘things’.
The Identity of Things (IDoT) is an effort that involves assigning unique identifiers (UID) with associated metadata to devices and objects (things), enabling them to connect and communicate effectively with other entities over the Internet.
The metadata associated with the unique identifier collectively defines the identity of an endpoint. Identity of things is an essential component of the Internet of Things (IoT), in which almost anything imaginable can be addressed and networked for exchange of data online. In this context, a thing can be any entity -- including both physical and logical objects -- that has a unique identifier and the ability to transfer data over a network.
The definition of Identity has evolved with the Internet of Things. Identity cannot be defined just by by attributes or claims. It can be further refined by patterns or behaviors. The Fitbit you wear while you sleep, knows your sleeping patterns. The sensors attached to your connected car knows your driving patterns. The sensors attached to your refrigerator knows your daily food consumption patterns. None of the identity stores out there can build a complete image of a given entity’s identity. Forget about the aggregated view - another challenge we face today in the connected world is the data migration and the ownership.
Connected cars collect and store a vast amount of data. This data goes well beyond a vehicle owner's personal preferences and settings. Connected cars collect driver data such as travel routes, travel destinations, car speeds, driver behavior, commute patterns and much more.
Connected cars are only a fraction of the millions and millions of Internet-connected devices that enable users to set their personal preferences and that collect vast amounts of user data. All of these IoT devices are helping to create a "virtual identity" for each and every user.
While this user-generated data will most likely last forever, connected cars and all the other Internet-connected devices will not. This leads to several important questions concerning connected car owners and their data:
- What happens to connected car owners' data when they want to purchase a new car?
- Can the car owner's data be transferred to another connected car, even if that car is made by a different manufacturer?
- How and where is all of these connected car data being stored?
Identity silos create a lot of friction in the connected business. One way to reduce friction - but still keeping data in silos - and of course the ownership of data - is by exposing Identity data via APIs. That would help end users to build and understand a better picture of their own identity. Now they can relate driving patterns with sleeping patterns. The daily food consumption patterns with sleeping patterns and many more. The BMW Connected Drive, which connects to your Fitbit, now knows if you haven’t slept well last night - and possibly, present you the options that helps you for a safe drive.
Propagating end user identity across these APIs is the next challenge. Building a protocol agnostic security model is the key for connected identity. If we build BMW Connected Drive to be compliant with the security model of Fitbit, then, when it talks to Yelp to find the best nearby restaurant, that’s mostly rated by your friends in Facebook, BMW Connected Drive should then also be compatible with the security model of Facebook and Yelp. In other words, we are just starting to build a point to point security model, that would lead to the spaghetti identity - antipattern.
Identity silos and spaghetti identity anti-patterns are not only present in the IoT world.
If you look at the history, most enterprises grow today via acquisitions, mergers and partnerships. In U.S only, mergers and acquisitions volume totaled to $865.1 billion in the first nine months of 2013, according to Dealogic. That’s a 39% increase over the same period a year ago — and the highest nine-months total since 2008.
A research done by the analyst firm Quocirca confirms that many businesses now have more external users than internal ones: in Europe 58 percent transact directly with users from other businesses and/or consumers; for the UK alone the figure is 65 percent. Another analyst firm predicts by 2020, 60% of all digital identities interacting with enterprises will come from external IdPs.
Each external Identity Provider can be treated as an Identity silo. The way identity data are shared, is through APIs. The Identity consumer, or the service provider, must trust the identity provider to accept a given user identity. Beyond the trust, both the service provider - and the identity provider must speak the same language to bootstrap the trust relationship, and then transport identity data. How about a service provider, which is incompatible with the Identity token sharing protocol supported by the Identity provider? Either you need to fix the Identity provider end to speak the same language of the service provider, or the otherway around.
Under today’s context connected business is a very dynamic and complex environment. Your desire is to reach out to your customers, partners, distributors and suppliers and create more and more business interactions and activities, that will generate more revenue. The goal here is not just integrate technological silos, in your enterprise – but also make your business more accessible and reactive.
Having friction to build connections between your business entities - is something that cannot be tolerated. The cost of provisioning a service provider or an identity provider into the system could be high, due to the protocol incompatibilities. Also, building point-to-point trust relationships between service providers and identity providers - does not scale well.
With the Identity Bus or the Identity Broker pattern, a given service provider is not coupled to a given identity provider - and also not coupled to a given federation protocol. The broker maintains the trust relationships between each entity and also mediates identity tokens between multiple heterogeneous security protocols. It can further centrally enforce access controlling, auditing and monitoring.
With ever evolving standards for identity federation - and having no proper standard to manage and propagate device identities, Identity Broker will play a key role in building a common, connected identity platform in a protocol agnostic manner.
Following highlights some of the benefits of the Identity Broker pattern.
- Introducing a new service provider is frictionless. You only need to register the service provider at the identity bus and from the there pick which identity providers it trusts. No need to add the service provider configuration to each and every identity provider.
- Removing an existing service provider is frictionless. You only need to remove the service provider from the identity bus. No need to remove the service provider from each and every identity provider. Introducing a new identity provider is frictionless. You only need to register the identity provider at the identity bus. It will be available for any service provider.
- Removing an existing identity provider is extremely easy. You only need to remove the identity provider from the identity bus.
- Enforcing new authentication protocols is frictionless. Say you need to authenticate users with both the username/password and duo-security (SMS based authentication) - you only need to add that capability to the identity bus and from there you pick the required set of authentication protocols against a given service provider at the time of service provider registration. Each service provider can pick how it wants to authenticate users at the identity bus.
- Claim transformations. Your service provider may read user's email address from the http://sp1.org/claims/email attribute id - but the identity provider of the user may send it as http://idp1.org/claims/emai. Identity bus can transform the claims it receives from the identity provider to the format expected by the service provider.
- Role mapping. Your service provider needs to authorize users once they are logged in. What the user can do at the identity provider is different from what the same user can do at the service provider. User's roles from the identity provider define what he can do at the identity provider. Service provider's roles define the things a user can do at the service provider. Identity bus is capable of mapping identity provider's roles to the service provider's roles. For example a user may bring idp-admin role from his identity provider - in a SAML response - then the identity bus will find the mapped service provider role corresponding to this, say sp-admin, and will add that into the SAML response returning back to the service provider from the identity bus.
- Just-in-time provisioning. Since identity bus is at the middle of all identity transactions - it can provision all external user identities to an internal user store. Centralized monitoring and auditing.
- Centralized access control.
- Introducing a new federation protocol needs minimal changes. If you have a service provider or an identity provider, which supports a proprietary federation protocol, then you only need to add that capability to the identity bus. No need to implement it at each and every identity provider or service provider.
1. The Internet of Things (The MIT Press Essential Knowledge series), http://www.amazon.com/Internet-Things-Press-Essential-Knowledge/dp/0262527731
2. Future Crimes: Everything Is Connected, Everyone Is Vulnerable and What We Can Do About It, http://www.amazon.com/Future-Crimes-Everything-Connected-Vulnerable/dp/0385539002
3. http://www.programmableweb.com/news/identity-and-access-management-iam-will-greatly-impact-future-connected-car-sales/analysis/2014/08/20
Subscribe to:
Posts (Atom)