Delegated authentication Electronic identity: delegated and federated authentication, policy-based access control

Transcription

1 Delegated authentication Electronic identity: delegated and federated authentication, policy-based access control Antonio Lioy < polito.it > 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) Politecnico di Torino Dip. Automatica e Informatica Delegated authentication Transmission of authentication result 3. authn protocol client 2. redirect 1. application request AS RP 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 Push ticket ticket sent directly from AS to RP Indirect push ticket ticket sent from AS to client and then from client to RP AS AS 4. authn result (ticket) client 4. ticket RP RP 1

2 Push reference + pull ticket ticket reference sent from AS to client and then from client to RP then ticket pull from RP to AS client 4c. ticket ref AS 4d. ticket 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) RP 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 XACML extensible Access Control Markup Language Antonio Lioy < polito.it > Politecnico di Torino Dip. Automatica e Informatica What is XACML? a language to describe authorisation policies, defined in terms of: subject (users, computer, services) resource (documents, file, data) identified through URI a language to manage access to resources protected by authorisation: data format to represent request/response transmitted over a client-server protocol of choice OASIS standard (based on XML syntax) 2

3 Policy-based access control model designed by IETF for the description of the admission control policies for QoS on routers: A framework for policy-based admission control (RFC-2753) The COPS (Common Open Policy Service) protocol (RFC-2748) subsequently generalized and extended to : management of information systems (DMTF) access control in distributed environments (OASIS) Components policy-based access control PEP = Policy Enforcement Point protects a resource and allows access only after verification of compatibility with the policy PDP = Policy Decision Point receives all the data (policy, subject, resource, access type, context) and decides whether to permit or deny the access PIP = Policy Information Point provides the info related to the access requested PAP = Policy Access Point provides the policy applicable to the requested access T subject PIP 1. S, O, T 8. authorised/denied 3. context info 7. response PDP PEP context handler 2. request 5. retrieve policy??? policy repository 0. write policy object PAP Context handler PEP: is tightly bound to the application or service (e.g. web server, firewall XML) uses specific formats for requests/responses (few PEP are capable of using directly XACML) context handler: converts access requests/responses from/to XACML enhances the requests with the attribute values (obtained from PIP) often in the form of SAML assertions XACML: policy format <PolicySet> container of single policies or other policy set <Policy> is the single access control policy <Rule> is the single rule in the policy (possibly more than one) <Effect> the effect of the rule (permit/deny) <Condition> condition to be verified (optional) <Target> used to control the applicability of the request and to index the various policies for the PDP <Subject> (one or more) can contain the list of the attributes of the subject to which the policy applies <Action> action allowed by the policy (view, execute, ecc) <Resources> reference to the resources to be protected (URI) XACML: request format <Request> contains the specifications for the subjects, the resources, the action and the environment obtained from the request context <Resource> specifies the data for the resource to which the access was requested, described through its <Attribute> <Action> specifiies the action on the resource, by listing a set of <Attribute> elements connected with the action <Subject> is the subjcet requiring the action, described with a set of its <Attribute> <Attribute> (of Subject, Request, Resource) <AttributeID> (e.g. username, DN, action, URI) <AttributeValue> 3

4 XACML: response format <Response> encapsulates the decision of the PDP <Result> represents a unique authorisation decision <Decision> contains the result of the application of the policy on the request (Permit / Deny / Indeterminate / NotApplicable). <Status> represents the status of the result of the authorisation decision (contains a status code, a message status and the status details) SAML Security Assertion Markup Language Antonio Lioy < polito.it > Politecnico di Torino Dip. Automatica e Informatica What is SAML? a data format used to: represent various types of assertions construct requests of assertions represent responses containing assertions assertion = ASSERTION (base object of SAML) has the scope to simplify and to make standard the interactions aimed to establish permissions in a multi-domain distributed system OASIS standard (based on XML syntax) SAML 1.0 november 2002 original version SAML 1.1 september 2003 SAML 1.* can protect messages with XML-dsig defines profiles for web browser SSO: browser/artifact profile = token SAML by ref browser/post profile = token SAML by value SAML 2.0 Web browser SSO use case march 2005 incompatible with the previous versions can protect messagges with XML-dsig can use XML-enc for identifiers, attributes and assertions (for privacy) defines new protocols, binding and profiles web user authenticate access protected resource source web site ( IdP ) destination web site ( SP ) IdP = Identity Provider SP = Service Provider 4

5 Authorization service use case Back office transaction use case PDP check permission authenticate and qualify authority known to both buyer user request access PEP transact business seller SAML assertion an assertion is: a declaration of a fact regarding a subject (e.g. the role of a user) declaration made by a certain issuer three types of assertions (all regarding security): authentication attributes authorisation decision can be extended to add other types of assertions assertion can be digitally signed (by using XML signature) Info common to all assertions issuer and issuance timestamp assertion ID subject name plus security domain "conditions" for which the assertion is valid: client SAML must reject the assertion containing conditions that are not understood an important condition: assertion validity period other useful information: e.g. explanation / proof of the basis on which the assertion was constructed Authentication assertion an issuer declares that: the subject S was authenticated with the mechanism M at time T attention! SAML does not perform authentication (e.g. password request, challenge and response) but provides a mechanism to create a link with the result of an authentication performed previously by an authentication agent Example of 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> 5

6 an issuer declares that: the subject S Attribute assertion is associated to the attributes A, B, C, that currently have the values "a", "b", "c", typically obtained from an LDAP query example: "alioy" in "polito.it" is associated to the attribute "Department" with value "DAUIN" Example of 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> Authorization decision assertion an issuer declares that it has taken a decision regarding an access request: made by a subject S for an access of type T to the resource R based on the evidence E the subject can be a person or a program the resource can be a web page, a file, a webservice, Example of 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> SAML: producer-consumer model SAML: protocol for the assertion Policy Policy Policy Asserting Party Credentials Collector Authentication Authority Attribute Authority Policy Decision Point SAML SAML Authentication Assertion Attribute Assertion Authorization Decision Assertion Request for Assertion of Certain Type Response Assertion System Entity Application Request Policy Enforcement Point Relying Party 6

7 Request of authentication assertion conceptually "Please, give me authentication information regarding this subject, if you have any" it is assumed that the requester and the responder have a trust relation: they speak about the same Subject the response is a sort of recommendation letter" for the Subject Example of request of 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> Trust relation often the assertion is part of a triangle who accepts the assertion must "trust" the entity that generates an assertion in practice the trust relation is established by deciding the security aspects of the assertion exchange push or direct pull on secure channel (e.g. TLS) shared or public key for XMLsignature Binding SAML SAML defines what" to transport, the binding defines how" to transport it, i.e. a network protocol for SAML requests and responses SAML/SOAP-over-HTTP is the original binding 1.0 SAML 2.0 defines other bindings: SAML SOAP binding (based on SOAP 1.1) reverse SOAP (PAOS) binding HTTP redirect (GET) binding HTTP POST binding HTTP artifact binding SAML URI binding SAML Profiles A SAML profile is a concrete manifestation of a defined use case using a particular combination of assertions, protocols and bindings in practice a "profile" is a pattern to make assertions relative to important information for a specific use case: "web browser profile" to implement SSO web "SOAP profile" for assertions on the SOAP payload 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, with hidden field containing SAML-authN-resp (C > SP) POST with SAML-authN-resp (SP > C) verifies SAML-authN-resp and eventually provides the requested service also named "front-channel exchange" 7

8 SSO push use case 1. service req SP 2. redirect to IdP (w/ authn req) 6. authn res 7. service C 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 with an artifact (=pointer to SAML-authN-resp on the 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 also named "back-channel exchange" SSO pull use case 1. service req 2. redirect to IdP (w/ authn req) 6. artifact 9. service C SP 7. authn-res req SAML SSO for Google Apps a company (partner) installs its own application on Google (service provider) the partner wants to maintain control of the authentication and authorisation part (identity provider) the exchange is based on SAML-2.0 with XML signature 5. redirect to SP (w/ artifact) 4. authn exchange IdP 8. authn-res 3. authn req SAML SSO for Google Apps: details the partner must provide to Google: the URL of hiw own SSO service the X.509 certificato to verify his signatures the step 3 contains (in opaque mode): the URL of Google service requested by the user the SAML authentication request the URL of the ACS (Assertion Consumer Service) the step 6 contains (in opaque mode): the URL of Google service requested by the user the SAML authentication response with XML sig the URL of the ACS 8

9 Federated identity SAML is often used to create federated identity systems SAML typically used in PC / server web-based environments (heavy and difficult to support in light / mobile environments) OpenID-connect makes similar things as SAML the same architecture C / SP / IdP JSON data format and REST protocol (both native on smartphone and tablet) not correlated to OpenID-2.0 an identity layer over Oauth-2.0 (IETF authorisation framework) 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) OIDC: user authentication OIDC: login with token 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 9

10 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) 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) Adaptive security and privacy protection The eidas infrastructure 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) ( O O ) 1. ask for service Italian citizen service provider 2. use eidas 3. select your country Swedish eidas SP-proxy 4a. consent? 4b. which e-id? 5a. authentication 5b. consent (final) Italian eidas IDP-proxy IDP + AP (Italian) 10

11 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 11