[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [provision] SPML Use Cases: Emergency Response and AttributeService focused...
Gary, All good questions. I am locked in an all day meeting today and as such won't be on the call today (Someone from my org will be) I'll be sure to respond to your questions below on the list as soon as I come up for air. Regards, - Anil :- :- Anil John (JHU/APL) :- Currently mobile. Expect brevity. :- ----- Original Message ----- From: Gary Cole <gary.cole@oracle.com> To: John, Anil Cc: provision@lists.oasis-open.org <provision@lists.oasis-open.org>; Richard Sand <Richard.Sand@skyworthttg.com> Sent: Mon Sep 13 12:31:20 2010 Subject: Re: [provision] SPML Use Cases: Emergency Response and Attribute Service focused... Hi, Anil. Thank you for writing up those use-cases. Using SPML for these use-cases makes sense to me. Before I go into details, I'd like to ask a few questions that are higher-level. The answers may be obvious to those who are already familiar with these (or similar) use- cases, but I'd like to be sure that I understand. 1) Are these use-cases separate? I ask because when I read them, it sounds to me as though #1 and #2 are the same provider being used in different ways by two different sets of clients: 1) departmental clients pushing data into a centralized repository; and 2) mobile clients pulling data from that centralized repository. Even #3 sounds as though it could be the same provider, but I assume that it is not, or there would be no issue with compliance. 2) If these three use-cases all deal with the same set of data--that is, the same centralized repository of Responders--then why are the providers separate? Are the providers kept separate for security reasons--that is, each type of client should get access only to certain functions, and the easiest way to lock this down is to deploy a separate provider for each class of client? I also want to a few questions that are more specific. In some cases, I may be jumping ahead to try to figure out where SPMLv2 falls short in addressing the use-cases. 3) Batch CRUD operations are okay, right? The main problems I see are that: A) Batch Add operations can return the generated psoID only in an AddResponse nested within the BatchResponse; and B) Batch Modify operations can return a modified psoID only in an AddResponse nested within the BatchResponse. This means that only a subsequent request can act on those newly-created PSOs (or newly-modified PSOs where the modification changed the PSOID) in a way that requires the PSOID. (Of course, these are not problems in cases where the provider allows the client to specify the PSOID and where the client can trust that modification of a PSO will never change its PSOID.) 4) The ListTargetsResponse already advertises supported operations via metadata, right? I suspect that you have a specific shortcoming in mind--or perhaps that you want to perform the same function in a different style. (Later on, you talk about using SAML2 metadata to declare supported operations. Is this what you mean by "metadata" in the first use-case?) 5) What kind of support for standardized cross-cutting security processing (e.g. SOAP/WS-Security) is needed in the specification (or in a profile) of SPML? As a committee, we took the stance that message security would be layered on top of (i.e., independent of) the message formats defined in the specification. By calling this out in your first use-case, are you suggesting that more should be done? Or you stating this merely for the sake of completeness? 6) In the third use-case, SMPL Operations on an Attribute Service, is it important that a client be able to ask those two questions separately? I'm wondering why a client would not simply "search for all users with attribute X" and obtain the attributes for each user from the search result. 7) The possibility of using SAML2 metadata to advertise capabilities is intriguing. Is there a specific link that would be helpful for participants to follow in learning about SAML2 metadata? Also, wasn't there some work in the SAML TC to develop a SAML2 profile for SPML (possibly related to Federation use-cases)? Would that work be related to this in any way? If so, what is the status of that work? Gary On Sep 3, 2010, at 12:26 PM, John, Anil wrote: > All, > > I thought I would take a shot at describing what the SPML needs and > use cases we are running into in the public sector work we are > doing. There are some things that we are working on that I have > permission to use organization names (given that I've already talked > about them in external presentations) and others for which we have > not gone through the public release process, and as such will > deliberately be generic. > > Please know that for us, SPML is a means to an end, and our focus is > around the management and movement of attributes that will typically > be used in Logical Access Control Systems (LACS) and Physical Access > Control Systems (LACS) for Attribute Based Access Control. > > 1) Emergency Response Case 1 > > If you look at the National Response Framework @ http://www.fema.gov/emergency/nrf/ > and the Emergency Support Function Annexes that are found there, > you will note that Emergency Response Officials, whether in the > Federal Government or State/Local/Tribal arena, are assigned certain > specific attributes that call out their responsibilities. Typically > this is NOT done in a top down manner, but is left up to individual > organizations to assign the attributes to their Emergency Response > Officials, and this information is kept within their own systems. > > But in order to coordinate the response to a disaster, those > organizations (particularly at the Federal level) are required to > provide information about those officials and their particular > attributes to a repository that is managed and maintained by a > central organization. It would behoove this repository to expose a > standardized and open interface such that the provisioning of the > users and their attributes, from their home organizations, takes > place in a standardized and automated manner that leveraging > existing tooling. It is assumed that network connectivity exists > between the interface and the "clients" that need to talk with it. > This interface would need to support the following characteristics: > > * The ability to do CRUD operations > * The ability to do batch CRUD operations > * The ability to advertise supported operations that can be > performed on the interface via metadata > * Support for layering in standardized cross-cutting security > processing on the message exchanges (typically SOAP/WS-Security) > > > 2) Emergency Response Case 2 > > This is the other side of the picture. Now that we have the > attributes in the repository, how can they be leveraged in a mobile > and potentially comms-out (communications infrastructure is not > available) environment? This typically requires the ability to bring > "down" the attributes into some sort of mobile device that may or > may not have real-time network access so that it can be taken on > site in the case of disasters. As such the interface is more of a > "synchronization" and/or "get/refresh" from the client's > perspective. This interface would need to support the following > characteristics: > > * The ability to GET attributes > * The ability to obtain UPDATES to data that exists locally on the > mobile platform > > 3) SPML Operations on an Attribute Service > > This use case was something that was described in a presentation I > gave at Gartner/Burton Group Catalyst this summer on the the Federal > ICAM Backend Attribute Exchange (BAE). The BAE interface supports > both a SAML Attribute Query Interface as well as a set of SPML > operations for "batch pull" capabilities. The reason for the > existence of the SPML operations is that a SAML Attribute Query is > not able to answer the following questions: > > * "Give me the unique id's of all users with Attribute X" > * "For all users (whose unique id's I just got), give me listing > of attributes for each (in one shot)" > > > The way forward for us was to focus on a very simple set of SPML > operations that included: > > * search (needs to be restricted and described via metadata) > * lookup > * batch > > The problem as it exists is the following: > - search operations are pretty unbounded and there does not exist a > way for me to advertise "what is permitted on which attributes" as > part of the SAML 2 Metadata I am exposing > - by implementing just these three operations I am no longer "SPML > v2 compliant" > > So what we are looking for is a "Read Only" profile for SPML that > does just that. > > Finally and just as important, we would be very interested in how > SAML 2 Metadata can be used/extended to advertise SPML Operations. > From the Attribute Service perspective we have profiled SAML 2 > Metadata to be able to advertise an Attribute Services' capabilities > (Unique identifier, Certs used, endpoints, supported subject > identifier types, supported attributes, contact info etc) and as > such would like to leverage what already exists instead of creating > something new for SPML. > > Would be glad to answer any questions. > > Regards, > > - Anil > > > :- > :- Anil John > :- Johns Hopkins University - APL > :- http://www.jhuapl.edu > :- +1 240.228.0612 > :- > :- E-Mail Response Time: 24 hrs > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]