Identità digitale: autenticazione delegata e federata, policy-based access control

Transcript

1 Identità digitale: autenticazione delegata e federata, policy-based access control Antonio Lioy < polito.it > Politecnico di Torino Dip. Automatica e Informatica Delegated authentication several RPs (Replying Party) may decide to delegate authentication to a separate entity AS AS (Authentication Server) is performing authn on behalf of the RP interacting with the authn client with one among a set of authentication protocols and finally providing to the RP the authn result in the form of a ticket (or assertion) 1

2 Delegated authentication 3. authn protocol AS client 2. redirect 1. application request RP Transmission of authentication result AS can transmit authn result to RP in various ways differences in terms of: speed security and trust implications on services, interfaces, network filters no correct or best solution select based on your application scenario 2

3 Push ticket ticket sent directly from AS to RP AS 4. authn result (ticket) RP Indirect push ticket ticket sent from AS to client and then from client to RP AS client 4. ticket RP 3

4 Push reference + pull ticket ticket reference sent from AS to client and then from client to RP then ticket pull from RP to AS AS client 4c. ticket ref 4d. ticket RP Problems with tickets binding with client ticket authentication ticket manipulation (at client) ticket manipulation (by MITM) ticket sniffing (in the network / at client) privacy! listening service at RP incoming firewall at RP ticket replay (by same client) ticket reuse (at different client) 4

5 Ticket protection direct transmission AS RP digital signature by AS + encryption for RP, or secure channel (AS authn + packet integrity/authn + packet encryption + no replay, e.g. TLS) indirect transmission via client digital signature by AS + encryption for RP protection from replay or reuse timestamp (time limit?) binding with ID and/or network address Federated authentication various security domains each one managed by a different AS create a trust relationship so that a RP belonging to one domain will accept the authentication performed by the AS in another domain actors are usually renamed as: IDP (Identity Provider) ~ AS SP (Service Provider) ~ RP 5

6 XACML extensible Access Control Markup Language Antonio Lioy < polito.it > Politecnico di Torino Dip. Automatica e Informatica Cos'è XACML? un linguaggio per descrivere politiche di autorizzazione, definito in termini di: subject (utenti, computer, servizi) resource (documenti, file, dati) identificati tramite URI un linguaggio per gestire accessi a risorse protette da politiche di autorizzazione: formato dati per esprimere richiesta/risposta da veicolare su un protocollo client-server a scelta standard OASIS (basato su sintassi XML) 6

7 Controllo accessi policy-based modello ideato da IETF per la descrizione delle politiche di admission control per QoS sui router: A framework for policy-based admission control (RFC-2753) The COPS (Common Open Policy Service) protocol (RFC-2748) poi generalizzato ed esteso alla: gestione di sistemi informativi (DMTF) controllo accessi in ambienti distribuiti (OASIS) Componenti controllo accessi policy-based PEP = Policy Enforcement Point protegge una risorsa e ne permette l'accesso solo se le verifica di compatibilità con la policy è positiva PDP = Policy Decision Point riceve tutte le informazioni (policy, soggetto, risorsa, tipo di accesso, contesto) e decide se concedere o meno l'accesso PIP = Policy Information Point fornisce le informazioni relative all'accesso richiesto PAP = Policy Access Point fornisce la policy applicabile all'accesso richiesto 7

8 T soggetto PIP 1. S, O, T 8. autorizzato/negato 3. context info 7. risposta PEP context handler 2. richiesta??? policy repository 0. scrittura policy oggetto PDP 5. recupera policy PAP Context handler il PEP: è strettamente legato all'applicazione o servizio (es. web server, firewall XML) usa formati specifici per richieste/risposte (pochi PEP sono in grado di usare direttamente XACML) context handler: traduce richieste/risposte di accesso da/a XACML arricchisce le richieste coi valori degli attributi (ottenuti dal PIP) spesso nella forma di asserzioni SAML 8

9 XACML: formato policy <PolicySet> contenitore di singole policy o di altri policy set <Policy> è la singola politica di controllo degli accessi <Rule> è la singola regola nella politica (possibile più di una) <Effect> L effetto della regola (permit/deny) <Condition> La condizione da verificare (opzionale) <Target> usato per controllare l applicabilità della richiesta ed indicizzare le varie policy per il PDP <Subject> (uno o più soggetti ) può contenere l elenco degli attributi legato al soggetto al quale è rivolta la policy <Action> Ciò che la policy permette di fare (view, execute, ecc) <Resources> Il riferimento alle risorse da proteggere (URI) XACML: formato richiesta <Request> contiene le specifiche per i soggetti, le risorse, l azione e l ambiente ricavati dal contesto di richiesta <Resource> specifica le informazioni sulla risorsa alla quale è stato richiesto l'accesso, descritta tramite i suoi <Attribute> <Action> specifica l'azione sulla risorsa, elencando un insieme di elementi <Attribute> connessi con l'azione <Subject> è il soggetto richiedente l'azione, descritto tramite un insieme di suoi <Attribute> <Attribute> (di Subject, Request, Resource) <AttributeID> (es. username, DN, action, URI) <AttributeValue> 9

10 XACML: formato risposta <Response> incapsula la decisione del PDP <Result> rappresenta un'unica decisione di autorizzazione <Decision> contiene il risultato dell applicazione della policy sulla richiesta (Permit / Deny / Indeterminate / NotApplicable). <Status> rappresenta lo stato del risultato della decisione di autorizzazione (contiene un codice di stato, un messaggio di stato e i dettagli di stato) SAML Security Assertion Markup Language Antonio Lioy < polito.it > Politecnico di Torino Dip. Automatica e Informatica 10

11 un formato dati per: Cos'è SAML? esprimere vari tipi di affermazioni formulare richieste di affermazioni esprimere risposte contenenti affermazioni affermazione = ASSERTION (oggetto base di SAML) ha lo scopo di rendere standard e semplificare le interazioni relative a stabilire dei permessi in un sistema distribuito multi-dominio standard OASIS (basato su sintassi XML) SAML 1.0 nov 2002 versione base SAML 1.* SAML 1.1 set 2003 può proteggere messaggi con XML-dsig definisce profili per web browser SSO: browser/artifact profile = token SAML by ref browser/post profile = token SAML by value 11

12 mar 2005 SAML 2.0 incompatibile con versioni precedenti può proteggere messaggi con XML-dsig può usare XML-enc per identificatori, attributi ed asserzioni (per privacy) definisce nuovi protocolli, binding e profili Web browser SSO use case authenticate source web site ( IdP ) web user access protected resource destination web site ( SP ) IdP = Identity Provider SP = Service Provider 12

13 Authorization service use case PDP check permission request access user PEP Back office transaction use case authenticate and qualify authority known to both buyer transact business seller 13

14 un'assertion è: SAML assertion una dichiarazione relativa ad un fatto pertinente ad un soggetto (es. il ruolo ricoperto da un utente) dichiarazione fatta da un certo issuer tre tipi di assertion (tutte relative a sicurezza): autenticazione attributi decisione di autorizzazione estendibile per aggiungere altri tipi di assertion assertion può essere firmata digitalmente (tramite XML signature) Info comuni a tutte le assertion issuer e issuance timestamp assertion ID subject nome più il dominio di sicurezza "condizioni" sotto cui l'assertion è valida: client SAML devono rifiutare assertion contenenti condizioni non comprese una condizione importante: assertion validity period altre informazioni utili: es. spiegazione / prova della base su cui è stata costruita l'assertion 14

15 Authentication assertion un issuer afferma che: il soggetto S è stato autenticato col meccanismo M al tempo T attenzione! SAML non effettua lui l'operazione di autenticazione (es. richiesta di password, sfida e risposta) ma fornisce un meccanismo per creare un collegamento col risultato di un'autenticazione svoltasi in precedenza da parte di un agente di autenticazione Esempio di authentication assertion <saml:assertion MajorVersion="1" MinorVersion="0" AssertionID=" " Issuer="Politecnico di Torino" IssueInstant=" T10:02:00Z"> <saml:conditions NotBefore=" T10:00:00Z" NotAfter=" T10:05:00Z" /> <saml:authenticationstatement AuthenticationMethod="password" AuthenticationInstant=" T10:02:00Z"> <saml:subject> <saml:nameidentifier SecurityDomain="polito.it" Name="alioy" /> </saml:subject> </saml:authenticationstatement> </saml:assertion> 15

16 un issuer afferma che: il soggetto S Attribute assertion è associato agli attributi A, B, C, che hanno attualmente i valori "a", "b", "c", tipicamente ottenuto da una query LDAP esempio: "alioy" in "polito.it" è associato all'attributo "Dipartimento" con valore "DAUIN" Esempio di attribute assertion <saml:assertion...> <saml:conditions.../> <saml:attributestatement> <saml:subject> <saml:nameidentifier SecurityDomain="polito.it" Name="alioy" /> </saml:subject> <saml:attribute AttributeName="Dipartimento" AttributeNamespace=" <saml:attributevalue> DAUIN </saml:attributevalue> </saml:attribute> </saml:attributestatement> </saml:assertion> 16

17 Authorization decision assertion un issuer afferma di aver preso una decisione circa la richiesta di accesso: da parte del soggetto S per un accesso di tipo T alla risorsa R basandosi sull'evidenza E il soggetto può essere un individuo o un programma la risorsa potrebbe essere una pagina web, un file, l'invocazione di un webservice, Esempio di authorization decision assertion <saml:assertion...> <saml:conditions.../> <saml:authorizationstatement Decision="Permit" Resource=" <saml:subject> <saml:nameidentifier SecurityDomain="polito.it" Name="alioy" /> </saml:subject> </saml:authorizationstatement> </saml:assertion> 17

18 SAML: modello produttore-consumatore Policy Policy Policy Credentials Collector Authentication Authority Attribute Authority Policy Decision Point SAML Authentication Assertion Attribute Assertion Authorization Decision Assertion System Entity Application Request Policy Enforcement Point SAML: protocollo per le assertion Asserting Party SAML Request for Assertion of Certain Type Response Assertion Relying Party 18

19 Richiesta di authentication assertion concettualmente "Per favore, forniscimi l'informazione di autenticazione relativa a questo soggetto, se ne hai" si assume che richiedente e risponditore abbiano una relazione di fiducia: stanno parlando dello stesso Soggetto la risposta è una sorta di "lettera di introduzione" per il Soggetto Esempio di richiesta di authentication assertion <samlp:request MajorVersion="1" MinorVersion="0" RequestID=" " > <samlp:authenticationquery> <saml:subject> <saml:nameidentifier SecurityDomain="polito.it" Name="alioy" /> </saml:subject> </samlp:authenticationquery> </samlp:request> 19

20 Relazione di fiducia spesso le asserzioni fanno parte di una triangolazione chi accetta l'asserzione deve "fidarsi" di chi genera l'asserzione nella pratica la relazione di fiducia si stabilisce fissando gli aspetti di sicurezza dello scambio dell'asserzione push o pull diretto su canale sicuro (es. SSL) chiave condivisa o pubblica per XMLsignature Binding SAML SAML definisce "che cosa" trasportare (what), il binding definisce "come" trasportarlo (how), ossia un protocollo di rete per richieste e risposte SAML SAML/SOAP-over-HTTP è il binding base 1.0 SAML 2.0 definisce altri binding: SAML SOAP binding (basato su SOAP 1.1) reverse SOAP (PAOS) binding HTTP redirect (GET) binding HTTP POST binding HTTP artifact binding SAML URI binding 20

21 Profili SAML A SAML profile is a concrete manifestation of a defined use case using a particular combination of assertions, protocols and bindings in pratica un "profilo" è un pattern per fare asserzioni relative ad informazioni importanti per uno specifico caso d'uso: "web browser profile" per implementare SSO web "SOAP profile" per asserzioni sul payload SOAP SSO push use case (C > SP) GET service URI (SP > C) REDIRECT to IdP with SAML-authN-req (C > IdP) GET with SAML-authN-req (C : IDP) authentication exchange (IdP > C) HTML form: POST to SP, con campo nascosto che contiene SAML-authN-resp (C > SP) POST con SAML-authN-resp (SP > C) verifica SAML-authN-resp ed eventualmente fornisce il servizio richiesto anche detto "front-channel exchange" 21

22 SSO push use case 1. service req SP 2. redirect to IdP (w/ authn req) 6. authn res C 7. service 5. redirect to SP (w/ authn res) 4. authn exchange IdP 3. authn req SSO pull use case (C > SP) GET service URI (SP > C) REDIRECT to IdP with SAML-authN-req (C > IdP) GET with SAML-authN-req (IdP > C) HTML form: POST to SP con un artifact (=puntatore a SAML-authN-resp sull'idp) (C > SP) POST with artifact (SP > IdP) GET with artifact (IdP > SP) SAML-authN-resp (SP > C) verifies SAML-authN-resp and eventually provides requested service anche detto "back-channel exchange" 22

23 1. service req SSO pull use case 2. redirect to IdP (w/ authn req) SP C 6. artifact 9. service 7. authn-res req 5. redirect to SP (w/ artifact) 4. authn exchange IdP 8. authn-res 3. authn req SAML SSO per Google Apps una ditta (partner) installa la propria applicazione su Google (service provider) il partner vuole mantenere il controllo della parte di autenticazione ed autorizzazione (identity provider) lo scambio è basato su SAML-2.0 con firma XML 23

24 SAML SSO per Google Apps: dettagli il partner deve fornire a Google: la URL del proprio servizio di SSO il certificato X.509 per verificare le proprie firme il passo 3 contiene (in modo opaco): la URL del servizio Google richiesto dall'utente la richiesta SAML di autenticazione la URL dell'acs (Assertion Consumer Service) il passo 6 contiene (in modo opaco): la URL del servizio Google richiesto dall'utente la risposta SAML di autenticazione con firma XML la URL dell'acs 24

25 Identità federata SAML spesso usato per creare sistemi di identità federata SAML molto orientato all'ambiente PC / server web-based (pesante e difficile da supportare in ambiente light / mobile) OpenID-connect svolge funzioni simili a SAML stessa architettura C / SP / IdP formato dati JSON e protocollo REST (entrambi nativi su smartphone e tablet) non correlato a OpenID-2.0 uno strato di identità sopra ad Oauth-2.0 (framework IETF di autorizzazione) OpenID-connect (OIDC) delegated authentication system JSON data + REST protocol, native on mobile OS not correlated to OpenID-2.0 but an identity layer over Oauth-2.0 (IETF authorisation framework) user agent = browser or mobile app client = RP wishing to use OIDC for authn OP = OpenID Provider (~IDP), w/ various endpoints AuthZ EP = manages authn protocol Token EP = verifies token validity UserInfo EP = provides user information (if user consents to) 25

26 OIDC: user authentication OIDC: login with token 26

27 OIDC: trust, security, and discovery messages authenticated with digital signatures requires registration of public keys among the various actors message exchange protected via secure channel (TLS) no real federation but can use WebFinger to discover the OpenID Providers (if registered with WebFinger) well-known OIDC providers: Google, Facebook, Salesforce, eidas Antonio Lioy < polito.it > Politecnico di Torino Dip. Automatica e Informatica 27

28 eidas regulation European Union Regulation no. 910/2014 electronic identification and trust services for electronic transactions in the internal market ensures that people and businesses can use their own national electronic identification schemes (eids) to access public services in other EU countries where eids are available. adopted on 23 July 2014 eidas eid infrastructure is currently voluntary compulsory for EU public services from 2018/09 private sector adoption is optional but welcome eidas purpose and principles boost confidence and trust towards digital world by adopting the following principles among others mutual acceptance of national e-id common framework for secure interaction between citizens, companies and public administration technological neutrality of requirements required to not restrict to specific solutions level of trust in national electronic identity can be defined by a certain e-id quality level country-specific supervision organisations to verify the Regulation adoption and interact with the European Commission (e.g. for data privacy) 28

29 eidas implementing acts Commission Implementing Decision (EU) 2015/296 (24 February 2015) eid procedural arrangement for MS cooperation 2015/1501 (8 September 2015) interoperability framework 2015/1502 (8 September 2015) technical specifications for assurance levels for electronic identification means 2015/1984 (3 November 2015) formats and procedures for notification Pan-european eid e-identity = authentication + certified attributes set of certified European attributes lexicon (multilanguage attribute names) syntax (possible values) semantics (e.g. surname) various authentication credentials reusable password, one-time-password, cellphone, software certificate, smart-card used in a transparent way and with legal value (according to the citizen's country) 29

30 Adaptive security and privacy protection various authentication levels crypto strength of the authn technique strength of the identification process LOA (Level of Assurance) substantial, medium, high requested (by the service) versus effective LOA (depending on the authn technique used) privacy protection and localization user talks with her own country and provides explicit consent for the required attributes attributes managed end-to-end (no storage of personal data in the infrastructure) minimal disclosure (NEED-TO-KNOW principle) The eidas infrastructure 1. ask for service service provider 2. use eidas 3. select your country Swedish eidas SP-proxy Italian eidas IDP-proxy Italian citizen 4a. consent? 4b. which e-id? 5a. authentication 5b. consent (final) IDP + AP (Italian) 30

31 eidas Technical specifications version 1.1 publicly available based on STORK1 similar, but not compatible covers e.g. end-to-end encryption of authn response architecture SAML message format SAML attribute profiles cryptographic requirements eidas minimum data-set defines a minimal data-set to be supported by any eidas node for cross-border authentication 8 attributes for natural persons (mandatory) PersonIdentifier, FirstName, FamilyName, DateOfBirth (optional) BirthName, PlaceOfBirth, CurrentAddress, Gender 10 attributes for legal persons (mandatory) LegalName, LegalPersonIdentifier (optional) LegalAddress, VATRegistration, TaxReference, BusinessCodes, LEI, EORI, SEED, SIC 31