1 1 Australian Government Information Management Office AGAF guide to authorisation and access management
2 Contents 1 Summary... 4 Implementing layered permissions enforcement... 4 Addressing varying user access modes... 4 Providing links between e-authentication and permissions management... 5 Enabling acceptance of third-party credentials... 5 Determining user identifiers... 6 Assigning and enforcing roles of business representatives... 6 Using a permissions management architecture Introduction... 7 Background... 7 Identity management... 7 Purpose and structure of this guide Key constructs... 9 Identity management... 9 Permissions management Registration and enrolment Registration Enrolment Deregistration Positioning e-authentication and authorisation controls Implementing layers and granularity of controls Using role-based authorisation or access control Using business application or fine-grained controls Designing e-authentication or authorisation architectures Re-engineering legacy applications Management, audit and controls Business architecture considerations Business needs Businesses acting for themselves Businesses acting on behalf of others Access model scenarios Changing access environments Access types Implementation approach Choosing identifiers and credentials Technology architecture Overview... 26
3 Registration and credential issuing services Enrolment and business delegation services E-authentication services Permissions enforcement services Audit services Shared service implementation options Credential management Audit services Credential validation services E-authentication services Enrolment and mapping services Authorisation services Applicable standards Use of standards is more important for security protocols Relevant standards bodies Useful standards for access control Applicability Security purpose or external technology matrix Summary of infrastructure standards or protocols... 39
4 1 Summary This guide provides a framework to enable agencies to examine and address the authorisation and access management requirements associated with the deployment of online services to Australian businesses. The guide examines these matters within the broader context of identity management. Identity management represents the policies, processes, systems and technologies required to address the operational risks, systems usability and technology management issues associated with the provision of internal and external user access (across networks) to systems at an enterprise level. It encompasses electronic authentication (e-authentication), authorisation and access, and audit. The style of the guide is essentially discursive rather than prescriptive. This is seen as appropriate, given the current lack of maturity and received wisdom in the area of identity management and the diversity of environments and requirements of agencies in this area. The key constructs and guiding principles of the guide are summarised below. Implementing layered permissions enforcement Controlling what system resources users access and what they are authorised to do thereafter can be implemented at three levels within a systems architecture: e-authentication layer authorisation (permissions management) layer, and business application layer. Increasingly, controls or rules are being abstracted from the business application layer and repositioned in the other two layers. The underpinning logic for this is that once rules are implemented within a business application, they are not easily audited or reviewed by an external agent. Similarly, revoking user access permissions is more difficult when rules proliferate across multiple discrete business applications. Selecting the appropriate level within which specific checks or controls should be implemented depends on: how easily business rules can be implemented and maintained within an abstracted (authorisation) layer as opposed to within business applications the extent to which there is the requirement or demand to handle authorisation for the same user groups across multiple application systems, and how important it is for an agency to have a single view of a user s privileges across an application suite or across all agency systems, for example for the purposes of effectively de-provisioning the user when they change job roles or leave the organisation or forfeit the rights to access systems for some other reason. Guiding principle: Maintain permissions where practicable within abstracted e-authentication and authorisation management layers. Addressing varying user access modes There is an emerging requirement for agencies to handle e-authentication, authorisation and access management across three modes or categories of user connections to agency sites: browser attended business applications, and
5 unattended business applications. This diversity directly affects how and where user e-authentication and authorisation is undertaken. Guiding principle: Recognise that it is likely that agency applications will be accessed via all these modes and develop identity management solutions that can accommodate the nuances of each mode non-disruptively. Providing links between e-authentication and permissions management A layered approach to identity management will encompass separating permissions management from e-authentication. Permissions management is, however, vitally interested in the assurance level associated with an authenticated identity see Volume 2 (Key Concepts) of the AGAF implementation guide for government for an explanation of assurance level. Permissions management must therefore be able to access the assurance level (associated with the e-authentication credential) and, moreover, request step-up e- authentication as required. This includes situations where permissions management is implemented within a business application. Guiding principle: The authorisation process must take account of explicit permissions assigned to identities and must enforce the e-authentication assurance level policies of the business applications. Enabling acceptance of third-party credentials Using suitable third-party credentials in lieu of issuing application-specific or agencyspecific credentials offers potential benefits to agencies through reduced costs of the credentials themselves, deployment, user support and ongoing credential management. In approaching use of third-party credentials, agencies should review, and where necessary re-affirm, identity information associated with a credential. This may include linking the credential to an agency s record of the user already held within a database and/or gathered during an enrolment phase. This late binding will create, in effect, the linking of the credential to the existing identifier used within the agency to distinguish a business from other businesses. Guiding principles: 1. Where practicable, recognise and use suitable credentials that have been issued by, and continue to be supported by, another agency or certified third-party credential provider. 2. Handle additional credential information requirements outside of the credentials themselves, for example, in directories or databases. 3. Embed an enrolment process as part of an agency s standard identity management life cycle to encompass late binding of externally issued credentials.
6 Determining user identifiers Where businesses have existing offline dealings with an agency, they will be known by an identifier, such as an Australian Business Number (ABN) or a business name. In developing online services, agencies need to determine appropriate online identifiers for these businesses, taking into account the differing needs of identity e-authentication compared with previous paper, voice or personal channels. Guiding principle: Choice of identifiers should be completed in concert with a credential type for e-authentication, but should not depend on choice of credential. Where no existing identifiers exist or where adoption of a new identifier is not invasive, agencies should adopt the ABN as the preferred business identifier. Assigning and enforcing roles of business representatives Businesses will have many different dealings with government and will often have different officers within the organisation authorised to dealing with particular transaction types and/or agencies. Agencies must implement processes and procedures that allow roles of business representatives to be assigned and enforced. Guiding principle: Permissions management systems should ensure that businesses have suitable mechanisms to manage the enrolment of business representatives with various authorities and, as a corollary, that agency application owners have suitable mechanisms to validate that authenticated representatives have the authority to act on behalf of the business. Using a permissions management architecture Agencies should seek to implement permissions management functionality within an architecture that will provide for consistency of implementation across application suites and across agencies. This will enable rationalisation of permissions management services which, over time, will bring operational, cost and integrity benefits to the applications. Government tenders should be incorporated the requirement for vendor solutions to support the appropriate standards that enable such architectures to work and interoperate; see section 6 Applicable standards. Guiding principle: As agencies develop, upgrade or replace existing online services and (some) business applications, they should give preference to applications and products that support existing and emerging standards thereby allowing the use of abstracted permissions management infrastructure.
7 2 Introduction Background The knowledge of who is requesting services and their authority to access these services has long been a fundamental element of the effective operation of internal government systems and in providing government services to external individuals and organisations. Historically, as business and online systems were developed, the issues of user identification and authority, and the associated risks of getting it wrong, were handled implicitly within each business system domain, and solutions were tailored to the specific constituency that used the services. The explosion in electronic service delivery globally sees government agencies and large private sector organisations facing a number of issues that are rapidly driving a change from this multi-siloed approach to one of managing a diverse user base in a coordinated and consistent manner across, the entire organisation. Initiatives such as the Australian Government e-authentication Framework (AGAF) seek to extend this coordination and consistency across agency boundaries. These issues have led government and businesses globally to the view that a more structured and organised enterprise-wide approach is required for managing and controlling the who, when, what, how and why of user access to networked enterprise resources. Identity management The emergence of so-called identity management as an enterprise-level function is a response to the changing requirements outlined above. Identity management represents the policies, processes, systems and technologies that address the operational risks, systems usability and technology management issues surrounding internal and external user access to systems at an enterprise level. It encompasses the complementary requirements of e-authentication, authorisation and access, and audit. These concepts and their interaction are dealt with in Section 3. The recognition of identity management as a separable set of functions is akin to the previous and now widely accepted practice of unbundling major functional elements such as communications and database management from within business applications and placing them into separately managed infrastructure. This enables organisations to standardise, optimise and potentially share the component policies, processes, technologies and systems across all their business application areas. This unbundling of access control matters results in a three-layer approach to identity management, as shown in Figure 2.1. Figure 2.1 Three-layer identity management model
8 Adopting this model enables organisations to shift from an applications-focused to a userfocused regime of managing identity e-authentication and authorisation. An applicationsfocused approach is a legacy of previous siloed development of systems and their access mechanisms. The AGAF represents the first step in defining an Australian Government identity management approach. It focuses on authenticating external user identities (and, prospectively, other assertions such as age and group membership). As such, it addresses the who and how of online access, but has so far left open the issue of dealing with the what, when and why of access to government services. Purpose and structure of this guide This guide focuses on providing a framework for addressing the what, when and why issues, generally termed authorisation and access management, in the context of the AGAF. The guide provides: the key constructs of an identity management approach required business and technology architectures, and applicable standards. While the guide focuses on managing access to authenticated identities, the same principles can be applied to managing access where e-authentication of other attributes or entitlements has been completed, such as the age or affiliation of the user. This guide should be read in conjunction with the AGAF implementation guide for government.
9 3 Key constructs This section is intended to be both explanatory and definitional. It examines the key constructs required for authorisation and access management and within which authorisation and access management is required to operate. The constructs covered are: identity management permissions management registration and enrolment deregistration positioning of e-authentication and authorisation controls within a three-layer, identity management architecture user access modes, and management, audit and controls. Identity management Authorisation and access management should be considered within the context of the identity management life cycle and identity management architectures. Identity management is a significant component of an overall risk-managed 1 approach to providing trusted and reliable online delivery of government services. The scope of identity management, presented in Figure 3.1, illustrates: the typical business processes that lead to the online enabling of users, incorporating registration, credential issuance and enrolment the subsequent transactional processes, incorporating identity e-authentication and permissions management, and the treatment of the disabling of users over time, including deregistration. This is also known colloquially as de-provisioning. Importantly, these processes should be undertaken within a robust and independent audit regime that achieves both: pre-emptive detection and prevention, and after-the-fact transaction analysis, and the detection and remediation of unauthorised activities. 1 The risk management approach is covered in detail in Part 3 of Volume 3 of the AGAF implementation guide for government.
10 Establish entitlements Identities Directory(ies) Permissions Store(s) Identity or Entitlement Checking Registration & Credential Issuing Enrolment Application (A) C Issue Identity & credential Credential C Transacting Authentication Access Authorisation Application (B) Application (C) Authentication Service Populate Issuer Directory Identities Directory(ies) Suspend identity; update roles Populate Issuer Credential store Credential Store(s) Revoke credential De-registration & De-provisioning Figure 3.1 Identity management life cycle Permissions management Throughout this guide, we use the industry-accepted term permissions management as a synonym for authorisation and access management. Permissions management forms the bridge between an authenticated identity and the portfolio of online business applications offered by various government agencies that the authenticated identity may be able to access. Permissions management enforces: the previously determined e-authentication level requirements of business applications 2, and various other access restrictions determined by business requirements. Implementation of permissions management depends on the context, which dictates: the nature of the transaction, and the complexity of the business rules surrounding the determination of access permissions. Contemporary systems typically have a dedicated permissions management layer within the architecture, and increasingly make this layer available as an infrastructure element to other applications (see Figure 2.1). This layer is intended to address the primary permissions management needs of an application system, with finer grained permissions typically implemented within the application or transaction. 2 The method of determining the assurance level requirements of applications and determining appropriate e-authentication mechanisms is dealt with in Parts 3 and 4 of Volume 3 of the AGAF implementation guide for government.
11 Registration and enrolment Registration Registration refers to the processes that culminate in providing an e-authentication credential 3 to a business or business user through which identity e-authentication can be effected. As described in the AGAF implementation guide for government, such e-authentication will have an associated e-authentication assurance level. This will be a function of the strength of both the registration process and of the e-authentication mechanism associated with the credential issued. This duality is represented in Figure 3.2. Authentication Assurance Level Matrix Strength of Registration of Entity, Identity, or Attribute Low (2) Low (2) Low (2) Moderate (3) Moderate (3) Low (2) High (4) Moderate (3) Moderate (3) High (4) High (4) Moderate (3) 1 Minimal (1) Low (2) Low (2) Low (2) 4 Strength of Authentication Mechanism Figure 3.2 AGAF assurance level table Registration can be completed by a government agency (for example, the Australian Taxation Office [ATO] or Centrelink) or, increasingly commonly, by third parties. Credentials issued by third parties can be used to authenticate users to a range of organisations. Verisign is an example of a non-government credential issuer. It issues Gatekeeper certificates and Australian Business Number Digital Signature Certificates (ABN DSCs). Registration typically incorporates some or all of the following elements: checking identity (or other) documentation in order to achieve a level of confidence in the identity of a business and its representative creating user entries in a directory or database, and/or issuing a credential to a business. Checking identity Checking identity (or other) documentation is intended to achieve a level of confidence in the identity of a business and its representative. This process might include, for example, face-to-face contact and sighting original documents such as company registration information, a passports or drivers licence. The extent of the checking will depend on the assurance level required to verify the claimed business identity. The Financial Transaction Reports Act 1988 provides guidelines on minimum identification methods for the financial sector, often referred to as 100-point checks. These and similar checks are used across a range of industries and are the subject of ongoing review and refinement to ensure continuing confidence in their use. 4 3 The credential and an associated e-authentication protocol make up the e-authentication mechanism see figure See Part 4 of Volume 3 of the AGAF implementation guide for government.
12 If the business does not already have a recognised and suitable identifier, the registration process will involve issuing such an identifier. It is expected that the primary online identifier for businesses will be the ABN, although there may be some instances where this is inappropriate. 5 Current Australian Government business registration practice usually sees an already authenticated business representative authorised and assigned to undertake elements of the registration process for other users within that business. Here the business representative is acting on behalf of the issuer of the credential, who usually prescribes strict operational procedures. The nature of this delegated registration will vary across credential types and issuers, and will be more onerous as the assurance level of the related credential increases. Creating user entries in a directory or database Creating user entries in a directory or database provides an electronic record of a business s identity and associated information, which can be used in subsequent maintenance of the directory. This electronic record should ideally also maintain references or indexes to information detailing the checks completed as part of registration, for example, evidence of identity checks. This directory will typically be maintained by the issuer of the credentials and may include private information provided as part of the registration process. In a business context, this is less likely than when dealing with individuals. Where a credential is to be used across government agencies or even more broadly, the extent of availability of this registration-related information to relying parties needs to be carefully considered. Issuing a credential The credential issued to a business will be used as the key element of subsequent e-authentication of the business. Details of the credential will be held in the directory. Credential mechanisms are intrinsically of different strengths and can include a password, a token of some kind (such as a smartcard) or a digital certificate. 6 The strength of the credential required will be determined by the assurance level requirements of the target business application or transaction. Issuing a credential involves issuing a credential plus any associated access codes to enable the credential to be used within an e-authentication and permissions management environment. Factors that need to be considered include: the methods of protecting shared secrets such as cryptographic keys, from the time of issuance until they are in the certain custody of the end-user the methods of activating the credential upon receipt by the user. This would typically be achieved through some sort of activation code entered into a device such as smartcard or token, a phone call to a help desk or Interactive Voice Response (IVR) centre, or a mailed confirmation, and the implementation and activation of any special software or hardware required by the credential. Examples of this include a smartcard reader and software and special application software. The ATO s Common-use Signing Interface (CSI) software is an example of the latter, although the ATO has decoupled the implementation of CSI from the credential issuance process. 7 5 For further coverage of identifiers see Choosing identifiers and credentials in Section 4 of this guide. 6 See Part 4 of Volume 3 of the AGAF implementation guide for government. 7 See the business portal area of
13 Enrolment Note: Difficulties in any of the above areas will result in potentially significant help desk imposts and loss of user confidence in the e-authentication regime. Once issued with a credential, a business will need to make arrangements with a government agency to assign permissions to the business to gain access to online services and transactions (such as making payments, lodging declarations, enquiring on status) using the credential. This activity is termed enrolment. Enrolment may proceed in one of two ways: 1) As a natural extension of the registration process described above. In this case, which is typical in a siloed application, the business will be issued with a credential and, based on elements of the registration process, will be given access permissions for various transactions offered by the agency. 8 The assurance level of the credential used in this context is well understood by the agency as it issued the credential and previously completed all elements of the registration and issuance processes. Whilst there is a logical separation of registration and enrolment within the business systems, to the business user, registration and enrolment steps would be seen as seamless processes and indistinguishable from one another. 2) As a discrete step performed at some time after the registration. This second method of enrolment is termed late binding. In this instance, an agency that already has an offline relationship with a business might elect to accept a credential issued to that business by another agency. The relying agency would make this decision as part of a broader consideration of its online deployment strategy and would need to consider: the number of third-party credentials issued by various issuers the extent of overlap of the credential holders (that is, businesses) with the particular agency application concerned, and any commercial issues (including liability, longevity, etc.) relating to acceptance of that credential type. In evaluating whether to accept credentials issued by others, the agency must first ensure that the e-authentication mechanism (incorporating the credential) is of a suitable assurance level for its needs. 9 Once this 'fitness-for-purpose has been determined, processes are required that link the information about a business s credential with the information the agency already has about the credential holder in its systems (for example, a user record in a database or directory). This might involve linking, say, a digital certificate to an account number, licence number or other internal application-based identifier that represents the relying agency s existing record of the business or business representative. This linking would be achieved by matching the business s details against records held within the agency s application systems. This matching process, or establishing evidence of relationship, is similar to completing an evidence of identity check, which is normally done at the time of registration. Once the link is established through this binding process, access permissions for various transactions offered by the agency will be established in the same way as for siloed applications described in (1) above. Processes surrounding enrolment and binding processes are described section 5. 8 The ATO approach is an example of this. 9 This is dealt with in the choosing identifier area of section 4, and in Parts 2 and 3 of Volume 3 of the AGAF implementation guide for government.
14 Deregistration A business s online interaction with an agency will vary over time, as will the identity and authority of individuals within the business. This is analogous to the situation with nonelectronic channels. Managing the currency and accuracy of these relationships is a critical element of the integrity of the identity management infrastructure. Thus a cohesive deregistration capacity is vital. In an open identity management environment, promulgation of changes in credential status or implicit authority must be readily accessible online or be promulgated in a robust and timely manner so that relying authorisation systems remain well informed. Guidance on implementation is provided in section 5. Positioning e-authentication and authorisation controls Dealing with a business is potentially a complex matter. Businesses are often represented by a number of individuals who are assigned various roles (and therefore access permissions), potentially across a number of agencies. Roles can be legislated (for example, company office bearer) or assigned arbitrarily by a business, and can be persistent or highly volatile. Thus authorisation of individuals to act in various capacities on behalf of the business presents significant design, operational and administrative challenges for agencies. A consistent approach to allocating permissions and their associated enrolment techniques across government agencies will improve the overall integrity of the authorisation processes and also provide businesses with a common interface to this function. Moreover, depending on the specific implementation, it enables a single view and consistent management of all the access permissions of a business, or an individual within a business, to agency and potentially whole-of-government services. Implementing layers and granularity of controls E-authentication and authorisation are complementary and sequential processes in online transaction processing models and deal with the preliminaries to processing transactions. In simple terms, e-authentication checks is this the person they claim to be, and authorisation checks what is this person allowed to do. Identity e-authentication deals with checking the identity of a business using the e-authentication mechanism and associated credential. In open models that rely on credentials issued by third parties, the e-authentication step may require interaction with the issuer of the credential to validate the credential and its status (for example, its currency). Once e-authentication is complete, the access permissions of the user need to be validated. In contemporary systems, this permissions management is typically implemented as a separate layer of the technology architecture (see Figure 3.3). This relieves application systems from the need to embody the functionality, and enables the functionality to be implemented just once and then used by many applications. The extent of permissions management logic that is implemented within an authorisation layer needs to be carefully assessed during the design stage.