Identity Management and Access Control

and Access Control Marek Rychly mrychly@strathmore.edu Strathmore University, @ilabafrica & Brno University of Technology, Faculty of Information Technology Enterprise Security 7 December 2015 Marek Rychly Identity Management and Access Control ES, 7 December 2015 1 / 32

Outline 1 Identity Management Digital Identity Single Sign-On (SSO) and Trust&Federation Identity Management in Databases 2 Access Control and Access Control Models Access Control in Databases Marek Rychly Identity Management and Access Control ES, 7 December 2015 2 / 32

Digital Identity Identity Management Digital Identity Single Sign-On (SSO) and Trust&Federation Identity Management in Databases Identifier information that uniquely identifies the subject of a particular identity within a given context (e.g., a login, email address, Globally Unique Identifier/GUID, X500 name, etc.) Credentials data used to prove authenticity of an identity claim (e.g., a password, token, private key of X509 public key certificate, etc) Core Attribute data that help describe the identity globally, across all contexts where the identity can be used (e.g., a user first and last names, address, email, phone number, etc.) Context-specific Attributes data that help describe the identity in a specific context where the identity is used (e.g., a home directory in an operating system, a user database in a DBMS, etc.) Marek Rychly Identity Management and Access Control ES, 7 December 2015 4 / 32

Digital Identity Life-cycle Digital Identity Single Sign-On (SSO) and Trust&Federation Identity Management in Databases (adopted from Identity and Access Management (IAM) Market worth $ 18.30 BN by 2019 ) Marek Rychly Identity Management and Access Control ES, 7 December 2015 5 / 32

Identity Management Digital Identity Single Sign-On (SSO) and Trust&Federation Identity Management in Databases business processes and a supporting infrastructure for the creation, maintenance, and use of digital identities comprised of three indispensable elements: policies are constraints, standards, and guidelines to follow (in order to comply with regulations and business best practices) processes are sequences of actions to complete business functions technologies are automated tools that help accomplish business goals (more efficiently and accurately while meeting the policies) controls end-to-end life-cycles of managed digital identities utilizes directory services and is utilized by access management (identity management for authentications, access management for authorization) Marek Rychly Identity Management and Access Control ES, 7 December 2015 6 / 32

Single Sign-On (SSO) Digital Identity Single Sign-On (SSO) and Trust&Federation Identity Management in Databases the ability to login just once and gain access to multiple systems by Web Single Sign-On (Web SSO) 1 a user access protected resource that require authentication (e.g., a web page, database, enterprise information system, etc.) 2 to authenticate, the user is directed to a SSO server (HTTP redirection in a web environment, or by other means) 3 the user authenticate itself by interaction with the SSO server (by credentials, i.e., by password, etc.; the SSO server is trusted by the user) 4 the SSO server redirect the user back to the resources and let it know that the user is authenticated and of a particular identity by Operations System Sign-On (OS SSO) (e.g., SSPI API for Windows application, GSSAPI in linux environment, etc.) by Federated Sign-On (the authentication responsibility is delegated to a trusted party, e.g., to Kerberos or Active Directory Federation Service, who will provide a user with a token proving his/her identity after the successful authentication) Marek Rychly Identity Management and Access Control ES, 7 December 2015 7 / 32

Digital Identity Single Sign-On (SSO) and Trust&Federation Identity Management in Databases SSO by Shared/Synchronized Credentials by Identity&Credential Mapping uses credential caches to keep track of the identities and credentials (one identity can have multiple different credentials for different applications) the cache updated manually or automatically on credential changes existing applications are modified to use identity-mapping solutions (maps application-specific to global user ident., use credentials from cache) the apps. that cannot be modified use a SW agent to login users (the agent monitors login events and provides credentials when required) by Password Synchronization (each application has its own identities and credentials database, all these databases are synchronized, manually or automatically) Identity&Credential Mapping and Password Synchronization described above are less secure than the previous solutions (users have to trust the applications to provide them with their credentials) Marek Rychly Identity Management and Access Control ES, 7 December 2015 8 / 32

Trust and Federation Digital Identity Single Sign-On (SSO) and Trust&Federation Identity Management in Databases federation implies delegation of responsibilities honoured through trust relationships between federated parties (fed. services, FSs) (e.g., the responsibility of authentication, as in Federated SO; of authorization; identity/profile management; accounting and billing; etc.) communication of FSs of individual realms needs to be secured (by using a federation protocol over a secure communication channel) trust propagated through federation according to a trust model 1 (breaking into one of FSs will harm all federated realms that trust the attacked FS) (adopted from Window Server 2003 R2, what s new with Active Directory ) 1 e.g., centralized hub-and-spoke, hierarchical, per-to-peer web of trust, etc. Marek Rychly Identity Management and Access Control ES, 7 December 2015 9 / 32

Identity Management in Databases Digital Identity Single Sign-On (SSO) and Trust&Federation Identity Management in Databases DBMS usually do not use SSO. (there is limited number of account) Usually one account per app. (all application-level users access db. via one database-level account) However, and therefore, it is important to manage identities. (i.e., database-level identities) Basic rule: keep a paper trail. (adopted from Afyouni, H.: Database Security and Auditing, Protecting Data Integrity and Accessibility ) Marek Rychly Identity Management and Access Control ES, 7 December 2015 10 / 32

Digital Identity Single Sign-On (SSO) and Trust&Federation Identity Management in Databases Application and Database-level Identities Application users are identified by an application. (contrary to db. users that are identified by a DBMS) There are different strategies for mapping of app. do db. users: one application user ) one database user (identity management and resource control can be done in a DBMS) + only authorized db. actions can be performed, by users and the app. access control granularity of db. objects (tables, views, etc.) multiple application users ) one database user (the app. decides which db. user to use, e.g., according his role in the app.) + only authorized db. actions can be performed by the app. (bypassing app. access control does not allow all actions) difficult mapping of groups of app. users to db. users all application users ) one database user (i.e., one db. user per app.; the app. does identity mgmt. and access ctrl.) all db. actions can be performed by the app. in a particular database (bypassing app. access control allows all actions in the database) + access control can be implemented in the app. without any limitations The optimal strategy depends on the application and its users. (how many users? variety of users roles? how often are they modified? etc.) Marek Rychly Identity Management and Access Control ES, 7 December 2015 11 / 32

Digital Identity Single Sign-On (SSO) and Trust&Federation Identity Management in Databases Application and Database-level Identities Example (adopted from Configuring Privilege and Role Authorization, Oracle ) Marek Rychly Identity Management and Access Control ES, 7 December 2015 12 / 32

Digital Identity Single Sign-On (SSO) and Trust&Federation Identity Management in Databases Identity Management in Oracle Database CREATE USER username IDENTIFIED ( BY password EXTERNALLY GLOBALLY ) [ PROFILE profilename ] [ PASSWORD EXPIRE ] [ ACCOUNT ( LOCK UNLOCK ) ] [ DEFAULT TABLESPACE tablespacename ] [...]; ALTER USER username...; DROP USER username [ CASCADE ]; Users can be identified by passwords (passwords are encrypted and stored in Oracle system catalogue) externally (authenticated by an external service, e.g, OS or a third-party service) globally (authorized by the enterprise directory service, Oracle Internet Directory) Security policies can be specified in user profiles. Passwords can be set as expired. (the expired passwords need to be reset by users on the first access) Accounts can be (un)locked. (DBMS should be hardened by locking unused accounts) Marek Rychly Identity Management and Access Control ES, 7 December 2015 13 / 32

Digital Identity Single Sign-On (SSO) and Trust&Federation Identity Management in Databases Security Policies by User Profiles in Oracle Database CREATE PROFILE profilename LIMIT ( resourceparams passwordparams ); ALTER PROFILE profilename...; DROP PROFILE profilename [ CASCADE ]; To set resource limitations: sessions_per_user, connect_time, idle_time cpu_per_session/call, logical_reads_per_session/call private_sga, composite_limit (amount of private space allocated in the system global area, all resources) To set password limitations: password_reuse_time/max, password_life_time/grace_time (a warning is issued in the grace period when a password expired) password_reuse_time/max failed_login_attempts, password_lock_time password_verify_function (to verify strength of passwords when set by users, not to authenticate) Marek Rychly Identity Management and Access Control ES, 7 December 2015 14 / 32

User Roles in Oracle Database Digital Identity Single Sign-On (SSO) and Trust&Federation Identity Management in Databases CREATE ROLE rolename ( NOT IDENTIFIED IDENTIFIED ( BY password USING schema.package EXTERNALLY GLOBALLY ) ); ALTER ROLE rolename...; DROP ROLE rolename; Roles are named collections of privileges that can be assigned to users. a role can be granted system or object privileges any role can be granted to any database user During session, a user can activate or deactivate one of its roles by: (activation of the roles may require identification, e.g., by password) SET ROLE rolename [ IDENTIFIED BY password ]; SET ROLE NONE; Default role(s) of a user can be set by: ALTER USER username DEFAULT rolename1 [, rolename2,...]; Marek Rychly Identity Management and Access Control ES, 7 December 2015 15 / 32

Digital Identity Single Sign-On (SSO) and Trust&Federation Identity Management in Databases Identity Management Views in Oracle Database DBA_USERS view contains information about all accounts. (username/id, account status, lock/expiry date, table-space, profile, etc.) USER_USERS view contains information about the current user. the name of the logged user can be obtained by: SYS_CONTEXT ( USERENV, SESSION_USER ) DBA_PROFILES view contains information about all profiles. (profile name, resource name and type, resource limit) There are two special system users: SYS owner of the data dictionary SYSTEM performs almost all database tasks There are also two roles SYSDBA and SYSOPER that can be assigned to db. users. (to administrate the db., or to perform operational maintenance, such as backup/restore) Marek Rychly Identity Management and Access Control ES, 7 December 2015 16 / 32

Access Control in Databases Access Control and Access Control Models Access Control in Databases The authorization of a particular subject to perform a particular action on a particular object. Subject are typically users, roles, and executable objects. (the exec. objects can be, for example, stored procedures/functions, triggers, etc.) Particular types of actions on objects are distinguished in dbs.: read (SELECT) modify (UPDATE) add/delete (INSERT/DELETE) Access to objects enforced through different types of controls: Mandatory Access Control (MAC) Discretionary Access Control (DAC) Role Based Access Control (RBAC) Rule Based Access Control (RBAC or RB-RBAC) Marek Rychly Identity Management and Access Control ES, 7 December 2015 18 / 32

Mandatory Access Control (MAC) Access Control and Access Control Models Access Control in Databases Users cannot freely determine who has access to their data. (an AC policy mandated by some regulation that must be absolutely enforced) Access depends on the integrity of both the security labels (security properties) of accessed objects the security clearance of subjects requesting access to the objects Security labels of an object contain pairs of the following: a classification of the object (e.g., top secret, confidential, etc.) a category of the object (e.g., project blue, human resources department, etc.) Security clearances of subjects contains the same pairs. A user (subject) can access particular data (object) if there is such clearance of the user and security label of the data that both: the classification of the object the clearance of the subject (e.g., a user with top secret clearance can access confidential data) the category of the object = the category of the subject (the user can access data of the classification above in a particular project) Marek Rychly Identity Management and Access Control ES, 7 December 2015 19 / 32

Access Control and Access Control Models Access Control in Databases Mandatory Access Control Restrictions MAC can distinguish between read and write actions: read up & write down (Biba) (to keep Integrity Level, IL) no read-down a subject at a given IL must not read an object at a lower IL (also know as the Simple Integrity Axiom) no write-up a subject at a given IL must not write to any object at a higher IL (also known as the Star-integrity Axiom) write up & read down (Bell-LaPadula) (to keep Security Level, SL) no read-up a subject at a given SL may not read an object at a higher SL (also know as the Simple Security Property) no write-down a subject at a given SL must not write to any object at a lower SL (also known as the Star-security Property) Marek Rychly Identity Management and Access Control ES, 7 December 2015 20 / 32

Access Control and Access Control Models Access Control in Databases An Example of Mandatory Access Control with write up & read down restriction (Bell-LaPadula) (adopted from O. Bodriagov: XACML, ABAC, Privacy preserving access controls ) Marek Rychly Identity Management and Access Control ES, 7 December 2015 21 / 32

Access Control and Access Control Models Access Control in Databases Discretionary Access Control (DAC) Users are allowed to freely control access to their data. (they can restrict or release access to the data as needed) Each object has an Access Control List (ACL) associated with it. An ACL of an object contains a list of the following pairs: a subject which can access the object (e.g., a particular user, group, executable object, etc.) a level of access for the subject to the object (e.g., read, modify, create/delete, set ACL, etc.) A particular user (subject) can perform a particular action on a particular data (object) if and only if this user and this action are together in the object s ACL. Users can set ACLs only for their objects, i.e., the objects that they own (their data in a database) the objects that they have been allowed to control (to set ACL) Marek Rychly Identity Management and Access Control ES, 7 December 2015 22 / 32

Access Control and Access Control Models Access Control in Databases An Example of Discretionary Access Control (adopted from S. Varghese: Access control lists (ACLs) ) Marek Rychly Identity Management and Access Control ES, 7 December 2015 23 / 32

Access Control and Access Control Models Access Control in Databases Role Based Access Control (RBAC) also known as Non-discretionary Access Control Users cannot freely determine who has access to their data. (an AC policy set by real-world role hierarchy of users) Each subject has assigned (only) one role in a particular system. (based on a user s job function within an organization to which the system belongs) Usually, the subjects are particular roles in the organization. (and than, particular users are assigned to these roles) Users can access only objects that are available to their roles. (e.g., an accountant can access only accounting data in the system) Roles in RBAC differ from Oracle roles or groups: in RBAC, each user can have assigned only one role in a particular system. (e.g., the accountant cannot be a customer in the same information system) Marek Rychly Identity Management and Access Control ES, 7 December 2015 24 / 32

Access Control and Access Control Models Access Control in Databases The Model of Role Based Access Control with multiple roles per an subject and other enhancements (adopted from Role-based access control, Wikipedia ) Marek Rychly Identity Management and Access Control ES, 7 December 2015 25 / 32

Access Control and Access Control Models Access Control in Databases Rule Based Access Control (RBAC or RB-RBAC) also known as Attribute-based Access Control AC based on a set of rules defined by a system administrator. (an AC policy implemented by the administrator) Each object has an Access Control List (ACL) associated with it. (usually, the same ACLs are defined for all objects of a particular category, e.g., all records in an accounting system) An ACL of an object contains a list of the following pairs: a rule to check on access of a subject to the object (e.g., it is office hours, it is an emergency situation, etc.) a level of access for the subject to the object (e.g., read, modify, create/delete, etc.) A particular user (subject) can perform an action on a particular data (object) if and only if the rules in the object s ACL are met. This AC is very flexible, it can implement any other AC, and rules engines allow to evaluate large set of rules quite efficiently. Marek Rychly Identity Management and Access Control ES, 7 December 2015 26 / 32

Data Control Language Access Control and Access Control Models Access Control in Databases RDBMS implement the discretionary access control model. (access to data objects can be restricted by their ACLs) Access to the objects can be set by GRANT and REVOKE statements. (these statements are part of Data Control Language, DDL, part of SQL) In Oracle, there are two types of privileges to grant/revoke: System privileges (granted only by a database admin. or by a user with ADMIN privileges) Object privileges (granted to a user by the schema owner or by a user with GRANT privileges) Both users with ADMIN and GRANT privileges can grant privileges to other users. (however, granted privileges may be revoked later automatically in the case of the user with GRANT privilege, see the following figures) Marek Rychly Identity Management and Access Control ES, 7 December 2015 27 / 32

Access Control and Access Control Models Access Control in Databases Granting and Revoking ADMIN Privilege (adopted from Afyouni, H.: Database Security and Auditing, Protecting Data Integrity and Accessibility ) Marek Rychly Identity Management and Access Control ES, 7 December 2015 28 / 32

Access Control and Access Control Models Access Control in Databases Granting and Revoking GRANT Privilege (adopted from Afyouni, H.: Database Security and Auditing, Protecting Data Integrity and Accessibility ) Marek Rychly Identity Management and Access Control ES, 7 December 2015 29 / 32

Access Control and Access Control Models Access Control in Databases GRANT/REVOKE Statements in Oracle Database GRANT ( obj-privilege1 [, obj-privilege2,...] ALL PRIVILEGES ) TO identity [ WITH ( GRANT HIERARCHY ) OPTION ]; GRANT ( sys-privilege1 [, sys-privilege2,...] ALL PRIVILEGES ) TO identity [ WITH ( ADMIN DELEGATE ) OPTION ]; REVOKE ( obj-privilege1 [, obj-privilege2,...] ALL PRIVILEGES ) FROM identity [ CASCADE CONSTRAINTS FORCE ]; REVOKE ( sys-privilege1 [, sys-privilege2,...] ALL PRIVILEGES ) FROM identity; WITH GRANT (the grantee can grant the object priv. to other users/roles) WITH HIERARCHY (the grantee can grant the object priv. on all sub-objects) WITH ADMIN (the grantee can do everything; can grant/revoke privileges/roles) WITH DELEGATE (the grantee can delegate granted role to another user; can be used only when granting role privilege to a user) Marek Rychly Identity Management and Access Control ES, 7 December 2015 30 / 32

Summary Summary Identity management to manage identities authentication. Access control and management to control access authorization. Different approaches to the identity management. (different Single Sign-On methods) Different approaches to the access control and management. (different Access Control models) In the next lecture: Database Application Security Models and Policies (security models for client-server and web-apps., system/data/user sec. policies) Marek Rychly Identity Management and Access Control ES, 7 December 2015 31 / 32

Thanks Thank you for your attention! Marek Rychly <mrychly@strathmore.edu> Marek Rychly Identity Management and Access Control ES, 7 December 2015 32 / 32