e-gov web-services for egovernment in germany brussels, feb. 19, 2009 oasis egov member section...
TRANSCRIPT
E-GOV
Web-Services for eGovernment in Germany
Brussels, Feb. 19, 2009
OASIS eGov Member Section
Frank SteimkeOSCI Leitstelle, Bremen, Germany
E-GOV
Folie 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
E-GOV
Folie 3
Agenda
Web Services Security: 1st Approach, OSCI-Transport 1.2
Standardization at the Application Level
Next Steps
E-GOV
Folie 5
Communication levels
Internet / http
Standardized message exchange (Application level)
E-GOV
Folie 6
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
E-GOV
Folie 7
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)
E-GOV
Folie 8
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
E-GOV
Folie 9
Agenda
Web Services Security: 1st Approach, OSCI-Transport 1.2
Standardization at the Application Level
Next Steps
E-GOV
Folie 10
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 Registry
in case of Residences in different Municipalities Need of Message exchange to keep Registries synchronous More than 20 legacy Systems to operate these Registries
E-GOV
Folie 11
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
E-GOV
Folie 12
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
E-GOV
Folie 13
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 Engine
University of Bremen, Germany
E-GOV
Folie 16
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
LocalRegistry
LocalRegistry
LocalRegistry
LocalRegistry
CentralizedRegistry for
TAX purposes
E-GOV
Folie 17
Agenda
Web Services Security: 1st Approach, OSCI-Transport 1.2
Standardization at the Application Level
Next Steps
E-GOV
Folie 18
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
E-GOV
Folie 19
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) ?