Current practices on Security /...

Current practices onSecurity / GeoRMINSPIRE IOC TF Services – 18/01/2010

Identification, authorization and authentication.

External drivers

� Heterogeneous group of stakeholders with divergingneeds and interests• SDI-Flanders• Federal authorities• Europe (INSPIRE)• Utility sector• Private companies• Private companies• Citizens

� Legislation, Contracts• Belgian Legislation• Flemish Legislation• INSPIRE directive

29-1-2010Editeer via Beeld > Koptekst en voettekst

Identification, authorization and authentication.

Internal drivers (1)

� Prevent abuse and illegal use� Making the end user aware of the responsabilities that

come with data access / application roles.� Pro-active / optimized service through personalisation

• End-user support• Personalized profile and data and service offering• Better user experience• Better user experience

� Ensuring service continuity by monitoring usage. � Quality of Service (SLA) in function of specific usage.


Identification, authorization and authentication.Internal drivers (2)

� E-commerce • Community model : SDI-Flanders, Utility sector, European Commission

- Users are committed (feedback, kwaliteitscontrole)

- Cyclic optimalisation of services and user interfaces

- Experimental environment / platform for innovation

- Free of charge

• Subscription model : Private sector, Utility sector.

- Click-through licences- Click-through licences

- Adapted to specific user requirements

- Subscription fee

• Utility model : Private sector, Utility sector

- Ad hoc use

- Click-trough licences

- Pay per request / dataset


What do we secure?

� External interfaces • human-machine interfaces

- Web pages, web applications

• machine-machine interfaces- Web, REST, FTP services

� Login procedure (SSO) (identifications, authentication)� Data (privacy & geodata)� Data (privacy & geodata)� Messages


AGIV security implementation roadmap : Vision

� Single-Sign-On (applications and services)• Support for encryption of messages, data and privacy

information• Support for different kinds of credentials

- Internally : Windows credentials

- Certificate published by a Certificate Authority

- User/Password

- E-id (Belgian federal electronic identity)


AGIV implementation roadmap (1) :

State of play authentication/authorization

� Website and web applications : SSO is available• Based on Microsoft ASP.Net Membership and Role

providers.• Identification (manual aproval), authentication (SSO login)

and authorisation (application roles) are in use.• E-id support has been developed. Tests are going on.• Support for Cardspace managers is in development.• Support for identity delegation (propagation of user

credentials to a web service via a web application based onWindows Identity Framework (SAML 1.0 + Secure Token Service) is in development/test.


AGIV implementation roadmap (2) : State of play services

� Web services (SOAP) – e.g. Address service• OASIS WS-SECURITY Username Token Profile +

PassWordDigest - Based on SSO account and web key (GUID)

� OGC web services (http kvp)• Staged security through a reverse proxy• Staged security through a reverse proxy

- Authentication on IP address

- HTTP digest authentication

– SSO account en web key (GUID)

� Others (specific usage, beta, test)• The above in combination with SSL (transport security),

FTPS, X.509 Certificate Token Profile


AGIV implementation roadmap(3): State of play GeoServices� Bindings

Discovery services :

• Mix of KVP and SOAP. For GetCapabilities we use KVP, for GetRecordById we have a KVP

and a SOAP binding and so on, conform the CSW ISO AP.

View services

• We don’t use SOAP for View services at the moment, since there is no supporting software

and we don’t see any advantage in encapsulating a map image in a SOAP message.

• We decided to follow the OGC standards. We implemented KVP bindings for View Services • We decided to follow the OGC standards. We implemented KVP bindings for View Services

(ESRI ArcGIS Server in the backend).

� Security• Similar implementations for KVP en SOAP.

• For KVP we use http digest authentication. Credentials (username / password) are entered

interactively by the user at the start of a browser session. Most browsers support http digest

and this kind of security is also supported by for example ArcGIS 9.3 and Gaia 3. This solution

seems to work fine for OGC like services.

• For SOAP we use OASIS WS-SECURITY Username Token Profile + PassWordDigest.


AGIV implementation roadmap (4) : State of play GeoRM� Now

• Download application (non INSPIRE) with a proprietary contract model

- Only for data (not for services)

• Service access

- Application roles based on Microsoft ASP.Net Membership and role provider

- Ganularity : service (e.g. access to WMS gives access to all layers of WMS; access to service gives access

to all methods)

� Near future

• INSPIRE compliant download service (predefined datasets) with a proprietary contract model

- Users still need to be granted access / access rights have to be managed centrally

- Not for services (only data)

� Vision (2012) – SAML/STS

• Access rights as SAML assertions in claimsets (authorization, )

- Managed by decentralized Identity Provider and/or Security Token Service provider (authentication +

authorization) (e.g. Access granted to European Officials by a STS hosted by the EC)

- For data, services and applications

- For different types of credentials

- High granularity : data (dataset groups, datasets, features) , services (service, methods)


Testbed


AGIV implementation roadmap :

Non-functional Implementation issues

� Requirements : Managebility (accounts, access rights), Interoperability , Low

implementation complexity (ease of development)

� How important is our data / security level in function of data sensitivity

� A few months ago we threw our services in a test bed and made them available to the public. The

feedback we got was that security was too complex for ordinary users who just want access to data, so

we watered down security for testing purposes. Security complexity should be handled by the

applications, users should merely have to logon/provide credentials. applications, users should merely have to logon/provide credentials.

� Users want to keep it as simple and transparent as possible (as it should be), current GIS applications

are very limited in their support, authorization at data level and service level (security + GeoDRM) add

extra complexity and there is nothing like a common solution that answers to all our needs. For the

moment we only have http security, OASIS-WS* and SSL that offer a decent level of interoperability

between systems in different flavors. In the future we believe that SAML tokens and Secure Token

Servers really could have an answer to our problems. In the meanwhile we are also waiting for GeoDRM

actions from OGC, just to get an idea of the roadmap they’re laying down.


AGIV implementation roadmap : Implementation vision

� Identification• E-id

• CA Certificate

• Username / Password

� Authentication• STS + Claims (SAML 2.0 authentication assertion)

• WS-Security profiles for legacy services• WS-Security profiles for legacy services

• HTTP basic and digest authentication if necessary

� Authorisation (GeoRM)• Claims (SAML 2.0 authorisation assertion)

- High granularity, flexible, usable for web apps and services.

• Application roles

- Low granularity, less flexible, application bound, complex and elaboraterole management and administration.


AGIV implementation roadmap : Claims, SAML, STS


AGIV implementatie roadmap : Open Identity management

providers and authentication

If there is no common identity management available (E-id, username/password, certificate), services provided by OpenID providers canbe used.


Current practices on Security /...

Documents

Transcript of Current practices on Security /...