[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...
Re: >> 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? >> > I was not aware of this work. It does seem relevant. Would there be any pointers > available? Maybe this: --------------------------------------------------------------------------- SAML 2.0 Profile of SPML 2.0 Submission June 01, 2007 Submitting Organizations AOL BMC Software HP Intel Neustar Sun Microsystems Tripod Technology Group http://lists.oasis-open.org/archives/security-services/200706/msg00001.html http://lists.oasis-open.org/archives/security-services/200706/bin00000.bin = SAML 2.0 Profile of SPML 2.0 Submission v0.5.pdf http://lists.oasis-open.org/archives/security-services/200706/doc00000.doc = SAML 2.0 Profile of SPML 2.0 Submission v0.5.doc --------------------------------------------------------------------------- - Robin Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/who/staff.php#cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783 On Wed, 15 Sep 2010, John, Anil wrote: > Gary, > > Here you go.. > > In the case of (1) and (2): > > * Per organizational policy & relationship to user, attributes are assigned in their home organization and/or business unit (Org A / Org B / …) > * Org A must move those users and/or their attributes to a central repository (Repository X) on a regular basis > * Repository X acts as the authoritative source of attributes of users from multiple organizations / business units and can provide those attributes to authenticated and authorized entities in a in a synch-take-offline-use modes. > > Some points to keep in mind are: > > * Org A / B / … may have, and all too often do, have their own existing identity and provisioning systems as well as associated governance processes in place. > * The organizations and the repository may or may not be under the same sphere of control and as such cannot mandate the use of the same piece of provisioning software and associated connectors on both ends of the divide. > * The systems where the organizations store the attributes of their users may not necessarily be directory based systems. > * The Repository may or may not be directory based system. > > From the above description, I hope you take away that the clients are not kept separate for arbitrary reasons, but because they truly are outside the sphere of control of the entity that manages the repository. Think external organizations. > > re: (3) > > Understood.. I think the choice in this scenario would lean more towards the client trusting that the modification of the PSO will never change its PSOID rather than allowing the provider to specify the PSOID. > > re: (4) > > The listTargets do provide a mechanism to advertise supported operations, but I was thinking one level deeper as to what could be advertised... e.g. From what I understand, is it possible to specify in the listTargets response that "When using Search, you are allowed to use only AND and OR operations against Attributes X, Y and Z and nothing more". This request is driven more by the need to have more specificity and boundaries around what can be allowed in Search and Updates operations. > > re: (5) > > Stating it for the sake of completeness. I completely support the stance you guys took on layering messaging security on top of the messaging formats. I put this in given the conversations around going beyond SOAP. My concern is that, SOAP and in particular WS-Security has been well-profiled, and has adoption in tooling and platforms that are out there as such it is relatively easy for me to layer in that support on top of SOAP using platform specific mechanisms or in-line proxy mechanisms. My concern is that if we decide to depreciate that approach in favor of REST only approaches, there is a lot more work that needs to be done (especially out-of-band work) to layer in security. > > re: (6) > > If the questions can be asked as part of one query, so much the better. We are actually very open here. I am on a couple of the US Gov ICAM working groups right now and one of the items that we are working on right now is the v2 of the Federal ICAM Backend Attribute Exchange (BAE) specification. We have pretty good clarity on the SAML Attribute Query piece of it but the BAE also has a "Read-only Batch" piece that allows for querying and retrieving attributes in batch mode from the attribute service. SPML is something that we are definitely looking at as the standard that will enable that piece. So a read-only profile of SPML that allows for query and batch retrieval of attributes (and we are currently open as to what operations should be included here), would be very welcome. If such a thing exists, my impression from the conversations I've had, have been that there would be little desire to re-invent the wheel w/in the ICAM. As you can imagine, that would be potential point of synergy and leverage for the work coming out of this TC. > > re: (7) > > This relates directly to (6). We have profiled OASIS SAML 2 Metadata to describe the SAML capabilities of the Attribute Service (see attached) and actually have some vendors that can directly consume this to support auto-configuration of an attribute service. We would like to leverage the same metadata to advertise the capabilities of the SPML interface of the Attribute Service. How? > >> 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? > > I was not aware of this work. It does seem relevant. Would there be any pointers available? > > Hope this helps. > > Regards, > > - Anil > > ________________________________________ > From: Gary Cole [gary.cole@oracle.com] > Sent: Monday, September 13, 2010 12:31 PM > To: John, Anil > Cc: provision@lists.oasis-open.org; Richard Sand > 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 >> > >
file: SAMLv2-Profile-of-SPMLv2.pdf
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]