* Helper functions
* In set_user_alias_in_source(), force_change parameter to allow to set an
alias in a source already used by another user for the same source
- The authorisation decision function now support regex object and first
try to find an IBAC or RBAC permission. If not found try to find an ABAC
permission.
- The user inteface for ABAC permission creation propose the predicateRole
- Single point of entry to add a permission with a page explaining the
between RBAC and IBAC and inviting user to select a type or permission.
- Review of navigation elements
- New model for LDAP sources
- LDAP attributes are provided with the attribute signal
- Multiple sources supported
- Add of a new source with the Web interface
- User alias per source support added
- Define alias per user per source with the Web interface
- Accept that the aliases within a source are the User instances username
attributes (will be usefull when the authentication on LDAP will be added)
All attributes are stored in an object profile used at the treatement of
the ABAC permissions.
Some of these attributes may be used in more that a single single user
session.
Then, a profile is recorded for each user. At the beginning of the
permission checking, the profile is loaded or created.
If it is loaded, all outdated attributes are removed.
The function to load dictionnary of attributes handle the expiration
date if it is ISO 8601 formatted:
attr = {}
attr['name'] = 'certificate_type'
attr['namespace'] = 'ACS-ABAC'
attr['values'] = ('eID',)
attr['expiration_date'] = 2011-09-05T11:48:24
An ABAC permission can now only be set on a user or on anybody.
Axiom (unformal notation):
p_RBAC(role, Y, Z)
equiv.
p_ABAC(None, Y, Z, abac_rule: PredicateRole(role))
IBAC: p_ABAC(user, X, Y, no_rule)
RBAC: p_ABAC(None, Y, Z, abac_rule: PredicateRole(role))
ABAC: p_ABAC(None/user, Y, Z, abac_rule: what_you_want)
p_ABAC(user, Y, Z, rule: PredicateRole(role)) means that user may be
granted the access if it has the role.
1- A core function for decisions based on ABAC permissions.
2- Core functions to add and modify policy objects checking administration
rights
A core function for decisions based on ABAC permissions
-------------------------------------------------------
* Preface
1- Reminder on aliases
Requester is the user accessing ACS. The username is equal to the alias in
default.
Who is the subject of the request, it is described by the alias in a
policy.
Requester == who means that default_alias(requester) == default_alias(who)
2- difference between ABAC and RBAC permissions
An RBAC permission set with who is a role means that at the evaluation,
the access is granted if who is that role, a subject (a user or a role)
has that role (directly or by hierarchy)
With an ABAC rule, a request with a role as subject can never be granted,
but can only serve to obtain a new rule with that role has subject or
other permissions with roles as who included in that role
Note that an ABAC rule with who that is a role is strictly equivalent to
a rule on anybody with in the ABAC rule a PredicateRole at the root with
a AND statement with the rest of the logical expression.
Then an ABAC permission set with who is a role is not a way to authorize a
role (only possible with classic RABC rules) but a way to indicate that
they are candidate permissions for users that have that role.
In fact it is not very useful to ask if a role may have an access.
It does not make to say "does the role/function can access what/how?".
The right way to ask the question is "User lambda that eventually I don't
but who has the role/function X can access what/how?".
Then with ABAC rule we do not handle when the request is about a role.
It explains why we have removed the possibility to set an ABAC rule on a
role as who.
- When who is None/Anybody and the rule is only a predicate of having a
role, it is a classic RBAC permission.
- Idem with a rule on attributes, a classic ABAC rule.
- We can mix both. It is a way to give a logical expression on roles.
- Who is a user and no rule, classic IBAC rule.
- Who is a user and a rule, this user can have an access if the rule is
satisfied
* Requester != who
Requester != None
Who != None
A requester different from who request the policy to know if who can do
how on what.
The requester must be authorized in that policy for administration on who,
what and how.
RBAC permissions are checked. Then ABAC permissions are checked.
Attributes can be retreived from different sources. who has a default
alias that is the username that is mapped with the user identifiers wihtin
the different identity repositories (sources) configured.
A signal is send to make external functions provide attributes.
This is the preferred way the attributes should be provided from sources.
An option allows to say to not send this signal
no_attribute_signal = True, at False by default.
Attributes can also be given in parameters of the functions.
A validity period may be provided per attribute or per source. When it is
the case, these attributes are cached to be reused in other session.
These are stored is a special source called cached_attributes.
This function always tries to load attributes from this source.
Attributes are provided with dictionnaries as follows:
data = []
attr = {}
attr['name'] = 'certificate_type'
attr['namespace'] = 'ACS-ABAC'
attr['values'] = ('eID',)
data.append(attr)
attr = {}
attr['name'] = \
'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth'
attr['namespace'] = \
'http://schemas.xmlsoap.org/ws/2005/05/identity/claims'
attr['values'] = ('22', )
data.append(attr)
dic = {}
dic[source_name] = data
*All attributes are loaded in an object profile used for the evaluation.*
If the access is granted, the function return un tuple containing 'True',
the permission that allowed the positive answer and error code at 0.
If the access is denied, the function return un tuple containing 'False',
the ABAC rule necessary to grant the access and error code at 0.
Obtaining a new ABAC rule can only be done with ABAC permissions.
The rule returned can be build from any ABAC permission that is on what to
do how.
The process of building a new rule is ressource consuming, this process
can be desactivated with the option no_rule_returned = True, at False by
default.
If who is a role. If there is a matching RBAC rule, the decision is True.
If there is an ABAC rule set on anybody with a unique predicate role on
that role, the decission is True.
Else a new rule is returned made of permissions set on anybody.
* Requester != who
Requester == None
Who != None
Unauthorized access to request the policy on somebody is not authorized.
This request is rejected with an error code
* Requester != who
Requester != None
Who == None
This is supported to only to make a requester authorized for
administration on what and how to obtain a rule that anybody may satisfy
to do how on what.
This is not compatible with no_rule_returned = True
* Requester == who != None
This mode means that the user is currently using an application coupled
with ACS. This application and ACS share the user session.
Checking administration rights does not have sense here.
Except this, this functions the same way as the first case.
However, attributes are also check in the session:
request.session['attributes']
An option allows to say to not check attributes in the session
no_session_attributes = True, at False by default.
This mode also always try to load attributes from the cached_attributes
source
The rule returned can only contain predicates of ABAC rules set on
anybody or on who or on a role that who has.
Differently from when requester != who and the requester is checked for
administration, new rule can not be set from any ABAC permission matching
what and how. Indeed, since the administration rights are not check, the
access to the policy is given on ABAC permissions that have as subject
anybody, the requester or a role that the requester has.
* Requester == who == None
This mode means that the user is currently using an application coupled
with ACS. This application and ACS share the user session.
Checking administration rights does not have sense here neither.
The requester/subject being 'anonymous', identity attributes can't be
retreived from sources.
Contextual attributes (time for instance) but it is not supported yet.
Signals may be used for contextual attributes.
Attributes in parameters and in the session can be used.
Example of scenario:
- The user is redirected on an IdP proxy with an access request from a SP.
- The user is not able to authenticate against the proxy.
- The proxy asks the policy in that mode with no attributes, a new rule from
permissions set on anybody are returned.
- The attributes can only come from external sources and be brought by
the user, i.e. certificates.
- The proxy make the user provide certificates to from the ABAC rule.
- Then the proxy parse the certificates and builds a dictionnary. The proxy
may also try to authenticate the user from certificates. if yes,
previously provided certificates may be loaded from cached_attributes.
- Either the dictionnary is put in the session, or given in parameter of
this function.
- The policy is requested.
- If the access is not granted, a new rule is returned.
- If the access is granted, before responding to the SP, the proxy may
create an account giving authentication credentials to the user or using
one of the certificates as an authentication credential.
- Then the proxy associates the living-more-than-a-session certified
attributes to this profile. The proxy is in charge to add by itself add
attributes in the cached_attributes source.
- Next time, the user will be able to authenticate and benefit from the
cached_attributes source
Mikaël Ates