Federation key to Web services
Heterogeneity rules in network security environments. In the stubbornly multiorganizational, multidomain and multivendor world of Web services, the political concept of "federation" takes on new meaning. Federation describes scenarios in which no one group or organization manages all users and resources in a distributed application environment. Instead, administrators in diverse domains must manage local security policies that support mutually beneficial transactions among their respective spheres of operation.
The term federation derives from the Latin word for trust. In the world of distributed network services, the term refers to the need for trust agreements among decentralized security and policy domains. Federation lets access-management functions span diverse organizations, business units, sites, platforms, products and applications. Federation requires that an organization trust each trading partner to authenticate its own users' identities. In a federated environment, a user can log on to his home domain and access resources transparently in external domains, such as those managed by customers or suppliers, subject to various policies defined by home and external administrators.
You increasingly will see the term federation used with a new security standard, the XML-based Security Assertions Markup Language (SAML) 1.0, which is nearing ratification by the Organization for the Advancement of Structured Information Standards (OASIS). Web access-management vendors such as IBM/Tivoli, RSA Security/Securant, Netegrity, Oblix, Entegrity, Entrust Technologies and Sun/iPlanet have rallied around SAML 1.0 as a means for establishing standards-based interoperability among their products. As these vendors sell their wares into corporations large and small, SAML-based federation will be critical to knitting organizations' diverse access-management environments into unified business-to-business supply chains.
So what precisely is SAML 1.0? At its heart, the standard defines XML/Simple Object Access Protocol-based protocol interactions that support real-time authentication and authorization across federated Web services environments. The standard defines request and response messages that security domains use to exchange authentication, attribute and authorization information in the form of trust-assertion messages about named users and resources. Users log on to their home domains through authentication techniques such as ID/password or Kerberos, and this authentication is communicated to a federated destination site through a SAML authentication assertion.
In coming months, SAML-based products will be promoted so aggressively that we'll have to remind ourselves of the standard's immaturity, limited commercial availability and functional constraints. For starters, SAML 1.0 is not yet a ratified OASIS standard and won't likely attain that status until mid- to late summer. In addition, there are few SAML-enabled Web access-management products on the market, though standards-compliant products will become increasingly available over the coming year.
But an even more pressing concern is the need for SAML deployment guidelines. Web access-management vendors will need to help users implement SAML federation profiles without getting lost in the sundry technical options that the standard allows - or doesn't address at all.
During the next several months, Web access-management vendors will address interoperability issues among their SAML 1.0 implementations. If all goes well with initial interoperability testing, expect to see some commercial SAML 1.0-enabled products this year. But it may take several years before SAML-based products mature to the point where users can implement federated single sign-on and authorization scenarios without having to write excessive amounts of custom code to bridge divergent vendor implementations of the core standard.
In any event, we can't afford to ignore SAML. Federation is no fad, and SAML will become a key standard for bridging security domains across Web services environments.
Kobielus is an Alexandria, Va.-based analyst with The Burton Group, an IT advisory service that provides in-depth technology analysis for network planners. He can be reached at (703) 924-6224 or
OASIS SAML page
More info on the protocol.
Baltimore Tech first to add SAML
Network World, 4/29/02.
Error 404--Not Found
From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:
10.4.5 404 Not Found
The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent.
If the server does not wish to make this information available to the client, the status code 403 (Forbidden) can be used instead. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address.