Project Abstract Portalverbund

Key data see overview.

Key purpose, services, user community, numbers: Largely focused on managing identities and delegated authorization for government employees and contractors. As of Jan. 2011 153 applications within the legal framework, and est. 1500 application within the technical framework. There are est. 200,000 end users registered.

Inception: With the establishment of a centralized citizen registry in 2001 the identity management was established as a separate project with the intend to support other applications in the future. A key success factor was the inclusion of other stakeholders than the application provider into the definition of legal and technical matters.

Maturity: Both the legal framework and current proprietary protocol are very stable. However, to enable interoperability with federations in other sectors and to support certain use cases, a transition to SAML2 is underway.

Business case: The key benefits that were recognized in this project are:* “Single point of management”: Delegated user and privilege management is located at the organization where a user is employed. This lessens the burden of proper user management

• Avoidance of bilateral contracts per application - with several applications per organization and thousands of parties bilateral contracts would not scale
• Uniform security agreement: various application-specific security policies would contradict each other and result in a management nightmare
• Improved data protection compliance: Scattered user accounts were hard to maintain, accounts were not cancelled when they should have been.

Legal framework: A single agreement for both service and identity providers is signed unilaterally by each participating government agency. There is a central registry (at the Office of the Federal Chancellor) that administers and publishes participants and applications.

Technical standards: A proprietary protocol using custom HTTP-headers and SOAP-headers are used. Both IdP and SP are usually implemented as reverse proxy. There is a common data model for federation objects and user attributes based on a LDAP schema. Metadata is published in a LDAP directory.

Assurance levels and policy profiles: There are 4 security classes (0 .. 3) that are very similar to NIST 800-63 LoA 1 .. 4

Lessons learned:
Advantages: The reverse proxy model is rather simple to implement, IdPs have full control over client sessions, and SP proxies serve as application firewall which is a good security practice.
Drawbacks: Shared namespaces behind proxies cause problems with applications using absolute paths, ignoring cookie-standards of requiring / as root context.
The metadata directory was not mandatory initially. As a consequence it proved difficult to have complete and up-to-date data in the directory. Roll-out of new applications proved more difficult as metadata is published in unstructured documents in parallel, again incomplete.