DIDW Workshop 2007 Notes

From Project Concordia

Jump to: navigation, search

We held a five-hour workshop after the close of Digital Identity World in San Francisco, CA, on 26 September 2007. The attendance is recorded here: DIDW Workshop participation list. The first half was dedicated to hearing additional use-case presentations:

The second half was dedicated to reviewing the use case buckets collected in the August telecon (see Concordia telecon 15 Aug 2007 notes), prioritizing use cases with specific technology pairings/groupings within them based on the "votes" each was getting from deployers, and figuring out next steps (deliverables, schedules, action items).


Contents

Introduction by Roger Sullivan

We're here to listen to interop use cases from enterprise customers and figure out how they might be fulfilled. Michael Barrett's keynote today noted the proliferation of standards and initiatives. Thus there's confusion in the marketplace, inhibiting deployers and developers. People don't know where to place their bet. Concordia's premise is that there are legitimate reasons for deploying multiple technologies, and figuring out how they can interoperate to span the continuum of identity use cases seamlessly.


Use-case presentation by Edmund Yee of Chevron

There are four categories of business entities.

The super-majors (integrated oil companies) have many petabytes of information used for collaboration. Most are large MSFT platforms, with some Linux clusters for seismic interpretation etc. They make heavy technology sector investments for oil research. The national oil companies often have a government ownership component and have the largest oil reserves. They partner for technology. The oil field services companies like Schlumberger and Halliburton also provide custom applications for the oil sector. They host information portals for the data collected, such as daily drilling status. Joint operations/ventures help to spread the risk, such as around refinery operations. Focusing here on the joint scenarios. The business partnerships span all the functions, including supply chain.

Their goal is better collaboration. Speeding time to production is key. If it takes 1-3 months to provision IT systems for collaboration, it's a waste. They want real-time provisioning for identities and access. They want to collaborate on both structured and unstructured information. Seismic interpretation and 3D modeling are examples. Containing cost is always important. They need to do more with less or the same resources. They need to contain development costs. They need to improve compliance. There are antitrust issues in their sector and they need to do internal auditing for regulatory and competitive compliance. Finally, they want to reduce risk and do security lifecycle management.

Problem statement: joint venture. There are many types: refinery, exploration, and HQ backhaul -- this is the biggest concern. The primary operator's environment usually determines the choices, and ownership percentages differ per venture, and employees often need to get into their own company's system for some joint venture purposes. There are political (government and partner) concerns around sharing data. Internal applications generally don't support multi-domain scenarios. International ventures often have concerns around connectivity: offline usage, low bandwidth, and Internet usability.

Desired state: Chevron's CIO says: Third parties should be granted access to the appropriate resources quickly and easily. The chosen solution should provide authentication and authorization services in a more automated and secure fashion. Access rights should be easily revocable if an individual's roles change. Key desired features -- presented in a matrix. The energy companies have funded a non-profit identity trust (Energistics) that's developing a requirements framework.

  • Real-time provisioning of identities
  • Provisioning of access
  • Common identity repository
  • Identity service
  • Resource publication and subscription service
  • Extensible authentication model and common identity data service
  • De-perimeterization

Want to eliminate username/password and move to higher assurance levels without reducing costs (e.g. issuing smartcards to everyone).

Q: Is there a conflict between wanting a single identity repository and doing real-time provisioning? A virtual directory approach might allow both.

Q: What about standards efforts? The standards component is not yet determined. We're looking at SAML, WS-Federation, SPML, XACML, and so on. None are ready to say. We need interop between all of these: SAML/WS-Fed, XACML/WS-Policy, etc. The message is that interop is a huge concern. We can't guarantee that everyone will choose the same one.

Energistics could look like a federation-operating hub, but they haven't decided yet. They've looked at Covisint. They'll do a pilot by late 2008 go into production by 2009. The trust could actually provide the identities; they're leaning towards that. An identity inside Chevron would also get mapped/provisioned into the trust.

Advantages of a community federation model: scalability, cost effectiveness, efficiency, leveraging expertise.


Use-case presentation by Bill Young of New Zealand State Services Commission

Program architect of the all-of-government authentication program. It has been around for 6-7 years. It develops authentication standards (such as password quality and lots of other things). They also build and operated shared authentication services. Finally, they develop next-generation services.

They do this to enable transformation of the government to better serve the public. It helps agencies innovate in service delivery. Security, terrorism, etc. are not part of the goal; it's about improving the relationship with the public.

Basic use case: deliver high-quality identity information on request. Government is authoritative for this information, and other parts of government need to know it. People don't want to have to repeat themselves in supplying information! There are also strong privacy laws, so users need to tell one agency that they should go get information from another one.

The early view was that it would be simple: users at browsers, SAML IdP, agencies. :-) Today, the government logon service does use SAML (V1.1), with persistent pseudonyms, and agencies do their own identity proofing. Implementing new kinds of authentication is efficient because they can do it only at the government logon service. It's been in production 1.5 years. A big pipeline of agency RPs coming online. In 6 months, they'll move to SAML2.

After that (in 12 months), they'll deploy an identity verification service that leverages the high-quality identity proofing process the citizens have already gone through (and paid for!) to get their passports. It will be part of the shared authentication services (which already includes the logon service). You need to, say, walk up to a counter and show your passport to forge the GLS/IVS link. They've already done a POC.

They can assert identity attributes for name, DOB, place of birth, and just a few others. This may kill pseudonymy where they need to know a name, but they have to be authorized to have this info in the first place. The privacy laws govern how the RPs persist the information -- they can generally keep it as long as they provide service to you. The same laws apply if you show up in person and show your passport to get service.

Future services in the shared authentication services might serve up additional attributes, such as whether you're a company director or doctor. These might be sourced from many different agencies, but the SAS hide this. This will be hooked up to the agencies by ID-WSF as well as by users at browsers, and thus would offer a discovery service, maybe an interaction service, etc.

Issues: Users will interact by means of more than just browsers. Identity selectors are probably in their future. And they use mobile devices now. Agencies (300 of them, and eventually the private sector) might use any platform, any OS, any IAM solution, and any protocol stack. Final thoughts: interop vs. convergence. Interop solves a big business problem, but the long-term answer is convergence. Especially in a federated environment, you have to extend your reach across federation boundaries.

Use-case presentation by Scott Cantor of InCommon Federation

It's the premier higher-education federation in the U.S. right now. It represents 60+ organizations (many of them top-tier research institutions) and over 1.3M SAML-enabled identities. They focus on SAML because it was the first candidate that solved their needs.

Other countries tend to have different scope, such as dealing with preschool-age kids on up. Most are IdP-centric. InCommon is the most minimalistic of infrastructures, placing few requirements on members (such as undergoing audits). It operates at serious scale -- hundreds or even thousands of IdPs. It doesn't lend itself to the "circle of trust" model; it's more like a trust network. Adding too much process for members would kill the federation.

InCommon vets a trusted (human) contact that will provide authoritative metadata, provide signing keys, etc. InCommon then signs and distributes the results. They also foster a community of practice, including privacy, user consent, transparency, and open standards. Incommon also leverages Internet2/MACE, such as using the eduPerson LDAP schema and adapting it to the SAML world.

If the federation provides PII, the participation agreement dictates baseline behavior (minimal disclosure, rules around retention, etc.). Each member's operating statement is supposed to document what they do. It's descriptive, not prescriptive. Machine-readable privacy enforcement doesn't have the whole answer yet.

They do batch processing of distribution of metadata, and at run time it gets re-verified and adopted. A new member is visible within a day (for those who update their metadata regularly!).

Near-term challenges: scaling metadata and trust management. commercial certificates are inadequate, and he's dubious about EV certificates becase of cost models and history of the organizations. Various techniques around DNS self-assertion will probably help, but not completely. Dynamic exchange of metadata is a promising avenue. We're at the "/etc/hosts" phase of federation. :-)

As deployers, they're interested in getting better support of metadata in products. (Comment: The E-Authentication Gateway has that problem too.) Better SAML support and conformance testing would help.

Another near-term challenge: IdP discovery (the "Where are you from?" or WAYF problem). His customers tell him that not a single one is willing to deploy client-side software of any type at all. For this reason, he's skeptical about CardSpace for now. This will be a very, very, very slow change, and client software is a deal- breaker today. They also don't want to encourage people to start typing their username and password into any random login box.

When does discovery become protocol translation and ultimate a privacy-compromising intermediary? If a user at Ohio State wants to access an outsourced benefits provider, no intermediary in between has a right to see the transaction.

The type-your-username-here approach has the problem that it gives RPs your username! You need infrastructure to obfuscate it. Also, it doesn't solve the problems their user community (developers) really has. They want zero clicks to login, which is very hard to achieve. He believes IdP discovery is insoluble in the absence of smart clients on every desktop.

Mike Beach: They can't dictate what's on all the desktops. Mike Jones: We're working on it! Scott: But you're working on it in the context of other protocols.

Other near-term challenges; protocol co-existence and migration. About 100 SAML V1.1 entities need to be gradually migrated to SAML2. There's occasional interest in adding WS-Federation, but translating between it and SAML V1.1 is straightforward. SAML2 is a large superset, so that would be difficult to translate.

Gateways and proxies will take up some slack, but we have to solve the end-to-end problem.

Finally, there's a near-term challenge getting people to roll out opaque identifiers, which introduces state and having to write back data to the IdP's directory. The added value would be personalization. There's interest in moving beyond transient attribute-based authorization but there's cost too.

Longer-term challenges: higher levels of assurance, inter-federation, federating non-web-based applications, gride and n-tier computing models, and federation of multiple sources of authority.

He's been following the KAML discussions. It will probably be more of a Kerberos solution than a federation solution, and there will be resistance by the ASN.1 people to adding XML. The SASL discussion should be re-raised; a small profile could easily SAML-enable LDAP and lots of other things. It would take 1.5 days, which he doesn't have!

What are the top things Concordia could do? If it includes interop of existing protocols, then pushing the metadata support agenda is really important. Fixing the IdP discovery thing (that impossible thing...) would be great. Note that the SAML IdP discovery mechanism is essentially protocol-neutral. Having an organization that's independent of a particular protocol explain the limited viable choices with discovery would be helpful.


Technical deep-dive conducted by Eve Maler

The goal is to distill requirements around multi-technology interoperability by first identifying the low-hanging fruit. Eve presented her takeaways from today's use-case presentations in terms of prioritizing our choices of work items:

  • Chevron
    • Increasing levels of assurance
    • Faster, more efficient federation rollouts
  • New Zealand
    • Integrating identity selectors with SAML
    • Multiple federation/identity services stacks
    • Interop vs. convergence
  • InCommon
    • Metadata support (and additional features?)
    • IdP discovery (education? leverage SAML profile?)
    • WS-Fed to SAML2?
    • SASL-SAML


Use case buckets and discussion

She presented the use case buckets we had developed earlier, along with specific selections of technologies within those buckets based on (a) indications of which deployers (NZ=New Zealand, Chev=Chevron, IC=InCommon) seem to want more progress in which areas (we also discussed the input from AOL, the BC government, Boeing, and General Motors that was collected in June) and (b) known examples of technology work already being undertaken in those areas:

General discussion ensued as we worked to select among and prioritize these:

CardSpace/SAML: People are generally interested in/concerned about identity selector interoperability with existing SAML deployments. There are different ways to accomplish this, which should be treated as different use cases in order to tease apart the pros and cons for each (they all might need to be accounted for). Shibboleth has integrated CardSpace support, and it was conjectured that perhaps its attribute-based authorization approach makes this easier to do than if you're using authentication statements, but apparently the majority of Shib deployments don't use attribute-based authorization.

WS-Fed/SAML: It was noted that using the POST method with WS-Federation and with SAML V1.1 are extremely similar. It implies that the relying party/service provider has to handle both SAML and WS-Trust protocols.

User experience: A concern was expressed about the lack of consistency bewteen client-based and browser-based interfaces. There are consequences for the UI in the choice of protocols for a deployment. Deployment guides are desired for all cases, including error cases.

Single logout (SLO): If multi-protocol SSO is achieved (a single session being access through multiple different protocols), then if SLO is desired, it should be similarly supported. Scott described having developed support for syncing WS-Fed logouts and SAML logouts, but it appeared that many of the complications experienced in rollout were of the classic SLO vs. single-app logout sort -- users get confused about what they're doing and what they're supposed to be doing when they log out. Currently, even within a single protocol, support for SLO isn't often demanded, though this may change with strong authentication for which there's a business model (IdPs charge for it).

IdP discovery: The card model solves this by putting the IdP's location into the card that's installed in the selector. If identity selectors become ubiquitous the problem goes away, but this is a big step, and usability questions remain unanswered for this model. Many other issues are unanswered too, such as mobile network issues, the role of Radius and Diameter (some solutions that integrate SAML have been sketched out), and the possible role smart IdP-to-IdP proxying might play.

Levels of assurance (LOA): NIST has a standard for its 4 levels, which is borrowed by many but doesn't suit all. GSA currently uses SAML attributes to hold the level but is moving to an authentication context mechanism, which is theoretically better because the semantics then become "part of SAML" rather than remaining at the application level above -- but it's unclear if a context class maps properly to the NIST 11-space. We agreed that one-dimensional levels are a poor substitute for multi-dimensional descriptor matrices, and that individual deployment communities (not Concordia!) need to determine the semantics of which levels (if any) work for them. But representing the same system of LOA in different protocols would be in Concordia's scope if anyone is interested in int. The Identity Assurance Expert Group (IAEG) in Liberty is defining a trust framework with levels of trust that may be relevant to technical LOA work.

Dynamic web SSO: We anticipate some new work (by Patrick Harding and others) coming soon on making SAML web SSO faster to deploy, in 80/20 fashion, for a particular set of use cases. Making the metadata more useful is a key part of this. The plan is to draft a SAML profile and submit it to the SSTC. Concordia has a role to play in vetting the use cases. It was suggested that "dynamic web SSO" isn't a good name; an alternative, "deployment provisioning", was suggested.

Metadata: We discussed the PKI-centric approach vs. other approaches for making metadata work better. The current means of updating and exchanging certificates in SAML doesn't work or scale particularly well. Scott Cantor noted: "PKI is static and federation isn't." SAML's metadata spec is largely not specific to SAML, and the WSFED TC is currently working on its metadata specification, so perhaps there's an opportunity for cross-pollination of good ideas.

Attribute schema mapping: Work is ongoing in Identity Commons to do this. We don't want to get into this activity in Concordia, but it might be useful to identify a high-level set of attributes that meet particular common use cases, such as "consumer" ones. (The dynamic web SSO work might identify such a thing.) Shibboleth has defined eduPerson and CardSpace borrows from this. OpenID has the Simple Registration set. SAML defines a way to pull in any LDAP schema, which is more abstract than any of these mechanisms. In general, deployment communities need to select relevant attribute sets/schemas themselves.

Demonstrating interop: It was suggested that setting up semi-persistent live endpoints to test and demonstrate interop would be a good thing. We'd like to get some interop between implementations working ASAP, even if our ultimate goal goes beyond identity "mashups" (API-level interop) and towards wire-level interop.

Prioritized use cases and other tasks

We developed lists of A-priority, B-priority, and "keep an eye on" tasks. We didn't artificially limit the length of the A-priority list, figuring that if people strongly need answers for this many items, that's an important reflection of reality.

A-priority:

  • WS-Federation/SAML:
    • Smart IdP use case (IdP proxying/gatewaying to handle both)
    • Smart RP use case (protocol-switching at the service provider)
  • Infocards/SAML:
    • Smart RP use case (how Shib has done things)
    • Smart(er) client use case (possibly involving the Enhanced Client/Proxy profile, attribute profiles, etc.)
  • IdP discovery:
    • Do a survey of how it's done and how painful the current methods are
    • Collect usability data
    • Do education and share knowledge about the issue (everyone hates each individual way, but add it all up and you still have to pick a way!)
  • WS-Federation/SAML metadata lessons:
    • Fill in holes in both directions
    • Consider how to build in multi-protocol capabilities to each
  • WS-Federation/SAML metadata distribution and lifecycle:
    • Consider the in-band and out-of-band ways in which this can be improved
    • May be impacted by the direction of the dynamic web SSO work
  • Interop endpoints
    • Put a priority on demonstrating interop by RSA conference in April 2008

B-priority:

  • SLO:
    • Gather ITU-T IdM Focus Group requirements
  • LOA representations:
    • Examine them all for opportunities to rationalize across them
  • CardSpace/ID-WSF bootstrapping
  • SASL-SAML opportunities:

Keep an eye on:

  • Roaming network access (by IdP proxying?)
  • Dynamic web SSO profile work:
    • Vet use cases
  • Attribute schema mapping work

Next steps

We plan to hold a telecon on 9 October 2007; for details see the [meeting schedule] on the main page for more details about upcoming telecons, workshops, and interop events.

Action items:

  • Britta Glade:
    • Plan December 1007 workshop prior to IIW.
    • Plan logistics of workshop/interop activities in April 2008 at RSA conference.
  • Rakesh Radhakrishnan: Send out ITU-T IdM Focus Group gap analysis to Concordia community list.
  • Jeff Hodges (=JeffH): Send out info on SAML-SASL approaches. (Done).
  • All: In next telecon, discuss how to push forward on at least some of the A-priority items identified.
Retrieved from "http://projectconcordia.org/index.php/DIDW_Workshop_2007_Notes"