)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"c8264ed03cb1fd7569f626a513cea02d74d4e562","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Simplified Mapping for Federated Authentication"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"It is proposed that the mapping API for mapping external federated attributes to internal groups and users should be simplified to be independent of the identity provider."},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"Change-Id: Ifbdebe5a7ccb258d2fc862ed51af3ded55c69153"},{"line_number":12,"context_line":"Co-Authored-By: David Chadwick \u003cd.w.chadwick@kent.ac.uk\u003e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"1ae5cdf2_e59e0eb8","line":9,"updated":"2014-06-16 17:58:18.000000000","message":"NIT: suggest keeping description lines under 74 characters.","commit_id":"20256a768ec4d0f64264ad3d180d285011b0234e"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"c8264ed03cb1fd7569f626a513cea02d74d4e562","unresolved":false,"context_lines":[{"line_number":8,"context_line":""},{"line_number":9,"context_line":"It is proposed that the mapping API for mapping external federated attributes to internal groups and users should be simplified to be independent of the identity provider."},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"Change-Id: Ifbdebe5a7ccb258d2fc862ed51af3ded55c69153"},{"line_number":12,"context_line":"Co-Authored-By: David Chadwick \u003cd.w.chadwick@kent.ac.uk\u003e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"1ae5cdf2_c580324c","line":11,"updated":"2014-06-16 17:58:18.000000000","message":"link \n\n    bp simplified-mapping-api","commit_id":"20256a768ec4d0f64264ad3d180d285011b0234e"}],"specs/juno/simplified-mapping.rst":[{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"c8264ed03cb1fd7569f626a513cea02d74d4e562","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Simplified Mapping API"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"`bp simplified-mapping-api \u003chttps://blueprints.launchpad.net/keystone/+spec/simplified-mapping-api\u003e`_"},{"line_number":12,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_05c93aac","line":9,"updated":"2014-06-16 17:58:18.000000000","message":"header should be the same length as title: \n\n    \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n    Simplified Mapping API\n    \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d","commit_id":"20256a768ec4d0f64264ad3d180d285011b0234e"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"c8264ed03cb1fd7569f626a513cea02d74d4e562","unresolved":false,"context_lines":[{"line_number":11,"context_line":"`bp simplified-mapping-api \u003chttps://blueprints.launchpad.net/keystone/+spec/simplified-mapping-api\u003e`_"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"We propose a simplified mapping system dependent on the trusted attribute API"},{"line_number":14,"context_line":"`spec : \u003chttps://blueprints.launchpad.net/keystone/+spec/trusted-attribute-issuing-policy\u003e`"},{"line_number":15,"context_line":""},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Problem Description"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_c53592a9","line":14,"updated":"2014-06-16 17:58:18.000000000","message":"This could be removed since it is already in the \u0027Dependencies\u0027 section.","commit_id":"20256a768ec4d0f64264ad3d180d285011b0234e"},{"author":{"_account_id":6482,"name":"Steve Martinelli","email":"s.martinelli@gmail.com","username":"stevemar"},"change_message_id":"773bf7347df10c30cd93041bba9f36439664f380","unresolved":false,"context_lines":[{"line_number":24,"context_line":""},{"line_number":25,"context_line":"2. Mapping rules are currently associated with an IDP. This means each rule to"},{"line_number":26,"context_line":"map an external attribute must be written once for each IDP which issues the"},{"line_number":27,"context_line":"attribute"},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Proposed Change"},{"line_number":30,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_541e8e0e","line":27,"updated":"2014-06-16 18:29:55.000000000","message":"\"must be written once for each IDP\"\nAre you saying that for the current design you would need to define X mappings for X idps?\n\n\nBecause that\u0027s not what is currently implemented or designed, in the current design, say you define a mapping: UNI_MAPS via PUT /OS-FEDERATION/mappings\n\nThen you want to associate the mapping with two SAML IdPs (KENT and YORK), to re-use the mapping you would just issue the following:\n\n  PUT /OS-FEDERATION/identity_providers/KENT/protocols/saml2\n\n  {\n    \"mapping_id\": \"UNI_MAPS\"\n  }\n\n  PUT /OS-FEDERATION/identity_providers/YORK/protocols/saml2\n\n  {\n    \"mapping_id\": \"UNI_MAPS\"\n  }\n\n\nIf I\u0027m completely off base, let me know.","commit_id":"20256a768ec4d0f64264ad3d180d285011b0234e"},{"author":{"_account_id":5956,"name":"Kristy Siu","email":"kwss@kent.ac.uk","username":"kwss"},"change_message_id":"be2bc15ab573cb1eaf2ef0e0bc9811adaa3e9430","unresolved":false,"context_lines":[{"line_number":24,"context_line":""},{"line_number":25,"context_line":"2. Mapping rules are currently associated with an IDP. This means each rule to"},{"line_number":26,"context_line":"map an external attribute must be written once for each IDP which issues the"},{"line_number":27,"context_line":"attribute"},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Proposed Change"},{"line_number":30,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_3a7b7bf5","line":27,"in_reply_to":"1ae5cdf2_541e8e0e","updated":"2014-06-17 17:41:54.000000000","message":"Sorry, I\u0027ll reword this in the next patch to be clearer, I\u0027m talking about the individual rules that make up a mapping rather than the mapping policy itself. So you define a rule which says that NameID should map to user, eduPersonAffiliation\u003dKent should map to group1 and eduPersonAffiliation\u003dYork should map to group2. Now if I want two policies, one for York and one for Kent that map the NameID and the affiliation to user and the appropriate group, then the rule for NameID must be written twice. Expand this example to include all of the organisations in a large federation and you might have to add the NameID rule to hundreds of policies - one for each IdP. If we add another attribute into the mix, then it easily becomes unmanageable for an administrator creating these policies. Hope this is clearer.","commit_id":"20256a768ec4d0f64264ad3d180d285011b0234e"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"c8264ed03cb1fd7569f626a513cea02d74d4e562","unresolved":false,"context_lines":[{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Proposed Change"},{"line_number":30,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":31,"context_line":"The Trusted Attributes Policy API could help address the first issue by ensuring"},{"line_number":32,"context_line":"that only attributes which are explicitly trusted will be processed by the"},{"line_number":33,"context_line":"Mapping API."},{"line_number":34,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_6ef3bb9f","line":31,"updated":"2014-06-16 17:58:18.000000000","message":"include a link to the API?","commit_id":"20256a768ec4d0f64264ad3d180d285011b0234e"},{"author":{"_account_id":5956,"name":"Kristy Siu","email":"kwss@kent.ac.uk","username":"kwss"},"change_message_id":"be2bc15ab573cb1eaf2ef0e0bc9811adaa3e9430","unresolved":false,"context_lines":[{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Proposed Change"},{"line_number":30,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":31,"context_line":"The Trusted Attributes Policy API could help address the first issue by ensuring"},{"line_number":32,"context_line":"that only attributes which are explicitly trusted will be processed by the"},{"line_number":33,"context_line":"Mapping API."},{"line_number":34,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_3a4c5b9d","line":31,"in_reply_to":"1ae5cdf2_6ef3bb9f","updated":"2014-06-17 17:41:54.000000000","message":"Will do.","commit_id":"20256a768ec4d0f64264ad3d180d285011b0234e"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"c8264ed03cb1fd7569f626a513cea02d74d4e562","unresolved":false,"context_lines":[{"line_number":32,"context_line":"that only attributes which are explicitly trusted will be processed by the"},{"line_number":33,"context_line":"Mapping API."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Following on from this, mapping rules can be made independent of IDPs and"},{"line_number":36,"context_line":"all rules can be applied to the return Auth Context of federated authentication"},{"line_number":37,"context_line":"plugins."},{"line_number":38,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_59ade7e9","line":35,"updated":"2014-06-16 17:58:18.000000000","message":"IdPs*","commit_id":"20256a768ec4d0f64264ad3d180d285011b0234e"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"c8264ed03cb1fd7569f626a513cea02d74d4e562","unresolved":false,"context_lines":[{"line_number":37,"context_line":"plugins."},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"The change would involve changing the flow of federated authentication to use a"},{"line_number":40,"context_line":"3 stage filtering process."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"1. Trusted Identity Provider filter"},{"line_number":43,"context_line":"Firstly, each trusted identity provider should be added (this is the current"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_eef18b6b","line":40,"updated":"2014-06-16 17:58:18.000000000","message":"Lines should be less than 80 characters.","commit_id":"20256a768ec4d0f64264ad3d180d285011b0234e"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"c8264ed03cb1fd7569f626a513cea02d74d4e562","unresolved":false,"context_lines":[{"line_number":84,"context_line":""},{"line_number":85,"context_line":"    {"},{"line_number":86,"context_line":"        \"protocol\": {"},{"line_number":87,"context_line":"            \"mapping_id\": \"xyz234\""},{"line_number":88,"context_line":"        }"},{"line_number":89,"context_line":"    }"},{"line_number":90,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_b9b98b17","line":87,"updated":"2014-06-16 17:58:18.000000000","message":"is this mapping ID represented by uuid? If so, I suggest using the first six characters of a valid uuid. Similar to what we already use in the Identity V3 API spec: \n\nhttps://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3.md#list-services-get-services","commit_id":"20256a768ec4d0f64264ad3d180d285011b0234e"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"c8264ed03cb1fd7569f626a513cea02d74d4e562","unresolved":false,"context_lines":[{"line_number":304,"context_line":"-----------"},{"line_number":305,"context_line":""},{"line_number":306,"context_line":"Primary assignee:"},{"line_number":307,"context_line":"  Kristy Siu Launchpad ID: kwss@kent.ac.uk"},{"line_number":308,"context_line":""},{"line_number":309,"context_line":"Other contributors:"},{"line_number":310,"context_line":"  David Chadwick Launchpad ID: d.w.chadwick@kent.ac.uk"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_3913bb0e","line":307,"updated":"2014-06-16 17:58:18.000000000","message":"Do you have an IRC nick that could be included here?","commit_id":"20256a768ec4d0f64264ad3d180d285011b0234e"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"c8264ed03cb1fd7569f626a513cea02d74d4e562","unresolved":false,"context_lines":[{"line_number":326,"context_line":"Testing"},{"line_number":327,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":328,"context_line":""},{"line_number":329,"context_line":"Updated unit tests for the Mapping API."},{"line_number":330,"context_line":""},{"line_number":331,"context_line":""},{"line_number":332,"context_line":"Documentation Impact"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_59f7a7d4","line":329,"updated":"2014-06-16 17:58:18.000000000","message":"What about tempest test cases.","commit_id":"20256a768ec4d0f64264ad3d180d285011b0234e"},{"author":{"_account_id":6486,"name":"Brant Knudson","email":"blk@acm.org","username":"blk-u"},"change_message_id":"162b118a45cacfea5ab1e5caba2a45ac7939ae8d","unresolved":false,"context_lines":[{"line_number":21,"context_line":""},{"line_number":22,"context_line":"2. Mapping rules are currently associated with an IDP. This means each rule to"},{"line_number":23,"context_line":"map an external attribute must be written once for each IDP which issues the"},{"line_number":24,"context_line":"attribute."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"**Example**:"},{"line_number":27,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_bf7173ad","line":24,"updated":"2014-06-23 20:28:05.000000000","message":"you can use the same mapping_id for multiple providers. https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3-os-federation-ext.md#add-a-supported-protocol-and-attribute-mapping-combination-to-an-identity-provider-put-os-federationidentity_providersidp_idprotocolsprotocol_id","commit_id":"9e0065316101297b5a6e26ebe3d00e38c06d1324"},{"author":{"_account_id":6486,"name":"Brant Knudson","email":"blk@acm.org","username":"blk-u"},"change_message_id":"162b118a45cacfea5ab1e5caba2a45ac7939ae8d","unresolved":false,"context_lines":[{"line_number":22,"context_line":"2. Mapping rules are currently associated with an IDP. This means each rule to"},{"line_number":23,"context_line":"map an external attribute must be written once for each IDP which issues the"},{"line_number":24,"context_line":"attribute."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"**Example**:"},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"A cloud service provider (CSP) wishes to provide access to resources for the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_1fa8a7da","line":25,"updated":"2014-06-23 20:28:05.000000000","message":"This seems like it could be split up into 2 simpler proposals.","commit_id":"9e0065316101297b5a6e26ebe3d00e38c06d1324"},{"author":{"_account_id":6486,"name":"Brant Knudson","email":"blk@acm.org","username":"blk-u"},"change_message_id":"162b118a45cacfea5ab1e5caba2a45ac7939ae8d","unresolved":false,"context_lines":[{"line_number":30,"context_line":"organisation issues a unique identifier for their members: NameID and an"},{"line_number":31,"context_line":"affiliation attribute: eduPersonAffiliation. For each identity provider the CSP"},{"line_number":32,"context_line":"would like to map NameID to user (regardless of value). Additionally, users"},{"line_number":33,"context_line":"from each organisation should be given access to a group, e.g. groupKent and "},{"line_number":34,"context_line":"groupYork for Kent and York respectively."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"In the current system, the CSP must create two mappings, each with two rules:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_5f906f96","line":33,"updated":"2014-06-23 20:28:05.000000000","message":"clean up trailing whitespace","commit_id":"9e0065316101297b5a6e26ebe3d00e38c06d1324"},{"author":{"_account_id":8978,"name":"Marek Denis","email":"marek.denis+openstack@gmail.com","username":"marek-denis"},"change_message_id":"615fa64540ffdaf4daeefaa5e53d629fc8d29874","unresolved":false,"context_lines":[{"line_number":47,"context_line":""},{"line_number":48,"context_line":"1. NameID mapped to user"},{"line_number":49,"context_line":"2. eduPersonAffiliation\u003dkent mapped to groupKent"},{"line_number":50,"context_line":"3. eduPersonAffiliation\u003dyork mapped to groupYork"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"In a small scale, the gains do not seem to be extensive, but if we consider an"},{"line_number":53,"context_line":"example using a large federation such as the UK Access Management Federation"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_57dbe64e","line":50,"updated":"2014-06-24 08:41:18.000000000","message":"I still don\u0027t want your proposal to completely replace the current one . Mainly because this makes one single, global set of rules. While it may be useful in a cloud within one federation, like AMF I think we should keep in mind public cloud providers usecase. They may want to share some resources with many, independent cloud providers. This means many, small \u0027federations\u0027. And then I think there might be a viable usecase, where IdP_PEPSI issues param, say Drinks\u003dsoda and that should be mapped to group PEPSI_SODAS group, and IdP_COLA also issues parameter Drinks\u003dsoda and this should map to group COLA_SODAS. This is easy to configure for current state, and how could it be done for a global set of rules? I think I don\u0027t want to mention that Pepsi and Cola don\u0027t want to share any information between themselves.","commit_id":"9e0065316101297b5a6e26ebe3d00e38c06d1324"},{"author":{"_account_id":7186,"name":"Matthieu Huin","email":"mhuin@redhat.com","username":"mhu"},"change_message_id":"a3070b65d4371be2912d089a424df09764f2bc81","unresolved":false,"context_lines":[{"line_number":47,"context_line":""},{"line_number":48,"context_line":"1. NameID mapped to user"},{"line_number":49,"context_line":"2. eduPersonAffiliation\u003dkent mapped to groupKent"},{"line_number":50,"context_line":"3. eduPersonAffiliation\u003dyork mapped to groupYork"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"In a small scale, the gains do not seem to be extensive, but if we consider an"},{"line_number":53,"context_line":"example using a large federation such as the UK Access Management Federation"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_c598e577","line":50,"in_reply_to":"1ae5cdf2_57dbe64e","updated":"2014-06-25 14:53:13.000000000","message":"++ about the public clouds use cases. This change makes it significantly more difficult to maintain multiple federations.","commit_id":"9e0065316101297b5a6e26ebe3d00e38c06d1324"},{"author":{"_account_id":8978,"name":"Marek Denis","email":"marek.denis+openstack@gmail.com","username":"marek-denis"},"change_message_id":"615fa64540ffdaf4daeefaa5e53d629fc8d29874","unresolved":false,"context_lines":[{"line_number":48,"context_line":"1. NameID mapped to user"},{"line_number":49,"context_line":"2. eduPersonAffiliation\u003dkent mapped to groupKent"},{"line_number":50,"context_line":"3. eduPersonAffiliation\u003dyork mapped to groupYork"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"In a small scale, the gains do not seem to be extensive, but if we consider an"},{"line_number":53,"context_line":"example using a large federation such as the UK Access Management Federation"},{"line_number":54,"context_line":"with over a hundred members, then 2n compared to n+1 where n is number of"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_5a6cebd0","line":51,"updated":"2014-06-24 08:41:18.000000000","message":"Hmm, just opened mapping API again and I started wondering why do you think your proposed \u0027global\u0027 rules will not work:\n\nrules : [ \u003cmap NameID to user\u003e, \u003cEduPersonAffiliation\u003dkent : groupKent\u003e, \u003cEduPersonAffiliation\u003dyork: groupYork\u003e ] \n\nand later reuse this mapping Id among multiple IdP within AMF. Mapping engine should iterate over rules, and return groups from rules that match.\nDoesn\u0027t 3 pieces rules look similar to what we have already in fixtures for tests: https://github.com/openstack/keystone/blob/master/keystone/tests/mapping_fixtures.py#L23 ?","commit_id":"9e0065316101297b5a6e26ebe3d00e38c06d1324"},{"author":{"_account_id":6486,"name":"Brant Knudson","email":"blk@acm.org","username":"blk-u"},"change_message_id":"162b118a45cacfea5ab1e5caba2a45ac7939ae8d","unresolved":false,"context_lines":[{"line_number":56,"context_line":""},{"line_number":57,"context_line":"Proposed Change"},{"line_number":58,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":59,"context_line":"The Trusted Attributes Policy API could help address the first issue by"},{"line_number":60,"context_line":"ensuring that only attributes which are explicitly trusted will be processed by"},{"line_number":61,"context_line":"the Mapping API."},{"line_number":62,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_7fbb6b0f","line":59,"updated":"2014-06-23 20:28:05.000000000","message":"suggest make this a link: `Trusted Attributes Policy`_","commit_id":"9e0065316101297b5a6e26ebe3d00e38c06d1324"},{"author":{"_account_id":6486,"name":"Brant Knudson","email":"blk@acm.org","username":"blk-u"},"change_message_id":"162b118a45cacfea5ab1e5caba2a45ac7939ae8d","unresolved":false,"context_lines":[{"line_number":62,"context_line":""},{"line_number":63,"context_line":"`Trusted Attributes Policy API \u003chttps://review.openstack.org/#/c/100279/\u003e`_"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"Following on from this, mapping rules can be made independent of IdPs and"},{"line_number":66,"context_line":"all rules can be applied to the return Auth Context of federated authentication"},{"line_number":67,"context_line":"plugins."},{"line_number":68,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_1f126709","line":65,"updated":"2014-06-23 20:28:05.000000000","message":"From the OS-FEDERATION spec, looks like mapping rules are already independent of IdPs.","commit_id":"9e0065316101297b5a6e26ebe3d00e38c06d1324"},{"author":{"_account_id":8978,"name":"Marek Denis","email":"marek.denis+openstack@gmail.com","username":"marek-denis"},"change_message_id":"615fa64540ffdaf4daeefaa5e53d629fc8d29874","unresolved":false,"context_lines":[{"line_number":62,"context_line":""},{"line_number":63,"context_line":"`Trusted Attributes Policy API \u003chttps://review.openstack.org/#/c/100279/\u003e`_"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"Following on from this, mapping rules can be made independent of IdPs and"},{"line_number":66,"context_line":"all rules can be applied to the return Auth Context of federated authentication"},{"line_number":67,"context_line":"plugins."},{"line_number":68,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_14cebcb7","line":65,"in_reply_to":"1ae5cdf2_1f126709","updated":"2014-06-24 08:41:18.000000000","message":"++","commit_id":"9e0065316101297b5a6e26ebe3d00e38c06d1324"},{"author":{"_account_id":6482,"name":"Steve Martinelli","email":"s.martinelli@gmail.com","username":"stevemar"},"change_message_id":"4b79b7009f7eab5f0d154cf9b25b5f77a3005672","unresolved":false,"context_lines":[{"line_number":45,"context_line":"one, along with the regular expression mapping rule which would now guarantee"},{"line_number":46,"context_line":"that an untrusted attribute cannot sneak through."},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"Proposed Solution"},{"line_number":49,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"1. The federation protocol handling code returns the user identity with the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"dab895d6_07f6b4d7","line":48,"updated":"2014-06-30 06:45:29.000000000","message":"fyi - this is causing the py27 jenkins job to fail.","commit_id":"7c7f140e8b070144e6e724a36c7b0a236965abab"},{"author":{"_account_id":6534,"name":"David Chadwick","email":"d.w.chadwick@truetrust.co.uk","username":"d-w-chadwick"},"change_message_id":"d69abc90a42a9e3a4c25083967b0508c99b2ecf4","unresolved":false,"context_lines":[{"line_number":18,"context_line":"\r"},{"line_number":19,"context_line":"1. Undue complexity. This can be subdivided into the following symptoms\r"},{"line_number":20,"context_line":"\r"},{"line_number":21,"context_line":"    a) Mapping rules are currently associated with an IDP\r"},{"line_number":22,"context_line":"    whereas they should be mapping user identity attributes not IdPs. This means\r"},{"line_number":23,"context_line":"    that current rules to map an external identity attribute must be written\r"},{"line_number":24,"context_line":"    once for each IDP which issues the attribute.\r"}],"source_content_type":"text/x-rst","patch_set":12,"id":"baada198_9508f692","line":21,"updated":"2014-07-02 05:54:32.000000000","message":"and a protocol","commit_id":"9d6e9b0594ce1378e88816f04d735418c0c10065"},{"author":{"_account_id":6534,"name":"David Chadwick","email":"d.w.chadwick@truetrust.co.uk","username":"d-w-chadwick"},"change_message_id":"d69abc90a42a9e3a4c25083967b0508c99b2ecf4","unresolved":false,"context_lines":[{"line_number":21,"context_line":"    a) Mapping rules are currently associated with an IDP\r"},{"line_number":22,"context_line":"    whereas they should be mapping user identity attributes not IdPs. This means\r"},{"line_number":23,"context_line":"    that current rules to map an external identity attribute must be written\r"},{"line_number":24,"context_line":"    once for each IDP which issues the attribute.\r"},{"line_number":25,"context_line":"\r"},{"line_number":26,"context_line":"    b) Adding a mandatory name mapping is unnecessary if the federation design\r"},{"line_number":27,"context_line":"    is correct. No mappings should be mandatory and all mappings should be\r"}],"source_content_type":"text/x-rst","patch_set":12,"id":"baada198_d5026e6e","line":24,"updated":"2014-07-02 05:54:32.000000000","message":"and protocol?","commit_id":"9d6e9b0594ce1378e88816f04d735418c0c10065"},{"author":{"_account_id":6534,"name":"David Chadwick","email":"d.w.chadwick@truetrust.co.uk","username":"d-w-chadwick"},"change_message_id":"d69abc90a42a9e3a4c25083967b0508c99b2ecf4","unresolved":false,"context_lines":[{"line_number":152,"context_line":"In a small federation, the gains are small - simpler to understand, less chance\r"},{"line_number":153,"context_line":"of mistakes, but in a large federation such as the UK Access Management\r"},{"line_number":154,"context_line":"Federation with over a hundred IdPs, there are far fewer rules as well -\r"},{"line_number":155,"context_line":"n+2 compared to 2n where n is the number of IdPs.\r"},{"line_number":156,"context_line":"\r"},{"line_number":157,"context_line":"\r"},{"line_number":158,"context_line":"**The Simplified Mapping API (Conceptually)**\r"}],"source_content_type":"text/x-rst","patch_set":12,"id":"baada198_35e64ab5","line":155,"updated":"2014-07-02 05:54:32.000000000","message":"(for the above example)","commit_id":"9d6e9b0594ce1378e88816f04d735418c0c10065"},{"author":{"_account_id":11045,"name":"Bob Thyne","email":"bob.thyne@hp.com","username":"bobt"},"change_message_id":"4e461197807d5f8395cefbc629b863a43f0211dd","unresolved":false,"context_lines":[{"line_number":239,"context_line":"**Add a supported protocol and attribute mapping combination to an identity provider:**\r"},{"line_number":240,"context_line":"`PUT /OS-FEDERATION/identity_providers/{idp_id}/protocols/{protocol_id}`\r"},{"line_number":241,"context_line":"\r"},{"line_number":242,"context_line":"Request: ::\r"},{"line_number":243,"context_line":"\r"},{"line_number":244,"context_line":"    {\r"},{"line_number":245,"context_line":"        \"protocol\": {\r"}],"source_content_type":"text/x-rst","patch_set":12,"id":"baada198_809c33c2","line":242,"updated":"2014-07-02 07:42:49.000000000","message":"Use:\n\n.. code-block:: javascript\n\nfor JavaScript.","commit_id":"9d6e9b0594ce1378e88816f04d735418c0c10065"},{"author":{"_account_id":11045,"name":"Bob Thyne","email":"bob.thyne@hp.com","username":"bobt"},"change_message_id":"4e461197807d5f8395cefbc629b863a43f0211dd","unresolved":false,"context_lines":[{"line_number":250,"context_line":"Response: ::\r"},{"line_number":251,"context_line":"\r"},{"line_number":252,"context_line":"    Status: 201 Created\r"},{"line_number":253,"context_line":"\r"},{"line_number":254,"context_line":"     {\r"},{"line_number":255,"context_line":"        \"protocol\": {\r"},{"line_number":256,"context_line":"            \"id\": \"saml2\",\r"}],"source_content_type":"text/x-rst","patch_set":12,"id":"baada198_a0d4d747","line":253,"updated":"2014-07-02 07:42:49.000000000","message":"Use:\n\n.. code-block:: javascript\n\nfor JavaScript.","commit_id":"9d6e9b0594ce1378e88816f04d735418c0c10065"},{"author":{"_account_id":11045,"name":"Bob Thyne","email":"bob.thyne@hp.com","username":"bobt"},"change_message_id":"4e461197807d5f8395cefbc629b863a43f0211dd","unresolved":false,"context_lines":[{"line_number":270,"context_line":"Response: ::\r"},{"line_number":271,"context_line":"\r"},{"line_number":272,"context_line":"    Status: 201 Created\r"},{"line_number":273,"context_line":"\r"},{"line_number":274,"context_line":"     {\r"},{"line_number":275,"context_line":"        \"protocol\": {\r"},{"line_number":276,"context_line":"            \"id\": \"saml2\",\r"}],"source_content_type":"text/x-rst","patch_set":12,"id":"baada198_8038b3a1","line":273,"updated":"2014-07-02 07:42:49.000000000","message":"Use:\n\n.. code-block:: javascript\n\nfor JavaScript.","commit_id":"9d6e9b0594ce1378e88816f04d735418c0c10065"},{"author":{"_account_id":11045,"name":"Bob Thyne","email":"bob.thyne@hp.com","username":"bobt"},"change_message_id":"4e461197807d5f8395cefbc629b863a43f0211dd","unresolved":false,"context_lines":[{"line_number":289,"context_line":"Response: ::\r"},{"line_number":290,"context_line":"\r"},{"line_number":291,"context_line":"    Status: 200 OK\r"},{"line_number":292,"context_line":"\r"},{"line_number":293,"context_line":"    {\r"},{"line_number":294,"context_line":"        \"links\": {\r"},{"line_number":295,"context_line":"            \"next\": null,\r"}],"source_content_type":"text/x-rst","patch_set":12,"id":"baada198_c042ab0f","line":292,"updated":"2014-07-02 07:42:49.000000000","message":"Use:\n\n.. code-block:: javascript\n\nfor JavaScript.","commit_id":"9d6e9b0594ce1378e88816f04d735418c0c10065"},{"author":{"_account_id":11045,"name":"Bob Thyne","email":"bob.thyne@hp.com","username":"bobt"},"change_message_id":"4e461197807d5f8395cefbc629b863a43f0211dd","unresolved":false,"context_lines":[{"line_number":316,"context_line":"Response: ::\r"},{"line_number":317,"context_line":"\r"},{"line_number":318,"context_line":"    Status: 200 OK\r"},{"line_number":319,"context_line":"\r"},{"line_number":320,"context_line":"    {\r"},{"line_number":321,"context_line":"        \"links\": {\r"},{"line_number":322,"context_line":"            \"next\": null,\r"}],"source_content_type":"text/x-rst","patch_set":12,"id":"baada198_004ca341","line":319,"updated":"2014-07-02 07:42:49.000000000","message":"Use:\n\n.. code-block:: javascript\n\nfor JavaScript.","commit_id":"9d6e9b0594ce1378e88816f04d735418c0c10065"},{"author":{"_account_id":11045,"name":"Bob Thyne","email":"bob.thyne@hp.com","username":"bobt"},"change_message_id":"4e461197807d5f8395cefbc629b863a43f0211dd","unresolved":false,"context_lines":[{"line_number":342,"context_line":"Response: ::\r"},{"line_number":343,"context_line":"\r"},{"line_number":344,"context_line":"    Status: 200 OK\r"},{"line_number":345,"context_line":"\r"},{"line_number":346,"context_line":"     {\r"},{"line_number":347,"context_line":"        \"protocol\": {\r"},{"line_number":348,"context_line":"            \"id\": \"saml2\",\r"}],"source_content_type":"text/x-rst","patch_set":12,"id":"baada198_6051dfd7","line":345,"updated":"2014-07-02 07:42:49.000000000","message":"Use:\n\n.. code-block:: javascript\n\nfor JavaScript.","commit_id":"9d6e9b0594ce1378e88816f04d735418c0c10065"},{"author":{"_account_id":11045,"name":"Bob Thyne","email":"bob.thyne@hp.com","username":"bobt"},"change_message_id":"4e461197807d5f8395cefbc629b863a43f0211dd","unresolved":false,"context_lines":[{"line_number":362,"context_line":"Response: ::\r"},{"line_number":363,"context_line":"\r"},{"line_number":364,"context_line":"    Status: 200 OK\r"},{"line_number":365,"context_line":"\r"},{"line_number":366,"context_line":"     {\r"},{"line_number":367,"context_line":"        \"protocol\": {\r"},{"line_number":368,"context_line":"            \"id\": \"saml2\",\r"}],"source_content_type":"text/x-rst","patch_set":12,"id":"baada198_a06217ab","line":365,"updated":"2014-07-02 07:42:49.000000000","message":"Use:\n\n.. code-block:: javascript\n\nfor JavaScript.","commit_id":"9d6e9b0594ce1378e88816f04d735418c0c10065"},{"author":{"_account_id":11045,"name":"Bob Thyne","email":"bob.thyne@hp.com","username":"bobt"},"change_message_id":"4e461197807d5f8395cefbc629b863a43f0211dd","unresolved":false,"context_lines":[{"line_number":379,"context_line":"`PATCH /OS-FEDERATION/identity_providers/{idp_id}/protocols/{protocol_id}`\r"},{"line_number":380,"context_line":"\r"},{"line_number":381,"context_line":"Request: ::\r"},{"line_number":382,"context_line":"\r"},{"line_number":383,"context_line":"    {\r"},{"line_number":384,"context_line":"        \"protocol\": {\r"},{"line_number":385,"context_line":"            \"mapping_id\": \"xyz234\"\r"}],"source_content_type":"text/x-rst","patch_set":12,"id":"baada198_e05c0ff0","line":382,"updated":"2014-07-02 07:42:49.000000000","message":"Use:\n\n.. code-block:: javascript\n\nfor JavaScript.","commit_id":"9d6e9b0594ce1378e88816f04d735418c0c10065"},{"author":{"_account_id":11045,"name":"Bob Thyne","email":"bob.thyne@hp.com","username":"bobt"},"change_message_id":"4e461197807d5f8395cefbc629b863a43f0211dd","unresolved":false,"context_lines":[{"line_number":389,"context_line":"Response: ::\r"},{"line_number":390,"context_line":"\r"},{"line_number":391,"context_line":"    Status: 200 OK\r"},{"line_number":392,"context_line":"\r"},{"line_number":393,"context_line":"     {\r"},{"line_number":394,"context_line":"        \"protocol\": {\r"},{"line_number":395,"context_line":"            \"id\": \"saml2\",\r"}],"source_content_type":"text/x-rst","patch_set":12,"id":"baada198_8006f3cc","line":392,"updated":"2014-07-02 07:42:49.000000000","message":"Use:\n\n.. code-block:: javascript\n\nfor JavaScript.","commit_id":"9d6e9b0594ce1378e88816f04d735418c0c10065"},{"author":{"_account_id":8978,"name":"Marek Denis","email":"marek.denis+openstack@gmail.com","username":"marek-denis"},"change_message_id":"14d0c8715c78f6206728a4e36d96e6f102c65cf8","unresolved":false,"context_lines":[{"line_number":62,"context_line":"            \"user\": {"},{"line_number":63,"context_line":"                \"id\": \"foo\","},{"line_number":64,"context_line":"                \"identity_provider\": \"bar\","},{"line_number":65,"context_line":"                \"identity\": ["},{"line_number":66,"context_line":"                    {"},{"line_number":67,"context_line":"                        \"identity_provider\": \"bar\","},{"line_number":68,"context_line":"                        \"attributes\": ["}],"source_content_type":"text/x-rst","patch_set":13,"id":"baada198_fbdbd918","line":65,"updated":"2014-07-02 11:46:14.000000000","message":"we are somehow enforcing unique userNames produced from rules, but having what IdP was the user authenticated could be a good idea.","commit_id":"5119602b7db1249794b2c2b8cd8818076c044f26"},{"author":{"_account_id":8978,"name":"Marek Denis","email":"marek.denis+openstack@gmail.com","username":"marek-denis"},"change_message_id":"14d0c8715c78f6206728a4e36d96e6f102c65cf8","unresolved":false,"context_lines":[{"line_number":107,"context_line":"authenticating IdP to each other, as different Keystones may trust different"},{"line_number":108,"context_line":"IdPs."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"The List of {Set of .... construction is built in now to cater for attribute"},{"line_number":111,"context_line":"aggregation which will be a future requirement. The only overhead of doing this"},{"line_number":112,"context_line":"now is an extra nesting in the JSON, but it stops us having to re-engineer the"},{"line_number":113,"context_line":"format of the returned user\u0027s identity later on."}],"source_content_type":"text/x-rst","patch_set":13,"id":"baada198_3819d788","line":110,"updated":"2014-07-02 11:46:14.000000000","message":"some editing mistakes?","commit_id":"5119602b7db1249794b2c2b8cd8818076c044f26"},{"author":{"_account_id":5956,"name":"Kristy Siu","email":"kwss@kent.ac.uk","username":"kwss"},"change_message_id":"582ec7831a3c068a7af2a6a8ea96e5f20f974093","unresolved":false,"context_lines":[{"line_number":107,"context_line":"authenticating IdP to each other, as different Keystones may trust different"},{"line_number":108,"context_line":"IdPs."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"The List of {Set of .... construction is built in now to cater for attribute"},{"line_number":111,"context_line":"aggregation which will be a future requirement. The only overhead of doing this"},{"line_number":112,"context_line":"now is an extra nesting in the JSON, but it stops us having to re-engineer the"},{"line_number":113,"context_line":"format of the returned user\u0027s identity later on."}],"source_content_type":"text/x-rst","patch_set":13,"id":"baada198_017d7eb1","line":110,"in_reply_to":"baada198_3819d788","updated":"2014-07-02 12:29:54.000000000","message":"This refers to 1. iii. above.","commit_id":"5119602b7db1249794b2c2b8cd8818076c044f26"},{"author":{"_account_id":8978,"name":"Marek Denis","email":"marek.denis+openstack@gmail.com","username":"marek-denis"},"change_message_id":"14d0c8715c78f6206728a4e36d96e6f102c65cf8","unresolved":false,"context_lines":[{"line_number":213,"context_line":"Finally, we can map the returned attributes to internal Keystone attributes"},{"line_number":214,"context_line":"according to the configured mapping rules. The rules should be processed"},{"line_number":215,"context_line":"independently of the identity provider and should be applied to all attributes"},{"line_number":216,"context_line":"returned from a federated authentication source."},{"line_number":217,"context_line":""},{"line_number":218,"context_line":"Alternatives"},{"line_number":219,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":13,"id":"baada198_dbf3759d","line":216,"updated":"2014-07-02 11:46:14.000000000","message":"I am against making one global set of rules. It\u0027s fine when we are all in one federation, it may be more troublesome when one CSP is a member of many independent federations. They want to map UK AMF IdPs differently than eduGAIN\u0027s (providing they have nothing in common).\n\nWhy not create one list of mapping rules that imitates your \u0027global\u0027 one and then simply use this id. The only effort you have then is simply that you need to set this mapping id while adding protocol to the IdP.","commit_id":"5119602b7db1249794b2c2b8cd8818076c044f26"},{"author":{"_account_id":5956,"name":"Kristy Siu","email":"kwss@kent.ac.uk","username":"kwss"},"change_message_id":"d484c7ed673766883433b5bcbc0dcd508304c33e","unresolved":false,"context_lines":[{"line_number":213,"context_line":"Finally, we can map the returned attributes to internal Keystone attributes"},{"line_number":214,"context_line":"according to the configured mapping rules. The rules should be processed"},{"line_number":215,"context_line":"independently of the identity provider and should be applied to all attributes"},{"line_number":216,"context_line":"returned from a federated authentication source."},{"line_number":217,"context_line":""},{"line_number":218,"context_line":"Alternatives"},{"line_number":219,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":13,"id":"baada198_2c619939","line":216,"in_reply_to":"baada198_dbf3759d","updated":"2014-07-02 12:44:42.000000000","message":"There is definitely scope for IdP specific mappings as well as a global set but I think you are missing the point this spec is making about reuse of mappings for large federations.\n\nIf I have 100 IdPs configured and all of them issue an email attribute which we map to user: email and an organisation which maps to a *different* group for each IdP then I cannot reuse the policy and must make a new one for each IdP. This results in 100 mappings each with 2 rules (so 200 rules). In this revised version, I make 1 mapping for email and 1 for each IdP specific group, resulting (so 101 rules)\n\nAlternately one could allow multiple mapping assignments per IdP, mean that only 101 rules would be required, however each of the IdPs would need 2 mapping assignments (so 200 assignments)","commit_id":"5119602b7db1249794b2c2b8cd8818076c044f26"},{"author":{"_account_id":8978,"name":"Marek Denis","email":"marek.denis+openstack@gmail.com","username":"marek-denis"},"change_message_id":"c1cd42855c5199c54678763e64f7f8992fd93899","unresolved":false,"context_lines":[{"line_number":130,"context_line":"be given access to their own group, e.g. groupKent and groupYork for"},{"line_number":131,"context_line":"Kent and York respectively."},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"In the current system, the CSP must create two mappings, each with two rules:"},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"**Kent**"},{"line_number":136,"context_line":"1. NameID mapped to user"}],"source_content_type":"text/x-rst","patch_set":14,"id":"baada198_0baad8d3","line":133,"updated":"2014-07-03 07:43:46.000000000","message":"This is not really true. One mapping is enough. And can be used across multiple IdPs if admin wishes to.","commit_id":"bc008fdaeeac3bba2798d072775d028cefb3f95a"},{"author":{"_account_id":8978,"name":"Marek Denis","email":"marek.denis+openstack@gmail.com","username":"marek-denis"},"change_message_id":"c1cd42855c5199c54678763e64f7f8992fd93899","unresolved":false,"context_lines":[{"line_number":153,"context_line":"        }"},{"line_number":154,"context_line":"    }"},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"Mapping: ::"},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"    {"},{"line_number":159,"context_line":"        \"mapping\": {"}],"source_content_type":"text/x-rst","patch_set":14,"id":"baada198_4b64d0e4","line":156,"updated":"2014-07-03 07:43:46.000000000","message":"We discussed yesterday that pretty much the same rule config would be ussed in the current setup and the only difference is that mappngs must be added to every idp/protocol pair.","commit_id":"bc008fdaeeac3bba2798d072775d028cefb3f95a"},{"author":{"_account_id":8978,"name":"Marek Denis","email":"marek.denis+openstack@gmail.com","username":"marek-denis"},"change_message_id":"4ec26dc8875e15396e46a6f79e38271dd46657db","unresolved":false,"context_lines":[{"line_number":153,"context_line":"        }"},{"line_number":154,"context_line":"    }"},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"Mapping: ::"},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"    {"},{"line_number":159,"context_line":"        \"mapping\": {"}],"source_content_type":"text/x-rst","patch_set":14,"id":"baada198_8bed08f2","line":156,"in_reply_to":"baada198_4b64d0e4","updated":"2014-07-03 07:50:34.000000000","message":"mapping_id to be more specific, not mappings. So, there is still one entry in the database.","commit_id":"bc008fdaeeac3bba2798d072775d028cefb3f95a"},{"author":{"_account_id":8978,"name":"Marek Denis","email":"marek.denis+openstack@gmail.com","username":"marek-denis"},"change_message_id":"4ec26dc8875e15396e46a6f79e38271dd46657db","unresolved":false,"context_lines":[{"line_number":202,"context_line":"In a small federation, the gains are small - simpler to understand, less chance"},{"line_number":203,"context_line":"of mistakes, but in a large federation such as the UK Access Management"},{"line_number":204,"context_line":"Federation with over a hundred IdPs, there are far fewer rules as well -"},{"line_number":205,"context_line":"n+2 compared to 2n where n is the number of IdPs."},{"line_number":206,"context_line":""},{"line_number":207,"context_line":"**Example 2. Semantically different attributes from multiple IdPs**"},{"line_number":208,"context_line":""}],"source_content_type":"text/x-rst","patch_set":14,"id":"baada198_2bcf9c80","line":205,"updated":"2014-07-03 07:50:34.000000000","message":"i think this will no longer be 2n.","commit_id":"bc008fdaeeac3bba2798d072775d028cefb3f95a"},{"author":{"_account_id":8978,"name":"Marek Denis","email":"marek.denis+openstack@gmail.com","username":"marek-denis"},"change_message_id":"c1cd42855c5199c54678763e64f7f8992fd93899","unresolved":false,"context_lines":[{"line_number":349,"context_line":"    "},{"line_number":350,"context_line":"        }"},{"line_number":351,"context_line":"    }"},{"line_number":352,"context_line":""},{"line_number":353,"context_line":"**The Simplified Mapping API (Conceptually)**"},{"line_number":354,"context_line":""},{"line_number":355,"context_line":""}],"source_content_type":"text/x-rst","patch_set":14,"id":"baada198_6b4c3471","line":352,"updated":"2014-07-03 07:43:46.000000000","message":"....and this may look relatively easy with 2 IdPs, but imagine what happens when such CSP has 100 independent clients. And a poor admin who needs to change something so carefully go through all the rules looking which actually apply for IdP he wants to reconfigure? \n\n I am not very happy managing one list of rules and fear that my change had an impact on other IdPs.","commit_id":"bc008fdaeeac3bba2798d072775d028cefb3f95a"},{"author":{"_account_id":10335,"name":"Marco Fargetta","email":"marco.fargetta@ct.infn.it","username":"fmarco76"},"change_message_id":"e050a88f4be872d0549189d3a8179d36fc6d5f70","unresolved":false,"context_lines":[{"line_number":47,"context_line":"ProjectManager etc.) without the complexity of a mapping rule accompanying each"},{"line_number":48,"context_line":"one, along with the regular expression mapping rule which would now guarantee"},{"line_number":49,"context_line":"that an untrusted attribute cannot sneak through."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"**Proposed Solution**"},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"1. The federation protocol handling code returns the user identity with the"}],"source_content_type":"text/x-rst","patch_set":16,"id":"5a890539_c650d60c","line":50,"updated":"2014-11-21 11:17:47.000000000","message":"By design the Identity Federation is managed by Apache using shibboleth module or other. Since it is possible to filter attributes at Apache level in a quite flexible way, why you need this Trusted Attributes Policy?\n\nI do not get why you (I see this in many specs) need to replicate the features provided by the service above Keystone inside it. Differently, if the authentication was managed only by Keystone itself then this would make sense.","commit_id":"e49832ab3a82bddf9bdaf47e68391a84efe32a4a"},{"author":{"_account_id":6482,"name":"Steve Martinelli","email":"s.martinelli@gmail.com","username":"stevemar"},"change_message_id":"85095b98133761d5da647986ef83f7555f760a35","unresolved":false,"context_lines":[{"line_number":64,"context_line":"            \"user\": {"},{"line_number":65,"context_line":"                \"id\": \"foo\","},{"line_number":66,"context_line":"                \"identity_provider\": \"bar\","},{"line_number":67,"context_line":"                \"identity\": ["},{"line_number":68,"context_line":"                    {"},{"line_number":69,"context_line":"                        \"identity_provider\": \"bar\","},{"line_number":70,"context_line":"                        \"attributes\": ["}],"source_content_type":"text/x-rst","patch_set":16,"id":"baada198_0053556b","line":67,"updated":"2014-07-04 18:47:53.000000000","message":"huh? where is this ever returned?","commit_id":"e49832ab3a82bddf9bdaf47e68391a84efe32a4a"},{"author":{"_account_id":10335,"name":"Marco Fargetta","email":"marco.fargetta@ct.infn.it","username":"fmarco76"},"change_message_id":"e050a88f4be872d0549189d3a8179d36fc6d5f70","unresolved":false,"context_lines":[{"line_number":100,"context_line":"and not for authorisation, we dont care what its value is. Once we mandate that"},{"line_number":101,"context_line":"this must be present we no longer need to have a *mandatory* mapping rule for"},{"line_number":102,"context_line":"names."},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"The name of the IdP that originally authenticated the user is optionally needed"},{"line_number":105,"context_line":"for evaluating trust in IdPs. If the user came in via a proxy IdP or Apache"},{"line_number":106,"context_line":"gateway then the name of the authenticating IdP must be inserted by the proxy"}],"source_content_type":"text/x-rst","patch_set":16,"id":"5a890539_a6374aaf","line":103,"updated":"2014-11-21 11:17:47.000000000","message":"Is this \u003cNameIdentifier\u003e available to the application using Shibboleth?","commit_id":"e49832ab3a82bddf9bdaf47e68391a84efe32a4a"},{"author":{"_account_id":10335,"name":"Marco Fargetta","email":"marco.fargetta@ct.infn.it","username":"fmarco76"},"change_message_id":"e050a88f4be872d0549189d3a8179d36fc6d5f70","unresolved":false,"context_lines":[{"line_number":107,"context_line":"IdP or gateway so that Keystone can check if that IdP is trusted or not. When"},{"line_number":108,"context_line":"multiple Keystones collaborate together, they should still pass the name of the"},{"line_number":109,"context_line":"authenticating IdP to each other, as different Keystones may trust different"},{"line_number":110,"context_line":"IdPs."},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"The List of {Set of .... construction is built in to cater for attribute"},{"line_number":113,"context_line":"aggregation and the chaining of tokens between"}],"source_content_type":"text/x-rst","patch_set":16,"id":"5a890539_868b2e67","line":110,"updated":"2014-11-21 11:17:47.000000000","message":"If the Keystones use the new approach proposed in Juno for SAML, then one Keystone is the IdP for the other. How the user get authenticated is not relevant anymore.\n\nIf they use the IdPs and are in the same federation the users will go from one to the other but getting authenticated by the IdP.\n\nWhat is the scenario you are referring to?","commit_id":"e49832ab3a82bddf9bdaf47e68391a84efe32a4a"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"2cc92b017705cc449e1f852ee890835129874585","unresolved":false,"context_lines":[{"line_number":173,"context_line":"                {"},{"line_number":174,"context_line":"                    \"local\": {"},{"line_number":175,"context_line":"                        \"group\": {"},{"line_number":176,"context_line":"                            \"id\": groupYork"},{"line_number":177,"context_line":"                        }"},{"line_number":178,"context_line":"                    }"},{"line_number":179,"context_line":"                    \"remote\": {"}],"source_content_type":"text/x-rst","patch_set":16,"id":"baada198_d447d475","line":176,"updated":"2014-07-09 22:13:37.000000000","message":"missing quotes","commit_id":"e49832ab3a82bddf9bdaf47e68391a84efe32a4a"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"2cc92b017705cc449e1f852ee890835129874585","unresolved":false,"context_lines":[{"line_number":180,"context_line":"                        \"type\": \"eduPersonOrgDN\","},{"line_number":181,"context_line":"                        \"any_one_of\": ["},{"line_number":182,"context_line":"                            \"o\u003dyork,c\u003dgb\""},{"line_number":183,"context_line":"                        ],"},{"line_number":184,"context_line":"                    }"},{"line_number":185,"context_line":"                },"},{"line_number":186,"context_line":"                {"}],"source_content_type":"text/x-rst","patch_set":16,"id":"baada198_d43ef4d9","line":183,"updated":"2014-07-09 22:13:37.000000000","message":"trailing comma","commit_id":"e49832ab3a82bddf9bdaf47e68391a84efe32a4a"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"2cc92b017705cc449e1f852ee890835129874585","unresolved":false,"context_lines":[{"line_number":186,"context_line":"                {"},{"line_number":187,"context_line":"                    \"local\": {"},{"line_number":188,"context_line":"                        \"group\": {"},{"line_number":189,"context_line":"                            \"id\": groupKent"},{"line_number":190,"context_line":"                        }"},{"line_number":191,"context_line":"                    }"},{"line_number":192,"context_line":"                    \"remote\": {"}],"source_content_type":"text/x-rst","patch_set":16,"id":"baada198_f45db849","line":189,"updated":"2014-07-09 22:13:37.000000000","message":"same","commit_id":"e49832ab3a82bddf9bdaf47e68391a84efe32a4a"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"2cc92b017705cc449e1f852ee890835129874585","unresolved":false,"context_lines":[{"line_number":193,"context_line":"                        \"type\": \"eduPersonOrgDN\","},{"line_number":194,"context_line":"                        \"any_one_of\": ["},{"line_number":195,"context_line":"                            \"o\u003dkent,c\u003dgb\""},{"line_number":196,"context_line":"                        ],"},{"line_number":197,"context_line":"                    }"},{"line_number":198,"context_line":"                },"},{"line_number":199,"context_line":"            ]"}],"source_content_type":"text/x-rst","patch_set":16,"id":"baada198_94347cfc","line":196,"updated":"2014-07-09 22:13:37.000000000","message":"trailing comma","commit_id":"e49832ab3a82bddf9bdaf47e68391a84efe32a4a"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"2cc92b017705cc449e1f852ee890835129874585","unresolved":false,"context_lines":[{"line_number":195,"context_line":"                            \"o\u003dkent,c\u003dgb\""},{"line_number":196,"context_line":"                        ],"},{"line_number":197,"context_line":"                    }"},{"line_number":198,"context_line":"                },"},{"line_number":199,"context_line":"            ]"},{"line_number":200,"context_line":"        }"},{"line_number":201,"context_line":"    }"}],"source_content_type":"text/x-rst","patch_set":16,"id":"baada198_b43b40ea","line":198,"updated":"2014-07-09 22:13:37.000000000","message":"trailing comma","commit_id":"e49832ab3a82bddf9bdaf47e68391a84efe32a4a"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"2cc92b017705cc449e1f852ee890835129874585","unresolved":false,"context_lines":[{"line_number":258,"context_line":"                            \"SODA\""},{"line_number":259,"context_line":"                        ]"},{"line_number":260,"context_line":"                    }"},{"line_number":261,"context_line":"                },"},{"line_number":262,"context_line":"            ]"},{"line_number":263,"context_line":"        }"},{"line_number":264,"context_line":"    }"}],"source_content_type":"text/x-rst","patch_set":16,"id":"baada198_7418c884","line":261,"updated":"2014-07-09 22:13:37.000000000","message":"trailing comma","commit_id":"e49832ab3a82bddf9bdaf47e68391a84efe32a4a"},{"author":{"_account_id":10335,"name":"Marco Fargetta","email":"marco.fargetta@ct.infn.it","username":"fmarco76"},"change_message_id":"e050a88f4be872d0549189d3a8179d36fc6d5f70","unresolved":false,"context_lines":[{"line_number":365,"context_line":"Alternatively, an intelligent client could detect when a"},{"line_number":366,"context_line":"user is adding a rule which already exists and just append the IdP id to the"},{"line_number":367,"context_line":"\"only_applies_to_idp\" list before PATCHing the policy."},{"line_number":368,"context_line":""},{"line_number":369,"context_line":""},{"line_number":370,"context_line":"**The Simplified Mapping API (Conceptually)**"},{"line_number":371,"context_line":""}],"source_content_type":"text/x-rst","patch_set":16,"id":"5a890539_c6bd36d9","line":368,"updated":"2014-11-21 11:17:47.000000000","message":"The IdP entityID is available among the attributes made available from apache to the applications. Maybe this information could go in the mapping so you could put one or more entityID ad value for the attribute containing them in the remote part of the mapping.","commit_id":"e49832ab3a82bddf9bdaf47e68391a84efe32a4a"}]}