Review-sheep-G071-UKIRIS.xlsx

	B	C	D	E	F
1
2	AARC-G071 Guidelines for Secure Operation of Attribute Authorities and issuers of statements for entities review sheet
3	Operator	STFC RAL			Peers:
4	AA scope	UK-IRIS			EUgridPMA56 attendees
5	Model	Push (OIDC)
6	Product(s)	Indigo IAM
7	Interop	OIDC, SAML supported on upstream side
8
9	Item	Description	Status	References	Review comments
10			OK, PARTIAL, N/A	link to document(s) and/or description of implementation, or substantiation	suggestions (by self or peers) on recommendations, next steps, and planned changes

11	AN-1	Identifiers of the AA Operator and the AA must both be non-reassigned and globally unique.	PARTIAL	OpenID connect sub does that implicitly within the scope of the authority. The IAM instance is registered with the federation. For the federation, the URL of the EntityID (https://iris-iam.stfc.ac.uk/sp-entityID/) is unique beause the hostname is unique. "iss" is also unique in the token and represent the community. Domain name of the "iss" URL ("https://iris-iam.stfc.ac.uk/") is based off the iris-iam.stfc.ac.uk domain.	Also relevant are AARC-G026 and AARC-G069. This is broader than just "iss". And these are mandatory under AEGIS. Each attribute authority has a defined namespace. the subject and the group membership should also be unique. Both are in scope of AN-1. This is for interoperation with other, sub-only, protocols that do not use iss+sub uniqueness. So this combined iss+sub by using sub@iss-scope The Indico IAM implementation uses the user identifier is the overall identifier generated at registration time. Every user within each instance thus is unique, but it it not unique without further tagging.
12	AN-1.2	In addition, the identifier of the Community should be unique.	PARTIAL	This is the "iss" URL	usually a URN is used
13	AN-1.3	Community User Identifiers for subjects and attributes should be chosen in accordance with the AARC Guidelines and the Community Membership Management policy [AARC-G003].	PARTIAL	User identifier follows G026 and communicated as an opaque identifer over a URN Could be done for group names as well - IRIS will review	G026 and G069 should be considered as well
14	AN-1.4	The AA must use a defined naming scheme for subjects and attributes.	OK
15	AN-1.5	Subject identifiers must be non-reassigned and unique within an AA.	OK	Implicit in IAM
16	AMR-1	The Community must define and document the semantics, lifecycle, data protection, and release policy of attributes stored or asserted by the AA.	'EXISTS' (using SCI terminology)	Unclear what the requirement is on the AA operator to 'force' this on the supported communities? The IRIS can by policy put this on the VOs. IRIS can define a default, that can be changes on a per-VO basis. IRIS is working on a community management policy - not documented yet	When seen in combination with AMR-2, this is a need for the AA operator to act in accordance with the VO's wishes. The top-level IRIS policy defines this now. This should be done in consultation with the communities
17	AMR-1.2	semantics	PARTIAL	defined but not documented	Do the community managers know?
18	AMR-1.3	lifecycle	PARTIAL	defined but not documented	Do the community managers know?
19	AMR-1.4	data protection	OK	"the ICO is happy" https://iris-iam.stfc.ac.uk/privacypolicy/	Fine - it may not need registration with the ICO. Definition of the controller role is unclear on a community basis
20	AMR-1.5	attribute release policy	PARTIAL	shown to the user during attribute release
21	AMR-2	The AA Operator must implement the community definitions as defined and documented, for all the AAs it operates.	OK	by definition if AMR-1 is undefined
22	AMR-3	It is recommended that the AA Operator provide a capability for the community to publish documents defining the attribute set and the semantics used by the community, for the benefit of Relying Parties.	OK	There is no such page for IRIS-IAM to be discussed next week at the IAM workshop	accepted Does the user get asked again for permission if the set of attributes changes
23	AMR-4	The AA must only issue assertions or release attributes in accordance with the policies that are applicable to the Community	OK	by definition if AMR-1 is undefined
24	AMR-5	When a community engages multiple AA Operators or operates multiple AAs, the community must ensure that the assertions issued are consistent between all issuers.	N/A	not applicable to IRIS	cannot be reviewed on a per-AA operator basis with multiple operators
25	AMR-6	The community should ensure that within one assertion issued attributes are consistent.	N/A		cannot be reviewed on a per-AA operator basis Having only positive capabilities (no denials) also mitigates this
26	AAS-1	Assertions provided by an AA must be integrity-protected. They must be signed by the identified AA, or be transmitted over an integrity-protected channel where the server has been authenticated, and preferably both.	OK	Everything is signed, and there is TLS transport channel (using a client-determined domain name and DCV). Both are satisfied	The authentication of the server is based on the DNS resolution in the client and matching it with the transport server certificate offered. The client is authenticated by the server is based on client-id (and maybe client-secret, or public clients wih 'explicit' release)
27	AAS-2	In addition to meeting its own regulatory obligations, the AA must respect data protection requirements of the Community.	OK	The IRIS privacy policy governs the community requirements. No community has expressed data protction requirements. Ergo: there are none For the SRCnet in the future, the SKAO (could) be the controller, and IRIS just the processor. But that will likely on a dedicated instance.	The data controller for this 'operational' data is IRIS, i.e. UKRI. In other communnities like SRAM/NL, the controller is the community (actually, the organisation bying the service) eduTEAMS is usually a processor, and there are separate deployment for e.g. PANOSC or LSAAI. Where it becomes 'messy', is in the shared instance for multiple communities. Then data separation becomes very complex.
28	AAS-2.2	It is recommended that AAs require client authentication, in addition to the encryption of the messages and the communication channel.	OK	Registred clients are enouraged. Public clients are still registred. In cases like userInfo, it is not encrypted.	For eduTEAMS, see e.g. https://wiki.geant.org/display/eduTEAMS/OIDC+Client+Configuration+Options Encryption would require client configuration with a (shared) secret. Not usually done, also not in IAM
29	AAS-2.3	The AA should not send more data than required by the RP.	OK	Only sends requested scopes
30	AAS-3	If an AA Operator issues assertions containing a lifetime, this lifetime must be compliant with the Community policies, as short as reasonably possible, and the assertion must not be valid beyond the validity period of the attributes it contains. The Community Management is responsible for the content of the assertion, as issued, during its entire lifetime	OK	All tokens are valid for 30 min	Refresh tokens are not yet used in IRIS IAM (not enabled yet)
31	AAS-4	Re-issuance of assertions must be based on information held in the AA at the time of re-issuance.	OK	Sensible, but not issued at the moment	See above, but if the userinfo values change, and the value is more sensitive, should that new value be released?! Ongoing discussion in AppInt - when this concludes, publish as an AARC Guideline!
32	OE-1	Through its personnel or by contractual measures, the AA Operator should ensure appropriate controls are in place over the security context.	OK	Limited RAL Staff Access to Hosts
33	OE-2	The AA must be located in a physically secure environment where access is controlled and limited to specific trained personnel.	OK	Secure RAL DC
34	OE-3	The protections on the AA and its operational environment, including the credentials of the AA administrators and operators, should meet or exceed the requirements of all of the communities hosted in the AA.	OK	No communities require MFA etc at this stage
35	KM-1	A key used to protect assertions should be dedicated to assertion protection functions.	OK	Signing key only uised for signing
36	KM-2	Keys must not be shared between AA Operators. A single AA Operator may use the same signing key for multiple AAs. Where multiple AAs are under the control of a single AA operator but located in physically distributed locations, the key must only be transported using secure protocols.	OK	Only one, so no shared key
37	KM-3	Keys must have a protection strength equivalent to 112 bits (symmetric) or higher.	OK	2048 key
38	KM-4	Keys must only be accessible by the service and by trained personnel subject to procedural controls.	OK	Access only to T1 admin users
39	KM-5	AA Operators are recommended to use an HSM to store signing keys.	No	Needs review and implementation
40	KM-5.2	When using software-based private keys, such keys must be suitably protected by the operating system. Keys should not be held unencrypted on persistent storage protected solely by database, storage and file system level permissions.	No	See above
41	NET-1	The network to which the AA system is connected must be highly protected and suitably monitored.	OK	Secure RAL site network
42	SITE-1	The AA Operator must ensure appropriate site security controls are in place and maintained in a state consistent with the security requirements of the hosted Communities.	OK	No communicated requirements from Communities, but access controlled RAL site
43	MD-1	The AA Operator must publish, to the Community and related Relying Parties, at least the following metadata for each AA it hosts [generic requirement: the AA operator has a meta-data publishing end-point]	OK	Metadata available at /metadata
44	MD-1.1a	administrative contact details for the AA Operator, including at least one role-based email address and one postal contact address	OK
45	MD-1.1b	an operational security contact for the AA Operator, being at least a role-based email address but preferably including a telephone number	PARTIAL	Currently direct to my (Tom) email
46	MD-1.1c	cryptographic key material required to verify signed messages, where that is required to validate issued attribute assertions	OK
47	MD-2	It is recommended that the AA Operator publishes, where available [generic requirement: the AA operator has a web site]
48	MD-2.1a	such validated trust marks as are relevant to the evaluation of the security and trust of the AA by the Communities, Identity Providers, and Relying Parties		In metadata, marks not published on website
49	MD-2.1b	a (web) URL to a general information web page about the Community.	OK	Outward links to main IRIS site, help and about pages at service level (IRIS set of communities)
50	MD-3	The AA Operator should provide a means to validate the integrity of its roots of trust.	OK	EV Cert for host
51	AR-1	The attributes in the AA and their binding to subjects must be verifiable and assessable.	OK	Group mangement decisions are logged
52	AR-2	The AA Operator must log, for the purpose of traceability in support of security incident response, where the AA provides relevant attributes, at least the following for all of its hosted AAs
53	AR-2.1a	all requests for attributes and all issued attribute assertions, to the extent that they are needed to allow traceability of attribute release to individuals during incident response by receiving qualified Relying Parties	OK	Logs for token requests in/out
54	AR-2.1b	any configuration change to the AA relevant to the access control of the attribute repository	OK	Aquilon/Quattor used for configuration management of IAM host
55	AR-2.1c	any change affecting the binding between subjects and attributes	OK	ID change, group and linking events recorded
56	AR-2.2	The AA Operator, in its published privacy and confidentiality policies must permit logging as required above.	OK	Policy covers logging and traceability
57	AR-3	The AA Operator must log at least the following for its AA issuance systems, for the purposes of incident response:
58	AR-3.1a	all login, logout, reboot, and key activation events of the issuing system	OK
59	AR-3.1b	changes to the configuration of the issuing system	OK	Aquilon/Quattor
60	AR-4	The AA Operator must keep records regarding attribute release and its issuance systems after termination of the effects of the auditable events for as long as required by the Community and any Relying Parties that have entered into an agreement with the AA Operator, and as required by applicable legislation.	OK	No guidance from Community/Relying, follows central logging within T1
61	AR-5	The AA operator must disclose and discuss, on request, those aspects of their operational environment that are relevant to the evaluation of the security and trust by the Communities and Relying Parties	OK	Would happily do so, on topics such as High Availability etc
62	AR-6	The AA Operator must be able and willing to collaborate with affected organisations in the management of a security incident	OK	Asserting SIRTFI
63	AR-7	The AA Operator should review roles, rights, and access of its staff at least once per year	OK	Current small admin pool, changed as needed. A review of group managers at a scheduled period would be sensible
64	PC-1	The AA operator must define and publish a privacy and data release policy, and that policy must be compatible with the assertions that it issues, and be compliant with relevant legislation	OK	Attributes which may be released are detailed in policy
65	BCDR-1	The AA Operator must have a compromise and disaster recovery procedure ...	OK	IRIS Incident Response Procedure, Hardware disaster is managed at Departmental/DC level
66	BCDR-1.2	... and a business continuity plan	PARTIAL	Current best effort - planned work for HA due to commence 03/23. 4 person operational team operating "9-5" 5/7
67	BCDR-2	The business continuity and disaster recovery plan must be compatible with the requirements of the hosted Communities.	PARTIAL	HA work being driven by community requirements, but not currently in place
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100