How it works
iAccess is a policy-driven authorization service, that is, based on security policies behind governing its behavior. The main advantage of the policy-driven authorization is the fact that once the security policies are well-designed they completely automate the behavior of an iAccess agent when interacting with other (iAccess) agents, i.e. protected resources and sensitive credentials will be given access only to authorized agents.
iAccess policies are programmable, i.e. an access control specification can be encoded (programmed) in different ways depending on the specific goals a policy designer has. Thus, the behavior of a negotiation agent may vary even run on a same access control specification.
However, well-designed security policies is a nontrivial task, and that's why we want to take you over a few points of how iAccess enforces security policies.
Point 1: iAccess is governed by the three security policies:
- Access Policy (Pa) protects resources which iAccess is responsible for. Pa states what resources are protected and under what foreign credential requirements. When an agent wants to use a protected resource of another agent, it has to present the required credential set to be authorized for that resource.
- Credential Policy (Pc) protects agent's own credentials from undesired disclosure. Agent's own credentials (credentials installed in the agent) are necessary
for the agent to authorize itself to other agents. In some sense, agent's own credentials become protected "resources" and access to them is given analogously to the access policy.
- Disclosure Policy (Pd) controls what foreign credentials are disclosable and under what conditions. Pd complements Pa and Pc by controlling how/when foreign credentials are "visible" to be requested to an opponent. Thus, credentials considered by Pd should be at least those occurring in Pa and Pc.
We note that Pd in a combination with Pa and Pc plays an essential role of defining the behavior of an agent during a negotiation process.
Point 2: iAccess policies are logic programs. A logic program is a set of rules of the form:
A :- B1,..., Bn, not C1,..., not Cm. (1)
:- B1,..., Bn, not C1,..., not Cm. (2)
Where A, B to Bn are positive literals and not C1 to not Cm are negative literals (negation-as-failure). iAccess uses DLV system as a back-end engine for logic computations on the three security policies. We refer to the DLV language syntax for more information.
Rules of form (1) define conditions under which a literal A is entailed in a model of a logic program, i.e. if all B1 to Bn are true and all of C1 to Cm are false then A is true in a model. While rules of form (2) define constraints that rule out from a set of acceptable models situations where all B1 to Bn are true and all of C1 to Cm are false.
A typical example of usage of constraints is to express the principle of separation of duties in RBAC models, or in a more general case limiting escalation of privileges. iAccess enforces only static separation of privileges, i.e, those that hold regardless of session information.
iAccess restricts the use of constraints (2) to only positive literals occurring in a constraint rule body, i.e. no negation-as-failure.
Generally, we do not recommend the use of negation-as-failure in security policies. However, in case negation-as-failure is really necessary to express certain policy requirements (allowed only in Rules of type 1) please ensure that the respective policy is a stratified logic program (i.e., avoid non-stratified negation).
Point 6: Security policies enforcement.
First, we will show how iAccess enforces (negotiates based on) the three security policies. The figure below shows a simple example of a sequence of steps two iAccess agents perform based on the security policies.
On Bob's side there is a resource with two credential requirements in the access policy and an own credential protected by a foreign credential in the credential policy. All necessary credentials are disclosed by the disclosure policy. On Alice's side there are three own credentials in the credential policy, two of them granted on demand and one of them protected with a foreign credential. Alice's disclosure policy discloses all necessary foreign credentials.
Next figure shows that if there are two solutions for a resource the iAccess agents will negotiate on the right solution. The minimality criterion chosen for this scenario is the minimal cardinality. Thus, on a service request R1 Bob's agent starts with {CA1,CA2} set. The disclosure policy on Bob's side discloses CA1, CA2 and CA5 on demand, but CA3 is disclosed if CA1 has been presented to the agent and, analogously, CA4 is disclosed if CA3 has been given. The whole interaction process one can follow on the figure.
Point 3: Expressing credential information in security policies.
iAccess divides digital certificates in identity certificates and attribute certificates. Identity certificates are represented as a predicate of arity two, e.g., id(subject_id,issuer_id), and attribute certificate with a predicate of arity three, e.g., cred(holder_id,attribute_id,issuer_id).
iAccess works with X.509 certificates. It has a local storage of public key certificates of trusted certification authorities (CAs) for issuing identity certificates and a local storage of public key certificates of trusted source of authorities (SOAs) for issuing attribute certificates. X.509 identity (public-key) certificates are verified against trusted CAs in order to be accepted as facts for logic reasoning, respectively, X.509 attribute certificates are verified against trusted SOAs to be accepted as facts for the underlying reasoning.
Once a X.509 certificate is successfully verified against trusted authorities, iAccess transforms it to a logic predicate of the respective arity. iAccess first extracts the X.500 structure of the Subject or Holder fields and then extracts the common name (CN) to be used in the logical predicate. iAccess extracts the X.500 name of the Issuer field and first checks if a CN field exists to obtain an issuer identifier, if it does not exist, iAccess takes an Organization (O) field as an issuer identifier and uses it for a predicate generation. iAccess extracts the Attribute field from an X.509 attribute certificate and treats it as a string value, i.e. without analyzing it for a specific structure.
We explicitly acknowledge that such a logic certificate representation is not expressive enough, and next iAccess release will provide better handling of certificate expressiveness on a logic level.
Since logic level syntax used by DLV does not allow special characters as part of a logic program specification, iAccess performs a character replacement on the subject, holder, issuer and attribute identifiers (as extracted from a certificate) to obtain an acceptable logic representation. The table below summarizes the replacement done.
| "s+" (reg.expr.) |
"-" |
"\" |
"/" |
"@" |
"." |
"," |
"?" |
"!" |
"\"" (doub.quote) |
"\'" (sing.quote) |
"=" |
"%" |
"$" |
| "_" |
"_" |
"_" |
"_" |
"_" |
"" |
"" |
"" |
"" |
"" |
"" |
"" |
"" |
"" |
The same replacement process is also applied on a service request (service name and action).
Example: if we have an X.509 attribute certificate with the following fields:
- Holder ::= "CN=Alice Milburk, OU=Computer Science Department, O=University of Trento, C=IT"
- Attribute ::= "Ph.D. Student"
- Issuer ::= "CN=University of Trento CA-1, O=University of Trento, C=IT"
the resulting predicate would be cred(alice_milburk,phd_student,university_of_trento_ca_1) given that University of Trento is a trusted SOA.
Point 4: Time-aware security policies. iAccess security policies can use two time specific predicates:
-
TNOW(dow, mon, dd, hh, mm, ss, zzz, yyyy) indicates current system time and date. It has the Java Date().toString() format where: -
dow is the day of the week: sun, mon, tue, wed, thu, fri, sat. -
mon is the month: jan, feb, mar, apr, may, jun, jul, aug, sep, oct, nov, dec. -
dd is the day of the month: 01 through 31 , as two decimal digits. -
hh is the hour of the day: 00 through 23 , as two decimal digits. -
mm is the minute within the hour: 00 through 59 , as two decimal digits. -
ss is the second within the minute: 00 through 61 , as two decimal digits. -
zzz is the time zone (and may reflect daylight saving time). Standard time zone abbreviations include those recognized by the method parse. If time zone information is not available, then zzz is empty - that is, it consists of no characters at all. IN IACCESS CASE ::= TNOW(dow, mon, dd, hh, mm, ss, yyyy). One needs to test what is the right format tuple for its time zone settings. -
yyyy is the year, as four decimal digits.
TNNOW(ms) indicates a current negotiation time. The negotiation time is measured either since a service request was submitted or since a service request was received. The value ms denotes the milliseconds passed since one of the two events above occurred. Use the predicate with cautious as a negotiation time is a function of many variables, such as network traffic, current CPU load, number of active negotiations at a time, etc.
The two predicates are dynamically generated (as facts) every time a logic reasoning operation is taken over to DLV. iAccess takes the current system time at the "closest" possible point in the code before a logic reasoning takes place and, as such, the time predicates have an accuracy modulo the time necessary for the OS to run the DLV solver. However, this time remains within several milliseconds but the exact time frame is hard to state as it depends on the specific hardware configuration one has.
Point 5: Policy requirements. iAccess is based on the assumption that agents have no knowledge on security requirements of other agents. In this regard, it is important to define the minimum requirements guaranteeing that whenever possible two agents will successfully negotiate upon a resource. These requirements are to be defined independently of agent's knowledge about other agents. We refer to the article in [1] for definitions and detailed analysis of the properties stated below.
- Access Control Policy (Pa) is to be a well-behaved policy (a subset of nonmonotonic policies) and to guarantee a fair access property. Note that in this requirement we exclude the use of negation-as-failure in Pa, i.e. we assume that there is a unique stable model of Pa. If one wants to use negation-as-failure he/she has to additionally guarantee that Pa is a stratified logic program (refer to Point 2).
Some tips for specifying an access policy:
- Use rules and constraints to define a specification of access control requirements.
- Use the time predicates in rules/constraints bodies to express time dependent requirements.
- Heads of rules in access policy must not be a credential attribute term or a credential identity term.
- Use the predicate
grant(resource_id,action_id) to specify that an action action_id is granted to be performed on a resource resource_id. Use the predicate in a head of a rule in the access policy to define when a service is granted.
- Credential Control Policy (Pc) is equivalently treated as Pa but for credential resources. Thus, Pc inherits the requirements for Pa, i.e. a well-behaved policy with a fair access property.
Some tips for specifying a credential policy:
- Use rules and constraints to define a specification of access control requirements to own credentials.
- Use the time predicates in rules/constraints bodies to express time dependent requirements.
- Use the predicate for granting service requests to express access requirements relevant to a service request.
- To specify that an attribute or identity credential is granted under some constraints there must be a rule in the policy having either
id(subject_id,issuer_id) or cred(holder_id,attribute_id,issuer_id) predicate in the head.
- All granting rules in a credential policy must have in their heads credential terms referring to agent's own credentials.
- Disclosure Control Policy (Pd) is to be a monotonic policy and to guarantee a fair interaction property with respect to Pa and Pc.
Some tips for specifying a disclosure policy:
- Use rules to express disclosure control requirements.
- The disclosure control policy has the following implicit semantics of rules:
ask(cred_1) :- has(cred_2),...,has(cred_n).
where cred_1 to cred_n are either a credential attribute predicate or a credential identity predicate.
- Any credential term appearing in a head of a rule in a disclosure policy must refer to a foreign credential requirement.
- Use the time predicates in rules' bodies to express time dependent disclosure requirements.
- Use the predicate for granting service requests (
grant(resource_id,action_id)) in rules' body to define disclosure requirements specific per a service request. In this way, one can define generic disclosure requirements applicable to any service request as well as specific ones applicable for a given service request.
- We do not recommend the use of constraints and negation-as-failure for disclosure control. However, if one wants to experiment with those he/she has to ensure that Pd is a stratified logic program.
Note: The above requirements guarantee that two agents will successfully negotiate upon a resource given that no deadlocks (interlocks) occur between agents' requirements. iAccess does not detect if credential requirements interlock a negotiation process or if a negotiation process takes too long. It simply awaits and denies a request when a session time expires.
Point 7: Example of security policies (McKinley Clinic [p. 4, Yu&Winslett'03]).
[Access Scenario] McKinley clinic makes its patient records available for online access. Let record_amilburk be Alice's record. To gain read access to record_amilburk a requester must either present Alice's patient ID for McKinley clinic (id(alice_milburk,mckinley_clinic_ca)), or present a California social worker license (cred(Holder,social_worker,california_state_soa)), and a release-of-information credential issued to the requester by Alice (cred(Holder,medic_record_release,alice_milburk)).
[Disclosure Scenario] Knowing that Alice's recordspecifically allows access by social workers will helppeople infer that Alice may have a mental or emotionalproblem. Alice wants to keep the latter constraint inaccessible to strangers. However, employees of McKinley clinic (cred(Holder,employee,mckinley_clinic_soa)) should be allowed to see the contents of this policy.
Designing policies: step 1
The access and disclosure policies of the clinic are shown below.
| Pa: |
grant(record_amilburk,read) :- id(alice_milburk,mckinley_clinic_ca).
grant(record_amilburk,read) :- cred(Holder,social_worker,california_state_soa),
cred(Holder,medic_record_release,alice_milburk).
|
| Pd: |
cred(Holder,medic_record_release,alice_milburk) :- cred(Holder,employee,mckinley_clinic_soa).
cred(Holder,social_worker,california_state_soa) :- cred(Holder,employee,mckinley_clinic_soa).
|
In the example we will use an abbreviation for a certification authority (CA) responsible for certifying identity information, and an abbreviation for a source of authority (SOA) responsible for certifying attribute statements (privileges). We follow the notations of PKI/PMI models.
The access policy, Pa, states that read access to Alice's record is given to Alice or to a holder of the certificates for a social worker and a release of information by Alice. We assume that McKinley clinic has the public-key certificate of a trusted CA for identifying entities in California state and that the clinic knows its patients' public-key certificates so that release of information statements are directly certifiable by the patients (Alice in our case).
The disclosure policy, Pd, states that the need for a release of information credential by Alice and a social worker credential stated by a California state SOA are disclosable to entities that have presented their employee certificate issued by the McKinley clinic's SOA. Note that the variable Holder in Pd rules will require the identity of the disclosed certificates to be the same of the presented employee certificate.
Designing policies: step 2
Now, let's enhance the two policies by taking into account that two iAccess agents establish mutual authentication (SSL channel) and an identity token is already bootstrapped from that.
| Pa: |
grant(record_amilburk,read) :- id(alice_milburk,mckinley_clinic_ca).
grant(record_amilburk,read) :- cred(Holder,social_worker,california_state_soa),
cred(Holder,medic_record_release,alice_milburk).
|
| Pd: |
cred(Subject,medic_record_release,alice_milburk) :- id(Subject,california_state_ca).
cred(Subject,social_worker,california_state_soa) :- id(Subject,california_state_ca).
cred(Subject,employee,mckinley_clinic_soa) :- id(Subject,mckinley_clinic_ca).
cred(Holder,medic_record_release,alice_milburk) :- cred(Holder,employee,mckinley_clinic_soa).
cred(Holder,social_worker,california_state_soa) :- cred(Holder,employee,mckinley_clinic_soa).
|
The first two rules of Pd disclose the need for a medic record release and a social worker credentials but bound to the subject name of the entity being on the other side of the channel. Similarly, the third rule discloses the need for an employee credential bound to the subject name of the entity identified on the channel. The issuers of the two identity tokens are different thus defining two different disclosure (negotiation) scenarios.
With the new Pd an iAccess agent will interact with entities identified by McKinley clinic CA for an employee certificate and, after a successful negotiation on the employee certificate, the agent will disclose the need for the other two certificates. In this way McKinley clinic employees are allowed to see the requirements for accessing Alice's medical record.
However, as of now all entities signed by California State CA will see the need of the two certificates and may infer that Alice have mental problems, which is not exactly the original intention of the example. One can remove the first two rules of Pd thus requiring an opponent to push the two certificates in order to get access. This approach assumes that an opponent's agent has a priori knowledge of what credentials to push for what resources. In autonomic communications entities may not be aware of potential resources and requirements necessary for those resources.
Designing policies: step 3
We will modify the two policies to capture the intention of the example scenario and will introduce the use of TNOW predicate.
| Pa: |
grant(record_amilburk,read) :- id(alice_milburk,mckinley_clinic_ca).
grant(record_amilburk,read) :- cred(Holder,social_worker,california_state_soa),
cred(Holder,medic_record_release,alice_milburk).
|
| Pd: |
cred(Subject,medic_record_release,alice_milburk) :- id(Subject,california_state_ca),
TNOW(D,_, _,H,_,_,_,2009),D!=sat,D!=sun,H>=08,H<18.
cred(Subject,social_worker,california_state_soa) :- cred(Subject,medic_record_release,alice_milburk),
TNOW(D,_, _,H,_,_,_,2009),D!=sat,D!=sun,H>=08,H<18.
cred(Subject,employee,mckinley_clinic_soa) :- id(Subject,mckinley_clinic_ca).
cred(Holder,medic_record_release,alice_milburk) :- cred(Holder,employee,mckinley_clinic_soa).
cred(Holder,social_worker,california_state_soa) :- cred(Holder,employee,mckinley_clinic_soa).
|
We have changed the enforcement requirements to first ask for a release of information credential and then ask for a California social worker credential. In this case only entities evidenced by Alice will know for the need of a social worker credential to access Alice's record. Additionally, we restricted the disclosure information within the working hours 08:00 - 18:00h from Monday to Friday only for social workers entities. As we can see, the time restriction does not apply for McKinley employees.
Since iAccess does not allow for pushing of credentials, one would ask why not to time restrict only the first rule of the disclosure policy. In this way, a negotiation starts if it is within the working days and hours. We want to force the disclosure of the whole solution set to be within the specified time limit and not only to when a negotiation starts. In this way, if a request arrives at 17:59h it will be denied if the release of information credential is presented at 18:00h or later.
One can achieve same policy specification by moving the time restrictions from the disclosure policy to the access policy. However, the difference in the latter case is that service access is denied beyond the working hours, while in the former case we forbid the disclosure information which as a side effect denies access. iAccess has an option to keep client's set of active credentials until they expire or the agent is restarted. If an entity, with active credentials in the system, submits a request for a resource beyond the working hours, the same will be granted access in the former case (if enough access rights), while in the latter case it will be denied access.
Designing policies: step 4
Let's include the access requirements for another patient's record of Linda Stoun.
| Pa: |
grant(record_amilburk,read) :- id(alice_milburk,mckinley_clinic_ca).
grant(record_amilburk,read) :- cred(Holder,social_worker,california_state_soa),
cred(Holder,medic_record_release,alice_milburk).
grant(record_lstoun,read) :- id(linda_stoun,mckinley_clinic_ca).
grant(record_lstoun,read) :- cred(Holder,social_worker,california_state_soa),
cred(Holder,medic_record_release,linda_stoun).
|
| Pd: |
cred(Subj,medic_record_release,alice_milburk) :- grant(record_amilburk,read),id(Subj,california_state_ca),
TNOW(D,_, _,H,_,_,_,2009),D!=sat,D!=sun,H>=08,H<18.
cred(Subj,medic_record_release,linda_stoun) :- grant(record_lstoun,read),id(Subj,california_state_ca),
TNOW(D,_, _,H,_,_,_,2009),D!=sat,D!=sun,H>=08,H<18.
cred(Subj,social_worker,california_state_soa) :- cred(Subj,medic_record_release, _ ),
TNOW(D,_, _,H,_,_,_,2009),D!=sat,D!=sun,H>=08,H<18.
cred(Subj,employee,mckinley_clinic_soa) :- id(Subj,mckinley_clinic_ca).
cred(Holder,medic_record_release,alice_milburk) :- grant(record_ amilburk,read),
cred(Holder,employee,mckinley_clinic_soa).
cred(Holder,medic_record_release,linda_stoun) :- grant(record_lstoun,read),
cred(Holder,employee,mckinley_clinic_soa).
cred(Holder,social_worker,california_state_soa) :- cred(Holder,employee,mckinley_clinic_soa).
|
We used the fact that a disclosure policy is a resource aware, i.e. iAccess dynamically adds a service request as a fact in the policy. Thus, the first two rules of the disclosure policy entail the need for a release of information credential by Alice or Linda depending on the exact request. Analogously, we have defined the fifth and the sixth rules. The third rule entails the need for a social worker credential regardless of the service request. In this way, some rules disclose information on a general level while others per request level.
Designing policies: step 5
Now, let's define the credential policy, Pc, of the McKinley clinic.
| Pa: |
|
|
grant(record_amilburk,read) |
:- |
id(alice_milburk,mckinley_clinic_ca). |
grant(record_amilburk,read) |
:- |
cred(Holder,social_worker,california_state_soa), |
| |
|
cred(Holder,medic_record_release,alice_milburk). |
grant(record_lstoun,read) |
:- |
id(linda_stoun,mckinley_clinic_ca). |
grant(record_lstoun,read) |
:- |
cred(Holder,social_worker,california_state_soa), |
| |
|
cred(Holder,medic_record_release,linda_stoun). |
| Pd: |
|
|
cred(Subj,medic_record_release,alice_milburk) |
:- |
grant(record_amilburk,read),id(Subj,california_state_ca), |
| |
|
TNOW(D,_, _,H,_,_,_,2009),D!=sat,D!=sun,H>=08,H<18. |
cred(Subj,medic_record_release,linda_stoun) |
:- |
grant(record_lstoun,read),id(Subj,california_state_ca), |
| |
|
TNOW(D,_, _,H,_,_,_,2009),D!=sat,D!=sun,H>=08,H<18. |
cred(Subj,social_worker,california_state_soa) |
:- |
cred(Subj,medic_record_release, _ ), |
| |
|
TNOW(D,_, _,H,_,_,_,2009),D!=sat,D!=sun,H>=08,H<18. |
cred(Subj,employee,mckinley_clinic_soa) |
:- |
id(Subj,mckinley_clinic_ca). |
cred(Holder,medic_record_release,alice_milburk) |
:- |
grant(record_amilburk,read), |
| |
|
cred(Holder,employee,mckinley_clinic_soa). |
cred(Holder,medic_record_release,linda_stoun) |
:- |
grant(record_lstoun,read), |
| |
|
cred(Holder,employee,mckinley_clinic_soa). |
cred(Holder,social_worker,california_state_soa) |
:- |
cred(Holder,employee,mckinley_clinic_soa). |
| Pc: |
|
|
id(mckinley_clinic_ca,trusted_ltd_ca). |
|
|
id(mckinley_clinic_soa,trusted_ltd_ca). |
|
|
cred(mckinley_clinic,legal_clinic,gov_health_dept_soa) |
:- |
id(_,mckinley_clinic_ca). |
cred(mckinley_clinic,legal_clinic,gov_health_dept_soa) |
:- |
id(_,california_state_ca),grant(record_amilburk,read). |
cred(mckinley_clinic,legal_clinic,gov_health_dept_soa) |
:- |
id(_,california_state_ca),grant(record_lstoun,read). |
The first two rules of Pc grant access to McKinley clinic CA' and SOA's public-key certificates (signed by Trusted Ltd. CA) on demand. The third rule grants access to the clinic's own certificate of a legal US clinic to entities identified by McKinley's CA. While, the last two rules grant access to McKinley's legal clinic credential to entities certified by California state CA which have explicitly requested read access to either Alice's or Linda's medical records. We have used the fact that Pc is a resource aware policy, as is the case of Pd.
Designing policies: step 6
We have generated the following public key infrastructure for the example.
iAccess installation package comes with already installed X.509 certificates representing the relations in the figure. iAccess agent of McKinley clinic has been installed with the following trusted authorities:
- Trusted CAs:
- California State CA self-signed public-key certificate,
- McKinley Clinic CA public-key certificate signed by Trusted Ltd CA.
- Trusted SOAs:
- California State SOA self-signed public-key certificate,
- McKinley Clinic SOA public-key certificate signed by Trusted Ltd CA,
- Alice Milburk public-key certificate signed by McKinley Clinic CA,
- Linda Stoun public-key certificate signed by McKinley Clinic CA.
An iAccess agent on a client side is configured with the following trusted authorities:
- Trusted CAs:
- California State CA self-signed public-key certificate,
- Trusted Ltd CA self-signed public-key certificate.
- Trusted SOAs:
- California State SOA self-signed public-key certificate,
- Gov. Health Dept. SOA self-signed public-key certificate.
We note that trusted CAs/SOAs in the context of an iAccess agent mean that X.509 identity certificates are accepted
only if signed by any of the trusted CAs and X.509 attribute certificates are accepted only if signed by any of the trusted
SOAs. But, the decision if a trusted CA or SOA is trusted to issue certain identities/attributes is subject to the security policies specification.
For example, the case of Alice and Linda defined as trusted SOAs is to allow an iAccess agent to verify the authenticity of a certificate, but the decision
if Alice and Linda are trusted to issue specific attribute statements is encoded in the security policies (in our case only the attribute statement of medical record release).
Designing policies: step 7
Client side security policies.
| Pa: |
|
|
| |
|
|
| Pd: |
|
|
cred(mckinley_clinic_ca,legal_clinic,gov_health_dept_soa) |
:- |
id(mckinley_clinic_ca,trusted_ltd_ca). |
| Pc: |
|
|
id(john_couk,california_state_ca). |
|
|
cred(john_couk,social_worker,california_state_soa) |
:- |
id(_, trusted_ltd_ca). |
cred(john_couk,medic_record_release,alice_milburk) |
:- |
id(mckinley_clinic_ca,trusted_ltd_ca), |
| |
|
cred(mckinley_clinic_ca,legal_clinic,gov_health_dept_soa). |
cred(john_couk,medic_record_release,linda_stoun) |
:- |
id(mckinley_clinic_ca,trusted_ltd_ca), |
| |
|
cred(mckinley_clinic_ca,legal_clinic,gov_health_dept_soa). |
id(john_couk,mckinley_clinic_ca). |
|
|
cred(john_couk,employee,mckinley_clinic_soa) |
:- |
id(_, trusted_ltd_ca). |
The access policy is empty since in the example scenario a client has no resources to provide. Pd discloses the need for a legal clinic credential to McKinley entities certified by the Trusted Ltd CA. Pc grants access to John Couk's public key certificates, signed by the California state CA and McKinley clinic CA, on demand. Access to social worker credential and McKinley employee credentials are granted to entities certified by Trusted Ltd CA. While access to release of information credentials certified by Alice and Linda, respectively, is granted to McKinley entities (iAccess agents running on behalf of McKinley CA) certified by the Trusted Ltd CA which have also a credential attesting that they are running on behalf of a legal US clinic (certified by the respective governmental authority).
Example Scenarios:
iAccess agent package of a client comes with four different identities installed. They are all located in IACCESS_ROOT/data/ssl directory.
Before to run an iAccess agent one can choose what identity to use for SSL connections establishment. The default identity is of John Couk signed by the California State CA. To specify a new identity one has to change the field SSLkeystore of the IACCESS_ROOT/config.xml file to point to a new identity.
The two negotiation scenarios of interest are with John Couk identity signed by California State CA and John Couk identity signed by the McKinley Clinic CA.
Point 8: Minimality criterion
If there are more than one credential sets solutions for a service request iAccess chooses one of them. The choice is limited to either minimal cardinality or to minimal sensitivity. If we have two credential sets {attr1,attr2, id1} and {attr3,attr4} then the minimal set cardinality will filter out {attr1,attr2, id1} and will choose {attr3,attr4}. If we assign a sensitivity level to attributes, say, attr1--4, attr2--1, attr3--3, attr4--3, and specify as minimality criterion minimal sensitivity then iAccess will select the set {attr1,attr2, id1}. iAccess sums the sensitivity levels of all attributes in a solution set and compares any two solutions to select the less sensitive one. In our case iAccess compares {4+1=5} and {3+3=6}, and selects the first one. We do not implement sensitivity level for identity information.
The sensitivity level has the meaning of "how expensive" an attribute is to be disclosed/negotiated upon. iAccess tries to find the least expensive set (among all applicable) by counting how expensive each set is.
There are two options for minimality selection:
- Minimal sensitivity over minimal cardinality (represented by MinimalityCriterion::=OFF)
- iAccess compares any two sets and takes the one with lower cardinality. If same cardinality of the two sets then it filters the one with less sensitivity level. If two sets have same cardinality and sensitivity levels iAccess picks the first one.
- Minimal cardinality over minimal sensitivity (represented by MinimalityCriterion::=ON)
- iAccess compares any two solution sets by taking the one with less sensitive level. If equally sensitive, for example {4,2,1} and {7}, it takes the one with lower cardinality. We note that identity information in a solution set has no sensitivity level and counts only for cardinality filtering. If equally sensitive and same cardinality iAccess picks the first set.
Minimality criterion can be used as an implicit (strategy) decision on what solution order to be asked to an opponent.
If sensitivity level makes no sense to you or the way it is computed is not applicable to your requirements then one can set up zero '0' level to all attributes and with MinimalityCriterion::=OFF mode iAccess will filter only the minimal cardinality sets and will pick one of the least minimal sets.
|
)
) 
)