Minutes of OGSA-WG + OGSA-AuthZ Joint telephone call 8 Mar 2007 Attending: Hiro Kishimoto Dave Snelling Marg Murray Dave Chadwick Chris Kantarjiev David Groep Dwayne Merrill Mark Morgan Andrew Grimshaw Proposed Agenda from David Snelling: 1) Clarify the need for AuthZ standards in a Grid. Do we need AuthZ standards within in a single enterprise or only with distributed grids. 2) Review the scope of the current AuthZ WG. Are they doing frameworks only, or are they defining roles and their semantics? What is the scope of these and how is extensibility managed? 3) Are the AuthZ requirements the same for both Enterprise and eScience? 4) Is there something in needed in AuthZ that is either a) not being addressed by the AuthZ-WG or b) needed is a short time frame as a stop gap? Dave S. reviewed the above agenda. Agenda bashing ensued. David C. felt Item 3 should be addressed first. A wiki for requirements has been created but has not been heavily trafficked yet. David S. asked whether AuthZ is best considered local or non-local. Alan responded that in his view, authorization always takes place locally, but often must be informed by factors that come from outside of the local boundary. David C. pointed out that this discussion, while true, is at a different level than the current activities of the OGSA-AuthZ group, which focuses on protocols for transmission of authorization-related information, rather than particular specific schema or attributes. (This was an important principle in getting AuthZ activities going forward in a useful way toward standardization of the _syntax_ of attributes.) He held out the example of LDAP, which went through a similar evolution. Marg Murray asked about the split between authN and authZ as it relates to virtual organizations. David C. reviewed the agreement that has been underlying the OGSA AuthZ work to date that assumes that VOs will be authoritative for some but not all attributes, just as institutions are authoritative for some but not all attributes, so what is needed and what the group has been working on has been methods to encode, transmit and understand attributes. Andrew joined and gave the opinion that advertisement, discovery and communication of information is preferable to hard specification of attributes, which is consistent with the above. Moving on to the roadmap, David C. referred to the OGF-16 SAML-based profile, which was felt to be deficient compared to the community assessment of needs. Two profiles are being worked on by the group at present, one based on XACML and one based on WS-Trust, and an architecture document. These are current in the OGSA-AuthZ gridforge pages. There is also a document describing these deficiencies from the previous approach, which include: inability to describe obligations (solved in the XACML case), need to describe parameters of actions, etc. Note the XACML-over-SAML approach used here has NOT been deprecated by OASIS, as reported earlier e.g. at OGF-20, according to David C. as per an e-mail that he will forward to the group. David S. proposed that the above discussion covers agenda item 2) for today, if supplemented by e-mails documenting the above points by those who made them. There does seem to be work for a framework for authorization that goes beyond the WS standards available to the community. Andrew pointed out a statement by Nate Klingenstein at last week's meeting regarding work by the Liberty Alliance that specifies extensions to WS-Security -- we need to track down a reference on this. Dwayne clarified that this specifies usage of the key within the metadata in an EPR. David C. said that we cannot escape the fact that every credential can in principle have a policy associated with or attached to it. It may be a usage field or a policy context. Thus the encoding format for that policy should be standardized. In X.509 this is done by a complex arrangement of OIDs. The recipient of a credential can always choose to ignore such policy statements, of course. David S. asked whether existing work covers the topic of advertisement of authorization requirements on the part of a given resource to describe what it needs to make an authZ decision. David C. said that there is a feature in XACML that could support this, but that this work has not been completely fleshed out yet by documents produced by OGSA-AuthZ. The PEP is the application-dependent piece; other application dependence is factored out. Andrew asks how can one determine what needs to be sent along in the SOAP? David C. (and Alan agreed) replied that some of these requirements may be published out of band, for efficiency, privacy or other reasons that do not necessarily have to interfere with such discovery. Reviewing the agenda, David S. stated that item 1) is also answered now as well. Item 3) may require more extended discussion. A requirements roll-up activity is taking place throughout OGF now and he felt that this should be brought up at the next such roll-up meeting. In terms of item 4), are there any short-term actions or needs that we can identify? David C. felt that interaction with credential issuing services to determine whether a given credential service can respond to a specific request needs to be documented. The field definition needs a look, too. Andrew asked whether there are use cases driving these requirements. The use cases he is looking at are simpler and don't seem to require some of the above. Dave S. pointed him to the wiki and asked for input. Andrew reminded the group of the informational document being worked on as a result of last week's discussion, and that this has been sent out to the OGSA-WG list. Hiro asked for review of this document to be scheduled in the Thursday F2F Security session. Hiro asked about the next joint call in this series. Candidates are Mar. 29, April 5, 12 and 19. None of April dates would work for David C. so Mar. 29th was selected and agreed to. Respectfully, Alan Sill, Ph.D TIGRE Senior Scientist, High Performance Computing Center Adjunct Professor of Physics TTU ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================

Hi Alan thanks for your comprehensive minutes. There is just one clarification I would like to make as below Alan Sill wrote:

David C. pointed out that this discussion, while true, is at a different level than the current activities of the OGSA-AuthZ group, which focuses on protocols for transmission of authorization-related information, rather than particular specific schema or attributes. (This was an important principle in getting AuthZ activities going forward in a useful way toward standardization of the _syntax_ of attributes.) He held out the example of LDAP, which went through a similar evolution.

Actually I thought I said that the LDAP/X.500 community tried to get international agreement on standard attributes (syntax and semantics), but in the end it failed for all but a small subset of attributes (such as telephone number) as most organisations either defined their own attributes entirely, or used the syntax of existing attribute definitions but bent the semantics to fit those of their own organisation. Thus the ability to standardise all attributes and transfer a complete set of user attributes between systems in a meaningful way never materialised (ignoring the privacy issues). My gut feeling is that the same thing will happen for authorisation attributes. The granularity and semantics of attributes used in one organisation will be too finely grained for transfer between organisations, and so systems will implement either attribute mappings at gateways or reissuing of new attributes in each VO that you participate. regards David ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************

Blair & Andrew, I'm not sure the former -- having authorities describe what they're authoritative for -- is entirely desirable or practical. When we discuss "authoritative for xyz data" in the context of identity information, I think it's necessary to append "for person abc" for it to have much meaning. My IdP isn't your IdP, the same attribute may be expressed by multiple authorities, and my release policies are likely to vary by SP, so this appendix adds a great deal of complexity. For each SP to manage and interpret the matrix of attributes/authorizations/identifiers and authorities for every principal they deal with strikes me as unreasonable and unnecessarily compromising of privacy. This gets back to my core philosophy: the IdP should push everything it can, and for what it can't push(e.g. things it's not authoritative for), it should push the information needed to retrieve the additional attributes/authorizations, ideally via a discovery service associated with that user. The discovery service can dynamically handle the user/authority/request pile and collect either raw data or pointers as appropriate. If someday there's an intelligent client, then it can manage attribute and authorization locations for a principal internally, which is even better. That said, I do think conversely there's value in SP's advertising the attributes or authorizations they need in order to reduce the need for callback queries, as those requirements are likely to be relatively static and unlikely to vary by IdP or user. There are additional questions to consider when talking about attribute metadata, though. Does some third party, e.g. a federation or a CA, need to vouch for my IdP's claim that it's able to assert staff@microsoft.com? Will that third party be universally trusted by all the SP's I deal with? The SP retains, and will always have, the right to validate and interpret information it receives. I believe it's the job of the authorities, intermediaries, and flows to preserve as much of that information as is practical so the SP has the basis for a decision once the information arrives. Whether the SP would like to rely on the certification of an external authority or its own judgment, it's able to do so. Any standard should recognize both sides of this coin. Anyway, regardless of your own beliefs, the expression of both attribute expression and request is possible today by using the <RequestedAttribute> and <saml:Attribute> elements from the SAML 2.0 metadata profile. Inasmuch as privileges and identifiers (NameIDFormat can be declared too, FWIW) can be thought of as attributes, I think this supports what you'd like to do, but not at the web services layer. The Higgins project seems to be trying to do this using WSDL through the IdAS API, but I don't know enough about it to talk authoritatively. ID-WSF and WS-Federation have somewhat coarse-grained abilities to express where attribute information is located as well. Does this make any sense to you? Nate. On 8 Mar 2007, at 22:40, Blair Dillaway wrote:

[blaird] I see two important aspects to this. First, authorities need to be able to communicate what they are authoritative for (attributes, types of principal identities, ...) so that resource admins can know what they can rely upon in developing authZ policies. Second, resources need to be able to communicate what authenticated information they require (token types, which authorities, ...). WS-SecureConversation (http://www.oasis-open.org/ committees/download.php/15979/oasis-wssx-ws-securitypolicy-1.0.pdf) could potentially be profiled as a way to do the latter. I'm not aware of an existing std that addresses the former.

Blair, Thanks for the elaboration; I took the association with WS- SecureConversation rather than WS-Policy to imply in-band and read "rely upon" as a firmer statement than you intended. This time, I'll assume that by "some way for SPs to discover the IdPs vocabulary" you still mean a protocol of some sort to do so, which isn't necessarily used during the identity exchanges themselves. Hopefully that's not too off-base so this message will be more useful to you. It seems you're talking more about awareness of what the choices are when writing policies, not what you're guaranteed to receive while executing them. It's absolutely true that to write an access control policy in the first place you need to know the names, semantics, and probably values of authorization-related information. Where I believe we differ is I don't see pre-configuring that data, especially in metadata, as pragmatic. A few of my reasons: 1) Most IdP's won't release any sensitive information to default or anonymous relying parties. See, for example, the UK Federation Technical Guidelines, which stress repeatedly that "identity providers should never attempt to delegate [the] responsibility [of deciding which attributes to release] by relying on appropriate AttributeDesignator elements being expressed by a service provider." We've encountered many IdP's who won't send an authentication assertion to an unauthenticated relying party, let alone group information, attributes, or XACML policies. There have to be agreements and understandings in place. That means people get in the way of the machines by manually determining release policies and we have to figure out what's available for access control decisions OOB anyway. http://www.ukfederation.org.uk/library/uploads/Documents/technical- recommendations-for-participants.pdf 2) Entitlements and authorizations are usually defined explicitly for a particular service, which means the value doesn't exist a priori and the IdP has to populate the value for the SP. See section 7.1.5 of the UK Federation Technical Guidelines. I assume this would be even more likely for XACML because it's such a powerful language. 3) For custom and local data definitions, which group-based authorizations regularly tend to be, it'd be difficult to interpret the authorization schema(for lack of a better word) received, particularly when you just get an eduPersonEntitlement URI. 4) There's likely to be significant push-back on publication of any useful authorization-related information because of privacy and security concerns. 5) Most of the vendors don't support the current standards that allow for even primitive discovery and don't consider federations bigger than a bilateral contract a primary business driver. 6) Some federations are even actively recommending *against* this practice -- in this instance, the use of <saml:Attribute> in metadata: http://www.e.govt.nz/standards/e-gif/authentication/nzsams/ chapter12.html All that said, I think there's great value in general attribute standardization out-of-band and in policy documents to the extent possible. That would be a great exercise for some subset of the grid community to undertake. Many federations recommend/mandate a small set of attributes all IdP's should/must support and describe their semantics(e.g. the UK and http://feide.no/dokumenter/ldap/ FEIDEldap.html#tth_sEc5 ). I'm also in favor of a resolvable schema for defining a simple attribute, primarily for flexible maintenance of controlled vocabularies. It just seems that to me that trying to represent the attributes/ groups/permissions an IdP could supply is not feasible today. If you can think of ways to alleviate my above concerns or show how they aren't relevant to what you're suggesting, I'd be very interested in your ideas. Really hope this is more along the lines of what you want, Nate. On 9 Mar 2007, at 02:40, Blair Dillaway wrote:

I believe you mis-understood what I was trying to say. If one wishes to write an attribute-based authorization policy for a resource, one must know what attributes a client could provide. I can't, for example decide to write a group-based authZ policy unless I know some IdP(s) will tell me about what groups a client is affliated with and how that group attribute is encoded. As you mention there could be several different group attribute types used by different IdPs. There has to be some way for SPs to discover the IdPs vocabulary. This tends to be handled in various ad hoc ways and can be difficult to discover and track over time. I was suggesting that having a standard way of doing this for large distributed systems is valuable.

This is completely independent of whether client attributes are pushed, pulled, sent via intermediaries, and how an SP decides whether that info is trustworthy.

Re our workflow use case discussion of 3/14 am http://forge.ogf.org/sf/docman/do/downloadDocument/projects.ogsa-wg/docman.r... Here's the template I propose for use cases: Title Keywords Goal and description Actors/stakeholders Assumptions Preconditions Main flow of events (Basic, alternate, exceptional) Postconditions Success requirements Special Requirements Issues Sources/references OGF sponsor/stakeholder/interested party

Geoffrey Fox wrote:

As you gather requirements, I would suggest looking at several mashups and the new generation of (workflow) tools they are supported by such as http://www.protosw.com/ (which offer an ipod a day in their mashup building contest) and Yahoo pipes http://pipes.yahoo.com/pipes/. A trivial discussion of mashups versus workflow is at http://grids.ucs.indiana.edu/ptliupages/presentations/Web20Mar04-07.ppt

I am known for following fads too much but I think the rather complex web service workflow will face increasing competition from Mashup technology with its naturally larger customer and developer base.

While some mashups do show the power of ad-hoc programming, there are areas where workflows have a distinct set of benefits. Firstly, I've been discovering over the past months how workflows are key to many business processes and planning (e.g. airports aren't mashups, even if they look like it superficially to travellers). Secondly, every mashup I've ever heard of relies on having the end user as a computation locus; the mashup is in their browser. The problem is that this requires the end user to be present and using a (full featured) browser. In turn, that restricts the applicability quite strongly, especially in relation to small devices and part-time networks. It's also not clear to me just how well mashups tackle security; I've certainly read in the past that this is a distinct problem from a privacy perspective. It's usually much clearer what is going on with a workflow, and that clarity is important in many application domains (especially ones with non-trivial legal requirements). In short, workflows (especially not service-oriented ones) can go places where mashups can't; the mashup advantage is in the presentation layer and not the business-logic layer. Maybe some businesses will try to keep the business-logic layer largely transparent so as to better support mashups, but many (most?) won't and there are many known problems with the approach of putting lots of critical code in the presentation layer. Donal.

During last week's face-to-face, Frank had requested a brief overview of Liberty's message level security mechanisms. The Liberty ID-WSF architecture appears to be a very different beast than the OGSA paradigm. (Clients use "discovery" services that locate desired provider services; the discovery services respond back with ID-WSF EPRs that wrap both the endpoint information and any necessary security credentials that client needs to provide for service authorization.) For a brief perspective on the Liberty ID-WSF architecture, I would recommend the following document sections: a.. Section 5 of the Liberty ID-WSF Architecture Overview (http://www.projectliberty.org/liberty/content/download/889/6243/file/liberty...) b.. Section 4 of the Liberty ID-WSF Security and Privacy Overview (http://www.projectliberty.org/liberty/content/download/327/2405/file/liberty...) There are three specifications concerning their security architecture that I have found to be relevant to the discussions we've been entertaining: a.. Liberty ID-WSF Discovery Service Specification (LibertyDisco: http://www.projectliberty.org/liberty/content/download/875/6201/file/liberty...) b.. Liberty ID-WSF Security Mechanisms Core (LibertySecMech: http://www.projectliberty.org/liberty/content/download/893/6255/file/liberty...) c.. Liberty ID-WSF SOAP Binding Specification (LibertySOAPBinding: http://www.projectliberty.org/liberty/content/download/897/6267/file/liberty...) The LibertyDisco spec is perhaps the most interesting, as it draws from the other two to create a ID-WSF profile for EPRs. In their terminology, an ID-WSF EPR comprises the "invocation context" necessary for interacting with the targeted service instance. Within the EPR's <Metadata> document, they use <SecurityContext> element(s) to express a grouping of security-specific metadata regarding the service provider. In this regard, their <SecurityContext> EPR metatadata extension is similar to the OGSA BSP-Core's <EndpointKeyInfo> metadata extension. A <SecurityContext> contains one or more <SecurityMechId> elements and zero or more <Token> elements. (See the example ID-WSF EPR in the postscript at the end of this email.) The <SecurityMechId> element (defined in LibertySecMech) contains a URI that identifies the peer (transport) and message authentication mechanisms required by the service provider. Examples are: a.. urn:liberty:security:2005-02:TLS:X509 (Server-authenticated TLS transport-level security with authentication of the client via the WS-S X.509 Token Profile at the SOAP level) b.. urn:liberty:security:2006-08:ClientTLS:SAMLV2 (Mutually-authenticated TLS transport-level security with authentication of the client via the WS-S SAML2 Token Profile at the SOAP level) c.. urn:liberty:security:2003-08:null:null (No transport-level security or message-level security) There does not appear to be a mechanism for specifying if/what encryption needs to be done at the message level (as required by the service resource). They suggest that message-level encryption be used in the presence of intermediaries, but it would appear that doing so would be at the discretion of the client; there is no mechanism for making it a provider-requirement. Unlike the OGSA BSP-Core, the <Token> elements with in a ID-WSF <SecurityContext> do not describe security tokens that are to be used expressely for authenticating the resource service to the client. Rather, they are either (a) authZ security tokens for the client to place in the outgoing message's SOAP WS-S security header or (b) a "target identity" to be placed in the outgoing message's ID-WSF SOAP header analogously to the way we use reference parameters. Additionally, neither the LibertySecMech nor the LibertySOAPBinding documents specify any mechanism for indicating the security context required by the client for response messages. In summary, I don't believe that the Liberty ID-WSF profiles on SOAP and WS-Addressing will provide us complete solutions for the considerations that I outlined in the recommendations document. Their <SecurityMechID> element is a good approach for advertising authentication mechanisms, but it lacks the ability to express the message-confidentiality requirements of the service resource. They do not profile the binding of key/cert material to EPRs for the purpose of authenticating the resource/endpoint to the client (let alone the intended usage for such key material). They do not profile a mechanism for indicating client requirements for response message-level security. -Duane PS -- The following is an example of an ID-WSF EPR taken from the LibertyDisco specification containing two alternative security contexts for interaction: <wsa:EndpointReference notOnOrAfter="2005-08-15T23:18:56Z" ...> <wsa:Address> http://profile-provider.com/profiles/so meFoobarProfileAddr </wsa:Address> <wsa:Metadata> <ds:Abstract> This is a personal profile containing common name information. </ds:Abstract> <ds:ProviderID>http://profile-provider.com/</ds:Provi derID> <ds:ServiceType>urn:liberty:id-sis-pp :2003-08</ds:ServiceType> <sbf:Framework version="2.0" /> <ds:SecurityContext> <ds:SecurityMechID> urn:liberty:security:2006-08:ClientTL S:SAMLV2 </ds:SecurityMechID> <ds:SecurityMechID> urn:liberty:security:2005-02:Cli entTLS:SAML </ds:SecurityMechID> <sec:Token wsu:id="_10" usage="urn:liberty:security:tokenusage:2006-08:Secu rityToken"> <!-- some security token goes here --> </sec:Token> </ds:SecurityContext> <ds:SecurityContext > <ds:SecurityMechID> urn:liberty:security:2005-02:ClientTLS:X509 </ds:SecurityMechID> <sec:Token wsu:id="_20" usage="urn:liberty:security:tokenusage:20 06-08:InvocationIdentity"> <!-- Identity Token goes here --> </sec:Token> </ds:SecurityContext> <ds:Options> <ds:Option>urn:liberty:id-sis-pp</ds:Option> <ds:Option>urn:liberty:id-sis-pp:cn</ds:Option> <ds:Option>urn:liberty:id-sis-pp:can</ds:Option> <ds:Option>urn:liberty:id-sis-pp:can:cn</ds:Op tion> </ds:Options> </wsa:Metadata> </wsa:EndpointReference>

I was asked by several people to provide an example use case that fits my template. Here's a simple one, not related to workflow: -Title: Resource Barter Services -Description Allow metrics to define and decide how and when can resource consumers trade or exchange resources already paid for or reserved for themselves. Create an exchange mechanism inside a data center between multiple consumer groups. Use metric to evaluate when it is profitable to use versus it is profitable to rent back. -Actors/Stakeholders · IT Resource Consumers · IT operations DBA · IT operations security geek -Assumptions Choose a small set of hardware metrics that can be agreed to and agree on the cost of each. This is a suggested starting point: · CPU (via some published/rated amount of gridbux/CPU seconds · Memory occupancy (megabyte seconds?) · disk I/O (bytes read/written) · Network (bytes read/written) · Session occupancy (do we charge for idle time?) A depreciation schedule has been established for every resource in the data center. A real-dollar budget has been established for the data center. Users are subject to a published fixed + variable pricing structure over a period of time (e.g., a month). Some mechanism exists for estimating the cost of a job. -Preconditions -Postconditions -Main flow of events User A wishes to complete a job J with estimate C, which is more than A’s fixed budget for the month. User B has fixed budget left over for the month. B advertises remaining fixed budget at a discount. A subleases B’s resources for the duration of job J. A is charged the discounted fee, which is applied to B’s costs for next month. -Issues A strictly pay-as-you go price model doesn’t provide any incentive to rent back. This simplistic example doesn’t really explain why a data center would be interested in allowing this. A customer may need to be able to rent the resources/budget from several providers to complete a single job. What happens if A exceeds the terms of the sublease? -Sources/references -OGF sponsor/stakeholder/interested party You can find many more use cases of this style in the EGA Reference Model documents, at http://gridalliance.org/en/workgroups/techdownloads_download.asp (and, eventually, coming to an OGF website near you).