1 / 18

Web-Services for eGovernment in Germany

Web-Services for eGovernment in Germany. Brussels, Feb. 19, 2009 OASIS eGov Member Section. Frank Steimke OSCI Leitstelle, Bremen, Germany. At a glance. Security as a key requirement for eGovernment Web Services Paperless processes  Electronic Forms with electronic Signatures

bertha
Télécharger la présentation

Web-Services for eGovernment in Germany

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Web-Services for eGovernment in Germany Brussels, Feb. 19, 2009 OASIS eGov Member Section Frank SteimkeOSCI Leitstelle, Bremen, Germany

  2. At a glance • Security as a key requirement for eGovernment Web Services • Paperless processes  Electronic Forms with electronic Signatures • Encryption for confidentiality, PKI for authentification • Development of OSCI-Transport 1.2 in 2002 • Secure message exchange based on XML-Technologies • Implementing a Registry for OSCI-Transport bases Web-Services • Interconnecting the Registries of Residents as Killer-application • Standardization at the application level (OSCI-XMeld) • Nation-wide in use since Jan. 1, 2007 • Other applications followed (e. g. Interior, Justice, Finance) • Next steps • Adopting international “web service security” in OSCI-Transport 2 • New Projects at the European level

  3. Agenda • Web Services Security: 1st Approach, OSCI-Transport 1.2 • Standardization at the Application Level • Next Steps

  4. Standardized message exchange (Application level) Internet / http Communication levels

  5. Reliable One-Way Scenario • User 2 acts as a service provider • Intermediary acts as mandatory controller • unable to decrypt message content • Delivery is recorded, can be retraced and confirmed • Service result can be sent back in a independent transmission • Processing of the message is done behind the scenes

  6. Implementation of OSCI-Transport 1.2 • Described in terms of XML-Schema • Data structures for atomic messages (e. g. forward delivery request) • Problem with schema definition (Early version of XML-DSIG & XML-ENC) • Client components available free of charge and open source • OSCI-Transport library • Supplied by the government to support the use of OSCI-Transport • Available in JAVA and .NET • Server components available as commercial products • Developed and maintained by Industry • Different types of integration • OSCI-Transport library integrated in desktop applications • Intermediary integrated into legacy middleware • Special purpose middleware products (usually file-system based)

  7. German Government Services Registry (DVDV) • Build from scratch as a distributed system • Organizations and services managed in an LDAP tree • Master is operated by federal government • Slaves with replicated data at the federal state level • Maps service requests to data of communication endpoints • Request: service (‘xmeld-0201’, ‘bremen’) • Response: endpoint (X509-certificates, URI-of-intermediary, …) • Acts as a Indicator for non-mandatory services“Is service xmeld-0410 offered by the registration office in Bremen ?” • Describes in terms of WSDL, but … • Usually the service descriptions are hardcoded in the legacy systems • Transport-Binding is proprietary up to now (OSCI-Transport 1.2) • EU eGovernment Award 2007 for effective and efficient administration • See http://www.epractice.eu/cases/dvdv

  8. Agenda • Web Services Security: 1st Approach, OSCI-Transport 1.2 • Standardization at the Application Level • Next Steps

  9. Civil registration in Germany • Mandatory for all residents • Used as a Source of Information about Citizens for many purposes • Municipal Administration and Statistics • Private Parties (Find someone's Address) • Security purposes • Decentralized System with more than 5.000 registries at the local level • Sometimes filed in more than one Registryin case of Residences in different Municipalities • Need of Message exchange to keep Registries synchronous • More than 20 legacy Systems to operate these Registries

  10. Amendment of Federal Law • Prerequisites: Law and Techniques for Secure Data Exchange • German Digital signature Act (2001) • OSCI – Transport (2002) • Public Key Infrastructure with Certificates for Registration Offices • ( Centralized Registry for electronic Services ) • Commitment of Ministries of Interior for Automation • Based on open Standards for Transport and Application Level • Protection of Investment for Legacy Systems • Amendment of Federal Law took place in 2002 • Transitional period ends in 2006 • Electronic Data Exchange became … • Mandatory for messages between registries in different federal states Every Vendor was obliged to implement the standards • Mandatory for Federal Authorities • Possible for Inquiries and other messages

  11. Application Level Standardization • OSCI XMeld (XML für das Meldewesen) • Open Standard, designed for civil registration in Germany • Based on the German federal law about Content of Registries • E. g. Name, Address, Locations, Citizenship, Tax data … • Described in Terms of UML Classes • Implemented as Types in XML Schema, derived from UML • Messages for Processes in Civil Registration • Based on Data exchange liabilities in the Federal Law • E. g. Inquiries, Synchronization between Registries, … • Described in Terms of UML Classes:Aggregations of Base Data Structures • Implemented as Root-Elements in XML Schema, derived from UML • OSCI XMeld-Message • XML Document Instance, valid with Respect to OSCI-XMeld Schema • Signed, encrypted and transferred within OSCI-Transport Infrastructure

  12. Single source modeling • Modeling is done within UML • Use Cases, Activity Diagrams, Class Diagrams • Single source for Schema and Documentation guarantees Consistency • XML-Schema is derived from UML Classes • Using the UML profiling Mechanism (“UML-Profil für XÖV”) • Generation of <<xsdAttributes>> or <<xsdElements>> • Documentation is derived from UML Classes • XMeld-Specification is a docBook <book> which consists of • Fragments, automatically generated from UML Classes • Manually written parts • Software “XGenerator” has been written for this Task • Open Source Java Project, hosted at Sourceforge • Eclipse Modeling Framework (EMF) • USE, an A UML based Specification Environment with OCL EngineUniversity of Bremen, Germany

  13. Responsibilities for XMeld

  14. New services for TAX purposes • New centralized Database for TAX purposes • Unique TAX-ID for every citizen • Services offered by TAX Registry • Insert • Forced-insert • Update • Delete • Services offered by Residents Registry • Accept-tax-ID • Check-for-duplicates • Services are described in OSCI-XMeld • Security assured by OSCI-Transport • In use since 2008 • More than 10.000 Messages / Month

  15. Agenda • Web Services Security: 1st Approach, OSCI-Transport 1.2 • Standardization at the Application Level • Next Steps

  16. OSCI Transport 2 and SAFE • OSCI-Transport 2: secure web services profiled for German needs • Bases on international standards from WS* and WS-Security • Profiling is done to meet German (and European) laws • Some extensions for issues known from Version 1 Experiences • Specification will be published soon • Implementation will be done by using WS-Frameworks (Apache, SUN, MS) • SAFE: Secure Access for Federated eGovernment • Standardized interfaces to identity management techniques • Registration, authentication, authorization of communication participants • Based on WS*-Stack, profiled to improve interoperability • Basic part: Application independent • Further profiling for applications in eJustic in a second part • Shall be used in conjunction with service Registry and OSCI-Transport 2

  17. Application interoperability Issues • Status quo • Different Standards at the application level • Problem: Interoperability Issues with legacy systems and –data • Every system has its own information model … • … which is usually not explicit • Sometimes they are not easy to transform • Sometimes they are conflicting • How to develop a common nucleus for eGov-Message exchange ? • What about OASIS Core Componentes, part of ebXML? • How to deal with legacy data? • Common data structures or transformation and conversion • Top down or bottom up? • Costs (Invest and long term) ?

  18. Thank you very much Frank SteimkeOSCI Leitstelle, Bremen, Germany

More Related