Successfully reported this slideshow.
Your SlideShare is downloading. ×

Session 3 - i4Trust components for Identity Management and Access Control i4Trust Marketplace| Train the Trainers Program

Ad

i4Trust Website
i4Trust Community
i4Trust components for
Identity Management and
Access Control
Speakers:
Rajiv Rajani - C...

Ad

i4Trust Identity and Access Management (IAM)
■ About:
■ This part of the session will introduce you to i4Trust IAM compone...

Ad

Technical Deepdive on IAM in iSHARE

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Check these out next

1 of 123 Ad
1 of 123 Ad

Session 3 - i4Trust components for Identity Management and Access Control i4Trust Marketplace| Train the Trainers Program

Download to read offline

This session consists of two parts. The first part of the session will introduce you to i4Trust IAM components in detail while the second will introduce i4Trust Marketplace Services. Technical session for Local Experts in Data Sharing (LEBDs)

This session consists of two parts. The first part of the session will introduce you to i4Trust IAM components in detail while the second will introduce i4Trust Marketplace Services. Technical session for Local Experts in Data Sharing (LEBDs)

Advertisement
Advertisement

More Related Content

Slideshows for you (19)

Similar to Session 3 - i4Trust components for Identity Management and Access Control i4Trust Marketplace| Train the Trainers Program (20)

Advertisement

More from FIWARE (20)

Advertisement

Session 3 - i4Trust components for Identity Management and Access Control i4Trust Marketplace| Train the Trainers Program

  1. 1. i4Trust Website i4Trust Community i4Trust components for Identity Management and Access Control Speakers: Rajiv Rajani - CTO iSHARE Foundation Álvaro Arranz - CEO FICODES Francisco de la Vega - CTO FICODES
  2. 2. i4Trust Identity and Access Management (IAM) ■ About: ■ This part of the session will introduce you to i4Trust IAM components in detail. ■ This session will: ■ Explain iSHARE Identity and Access Management concepts in detail ■ Explain the FIWARE components which comply with iSHARE specifications in detail ■ How to deploy them ■ How to use them ■ Goals: ■ After this session you will be able to implement a service using i4Trust IAM components ■ Target Audience: ■ LEBDs
  3. 3. Technical Deepdive on IAM in iSHARE
  4. 4. Data Space Recap: Roles in a Data Space Data Consumer Data Provider Data Owner Identity Provider Authorisations Provider Marketplace Trust Provider 4
  5. 5. Recap: iSHARE role model 5 Data Space or Domain International Legal Framework governed by iSHARE Foundation
  6. 6. What is iSHARE Satellite? ■ iSHARE satellite is a federated certified role ■ It essentially does: ■ Onboard and maintain list of participants and its statues ■ Enables multilateral trust when participants signup ■ Provide APIs for participants to get detailed information along with statues of other participants with whom they want to interact or are interacting ■ Plays the facilitator role for common agreements like, but not limited to business agreements, operational agreements, etc. ■ Is federated part of the governing body of data spaces that interoperate
  7. 7. Identity Provider role is designed for users to reuse their existing identity provider at various service/data providers Identity Provider • The Identity Provider role deals with the human identities with varying level of assurances, as defined in eIDAS framework, to support various use cases • It is based on OpenID Connect as standard, however, with slight adjustment to make it better suitable for B2B, B2G, G2G and of course B2C and G2C • Depending on the criticality of the data, appropriate level of assurance for an identity can be requested • iSHARE specifications are designed such that service/data provider does not necessarily need to pre-register an identity provider as it can verify if it is an iSHARE certified provider from iSHARE satellite 7
  8. 8. Authorisations Registry (provider) role
  9. 9. Example response of a fine-grained authorisation
  10. 10. Example of a coarse-grained authorisation
  11. 11. Interaction Machine-to-Machine (M2M) Communication between machines, without interference by a human Human-to-Machine (H2M) Communication between a human and (a) machine(s). Requires a user interface Facilitate Flexible authorizations • Coarse-grained: broad authorization • Fine-grained: specific authorization • Flexibility on where to store authorizations Portable identities Identities can be spread out and recognised, i.e. portable, across multiple, independent systems Enable Delegations Functions as evidence that a party is directly or indirectly operating on behalf of a known party Customer in control parties are allowed to modify or withdraw access rights to their data or services, whenever they wish Trustworthy Identification, Authentication and Authorisations 11
  12. 12. Basics of every IAM transaction
  13. 13. A certificate is a digital file used for integrity and authenticity
  14. 14. A certificate consists of a public and a private part
  15. 15. iSHARE relies on PKI-certificates to verify organisational identities
  16. 16. A private keys signs data A public keys verifies this signature
  17. 17. JSON Web Tokens (JWTs) are base64- encoded JSON objects
  18. 18. JSON Web Tokens (JWTs) are base64- encoded JSON objects
  19. 19. JSON Web Tokens (JWTs) are base64- encoded JSON objects
  20. 20. In iSHARE, client assertions are JWTs with iSHARE specific Header and Payload
  21. 21. In iSHARE, client assertions are JWTs with iSHARE specific Header and Payload
  22. 22. An iSHARE party uses the client_assertion to get an access token from another iSHARE Party
  23. 23. An iSHARE party uses the client_assertion to get an access token from another iSHARE Party
  24. 24. An iSHARE party uses the client_assertion to get an access token from another iSHARE Party
  25. 25. Fictional use case Case: ■ ABC Trucking wants to access container data at the terminal on behalf of Banana & Co. ■ Banana & Co needs to register at AskMeAnything Authorization Registry that they delegate access rights to ABC Trucking ■ When ABC Trucking requests the data at the Service Provider, Warehouse 13, it checks with AskMeAnything for delegation evidence ■ If AskMeAnything returns valid delegation evidence, Warehouse 13 can exchange data with ABC Trucking All calls are iSHARE calls, except if noted otherwise. These exceptions are marked with a RED arrow.
  26. 26. Participants of the fictional use case Case: ■ ABC Trucking wants to access container data at the terminal on behalf of Banana & Co.
  27. 27. Beforehand: Getting the trusted list iSHARE Satellite iSHARE Satellite
  28. 28. Participants of the fictional use case
  29. 29. Further reading and useful links ■ iSHARE framework covering all aspects - https://scheme.ishareworks.org ■ iSHARE developer portal - https://dev.ishareworks.org ■ Postman collections for fictional use case - https://dev.ishareworks.org/demo-and- testing/postman.html#postman-collections ■ Dummy participants in various roles for testing purposes - https://dev.ishareworks.org/demo-and- testing/test-participants.html ■ JSON Web Tokens (JWT) reference and libraries - https://jwt.io ■ OAuth specifications and other materials - https://oauth.net/2/ ■ OpenID Connect specifications and other materials - https://openid.net/connect/ ■ eIDAS regulation ■ PKI wikipedia - https://en.wikipedia.org/wiki/Public_key_infrastructure
  30. 30. i4Trust IAM components
  31. 31. iSHARE Architecture using FIWARE ● Keyrock is the FIWARE component responsible for identity management. ○ It supports, among others, the OAuth2, Open ID Connect and eIDAS standards ○ It is being extended to support the iSHARE specifications ○ Plays the role of the identity provider ○ In a near future, it will also provide the authorization registry features. ● API Umbrella is an open source API management platform for exposing and securing web service APIs. ○ It acts as a proxy that provides access control, rate limiting, analytics, … to API services. We will use it to protect our context broker instances. ○ It is being extended to comply with iSHARE specifications. ● Until officially released, release candidate docker images should be used. At the moment: ○ fiware/idm:i4trust-rc2 for Keyrock ○ And fiware/api-umbrella:i4trust-rc3 for API Umbrella
  32. 32. iSHARE Architecture using FIWARE
  33. 33. Requirements to deploy ● To be registered as a iSHARE party. This means to have a certificate signed by a trusted CA (e.g. a CA from eIDAS or from a test CA) with the associated private key. Also means to have access credentials to the iSHARE Satellite and Authorization Registry instance to be used. ● Please, contact Rajiv for requesting testing credentials and access to those services.
  34. 34. Setting up Keyrock: i4Trust related environment variables ■ IDM_PR_URL: ■ URL of the iSHARE Satellite instance to use (e.g. https://scheme.isharetest.net) ■ This setting also is the one that enables i4Trust support on Keyrock ■ IDM_PR_CLIENT_ID: ■ party identifier (EORI) associated with this Keyrock instance ■ IDM_PR_CLIENT_KEY_FILE: ■ path to the private key file (PEM format) ■ IDM_PR_CLIENT_CRT_FILE: ■ path to the certificate chain (PEM format) ■ IDM_AR_URL: ■ URL of Authorization Registry instance to use (e.g. https://ar.isharetest.net) ■ IDM_AR_IDENTIFIER: ■ Party identifier (EORI) associated with the Authorization Registry instance
  35. 35. Managing Keyrock accounts
  36. 36. Setting up API umbrella: i4Trust related configuration … jws: identifier: EU.EORI.NLHAPPYPETS root_ca: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- private_key: | -----BEGIN PRIVATE KEY----- MIIEvAIBADANBgkqhkiG9w0BAQEFAASCBKYwggSiAgEAAoIBAQC8yeRuxDI2/vyJ … -----END PRIVATE KEY----- x5c: - MIIE...Uw== - MIIF...vic= - MIIF...AQ== authorisation_registry: host: https://ar.isharetest.net identifier: EU.EORI.NL000000004 token_endpoint: https://ar.isharetest.net/token delegation_endpoint: https://ar.isharetest.net/delegation In this case, configuration is provided through the api-umbrella.yml file.
  37. 37. API Management with API Umbrella ■ It support two types of entries: ■ API Backends (this is the one we are interested in) ■ And Website Backends ■ Changes are not automatically applied. Once you have created/updated/deleted the API Backend configuration, you have to publish them.
  38. 38. Basic API Backend configuration You can configure a list of backend services. In this case there is only one backend server (http://orion.local:1026). “Frontend Host” is the DNS that will be associated with this API backend (Umbrella can be associated with multiple DNS names). The “Backend Host” setting allows you to pass a different “Host” header to the backend server (usually not required). Also, it is possible to transform path prefixes.
  39. 39. Enabling i4Trust support API Umbrella is able to automatically analyse the incoming NGSI-LD request and to determine the necessary policy required for each request. This is achieved by setting the “Authorization Mode” to “Context Broker attribute based - iSHARE compliant (automatically)” in the Global Request Settings section.
  40. 40. Context Broker policy example This policy is telling that EU.EORI.NLPACKETDEL is allowing EU.EORI.NLNOCHEAPER to issue GET requests to read DELIVERYORDER entities, including any of their attributes. { "delegationEvidence": { "notBefore": 1541058939, "notOnOrAfter": 2147483647, "policyIssuer": "EU.EORI.NLPACKETDEL", "target": { "accessSubject": "EU.EORI.NLNOCHEAPER" }, "policySets": [ { "maxDelegationDepth": 1, "target": { "environment": { "licenses": ["ISHARE.0001"] } }, "policies": [ { "target": { "resource": { "type": "DELIVERYORDER", "identifiers": ["*"], "attributes": ["*"] }, "actions": ["GET"] }, "rules": [ { "effect": "Permit" } ] } ] } ] } } }
  41. 41. Login (step 1) First, generate an iSHARE JWT signed using the JSON Web Signature standard (JWS) > Headers { "alg": "RS256", "typ": "JWT", "x5c": [ // Complete certificate chain of the party "MIIEhjCC….Zy9w==", ... ] } > Payload { "jti": "99ab5bca41bb45b78d242a46f0157b7d", // Unique JWT ID "iss": "EU.EORI.NLMARKETPLA", "sub": "EU.EORI.NLMARKETPLA", "aud": "EU.EORI.NLHAPPYPETS", // ID (EORI) of the IDP to be accessed "iat": "1540827435", "nbf": "1540827435", "exp": "1540827435", // 30 seconds after iat "response_type": "code", "client_id": "EU.EORI.NLMARKETPLA", "scope": "openid iSHARE profile email", "redirect_uri": "https://www.marketplace.com/openid_connect1.0/return", "state": "af0ifjsldkj", "nonce": "c428224ca5a", "acr_values": "urn:http://eidas.europa.eu/LoA/NotNotified/high", "language": "en" }
  42. 42. Login (step 2) Make a POST request to the /authorize endpoint, so the target Identity Provider (in this case a Keyrock instance) can validate we are a trusted iSHARE party. The JWT generated in step 1 has to be provided in the request parameter. > Content-Type: application/x-www-form-urlencoded POST https://idp-pdc.i4trust.fiware.io/authorize response_type=code& client_id=EU.EORI.NLMARKETPLA& scope=iSHARE openid& request=eyJ0eXA…YkNKOQ Keyrock with validate the JWT and will contact the iSHARE Satellite to check that the client is a valid iSHARE participant. If everything goes well, a 204 status code will be returned along with a Location header.
  43. 43. Redirect user’s browser to the URL provided on the Location headers. This way, the user can provide his credentials and consent through the login page of Keyrock. If everything goes well, Keyrock will return an authorization code using the provided redirect URI. Login (step 3) < Location: https://marketplace.i4trust.fiware.io/openid_connect1.0/return? code=Dmn-TbSj7OcKl5ym1j5xZsgkabzVP8dMugC81nzmeW4& state=ZqVQm4zHaEDyBhzpm1ZRH7fsxy703lq2
  44. 44. A new request to the /token endpoint of the Identity Provider has to be made to retrieve the final access token. The signed JWT created in step 1 has to be provided in the client_assertion parameter of the request. The authorization code obtained in step 3 is provided within the code parameter. Login (step 4) > Content-Type: application/x-www-form-urlencoded POST https://idp-pdc.i4trust.fiware.io/token grant_type=authorization_code& client_id=EU.EORI.NLMARKETPLA& client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer& client_assertion=eyJ0eXA…YkNKOQ& redirect_uri=https://marketplace.i4trust.fiware.io/openid_connect1.0/return& code=Dmn-TbSj7OcKl5ym1j5xZsgkabzVP8dMugC81nzmeW4
  45. 45. Finally, Keyrock will provide an access token that can be used to access services. In addition, an iSHARE JWT compliant id_token is also returned which is associated with the authenticated session. Login (step 5) < Content-Type: application/json < Cache-Control: no-store < Pragma: no-cache { "id_token": "eyJhb...V2jA", "access_token": "aW2ys...LIOw", "expires_in": 3600, "token_type": "Bearer" } Decoded id_token parameter { "iss": "EU.EORI.NLPACKETDEL", "sub": "419404e1-07ce-4d80-9e8a-eca94vde0003de", "aud": "EU.EORI.NLMARKETPLA", "jti": "378a47c4-2822-4ca5-a49a-7e5a1cc7ea59", "iat": 1504683445, "exp": 1504683475, "auth_time": 1504683435, "nonce": "c428224ca5a", "acr": "urn:http://eidas.europa.eu/LoA/NotNotified/low", "azp": "EU.EORI.NLMARKETPLA", }
  46. 46. Further reading and useful links ■ Official Keyrock Documentation - https://fiware-idm.readthedocs.io/ ■ Tutorials and descriptions on how to setup the components within an i4Trust data space ■ https://github.com/i4Trust/tutorials/tree/main/Data-Service-Provider ■ Example Keyrock Theme - https://github.com/i4Trust/keyrock-theme-pdc ■ Helm Charts (kubernetes) to deploy i4Trust IAM components: ■ https://github.com/FIWARE/helm-charts/tree/i4trust ■ Passport strategy for authentication with FIWARE Keyrock using iShare JWT: ■ https://github.com/Ficodes/passport-i4trust ■ iSHARE framework covering all aspects - https://scheme.ishareworks.org ■ iSHARE developer portal - https://dev.ishareworks.org
  47. 47. i4Trust Website i4Trust Community i4Trust Marketplace Francisco de la Vega - CTO FICODES
  48. 48. Agenda ■ Introduction - The Business API Ecosystem GE ■ BAE Concepts ■ Catalog models ■ Ordering models ■ Usage models ■ Revenue Sharing models ■ i4Trust Marketplace ■ Integration with iShare ■ i4Trust plugin ■ Step by Step
  49. 49. Business API Ecosystem
  50. 50. Business API Ecosystem (1 of 6) ■ Supports the creation of digital marketplaces for the monetization of digital assets ■ Manages the lifecycle of products offers, from product creation to monetization, billing, payment and revenue sharing ■ Integrated with Identity Management and Data Usage Policy Management frameworks ■ Relying on TM Forum Business Ecosystem Open APIs
  51. 51. Business API Ecosystem (2 of 6) ■ Customizable ■ Branding and theming support ■ Multiple identity providers supported, including FIWARE Keyrock, Keycloak and GitHub
  52. 52. Business API Ecosystem (3 of 6) ■ Support for digital asset monetization, including (but not limited to) data ■ Even regarding data, multiple types: ■ Files ■ Right-time NGSI queries ■ Data streams ■ Media streams ■ ...
  53. 53. Business API Ecosystem (4 of 6) ■ Multiple Price models: ■ Open / Free ■ One time payments ■ Subscriptions ■ Pay-per-use ■ Advanced models: ■ Fees ■ Discounts ■ Dynamic pricing
  54. 54. Business API Ecosystem (5 of 6) ■ Support for usage terms and conditions and data-specific licenses ■ Support for specifying SLAs
  55. 55. Business API Ecosystem (6 of 6) ■ Support for revenue sharing models
  56. 56. BAE Concepts
  57. 57. Catalog Elements ■ Catalog Models taken from TMForum Catalog Management API v14.5 ■ Product classification ■ Category: Created by a system administrator, can be used by providers to categorize offers. Categories can be nested to create a tree ■ Catalog: Created by providers to group their own offers. All offers of the system need to be part of a Catalog.
  58. 58. Catalog Elements ■ Catalog Models taken from TMForum Catalog Management API v14.5 ■ Product creation ■ Asset: Real digital product registered in the system (the data, file, service, etc). ■ Product Specification: Definition of product-related information linked to the asset in the system. It incorporates asset link, product characteristics, and attachments. ■ Product Offering: Definition of the business-related information linked to the product. It includes link to the catalog, product specification, licence, SLAs, pricing models and revenue sharing models.
  59. 59. Ordering Elements ■ Ordering Models taken from TMForum Ordering and Inventory Management API v14.5 ■ Models: ■ Order: Defines the acquisition of a couple of product offering, including customer, billing profile, provider and acquired offerings, . ■ Product: Defines an acquired product. It includes, the chosen pricing model, the chosen characteristics, and the list of charges made by the customer
  60. 60. Usage Elements ■ Usage Models taken from TMForum Usage Management API v14.5 ■ Models: ■ Usage Specification: Defines the kind of usage information expected for a given product offering, including the units and metrics. ■ Usage Document: Includes an actual usage made of a product specification asset during a period of time. It includes also its associated price and whether it has been charged or not.
  61. 61. Revenue Sharing ■ Models: ■ Revenue Sharing Model: It establishes how the incomes generated by a set of offers has to be distributed among the different stakeholders involved. It includes, the platform percentage, the provider percentage and the stakeholders percentage. ■ Transaction: A payment made by a customers linked to a particular revenue sharing model. ■ Revenue Sharing Report: Result of applying the a revenue sharing model to its linked transactions. It include the amount to be paid to the different stakeholders.
  62. 62. i4Trust Marketplace
  63. 63. iSHARE Integration ■ i4Trust Marketplace is a global instance offered to all participant organization. ■ It supports multiple IDPs thanks to iShare protocol, so providers and customers can sign in using its own IDP. ■ Each data provider organization is owning its own IDP, API Umbrella and Context Broker ■ iShare JWT are used to authenticate the Marketplace in the different IDPs and retrieve user profiles.
  64. 64. iSHARE Integration
  65. 65. iSHARE Integration ■ The user selects its IDP in the list the Marketplace has in its system ■ Once the user selects its IDP, the Marketplace builds its iShare JWT and submits it to the IDP to authenticate itself.
  66. 66. iSHARE Integration ■ The selected IDP validates and decodes the Marketplace JWT. ■ the selected IDP build its own JWT and validates the Marketplace as a participant in the iShare Satellite.
  67. 67. iSHARE Integration ■ The IDP returns to the Marketplace the login endpoint ■ The Marketplace redirects user browser to the login endpoint so the user can authenticate itself in its own IDP. ■ Once the user is authenticated, OIDC is used to get a user access token and user profile in the Marketplace.
  68. 68. i4Trust plugin ■ A new asset plugin has been developed for registering data offered by a participant Context Broker. ■ It allows to provide metadata representing the policy that is going to be applied to customers. ■ Context Broker URL ■ Entity to be monetized ■ Attributes that can be GET ■ Attributes that can be POST ■ Attributes that can be PATCH ■ Attributes that can be DELETED ■ Duration of the policy
  69. 69. i4Trust plugin ■ When a new product is created: ■ Provided metadata is validated ■ Relevant info is attached as product characteristics ■ When the offering is acquired ■ The Marketplace builds an iShare JWT and authenticates itself using client_credentials grant to get an access token for data owner organization Authorization Registry. ■ The Marketplace creates a new policy (delegationEvidence) using the metadata of the product and the identity of the buyer organization. ■ The Marketplace submits the policy to the AR of the data owner using its access token.
  70. 70. Step by Step
  71. 71. Step by Step ■ Access to the Marketplace ■ The sign in option allows to select the IDP between the registered in the Marketplace. ■ Select your IDP and click on Sign in, you will be prompted to your IDP login page.
  72. 72. Step by Step ■ Access My Stock section ■ Create a new Catalog providing a name and a description. ■ Catalogs are created in Active state, to make the catalog available to customers its status needs to be changed to Launched.
  73. 73. Step by Step ■ Access to Product Specification section ■ Click on New to open Product Spec. Form ■ Fill basic product information including name and description. ■ In Asset section, select the kind of asset you are creating and fill the requested metadata. ■ In attachment section provide the image for the product and any optional attachment, such as documentation. ■ Product Specs. are created in Active state, to make them available change the state to Launched.
  74. 74. Step by Step ■ Access to Product Offerings section. ■ Click on new to open Product Offering form. ■ Fill basic offering information including the name and the description. ■ Select the catalog where the offering is going to be published and select the categories. ■ Provide licence, and SLAs ■ Provide pricing model and revenue sharing model. ■ Create the offering. Offerings are created in Active state, to make them available change the state to Launched.
  75. 75. Thank you! i4Trust has received funding from the European Union’s Horizon 2020 research and innovation programme under the Grant Agreement no 951975.

×