Monday, January 12, 2009
Did you know that many federated identity deployments are insecure?
Jackson Shaw, Mark Diodati Ian Glazer, Jeff Bohren and others talked about and acknowledged how the Liberty Alliance along with Sun and Oracle has made mistakes in idM provisioning. Today, we will talk about the insecurity that exists within federated identity...
I apologize in advance to Pat Patterson, Nishant Kaushik, Gerry Gebel, Johannes Ernst, Bob Blakely, Kim Cameron, Mike Jones, Ashish Jain, Patrick Harding and others for bringing up the issues I will discuss. Hopefully, they will appreciate the notion that from incite comes insight.
First, let's dig into OpenID. An OpenID XRI can look like anything, including a SQL injection attack. Shouldn't this mean that folks over in this community should noodle at least some type of regular expression of permissible identifiers vs leaving it as yet another weakness?
Second, many of the federation products when serving in the role of relying party can potentially create several new exposures. Many of the products will perform a lookup of the subject within a SAML assertion against an LDAP store. Imagine in a world of SaaS should salesforce.com choose to use one of the off the shelf products, would this be sufficient? Of course not as there is a gap in logic.
So, if salesforce.com is a SP and supports multiple customers of which Credit Suisse is one and the other is say Goldman Sachs. Salesforce.com would have a trust relationship with both of them but what would prevent a rogue Goldman Sachs employee from putting into their directory the subject (say email address) of a Credit Suisse employee and allowing it to be passed along? More importantly, the SP should do more than trust as we all believe in the security principle of trust but verify and therefore would need to have entitlements capability built into the proxy in order to defend against this type of attack.
Have you ever looked at how this would be discovered after the fact from a forensic perspective? Hopefully, they are logging all federation activities to a separate tier and leveraging products such as loglogic, splunk, logarithm, etc but are the log records created detailed enough to catch this type of scenario? Nope.
Cardspace is fascinating and a solution to many problems but there are some risks that I don't know the answer to. Many enterprises have embraced the notion of an XML firewall be it layer 7, vordel, datapower, etc as the importance of handling secure parsing is something many have gotten burnt by. Now, Cardspace as an approach says lets ignore some of the best practice of XML firewalls and instead put a generic .NET parser on the front lines of our security model. Can Microsoft say that its parsing approach is as secure as Vordel? Would Mark ONeill of Vordel agree?
One way to make Cardspace more secure would be to at least guarantee it isn't subject to the OWASP Top Ten. Imagine being able to perform injection attacks on self-issued cards? Should Microsoft at least consider embedding the OWASP Enterprise Security API as a way to make it better?
Going back to the federation scenario for a moment, we would also need to consider the fact that federation products tend to be separate and distinct from web access management products. So, in this scenario the application wouldn't even have an opportunity to protect itself as the federation product would simply create a cookie and not pass context as to how this user was authenticated.
More interesting is the fact that even if the federation products wanted to pass it along to applications, there is no standard way of doing this. So, how would Ping Identity pass along the fact to Netegrity Siteminder that I signed on via federation? Does this mean that standards need to exist in the web access management space? Should Oblix, OpenSSO and others address this?
| | View blog reactionsI apologize in advance to Pat Patterson, Nishant Kaushik, Gerry Gebel, Johannes Ernst, Bob Blakely, Kim Cameron, Mike Jones, Ashish Jain, Patrick Harding and others for bringing up the issues I will discuss. Hopefully, they will appreciate the notion that from incite comes insight.
First, let's dig into OpenID. An OpenID XRI can look like anything, including a SQL injection attack. Shouldn't this mean that folks over in this community should noodle at least some type of regular expression of permissible identifiers vs leaving it as yet another weakness?
Second, many of the federation products when serving in the role of relying party can potentially create several new exposures. Many of the products will perform a lookup of the subject within a SAML assertion against an LDAP store. Imagine in a world of SaaS should salesforce.com choose to use one of the off the shelf products, would this be sufficient? Of course not as there is a gap in logic.
So, if salesforce.com is a SP and supports multiple customers of which Credit Suisse is one and the other is say Goldman Sachs. Salesforce.com would have a trust relationship with both of them but what would prevent a rogue Goldman Sachs employee from putting into their directory the subject (say email address) of a Credit Suisse employee and allowing it to be passed along? More importantly, the SP should do more than trust as we all believe in the security principle of trust but verify and therefore would need to have entitlements capability built into the proxy in order to defend against this type of attack.
Have you ever looked at how this would be discovered after the fact from a forensic perspective? Hopefully, they are logging all federation activities to a separate tier and leveraging products such as loglogic, splunk, logarithm, etc but are the log records created detailed enough to catch this type of scenario? Nope.
Cardspace is fascinating and a solution to many problems but there are some risks that I don't know the answer to. Many enterprises have embraced the notion of an XML firewall be it layer 7, vordel, datapower, etc as the importance of handling secure parsing is something many have gotten burnt by. Now, Cardspace as an approach says lets ignore some of the best practice of XML firewalls and instead put a generic .NET parser on the front lines of our security model. Can Microsoft say that its parsing approach is as secure as Vordel? Would Mark ONeill of Vordel agree?
One way to make Cardspace more secure would be to at least guarantee it isn't subject to the OWASP Top Ten. Imagine being able to perform injection attacks on self-issued cards? Should Microsoft at least consider embedding the OWASP Enterprise Security API as a way to make it better?
Going back to the federation scenario for a moment, we would also need to consider the fact that federation products tend to be separate and distinct from web access management products. So, in this scenario the application wouldn't even have an opportunity to protect itself as the federation product would simply create a cookie and not pass context as to how this user was authenticated.
More interesting is the fact that even if the federation products wanted to pass it along to applications, there is no standard way of doing this. So, how would Ping Identity pass along the fact to Netegrity Siteminder that I signed on via federation? Does this mean that standards need to exist in the web access management space? Should Oblix, OpenSSO and others address this?
