CRAC (!!!) (Centralized Retrieve Access Control)

1. CRAC (!!!)(Centralized Retrieve Access Control) Mauro Zanardini (consorzioArsenàl.IT) (mzanardini@consorzioarsenal.it)

2. 1) Obtain Retrieval Token • Patterns taken in consideration: • Request of Authorization COUPLED with a Query Request • Authorization Request into the SOAP header; • Authorization Request as a new BODY element; • Request of authorization (saml protocol with query parameters)  Response with Retrieval tokens, and a second transaction [ITI-18] for retrieving the whole set of metadata ([ITI-18] only if needed…); • No changes in [ITI-18] Request: the Registry response adds the Retrieval tokens (everytime… if the Consumer is able to understand how to use the token it should do it): • Retrieval Tokens within Body • Retrieval Tokens within SOAP Header • Add metadata specific for access control (one metadata for each documents returned in query Response). • No new transaction: the Registry creates authorization tokens related to a query Request, these tokens are stored by the Policy Manager that can be queried by the XDS document Repository for the Retrieving of Retrieval Tokens (WS-Trust);

3. 1) Coupled Request of Resource + Request of authorization • PROS: • One transaction to get Metadata and Retrieval Tokens • Explicit Request for authorization; • No integrations needed between PEP and PDP • … • CONS • Solution not appreciated by WS-Sec work-group. • Radical change of ITI-18 transaction • Could not work in a real implementation: the Client asks for two types of resources at the same time… this should be avoided • ….

4. 2) Ad-hoc SOAP Authz transaction • PROS: • Clean solution • New transaction that can be used for other type of Authz Requests (other resources that docs); • No changes needed for transaction already in place. • CONS • High Number of transactions • Change needed for the Consumer (authz transaction is totally new!) • The consumer should be able to manage multiple Assertions. (This is not granted for all Consumers…) • How the Document Consumer knows that it needs to provide Retrieval Token to the Repository… (this is common for all the first three patterns)

5. 3) Implicit Authz Request • PROS: • No changes needed for the Query Request • a) The XDS Doc Consumer should accept additional results for a Query (retrieval token) without errors (if they are conveyed within an additional SOAP header). • c) Adding a new metadata is a specific and clear solution for XDS actors (can be managed as an option) • CONS • a,b) Unexpected results for a standard [ITI-18] Request; • c) one token needed for each docs. High computational resources needed to sign multiple tokens (less clean solution: all docs in the same Response with the same token…)…

6. 4) No new Transaction • PROS: • This solution is the only one that does not require changes for the consumer • From the deploy point of view, this solution involves the upgrade of a low number of actors (Repositories and the Registry) • CONS • The Policy Manager is not stateless. • Consumer that makes frequent queries (polling for updates o for publication of docs) requires the creation of tons of tokens… • Integration between Reg and Rep should be more complex compared to other approaches

7. 2) Provide Retrieval Token a Provide Retrieval Token Retrieval Token Requester Retrieval Token Consumer • Transaction used to provide the Retrieval token to the Retrieval Token Consumer grouped with XDS Document Repository; • SAML 2.0 token conveyed within a Security header. • This transaction should describe only how to manage multiple Assertions in a Security Header. • This transaction should identify information needed by the Retrieval Token Consumer to Enforce the Policy Manager decision • This transaction should identify how to manage Exceptional Sitations(Retrieval Token not valid, Retrieval token Expired, Missing of information, … )  codified SOAP Faults ?

8. 2) Provide Retrieval Token a Provide Retrieval Token Retrieval Token Requester Retrieval Token Consumer PROS: • The Security token is full-consistent; • No additional integrations needed between PEP and PDP; • No changes needed for the XDS Doc Consumer for this transaction (same approach of XUA profile); • Business logic of the Retrieval token Consumer: just a token validation CONS: • High computational resources needed for Digital Signature of many tokens; • Requires a transaction for the request of authorization made by the XDS Document Consumer (the consumer obtains the token only using an explicit request…).

9. 2) Provide Retrieval Token b Retrieval Token Requester Retrieval Token Consumer [ITI-43] Retrieve Document Set-b • Without tokens conveyed by the XDS Document Consumer: the Retrieval token is stored by the Policy Manager, and the Retrieval Token Consumer asks for authorizations once receives a retrieve request; • The XDS document consumer is not affected by the supplement, the Enforcement is created by the WS-Trust relationship • The transaction profiled is the Query for authorization tokens made by the Retrieval Token consumer to the Policy Manager; Verify the existence of authorization tokens WS-Trust (???) Policy Manager

10. 2) Provide Retrieval Token b Retrieval Token Requester Retrieval Token Consumer [ITI-43] Retrieve Document Set-b PROS: • The Consumer is not affected by the profile; • A new transaction for the Token Request is not needed  for each query a decision is made (something that is already in place!!!), this decision should be formalized in a security token. This token is stored in the Policy Manager. Query Requests and Responses are unchanged. So NO changes needed for the XDS Doc Consumer; CONS: • Direct integration between Retrieval Token Consumer and Policy Manager; • Efficiency of the solution can be affected (MAYBE: we have a central collector of authoritazions that needs to store Security Tokens and make it available, and so on….) • Business logics of the Retrieval Token Consumer is more complex: it needs to performs queries to the Policy Manager based on specific parameters: user + resources Verify the existence of authorization tokens WS-Trust (???) Policy Manager