5 | | == GEC10 Authorization Engineering Meeting == |
| 7 | = GEC11 Engineering Meeting = |
| 8 | At GEC11 there was an [wiki:GEC11Identity identity engineering meeting] which discussed progress towards incorporating external identity providers in GENI. |
| 9 | |
| 10 | == Meeting Summary == |
| 11 | '''Tom Mitchell''' discussed the goals of the Identity Management effort within GENI and provided an update since GEC 10. Briefly: |
| 12 | * !InCommon membership took longer than expected, but the GENI Project Office became !InCommon members in July, shortly before GEC 11 |
| 13 | * A prototype identity portal has been built. It uses Shibboleth single sign on so it will be compatible with !InCommon. |
| 14 | * The prototype identity portal was federated with ProtoGENI to demonstrate the ability to create slices and allocate resources from an operational GENI aggregate manager. |
| 15 | |
| 16 | Tom gave a brief demonstration of the prototype identity portal that showed the creation of a GENI certificate, a slice and associated slice credential, and then using the GENI certificate and slice credential to list resources via Flack at ProtoGENI's Utah site. Tom's slides are available on the session wiki page. |
| 17 | |
| 18 | '''Ken Klingenstein''' discussed the state of federated identity management today and what's coming on the horizon for federated identity management in general, and !InCommon in particular. Some of the key topics included Social2SAML gateways, attribute release and consent, non-web apps (SAML ECP), and collaboration management platforms. Ken also talked about implications for GENI: federated identity and ABAC, levels of assurance, and incident handling. Ken's slides are available on the session wiki page. Specifically, Ken made the point that GENI will probably have to confront these issues as it moves forward with federated identity management. Ken posed questions like: |
| 19 | * What level of assurance will GENI aggregates and slice authorities require from identity providers? |
| 20 | * How will GENI handle incident response? |
| 21 | * How will attributes from identity providers be used in authorization decisions? |
| 22 | * What attributes will be used for authorization, and who will be trusted to make this assertions? |
| 23 | |
| 24 | == Proposed Next Steps == |
| 25 | * Continue to push !InCommon membership forward |
| 26 | * Publish Participant Operational Practices (POP) |
| 27 | * Publish Service Provider Metadata |
| 28 | * Negotiate For Attributes From A Few Institutions |
| 29 | * Continue to develop the prototype identity portal |
| 30 | * Proper certificate management |
| 31 | * Protected signing key |
| 32 | * Certificate Revocation List (CRL) |
| 33 | * Programmatic access to some functions |
| 34 | * Management/Operations integration |
| 35 | * Integration with Federation/Clearinghouse concepts |
| 36 | |
| 37 | |
| 38 | = GEC10 Engineering Meeting = |