Federating identities across information and security domains is not just a technical problem, and anyone who tells/sells you that it is, is not operating in a frame of reality that is conducive to success!

Please note that, for me, an implementation of an Identity Federation architecture takes into account both Authentication and Authorization as well as a host of other areas.  As such I've always found it amusing to be informed (usually by a vendor) that this is a straight forward problem and that once I deploy [Insert technology / tool / product / magic pixie dust of choice here], we will have you "federating in no time". Ha!

We have been wrestling with this and at one of our working meetings recently, one of my team-mates came up with the following representation to describe the challenges of reaching agreement on what information needs to flow across federation boundaries, and what needs to be in place to accomplish it. Based on the same principle as the Boy Scout's triangle (heat, oxygen, fuel), you take away one side, and the entire Attribute Triangle (or as we call it, "Tom's Triangle", in honor of our team-mate who came up with it) collapses.

When you look at it, it seems so obvious and simplistic, but we have found value in thinking thinking about it in this manner.  Organizational Policy determines the rules of the road. Those rules in turn are reflected in the choices of attributes and the agreements around their semantics. At the same time, you need to be assured that the agreed upon attributes are not things that you come up out of the blue but are instead drawn from trusted and authoritative sources in the Enterprise.

GSA's USA Services/Intergovernmental Solutions sponsors monthly workshops around topics such as emergency preparedness, environmental monitoring, healthcare and law enforcement.

The upcoming "Exploring Identity Management: Global Landscape and Implications for Stakeholder Engagement Around the National Response Framework" session is focused on the implications of the "National Response Framework [PDF]" to Identity Management.

National Response Framework (NRF) is a guide to how the Nation conducts all-hazards response.  It is built upon scalable, flexible, and adaptable coordinating structures to align key roles and responsibilities across the Nation, linking all levels of government, nongovernmental organizations, and the private sector.  It is intended to capture specific authorities and best practices for managing incidents that range from the serious but purely local, to large-scale terrorist attacks or catastrophic natural disasters.

I had the opportunity to speak with both Susan Turnbull at the GSA as well as Dr. Duane Caneva, Director of Medical Preparedness at the White House Homeland Security Council, who are putting this event together, and came away impressed with their obvious passion in addressing this critical issue.

Basically, this is all about the technical, social and organizational infrastructure that needs to be in place to respond to a Katrina-like or Tsunami-like event.  Identity Management is seen as an enabler in bringing the right people, the right resources and the right information together to help make a difference in responding to a crisis of this magnitude.

I also came away with an action item to discuss with this community how some of the work that I am currently involved with could help out in this particular domain.  The agenda looks pretty interesting and builds upon past events such as the IDTrust 2008 etc. Looking forward to this!

Just picked up the current issue of IEEE Security & Privacy Magazine and it is full of Identity Management Goodness!

• I'm Pc01002/SpringPeeper/ED288l.6; Who are You? by Susan Landau and Deirdre K. Mulligan
• The Venn of Identity: Options and Issues in Federated Identity Management (Abstract) by Eve Maler and Drummond Reed
• The Seven Flaws of Identity Management: Usability and Security Challenges (Abstract) by Rachna Dhamija and Lisa Dusseault
• Biometrics in Identity Management Systems (Abstract) by James L. Wayman
• Privacy and Identity Management (Abstract) by Marit Hansen, Ari Schwartz and Alissa Cooper
• Identity Management, Privacy, and Price Discrimination (Abstract) by Alessandro Acquisti
• Use Cases for Identity Management in E-Government (Abstract) by Robin McKenzie, Malcolm Crompton and Colin Wallis
• Dynamic Security Assertion Markup Language: Simplifying Single Sign-On by Patrick Harding, Leif Johansson, and Nate Klingenstein

Looking forward to this read!

Some time ago, I was having a conversation with some folks about the usage of SAML Authentication Assertions for Web Browser Single Sign-On (SSO) versus Digital Certificates.  The folks that I was having this conversation with support one of the larger PKI deployments in the US, and their response to my comment about the lack of support for SAML for Web Browser SSO in that particular vertical was the following question:

"Provided the experience to the user is the same, why does it matter?"

I didn't have a very good answer at that point in time but it is something that I've been mulling over since that time. The issue has come up again in separate conversations, including this one by Patrick Harding of Ping Identity and this posting by James McGovern.  This blog posting is an attempt to articulate some of the points on both sides of this debate.

SAML 2.0 and Web Browser SSO

The Web Browser SSO Profile in SAML 2.0 supports both an Identity Provider (IdP) initiated and Service Provider (SP) initiated SSO message flows. As described in the SAML documentation ".. the most common scenario for starting a web SSO exchange is the SP-initiated web SSO model which begins with the user choosing a browser bookmark or clicking a link that takes them directly to an SP application resource they need to access. However, since the user is not logged in at the SP, before it allows access to the resource, the SP sends the user to an IdP to authenticate. The IdP builds an assertion representing the user's authentication at the IdP and then sends the user back to the SP with the assertion.  The SP processes the assertion and determines whether to grant the user access to the resource.

In an IdP-initiated scenario, the user is visiting an IdP where they are already authenticated and they click on a link to a partner SP. The IdP builds an assertion representing the user's authentication state at the IdP and sends the user's browser over to the SP's assertion consumer service, which processes the assertion and creates a local security context for the user at the SP."

Some points to keep in mind regarding these two flows:

• The user's credentials are maintained at their IdP, which means that the SP must trust the IdP to assert information about its users. The establishment of this "organizational trust" is typically done out of band.
• The IdP can support multiple authentication mechanisms of varying strengths including user-id/password, software certificates and smart-cards based on a PKI, biometrics etc.
• The type and the strength of the authentication used by the user can be conveyed in a SAML authentication context which can be used in (or referred to from) a SAML Authentication Assertion. In fact an SP can include an authentication context in a request to an IdP to request that the user be authenticated using a specific set of authentication requirements, such as a multi-factor authentication.
• Do not conflate authentication with authorization! Although the user has been authenticated, the SP more than likely needs a LOT more information about the user (than what was provided in the Authentication Assertion) in order to make an access control decision.  This typically requires the usage of SAML attribute statements and/or SAML authorization decision statements. And in any reasonably complex environment that wants to remain standards based, this more than likely involves the usage of XACML for defining access control criteria.
• SAML supports mechanisms to support the integrity and confidentiality of the assertions themselves including SSL mutual authentication, XML Signature etc. and does so across both the HTTP and SOAP bindings.

PKI and Web Browser SSO

This is pretty straight forward from the usage perspective. It begins with a user choosing a bookmark or clicking a link that takes them directly to a Relying Party (RP) i.e. application resource they need to access.  The user is prompted to present a digital certificate as the authentication mechanism.  The user's certificate, whether it is in the form of a soft certificate or coming from a smart card, is used to authenticate the user.

Some points to keep in mind:

• In a PKI environment, when a Certification Authority issues a certificate, it is making a statement to a RP that a particular public key is bound to a specific entity (i.e. the subject of the certificate).
• The degree to which a RP trusts a CA is based on the RP's understanding of the CA's user identification and credential issuance practices, operating policies, security controls etc.
• Depending on the identity issuance requirements of a CA, the digital certificate is usually consider a higher assurance authentication mechanism than something like a user-id and password.
• Each RP has to put into place the technical infrastructure needed to make it PKI-aware i.e. the ability to use digital certificates as authentication mechanism.
• Each RP has to put into place the mechanisms for both validation and revocation operations. This is especially challenging when you have CA's that are cross-certified and CA's and clients need to support certificate path processing.
• The user experience, in browsing from one PKI protected resource to another may not be seamless.
• The authorization aspect is indeed separate from the authentication.  Information needed to make an access control decision may not be present in the information provided by a digital certificate.

What strikes me when I look at these two options is that the question posed at the start of this entry may not be the right one to ask. The question one should be asking instead is "Who do you trust?"

The fundamental precept of a PKI environment is that everyone must buy into trusting the CA. I would bet that that a lot of the "entrenched PKI communities" have expended significant amount of resources in standing up not just the technical infrastructure but the credential proofing and issuance processes for their domain. As such, they implicitly trust a certificate vouched for by the CA. The downside to this is that every single RP must be PKI-enabled, which is non-trivial.

SAML is not a trust mechanism but more of a mechanism for a particular domain to make assertions about its users. As such, what is needed in the federated world for this to work is for a relying domain to trust the asserting domain. The relying domain would have to have confidence in the credential proofing and issuance process of the asserting domain. The advantages here would be that SAML-enabling an SP is a more straight forward process and there is significant out-of-the-box support for SAML in vendor tooling.

In each case, I consider authorization to be separate and distinct from the authentication.

But that organizational trust... Ah!  Is it not remarkable that the truly hard problems, whether one is discussing Identity Management or Service Orientation, really do not have to do with technology but with people, culture and behavior?

Series of posts on threat modeling. Good stuff!
[Found via Bruce Schneier]

• The Trouble with Threat Modeling
• The New Threat Modeling Process
• Getting into the Flow With Threat Modeling
• Making Threat Modeling Work Better
• Threat Modeling Self Checks and Rules of Thumb
• The STRIDE per Element Chart
• Wrapping up Threat Modeling

Also check out JD's post on Getting Started with Threat Modeling and the Threat Modeling Blog maintained by the Microsoft Application Consulting and Engineering Team.

Congratulations to the Shibboleth Team on the release of Shibboleth 2.0.  This version provides support for SAML 2.0 as well as integration with most major identity stores, including Microsoft Active Directory, Kerberos, LDAP-compliant directory services, and JDBC-compliant databases.

For those not familiar with this fine piece of open source software, Shibboleth is a "... standards-based, open source middleware software which provides Web Single Sign-On (SSO) across or within organizational boundaries. It allows sites to make informed authorization decisions for individual access of protected online resources in a privacy-preserving manner."

One of the things I have been doing a bit of work on has been Attribute Authorities in the SAML 2.0 sense i.e. a SAML entity that produces assertions in response to identity attribute queries from an entity acting as an attribute requester.  In particular, my interest lies in controlling the release of attributes based on policies that could be externalized.

My interest in finding a hopefully standardized way of doing this was sparked by the article "Using XACML for Privacy Control in SAML-Based Identity Federations" by Wolfgang Hommel, which I found on the XACML section of the OASIS Cover Pages. The article describes the use of XACML to control the release of attributes and an implementation of this using an earlier release of Shibboleth.

At the IDTrust 2008 Symposium, one of the sessions that I enjoyed was the panel session on "Federations Today and Tomorrow" hosted by Ken Klingenstein of Internet2 and Patrick Harding of Ping Identity.  When Ken spoke a bit about the release of Shibboleth 2.0, which supports SAML 2.0, this brought me back full circle.

In an earlier conversation I had had on this topic with some colleagues who are working with release candidate versions of Shibboleth 2.0, I was curious to find out if the "Attribute Filter" capability in Shibboleth had made it into the SAML 2.0 standard given that Shibboleth 2.0 is the convergence of Shibboleth, SAML 1.X and the Liberty IDFF. Unfortunately, I was informed that it had not. The implementation is specific to the Shibboleth functionality and does not seem to exist as part of the SAML 2.0 specification.

So what I asked the panel was that given that both SAML 2.0 and XACML 2.0 are based out of OASIS, is there any work in integrating the two standards to enable this type of functionality, as there is definitely a use case for this in a lot of the communities that I am familiar with. The answer I got back was that, while this is not outside the realm of possibility, it is not something that someone is working on. In a hallway conversation I had with some other folks after the session, someone mentioned that this type of functionality may be built into one of the Oracle products, but again the implementation was proprietary to that vendor.

I'm going to be attending "IDtrust 2008 - 7th Symposium on Identity and Trust on the Internet" this week.

Especially looking forward to some of the discussions around Federated Identity, Access Control etc.

I recently got an e-mail asking about a blog entry I had made back in 2005 regarding Identity Federation, SAML and WS-Federation, and if I had attained any measure of clarity regarding their usage since that time. Since this is something I have been spending a bit of time on recently, it seemed like the perfect opportunity to talk about this.

When I wrote the original blog post, I phrased it as a competitive situation. I have since moved on from that position and consider them to be be complementary approaches, each with strengths in certain areas. An Enterprise that is looking at an IdM implementation should be seeking to leverage the strengths that each camp brings to the table.

As of November, 2007, SAML 2.0 is an OASIS standard and can be considered a combination of the features of SAML 1.X, Liberty Alliance Identity Federation Framework and Shibboleth.

The other camp one should be looking at in the area of Identity Federation is the OASIS Web Services Secure Exchange (WS-SX) family of standards which include WS-Trust, WS-SecureConversation and WS-SecurityPolicy.

The area of contention between the two camps all too often arises when it comes to the domain of browser-based Single Sign-On. This has historically been the playground of SAML but now the new kid on the block is WS-Federation which describes how to use WS-Trust for browser-based Single Sign On scenarios. WS-Federation is currently going through the standardization process at OASIS.

My perspective on both starts with the basic fact that SAML assertions are universal and can be used independently of the SAML protocol. I also very much like the capability that is provided by the WS-Trust based Security Token Service (STS) which provides the ability to translate token formats.

SAML has great deal of traction in the browser based federation arena while WS-SX targets securing web services. Given that SAML assertions are supported by a wide variety of IdM and SOA infrastructure products such as WAM products, WSM products, XML Security Gateways and more, my approach to dealing with interoperability concerns in this area (until the vendor camps work this out) will be to use products and technologies that bridge the gap by supporting both camps.

Note to self for for use as a reference...

SAML assertions have no dependencies on and can be used independently of the SAML Protocol. SAML 2.0 defines three types of assertion statements:

1. Authentication:- The assertion subject was authenticated by a particular means at a particular time.
2. Authorization Decision:- A request to allow the assertion subject to access the specified resource has been granted or denied.
3. Attribute:- The assertion subject is associated with the supplied attributes.

<Issuer> (Required):- The SAML authority that is making the claim(s) in the assertion.

<Signature> (Optional):- An XML Signature that protects the integrity of and authenticates the issuer of the assertion.

<Subject> (Optional):- The subject of the statement(s) in the assertion.

<Conditions> (Optional):- Conditions that MUST be evaluated when assessing the validity of and/or when using the assertion.

<Advice> (Optional):- Additional information related to the assertion that assists processing in certain situations but which MAY be ignored by applications that do not understand the advice or do not wish to make use of it.

Zero or more of the following statement elements:

• <Statement>
• <AuthnStatement>:- An authentication statement.
• <AuthzDecisionStatement>:- An authorization decision statement.
• <AttributeStatement>:- An attribute statement.

An assertion with no statements MUST contain a <Subject> element. Such an assertion identifies a principal in a manner which can be referenced or confirmed using SAML methods, but asserts no further information associated with that principal.

Otherwise <Subject>, if present, identifies the subject of all of the statements in the assertion. If <Subject> is omitted, then the statements in the assertion apply to a subject or subjects  identified in an application- or profile-specific manner. SAML itself defines no such statements, and an assertion without a subject has no defined meaning in this specification.

<Version> (Required):- Version of the assertion. "2.0" for SAML 2.0.

<ID> (Required):- The identifier for this assertion.

<IssueInstant> (Required):- The time instant in UTC.

SAML 2.0 Core Spec [PDF], OASIS Security Services (SAML) TC

Cisco announced today that it is planning on acquiring Securent,  which is considered a leading vendor in the area of Entitlement/Fine Grained Authorization with deep support for XACML.

My initial thought after hearing about that this was that this would be a rather interesting and complementary match to their earlier acquisition of Reactivity, the XML Security Gateway vendor.  Would it not be sweet if the the Reactivity (now the ACE XML) Security Gateway could act as a Policy Enforcement Point that for the Securent supplied Policy Decision Point and even more could now natively understand XACML?

Then I read this blog entry by Phil Schacter of the Burton Group and learned that the acquisition is actually driven by Cisco's Collaboration Software Group, which is looking to "... enhance its ability to provide some shared access control infrastructure for its growing portfolio of collaboration and unified communication offerings..". As noted in Phil's blog entry this acquisition is NOT driven by Cisco's Security  Technology Group which I presume has ownership of the NAC, VPN, network authentication product lines (which I assume is where the ACE XML Gateway product line lives). As he notes, it will be hard for Cisco to not focus exclusively on the business priorities of the Collaboration Software Group.

I personally would consider that to be a bad thing from the perspective of both the current Securent customers as well as folks from Enterprise's that are interested in Entitlement Management/Fine Grained Authorization.  Will be watching to see how this plays out.

Came across this on the Privacy Commissioner of Canada's blog:

It is a speech by Professor Valerie Steeves of the University of Ottawa's Department of Criminology on how "... children interact with popular sites like Webkinz, Neopets and Barbie Girls".

Scary!

Highlights from the presentation can be found here. If you have young children, would definitely recommend checking it out.

There is new blog posting by James McGovern, "How Industry Analysts weaken Enterprise Security", that seems to take industry analysts to task for not asking enterprise application vendors if they "...implement this security specification or any security specification..." in their product. The example specification that is used is XACML.

It is an interesting question but seems to be designed more to get a rise out of people rather than addressing the ground truth, which is that the responsibility lies not with the Analysts but with the Architects and Engineers who are evaluating potential products for their Enterprise. 

So, to my mind, the more appropriate questions would be:

1. Are the customers of the various analyst firms are being provided the appropriate and independent information such that they can ask the right questions of the vendors? Which is the role of the Analysts.
2. Are the Enterprise's actually holding the vendors accountable by NOT spending money with vendors that do not implement open standards? Which is the role of the Business and the Enterprise Architect.

Interesting report [1] published by the Information Assurance Technology Analysis Center (IATAC) and the Data and Analysis Center for Software (DACS) on the current state of Software Security Assurance.

"The [report] provides an overview of the current state of the environment in which software must operate and surveys current and emerging activities and organizations involved in promoting various aspects of software security assurance.  The report also describes the variety of techniques and technologies in use in government, industry, and academia for specifying, acquiring, producing, assessing, and deploying software that can, with a justifiable degree of confidence, be said to be secure.  The report also presents observations about noteworthy trends in software security assurance as a discipline."

[1] http://iac.dtic.mil/iatac/download/security.pdf

Message replay is a very real attack vector for web services attacks. The description of the defense against it is pretty straight forward. To quote the "Message Replay Detection Pattern":

Message replay detection requires that individual messages can be uniquely identified. [...] Cache an identifier for incoming messages, [...] identify and reject messages that match an entry in the replay detection cache.

You have a couple of choices in how you can leverage the relevant web services standards to implement this.

1. Given that WS-Security XML Signature must include a <ds:SignatureValue> element, you can use that as a unique identifier for the messages. The <ds:SignatureValue> is computed from the hash values of the message parts that are being signed (and you can make sure that the parts include both the message body and the WS-Security timestamp i.e. <wsu:Timestamp>.
2. You can use another unique identifier e.g. the WS-Addressing messageid <wsa:MessageID>, which is a URI value that uniquely identifies the message that carries it.  Combine it with the WS-Security timestamp i.e. <wsu:Timestamp> and you are good to go here as well.

In both cases, what you need in order for this to work is a configurable replay cache. And that is also relatively straight-forward to implement, especially if you are doing this in software.

The proverbial devil and the details come into play when you want to abstract this type of capability into the infrastructure.  I for one am very interested in NOT doing this in software (Perf, consistent implementation across SOAP stacks etc.), so a natural place that I would seek to implement this type of capability would be in my perimeter PEP which typically, at least in my environment, is implemented using a XML Security Gateway. 

When it comes to deployment, you do not want a single point of failure in your infrastructure, so what you typically do for deploying perimeter PEP's (XML Security Gateways) is to deploy a cluster (at least two) with a (clustered) load balancer in front of the Gateways. Now, if you are going completely stateless what typically happens in this configuration is that requests are dynamically spread across your cluster of XML Gateways. And that is where the details come into play. If each Gateway implements its own replay cache, and requests are spread out across multiple Gateways, how can you truly be assured that you can detect a replay attack?

The way that you would handle this, if you were implementing this in software, would be to have a shared replay cache (typically a shared database) across multiple load balanced app servers (Note that there are perf implications with this).  But this really does not work with XML Gateways. These are hardened, FIPS compliant devices that typically cannot be tied into a database back-end. So, what possible solutions could you have for this:

1. Configure the load balancer for Active-Passive rather than an Active-Active configuration. i.e. Instead of distributing traffic across the Gateways equally, send all traffic to one Gateway and only if that one fails should the traffic be sent to another cluster member.
2. Actually modify the Gateway configuration to be able to connect to a database back-end.
3. Others?

At present, I am thinking that option (1) is probably the most realistic one. I am not aware of any XML Security Gateway vendors who have implemented anything like option (2). But I am most certainly curious as to how folks are doing this in their environment, so if you are doing this, I would appreciate any info you can share on your implementation details and what you find to be the trade-offs.

Dominick Baier, now with thinktecture (Congrats Christian!), has a good article in the current issue of MSDN Magazine on the usage of certificates in .NET 2.0. The article covers:

• The Windows Certificate Store
• Certificate classes in .NET
• Validation, SSL, Web services, and code signing
• Signing and encrypting data

It is a good read for those who need to work with certs on the .NET Platform. Check it out!

Right after posting my last blog entry on Threats to Message Exchanges in a SOA, I cam across a blog entry by Gunnar Peterson of Cigital that points to a paper that he co-authored with Howard Lipson at CERT on "Security Concepts, Challenges, and Design Considerations for Web Services Integration" in which they describe "... best practices for development staff who want to actually build security services into the software they are developing. The paper is really two papers in one - the first part is on web services and their impact on security concepts, the second part deals with message level security (WS-Security, WS-Trust, WS-SecureConversation) to enable end to end security model for an integrated system, and the last part is on design considerations for security in Web Services." 

I have not had a chance to peruse this in detail, but this definitely looks like a must read document!

A new bit of security goodness from the MS ACE Security Services Team. From the docs:

"Cross-site scripting (XSS) attacks exploit vulnerabilities in Web-based applications that fail to properly validate and/or encode input that is embedded in response data. Malicious users can then inject client-side script into response data causing the unsuspecting user's browser to execute the script code. The script code will appear to have originated from a trusted-site and may be able to bypass browser protection mechanisms such as security zones.

These attacks are platform and browser independent, and can allow malicious users to perform malicious actions such as gaining unauthorized access to client data like cookies or hijacking sessions entirely.

Simple steps that developers can take to prevent XSS attacks in their ASP.NET applications include (see How To: Prevent Cross-Site Scripting in ASP.NET in the patterns & practices series for more detail):

• Validating and constraining input
• Encoding output

For defense in depth, developers may wish to use the Microsoft Anti-Cross Site Scripting Library to encode output. This library differs from most encoding libraries in that it uses the "principle of inclusions" technique to provide protection against XSS attacks. This approach works by first defining a valid or allowable set of characters, and encodes anything outside this set (invalid characters or potential attacks). The principle of inclusions approach provides a high degree of protection against XSS attacks and is suitable for Web applications with high security requirements."

Check it out @ http://msdn2.microsoft.com/en-us/security/aa973814.aspx

This came across on one of the lists that I am on. One of the best books on Security, “Security Engineering” by Ross Anderson is now available for free on the web!

Here is the chapter index:

1. What is Security Engineering?
2. Protocols
3. Passwords
4. Access Control
5. Cryptography
6. Distributed Systems
7. Multilevel Security
8. Multilateral Security
9. Banking and Bookkeeping
10. Monitoring Systems
11. Nuclear Command and Control
12. Security Printing and Seals
13. Biometrics
14. Physical Tamper Resistance
15. Emission Security
16. Electronic and Information Warfare
17. Telecom System Security
18. Network Attack and Defense
19. Protecting E-Commerce Systems
20. Copyright and Privacy Pro