Australian Government Information Management Office. AGAF guide to authorisation and access management

Transcription

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.

15 Business application Business application systems systems Authorisation Layer Authorisation Layer Fine grained Access Control Authentication Layer Authentication Layer Coarse grained Figure 3.3 Access control layers As a general principle, fine-grained access is more typically implemented within the business applications. Examples of fine-grained access controls include rules relating to individual data fields in a record that may be viewed or changed. Coarse-grained controls are often implicitly implemented within e-authentication systems. Coarse-grained control might include validating authorities that are intrinsic to the credential, including such attributes as medical practitioner, authorised officer of a company or an Australian-registered company. Medium-grained controls will predominate. They include access controls applicable to an individual officer within a business and typically provide control of access (authorisation) to an individual transaction or class of transactions. It is unlikely that these controls would interrogate information held within a transaction to determine permissions to access the business application. Using role-based authorisation or access control In dealing with medium-grained controls, it is convenient to group application functionality together on a role basis such that the collection of grouped transactions is accessible by any authenticated individual who has been assigned that role (and perhaps others) as part of enrolment. In this way, the permissions management systems do not need to incorporate access privileges (often referred to as policies) at an individual level, but only at a role level. A user s roles would be maintained as an attribute within the directory of users. Using business application or fine-grained controls Fine-grained controls also apply to an individual business representative and, in addition to controlling access to specific transactions at the application level, they implement finer resolution tests based on information within the transaction and potentially elsewhere. Examples of fine-grained controls include basing the capacity to undertake a transaction on: the value of the transaction an explicit authority to deal on behalf of, or as an agent of, nominated parties (either individuals or businesses) 10, and the timing or timeliness of a transaction. Designing e-authentication or authorisation architectures An assessment of the appropriate layers at which to implement permissions management and access control logic in new applications must be guided by: maintainability of the permissions as applications change. Implementing detailed business rules across more than one layer is likely to increase the maintenance overheads and possibly lead to instability of the business applications 10 There is more information on this in Businesses acting on behalf of other part of Section 4 of this guide.

16 management overheads. This relates to managing a business s or a business representative s permissions from both the agency and business owner s perspectives. Where permissions are distributed across implementation layers, processes are required to support aggregate control and reporting of these permissions on a per user basis system or network performance and reliability. Performance will vary depending on the manner of implementation. Purpose-built permissions management systems are usually designed for high performance, with mature failover provisions ensuring high availability of access to the business applications costs associated with either single or multiple layers of permissions management and authorisation processing, and complexity or simplicity of rules. Functionality needs may dictate the location of processing. The more complex the permissions management rules, the more likely their implementation will be within the business application systems layer. The following table contains a summary of an idealised approach to design. Control granularity Coarsegrained Mediumgrained Fine-grained Layer in which implemented Identity e- authentication system Permissions management systems Business application logic Typical layer functionality Authenticate identity of the user and implicitly grant permission to access portal or application suite. Determine high-level roles, attributes or qualification of the user through data explicitly or implicitly held within the user s credential (such as a certificate) and grant permission to access portal, application suite or application area. For an authenticated user, grant permission to access an application suite, application area or specific transaction (set) based on either: user s specific entitlements or attributes, or user s role where the entitlements, attributes or role information are held under the control of a permissions management system. For an authenticated user, grant permission to access an application suite, an application area or a transaction, or grant permission to complete specific application-level functions based on user or rolespecific information held within application-controlled databases or directories, potentially in conjunction with information contained within the transaction. Typical use Portal or website permissions management Role-based permissions management Agent-based permissions management Guidance on implementation is provided in section 5.

17 Re-engineering legacy applications Repositioning permissions management logic, currently embedded within existing siloed applications, into an e-authentication or authorisation layer will require detailed analysis and assessment of the benefits available. Experience has shown that permissions management at the transaction level is usually the main candidate for migration from the application logic to an authorisation or permissions management layer. Management, audit and controls Permissions management systems must be designed and implemented in such a way that enables both government agencies and businesses to affect the controls necessary to ensure the integrity of access to business functions. Businesses need to have full control over the roles and privileges of their authorised representatives, regardless of where or how the controls are implemented. Agencies need assurance that authenticated company representatives have the authority to complete particular transactions. Moreover, each party requires a trusted audit trail of both transactional and administrative dealings between an agency and a business that will provide the basis for any future dispute resolution. Guidance on implementation is provided in section 5.

18 4 Business architecture considerations Typically, agency business systems provide a range of online functionality to business users. As in the offline world, the authority required to undertake many of the underpinning transactions will vary considerably according to the nature of the transaction. Basic enquiry transactions could be made available to any authenticated business representative, whilst declarations, lodgements and some specific enquiries would usually be restricted to individuals with specific roles within the business. Note: It is important to emphasise that the transaction authorisation process assumes that identity (or other attribute) e-authentication has been completed. The authorisation process must, however, check that the assurance level of the e-authentication meets the minimum assurance requirement of the business application and, if not, request step-up e-authentication. 11 The permissions previously assigned to the identity during the enrolment phase are then checked before permitting or refusing access to the business application, as shown in Figure 4.1. Authenticate Identity Select Transaction Check Authority Apply Business Rules Request Step-up Authentication Check Assurance Level Check Permissions Reject Figure 4.1 Transaction processing summary The integrity of the authorisation processes ultimately relies on good housekeeping within an agency s operation (and within businesses where there is delegated administration) and the availability of trusted administrative interfaces to the permissions management systems. Business needs In considering best practice architectures, it is convenient to view the potential business application needs that determine authorisation requirements. Here we examine how permissions might be allocated in two key variations: businesses acting for themselves, and businesses acting on behalf of others for example agents for other businesses. 11 Step-up authentication involves requesting additional information or credentials from users. Information would be that which only the user and the agency should know (that is, knowledge-based e- authentication). An additional credential could take the form of a second password, PIN or pass phrase or a token (for example, a smartcard), digital certificate, biometric, etc.

19 Businesses acting for themselves For a business representing itself, access permissions to various transactions might be assigned to: any representative of the business, as determined by the business itself. In this situation, access would be granted to: o any and all users that can be authenticated as representing the business, with no immediate or future need to determine the identity of the business representative, or o any and all users that can be authenticated as representing the business, provided that the identity of the business representative can be established, if required, at a later stage This after-the-fact identification of the specific representative could be achieved through: o the business maintaining audit trails, with these accessible by the agency. Such access by the agency (or others such as regulators or law enforcement representatives) would need to occur under strictly defined conditions and controls o explicit knowledge passed through transaction or instruction content, such as a username field a specified representative of the business. Typically this would apply to either: o o designated officers, such as a company secretary, where there is a legal status attached to the identity and authority of the employee, and associated personal liability for any transactions, or personnel who are assigned permissions or authority based on their job role within the business, for example, environment officer, HR manager, accountant, administrative officer. The method of enforcing the above requirements will depend largely on the application access methods adopted. However, in general, all of the above authorisation controls are considered to be strong candidates for implementation within an authorisation layer, rather than within the application-resident business logic. Businesses acting on behalf of others Businesses acting on behalf of other businesses A number of businesses lodge returns or transact on behalf of other businesses through a delegated authority from the business. People such as tax agents or customs agents act on behalf of their business customers every day. Notwithstanding the wide adoption of authority delegation, there is significant variation in the nature of the underpinning commercial relationships between a government agency, a business entity, and the representative of the business. These factors make the possibility of any universal approach to treating delegated authorisation most unlikely. Issues that arise in managing such authorities include: how and when the delegated authority is established, maintained and enforced by the agency. The authority applies to the subject business and it is conceivable that such a business might: o o maintain arrangements with multiple organisations (for example, an accountant, tax agent and lawyer) that can each deal on its behalf across a range of transaction types retain authority to deal on its own behalf, and

20 what form the authority takes, and to what extent the authority assertion needs to be authenticated by the government agency explicitly within the online transaction processing flow. There are a number of examples where delegated authorities are declared implicitly as part of an agent s dealing with government agencies and regulated by the relevant legislation, for example: tax agents lodge returns on behalf of businesses and individuals where the authority is retained by the agent and declared implicitly to the ATO as part of the lodgement process, and customs agents implicitly declare both their authority to lodge declarations on behalf of businesses and the veracity of the identity of the subject business (for example, an importer) as part of the lodgement process. However, as business dealings extend beyond lodgements and declarations to more transactional exchanges (such as payments or business information enquiries), after-thefact e-authentication of delegated authorities may prove inadequate and introduce unacceptable risks of claims against a government agency. Businesses acting on behalf of individuals A significant percentage of Australian Government transactions represent businesses lodging returns or transacting on behalf of individuals. These representative businesses include tax agents, customs agents, and non-government organisations such as those engaged by Centrelink and other agencies for providing welfare services. While similar issues to those described above arise for businesses acting on behalf of individuals, in many cases the representation and activity completed by the business, whilst on behalf of the individual, is not a service that could be completed online by the individual on their own behalf. Managing such delegations is considered beyond the scope of authorisation services and should be dealt with fully within the business application. Classes of delegated authority Consideration of the above reveals that there are two clear classes of delegated authorities to deal with: 1) Where real-time validation is not required. This covers those instances, such as tax lodgements, where the delegated authority is implicit in the business transaction and where after-the-fact checking (if required) is an effective control. In this case, it is likely that the government agency application system will fully accommodate the treatment of the delegated authority, rather than have this processing implemented within an authorisation layer. However, the business would be required to provide, on request, the necessary evidence that this authority exists. The authority may be electronic or paper-based. 2) Where real-time validation is required. This covers those instances, such as enquiries on business status, where the delegated authority needs to be tested before transaction processing in order to maintain the integrity of the agency application systems environment. In this case, it is likely that the authority would best be established within a separate authorisation layer or application front-end. In both cases, the interaction of the agent (that is, the business holding the delegation) with the government agency will still be subject to controls (e-authentication and authorisation) on access in its own right before controls in relation to the delegated authority are applied.

21 Access model scenarios Agencies implementing online services with a business determine one or more modes of access or transacting. These include browser-based, application-mediated and application-unattended modes and are examined in further detail below. The mode of online dealings an agency chooses will influence the nature of the implementation of authorisation and access controls within its systems architecture. Changing access environments Traditional non-internet environments Traditional pre-internet online systems were developed with a distribution of application logic between central systems and (typically) PC-based platforms. In these situations, many central applications delegated user management to the remote end point and accepted all transactions received from that end point as being authorised. This was consistent with many offline business practices where the identity and rights of business representatives were taken at face value and underpinned by the context of the interaction (for example, letterhead, job title or physical signature). Browser-based or thin-client environments The advent of the internet and associated browser-based (thin-client) access to fully centralised applications necessitated a shift in approach. Typically, this involved centralising access and transaction authorisation because it was no longer possible to implement cohesive permissions management within a remote end point. This need was a large driver in developing present day identity management infrastructure. In these cases, information on user identity and access rights was maintained centrally. Control over managing this information was usually shared between the service provider and the business user. Establishment of users and their access rights was effected through a combination of online and offline processes, depending on the systems involved. Application-linked integrated environments Emerging interactive environments demand greater integration of internal business systems (for example, payroll, accounts) with third-party service providers (for example, banks, insurers) and, increasingly, with government. These business systems and the technology environments they operate in already encompass sophisticated usermanagement and authority-management capabilities as core components. These are implemented at the business level and managed by a business within its overall enterprise risk management or information technology (IT) security contexts. Systems designers are now looking to provide seamless integration between the functions supported locally within these business systems, and those functions provided by a third party. For instance, completion of a business s accounts at the end of a month could automatically generate the associated lodgement of activity statements with the ATO and initiate any related payments through the business s bank. Ideally, submission of new identifiers and related access codes by the system user should not be required to achieve this the required e-authentication and authorisation should be managed under the covers. In implementation, this requirement is leading to the adoption of web services for interaction between business systems and centralised applications. Web services are also likely to play a similar role between the centralised applications and the web front-ends that are made available to browser-based users. Access types Figure 4.2 presents three access types that agencies will need to accommodate over time.

22 Figure 4.2 Access mode and access control scenarios (1) The choice of access type will depend on the nature of the agency application, with key criteria being: the need for real-time interaction with the user; that is, does the agency transaction require a progressive, interactive exchange with the user to complete the transaction? Typically this is not the case for system-to-system interaction the requirement and potential for integration of the agency-based functionality (and thereby the user authorisation) with a business s systems, for example, its accounting systems, and the need for an authorised business user s presence during the transaction. Especially in large processing environments, interaction between a business and a government agency will be at critical processing steps within a broad business application cycle. The processing step might result, say, in a batch of transactions being transferred to the agency for processing. This step would often not require specific human initiation or authorisation, nor would this be desirable. These three access types, illustrated in Figure 4.2, can be categorised as follows. Thin-client or browser-based. In this case all access control must be implemented within the central environment. Each authorised individual representative of a business will, by necessity, be visible to the agency application. The ultimate control of user access permissions will remain the responsibility of the business. The extent to which the business controls user access permissions on the agency s central system will depend on the capabilities of the agency s front-end systems and the contractual relationship between the agency and the business. Application-based (fat-client, with attended operation, that is, user present). In this case, individual user access control will be managed within the local business environment and typically as part of a broader business application. An agency will implement controls at a business level rather than at an individual representative level. All interactions from an authenticated (and authorised) business will be treated as authorised.

23 The agency will need to determine whether, for valid reasons (for example, contract, law), it requires the business to be able to provide identity details of an individual that initiated such a transaction. This requirement could potentially be satisfied in a number of ways and could be in real time or after-the-fact. 2 Unattended business applications. In this case, systems would crossauthenticate themselves and permissions would be granted at an application level. There would be no provision for tracing the initiator of the interaction. Implementation approach It is not unusual for application systems to support more than one of the above access types, as described below and illustrated in Figure The selection of access type will be driven by the application needs of an agency, current and emerging business practices and the overall suitability of the respective types. It is likely that, over time, agencies will need to accommodate all access types within their permissions management strategies. Unattended Application Systems Internet BUSINESS ACCESS CONTROL COMPLETED HERE Online Business Apps Internet USER ACCESS CONTROL COMPLETED HERE BUSINESS ACCESS CONTROL COMPLETED HERE Access Layer Agency Application Server Internet Agency Web Server BUSINESS / USER ACCESS CONTROL COMPLETED HERE & HERE Figure 4.3 Access mode and access control scenarios (2) Regardless of the access type, a business must remain fully responsible for establishing and maintaining authorities for dealing with an agency for specified purposes. These authorities could apply at an individual business representative and/or business entity level. Implementation of validation and enforcement mechanisms can be distributed between agency and business systems, with Figure 4.3 showing the more likely distribution of these mechanisms. As discussed, factors influencing the distribution bias between individual business representative authorisation and business entity authorisation include: the need for the agency to know the identity and formal role of the individual representing the business at the time of the transaction (for example, office bearer) the need for the agency to know the identity of the individual representing the business at the time of the transaction, and 12 For example, the Australian Customs Service s Cargo Management System supports both browser and unattended application system interfaces, determined largely by the nature of the customer systems and the scale of interaction between Customs and individual customers.

24 the need for the agency to be able to identify the authorised individual representative of the business at some later stage. Where access control over individuals is implemented within an agency s systems, the agency will need to provide systems and facilities to enable businesses to maintain these authorities in a trusted manner. Where access control over individuals is implemented within a business, it is possible that the business may be required to provide details of the identity of the individual who authorised a transaction on behalf of the business. This will be after-the-fact and so the business applications will need to support this audit capability. Choosing identifiers and credentials An identifier is defined as one or more data items concerning an identity that are sufficient to distinguish it from other identities, and are used to signify that identity. The ABN is a universal identifier for businesses dealing with government agencies, and underpins the ABN DSC credential. In some situations, a business may have multiple ABNs and thus some care is required, potentially in the enrolment process, to ensure the appropriate use of an ABN in specific agency situations. Importantly, the ABN DSC incorporates other personal identity information relating to an authorised representative of a business, with the prospect of multiple ABN DSCs being valid in respect to any ABN at any time. There are other business identifiers that will continue to be used, either within the legacy applications or as part of ongoing credentials. They include: legacy identifiers, which are typically specific to an agency and have little if any meaning outside the agency. In some situations, these are simply keys that uniquely distinguish businesses within an agency application. These might include a tax file number, various business licence numbers, etc., and alternative identifiers for broader use than by the agency that issued them. These include Health Insurance Commission provider identifiers in HeSA certificates that are used in the health sector. While a common business identifier for use across government agencies has some attraction (such as potentially offered by the ABN and related ABN DSC credential), it is not essential. The use of abstracted e-authentication services and the introduction of an enrolment step (as described in Section 3) make it possible for agencies to continue to rely on their existing identifiers in conjunction with accepted third-party e-authentication credentials, indefinitely if required. For instance, an agency using a business licence number as an identifier may choose to use that business s ABN DSC to authenticate the business in any online dealings. Establishing the necessary links between the business licence identifier and the ABN DSC would be completed at an enrolment stage. Importantly, while the ABN DSC potentially provides some universality as a credential, agencies should take care in attributing authority to an ABN DSC in itself. For attribution of authority, there is a need to enrol the credential for use within agency applications, as for any other credential that might be used by an agency, even when issued internally The following table shows the distinction between identity, identifiers and credentials in the business context.

25 Identity Identifiers Credentials John Smith in his role as company secretary for ABZ Corporation John Smith in his personal capacity John Smith as treasurer of his golf club John Smith John Edward Smith Trading name Australian Business Zeitgeist Legal name ABZ Corporation Pty Ltd Company Secretary of ABZ Corporation ABN Customer number Tax file number for ABZ Corp John Smith John Edward Smith Customer number Tax file number John Smith Treasurer of Fairways Golf Club Fairways Golf Club Customer number ABN DSC containing the names: John Smith and ABZ Corporation and/or various passwords Various passwords and PINs Various passwords and PINs Clearly, the choice of appropriate identifiers will depend on the nature of the service being offered. Where the service involves migrating offline services online, it might be appropriate to retain the currently used identifier for use online, perhaps in conjunction with an existing credential such as the ABN DSC or ATO certificate. Where the application involves new services, the use of a more widely used identifier and related credential would be appropriate. The following table gives some guidance on identifiers and credential type for the three access modes described above. Access mode New application Existing application Unattended applications system-to-system Online business applications Browser-based applications Identifier: ABN Credential: Gatekeeper type 3 certificate Identifier: ABN Credential: Gatekeeper type 3 certificate Identifier: ABN Credential: ABN DSC or other credential based on the assurance level requirements of the application Identifier: Existing Credential: Gatekeeper type 3 certificate Identifier: Existing Credential: Gatekeeper type 3 certificate Identifier: Existing Credential: ABN DSC or other credential based on the assurance level requirements, or agencyspecific credential The suggestion of high-assurance level Gatekeeper type 3 certificates for system-tosystem e-authentication ensures the ongoing integrity of these business-to-agency links, regardless of the nature and assurance level requirements of transactions that use the link.

26 5 Technology architecture Overview Figure 5.1 presents a high-level view of a candidate technology architecture for implementing identity management. This addresses the key concepts described in Section 3 and the business architecture requirements described in Section 4. Browser Interface Web Services Interface Web Servers (Portals) and Web Enabled Applications Applications Legacy Interfaces Authentication Service Permissions Enforcement Services Enrolment Services Browser Interface External Credential Issuers Credential Stores Audit Credential Stores Credential Stores Credential Issuers Credential Issuers Directory Policy Store KEY Standards-based Web Services protocols External Registration & Provisioning Services Agency Registration & Provisioning Services Identity Management Services Browser interface Legacy interfaces Browser Interface Figure 5.1 Candidate technology architecture for identity management Key elements of the architecture are outlined below. It is consistent with contemporary trends of separating core infrastructure elements from business applications in order to achieve consistency in approach, improved control, and operational cost savings, both within an agency and, prospectively, across government. It supports the contemporary practice of separating the business application from issues relating to e-authentication of the identity of users and coarse or mediumgrained management of access control to the business applications. It supports a shared services mode of operations from operational, technology, and e-authentication and authorisation model perspectives. Sharing could be implemented at an agency level, for clusters of agencies, or across government. It is neutral in respect to the e-authentication model selected (for example, federated, scheme, silo) and e-authentication mechanisms adopted. It supports sharing many aspects of the infrastructure (particularly authorisation services), regardless of the e-authentication model. It supports the use of directories and has the potential for all major services to use user directories for: o o o o information in respect to identity assurance levels associated with the identity e-authentication mechanisms, and roles encompassing access permissions to various data and services.

27 It enables identity management services to be made available to other delivery systems (such as IVR, mobile devices) as they emerge. This enables the use of common e-authentication mechanisms across delivery channels (where appropriate, and within the constraints of the channel) and control over access to various information and services. It recognises and supports the rapid evolution of standards in the area of identity management driven by OASIS 13 and other groups, particularly Liberty Alliance 14, aimed at enabling the interworking of various identity management implementations, both at a technology and an operational level. Through the use of web services, e-authentication and permissions management service requests can be satisfied regardless of origin, provided the requesting agent has permission to access these service. This is discussed more fully in Section 6. It supports multiple assurance levels for e-authentication, thereby enabling the application assurance requirements to be aligned with the e-authentication mechanism. It is possible for the same identity to have multiple methods of e- authentication, and hence step-up e-authentication 15 would be possible if required by different applications within the same session. This could be invoked from the application. Importantly, authorisation and access control remain independent of the e-authentication mechanism, provided e-authentication has been effected at the appropriate assurance level for the transaction or application. It supports credentials issued by government agencies and other recognised thirdparty credentials such as ABN DSCs and, potentially, the banking sector. Selection of a suitable credential type is described in the AGAF implementation guide for government. It supports and enforces separation of identity e-authentication from permission to access various application services. Enrolment for application services is a fundamental element of the architecture, which enables the dissociation of the authenticated identity from the business application s internal knowledge (such as company number, employee number) of the authenticated identity. It supports mapping/cross-reference of the authenticated identity to the application identifier, within the permissions enforcement service or within the business application. There are privacy implications for both approaches. It allows the business service owner to retain full control over access to the business application even in a shared-services environment. It encompasses a robust audit-and-controls structure and serves as a single point of audit and alert for access to agency or whole-of-government business systems. The major components of the architecture are described in Figure 5.2 below in the context of their operation. 13 Refer to < 14 Refer to < 15 Step-up e-authentication refers to a further e-authentication step, using a stronger e-authentication mechanism, so that the user is authenticated to a higher level of assurance. This is a typical requirement in the finance sector where a customer may access simple banking services such as account enquiry with a moderate assurance level (such as a password over Secure Sockets Layer), but would be required to provide a higher assurance credential for, say, a large-value payment transaction. In general, it may be more convenient for users to normally interact with one simple type of e- authentication mechanism such as a password, and use a more onerous e-authentication mechanism only when required. Such decisions are influenced by the constituency and the volume and risk profile of transactions supported by the service provider.

28 Registration and credential issuing services Figure 5.2 Credential issuers, and registration and provisioning services The AGAF implementation guide for government deals with selecting appropriate credentials for use within particular applications based upon, inter alia, the assurance level needs of the business application and the method of connection. Figure 5.3 reflects the major components that underpin the issuing of a credential. Authentication Assurance Level Credential Based Authentication Mechanism Identity Registration Method Electronic Record 4 3 Credential 2 1 Linkage Authentication Protocol Generates Figure 5.3 Credential-based e-authentication Issuers of credential are the authoritative source of information about credentials. They store information on: registration details (held within the electronic record see above) the e-authentication protocol the assurance level of the credential and registration processes, and the credential status (revoked, suspended etc.). Enrolment and business delegation services Enrolment services provide the ability to set permissions for users to access the various internal or business-facing application systems they are entitled to access. Interaction with enrolment services could be:

29 only by agency personnel, who set permissions for users, or by agency personnel to set general permissions for businesses, and also by authorised business users to control access permissions for other users in the business. Enrolment Services Browser Interface Directory Policy Store Figure 5.4 Enrolment services Details of currently established permissions are held in the policy store, while user details (typically including group membership and role information) are held in the directory. This is shown in Figure 5.4. Permissions enforcement services act on the permissions information in the policy store to enforce access control. This permissions information will include required e-authentication assurance levels. Enrolment services for browser-based applications must also accommodate the need to manage access by multiple representatives of a business and the need for these representatives to have differing privileges in respect to the business s dealings with an agency. It is expected that the enrolment services will support the concept of one or more delegated officers within a business who will be authorised to assign specific access permissions to other registered business representatives. These delegation mechanisms within a business should be independent of the e- authentication mechanisms adopted, although it is expected that the delegated representatives of a business would require high-assurance e-authentication credentials in order to ensure the integrity of the delegated enrolment processes.

30 E-authentication services Browser Interface Web Services Interface Web Servers (Portals) and Web Enabled Applications Applications Legacy Interfaces Authentication Service Credential Issuers Directory Figure 5.6 E-authentication service Figure 5.6 shows that the e-authentication service authenticates credentials presented in support of an identity (or other assertion). It is accessible via standards-based interfaces and can be called from web or legacy systems, provided they themselves have authenticated to the e-authentication service. The e-authentication service resolves identity of the issuer of the credential by referring to the user directory and requesting e-authentication from the relevant issuer, which is the authoritative processor of e-authentication requests. Permissions enforcement services Figure 5.7 Permissions enforcement services Roles and specific permissions associated with an identity are established during enrolment and stored in the user directory and policy store, as shown in Figure 5.7.

31 Permissions enforcement services can be called from any authenticated application requesting the current permissions of a previously authenticated identity. The enforcement services provide the necessary information to the calling application to enable it to allow or disallow access. This is based on: the policy for particular applications (established by the application administrators), and the roles of the identity held within the user directory (established during the enrolment process) and subsequent updates to permissions and roles. Audit services Audit services provide a single point for monitoring all processes for the entire identity management life cycle (establishment, amendment, transaction, decommissioning). Audit services underpin pre-emptive detection of unauthorised access attempts, after-the-fact detection and remediation of exception events, and specific combinations of events that were undetected at the time of execution. They form a core part of the evidence chain and may be required in dispute resolution or legal proceedings. Audit services are typically provided within identity management systems and incorporate well-defined interfaces for alert processing and forensic review of event logs. Key characteristics include: time sequence it is critical that all components communicate with the audit subsystems using synchronised clocks, as many defences to challenges to the veracity of the authorisation of transactions depend on being able to establish, beyond reasonable doubt, that events occurred in a particular sequence tamper resistance audit subsystems typically rely on tamper-resistant event logs that can be validated with respect to completeness (no undetected deleted events), integrity (event records are intact) and authenticity (records inserted only by authorised subsystems). Audit log files are typically cryptographically protected and time-stamped, with the cryptographic processes being completed with approved cryptographic devices. These log files serve as a persistent record of the evidence of events and are archived in line with the archival requirements of the related business applications, and data analysis or forensics or intelligent agents audit systems should incorporate data analysis or forensic tools, including intelligent agents that seek out exception-event sequences, or clusters of events that could present pointers to sophisticated attacks. These run as background activities in much the same way as other subsystems, such as anti-virus and intrusion detection systems. Shared service implementation options Opportunities for agencies to reduce capital and operational costs, provide consistency and scalability of services and support more rapid roll-out of services flow from developing shared infrastructure components. This approach avoids the requirement for each agency to implement expensive e-authentication and authorisation infrastructure for its own silo. Options presented include: sharing technical and business architectures across agencies (or at least within larger agencies) to ensure consistency of approach sharing knowledge and implementation expertise, potentially leading to the development of broad standards for e-authentication service delivery across government agreeing on major interface standards for e-authentication and related authorisation services

32 sharing technologies through: o standardising products or a set of products across government, or o agencies sharing particular implementations of these technologies through a gateway service, and all agencies sharing a common e-authentication service. A number of areas for agencies to consider in adopting any shared e-authentication and authorisation infrastructure are outlined below. Credential management A number of credentials can already be shared across government agencies, including ABN DSCs and, prospectively, HeSA health industry certificates. Audit services The availability of a centralised audit service for online access to government services could provide a powerful tool for the early detection of attacks across agencies. It could also provide an independently maintained tamper-resistant trail of activity to assist in problem determination and dispute resolution. Credential validation services To the extent that agencies rely upon externally issued credentials (for example, ABN DSCs), this provides an aggregated service for validating those credentials. This obviates the need for each agency to buy or build and operate such a service. While initiatives such as the Business Authentication Framework facility have foundered for a variety of reasons, this approach has worked within other jurisdictions and may well offer considerable benefits in the emerging AGAF environment. E-authentication services This covers software and operational services to support the processes required to complete e-authentication of identity, documents, transactions, etc. An example of this is the ATO s Common-use Signing Interface (CSI) required to enable users to digitally sign content from a browser platform. It is expected that additional and higher level services could be provided to support user e-authentication, transaction signature verification and, potentially, time-stamping or notary services. For certificate-based credentials, the CSI is considered a major enabler of rapid integration of e-authentication services within agency applications. Enrolment and mapping services The implementation of a credential (for example, username+password or digital certificate) that can be accepted across agencies requires each agency to carefully map this credential to a specific identity within their business applications. This mapping is established through an enrolment process during an agency s first interaction with a user. Ongoing translation of the credential to the application-specific identity might be completed within the application, or implemented separately from the application in, for example, a shared services gateway. There is potential to share the implementation of common functions across multiple agencies, with a gateway or portal providing the essential link between the credential and the various agency-specific identities applying to that credential. At a minimum, agencies should implement consistent user interfaces for the enrolment process.

33 Authorisation services A number of agencies have implemented (or are considering implementing) permissions management infrastructure to support the need to apply and enforce access controls for authenticated users. While agencies consider these services to be very closely aligned to their applications, and as such not really candidates for sharing, there is a trend among very large information services providers to treat permissions management as an infrastructure component, shared across all major applications within an enterprise. There is an opportunity to explore this within the Australian Government. Possible outcomes could include standardisation of an approach to managing and treating roles (which is emerging as a major issue in dealing effectively with delegates within a company, and agents acting for principals) as well as common designation of authorising officers within a business. In the medium term, it is expected that e-authentication services will be implemented as a hybrid of shared and agency-specific infrastructure, driven by individual agency priorities, existing internal systems implementations and ease of integration of shared infrastructure with agency applications. Moreover, agencies may elect to opt in or out of shared infrastructure as circumstances change. Accordingly, there is a need to identify and standardise key interfaces to e-authentication services. This is an immature but rapidly advancing area. There are a number of initiatives under way in the broader information systems area that are gaining substantial take-up from major vendors. Significant among these is the OASIS Security Assertion Markup Language (SAML) standard. These and other standards are described in more detail in Section 6.

34 6 Applicable standards Use of standards is more important for security protocols Implementing secure communications is complex and fraught with danger, even for the expert. Subtle unobvious weaknesses can be discovered and exploited. Security is only as good as the weakest aspect. Wherever possible, standards-based approaches should be used to help avoid security flaws. Reputable standards will have withstood the scrutiny of the worldwide information security community and are thus much less likely to contain subtle security weaknesses. In implementing new systems, it is often tempting to avoid the complexity of the standards and implement a much simpler approach. However, this should be avoided wherever possible. Using security standards has the following advantages: security flaws are unlikely in reputable, well-scrutinised protocols, but highly likely in home-grown protocols interoperability is generally simpler unnecessary re-invention is avoided extensibility is easier, without the need for fundamental redesign, and documentation is reduced by referencing published standards. Although the design of cryptographic algorithms and security protocols is complex and prone to subtle errors, choosing a strong, reputable, standards-based approach is comparatively simple. In practice therefore, most security vulnerabilities will be in the implementation, not in the security protocols or cryptographic algorithms. This is evidenced by the prevalence of vulnerabilities in commercial software (for example, buffer-overflow vulnerabilities) which cause vendors to continually release security patches. Typically, systems are implemented under significant time and budgetary pressure, generally with only one or two programmers intimately familiar with the code. These programmers typically have no specific security expertise. Thus a strategy for protecting against security flaws should include: using reputable standards-based cryptographic algorithms (these are generally defined by the security protocol standards) using appropriate length cryptographic keys (these are generally defined by the security protocol standards). For guidance see Australian Government information technology security manual (ACSI33), or ask the Defence Signals Directorate for advice using reputable standards-based security protocols using the latest formally released version of each standard that is well supported in available products avoiding custom extensions to standard protocols, but using them if needed rather than re-inventing new protocols using reputable, well-tested security subsystems and components rather than local implementation, and having best practice development strategies, including good system architecture design, a defensive security-aware stance, code review, and thorough testing.

35 Relevant standards bodies The following table outlines some of the industry standards bodies and other organisations currently most active in the access control area. W3C OASIS Liberty Project IETF Alliance The World Wide Web Consortium < Organisation for the Advancement of Structured Information Standards < Liberty Alliance Project < The Internet Engineering Task Force < RSA Laboratories (PKCS) RSA (research centre of RSA Security Inc.) Public-Key Cryptography Standards (PKCS) < Laboratories Useful standards for access control The following list of standards is provided as a guide only. Other standards not listed here may be more suitable in some environments. Choice of standards will be influenced by support in available products, fit with requirements, and new and evolving standards work. TLS (SSL, HTTPS) Transport Layer Security (the successor to Secure Sockets Layer (SSL) and the S (secure) in HTTPS when used with HTTP) This is the protocol very commonly used to secure communications between a browser and a web server. The protocol provides: encryption of data for confidentiality message e-authentication for data integrity e-authentication of the web server (this is optional but is normally used) optional e-authentication of the user if client certificates are used. When client certificates are not used (the typical case), other types of e-authentication (for example, passwords) are afforded protection by the encryption and data integrity of TLS. See < (and RFC3546).

36 XML signature XML encryption S/MIME SAML XACML WSS (WS Security) Extensible Markup Language signature XML signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere. XML signatures are most suited to web services or thick-client interaction. The ability to include data by reference allows for significantly reduced message sizes where static data common to many transactions must be included within the signed data (for example, standard terms and conditions, policy). See < Extensible Markup Language encryption XML encryption specifies a process for encrypting data and representing the result in XML. The data may be arbitrary data (including an XML document), an XML element or XML element content. The result of encrypting data is an XML encryption element that contains or references the cipher data. XML encryption is most suited to web services or thick-client interaction. Considerable flexibility is provided, allowing encryption of only the sensitive portions of a message, which can significantly improve performance. See < Secure MIME (Multipurpose Internet Mail Extensions) S/MIME is the most commonly supported secure standard. It provides for digital signing and/or encryption of data based on the MIME (Multipurpose Internet Mail Extensions) standards. S/MIME is most useful for unstructured human-to-human correspondence, or for machine-to-human correspondence. It can also be used for machineto-machine transactions, although XML signatures and XML encryption are considered more suitable and provide more flexibility. See < Security Assertion Markup Language SAML is an XML framework for exchanging authentication and authorization information Although SAML also covers authorisation to some extent, its primary focus is on passing e-authentication information. The later XACML standard is a more complete protocol for passing authorisation information. See < Extensible Access Control Markup Language XACML allows permissions policy enforcement points to query permissions policy decision points, which can in turn query other policy decision points. This allows for centralised permissions enforcement, and centralised, collaborative or devolved permissions management. See < Web Services Security WSS specifies message integrity and confidentiality for server-toserver messaging using SOAP (Simple Object Access Protocol < It allows for a variety of e-authentication approaches including username+password, digital certificates, etc. E- authentication information can be exchanged using either Kerberos <web.mit.edu/ kerberos/www/> or SAML. See <

37 Liberty Alliance Project This consortium focuses on specifications and guidelines to support Federated Identity Management, building on available standards. Federated Identity Management means loosely coupled e- authentication, authorisation and access control across organisational boundaries. The protocols and guides have a strong focus on preserving user privacy. See < Applicability Figure 6.1 suggests an approach to applying standards to the access control layers discussed in Section 3 and illustrated below. Business application Business application systems systems Authorisation Layer Authorisation Layer Fine grained Access Control Authentication Layer Authentication Layer Coarse grained Figure 6.1 Access control layers Layer Business application systems Authorisation E-authentication Applicable security standards Applicable standards will depend on the application XACML (SAML) WSS Liberty Alliance SAML TLS with client certificates S/MIME XML signatures

38 Security purpose or external technology matrix Section 4 discusses the range of access modes agencies are using or will probably use in future. The following table maps relevant standards mentioned above against security purpose for commonly used external communications environments. Note that there are other unlisted alternatives in each case. This table covers only protocols used between external systems and the service provider. It does not cover protocols used within the e-authentication and authorisation layers, or for communications between service providers and credential providers. Security purpose E- authentication Message e- authentication (integrity) Signing (nonrepudiation) Browser to web server Thick-client to application TLS with client S/MIME XML certificates signatures TLS S/MIME XML signatures XML signatures S/MIME XML (by using signatures applet) Confidentiality TLS S/MIME XML encryption Web services (server-toserver) XML signatures XML signatures XML signatures XML encryption

39 Summary of infrastructure standards or protocols Figure 6.2 (adapted from Figure 5.1) indicates how some of the standards or protocols are used within the e-authentication and authorisation infrastructure. Browser Interface Web Services Interface Web Servers (Portals) and Web Enabled Applications Applications Legacy Interfaces Authentication Service Permissions Enforcement Services Enrolment Services Browser Interface KEY External Credential Issuers Credential Stores Audit Credential Stores Credential Stores Credential Issuers Credential Issuers Directory Policy Store Standards-based Web Services protocols Browser interface Legacy interfaces TLS External Registration & Provisioning Services Agency Registration & Provisioning Services Identity Management Services XML signatures & XML Encryption SAML XACML Browser Interface LDAP Figure 6.2 Architecture with overlaid standards Note that other protocols not shown here will also be needed across each connection at different or equivalent levels of the protocol stack. For example, where SAML is shown: a) the protocol stack might be IP TCP HTTP SOAP SAML. b) other web services protocols may be used over SOAP in addition to SAML, such as key exchange protocols, business process protocols (for example, from the ebxml suite) c) other security protocols may be used at lower levels of the protocol stack to secure the connection between servers, for example: L2TP IP TCP HTTP SOAP SAML or IP IPSEC TCP HTTP SOAP SAML or IP TCP TLS HTTP SOAP SAML.