[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ggf-ogsa-sec-wg] Re: Virtualized channels as abstractions for the Ws-xxxspecifications and beyond
Krishna
I read the ideas you have put forward wrt Grid and WS* specs. I have some
observation/comments on the technical note you sent out.
OGSA is based on Web services concepts and therefore, WS* proposals are
very relevant to OGSA (at a minimum). Therefore, these are definitely of
interest to this OGSA-SEC WG. The OGSA Security Architecture document
reflects this and outlines it. How each of these specs are relevant, how
they are exploited, profiles/extensions etc., is work need to be done. We
need to take this up.. the roadmap document outlines many specifications to
a granularity level. Most of your ideas, I believe (correct me), will fall
into one or more of those specs. So, let us identify those specs of
interest and start formulating a WG to hash the ideas out. We need to start
doing that..
I find your ideas/proposals interesting and very much applicable to the
work we are doing. The channel service is interesting but is something we
have not looked at explicitly in our architecture/roadmap document - it is
not necessarily specific to security though relevant. We can look into the
details and see if we need to address it here (under security), or get
advice from the OGSA WG (so that something can be formed under that). Now,
about the security specs, the OGSA-SEC WG is not going to be the
mother-of-all WG that works on every specification of interest. What we
intend to do is to identify the work items, and specifications that need to
be worked on. Most of those ideas are reflected in the architecture and
roadmap documents published out there. Given the ideas behind GGFs (i.e.,
to keep WGs focussed), we would like to identify, and help create other WGs
to solve some of the most important problems - and not solve all of those
under this one WG. This obviously will bring out the need for prioritizing
the various specs that need to be worked on. In this respect, OGSA-SEC WG
is similar to the operations of OGSA WG.
Given that, one thing I would like to hear from you is how do these ideas
fit into the specs outlined in the roadmap - if not, is there a spec that
needs to be added there? I do not want to lose your good ideas and at the
same time, we cannot work on everything at the same time (am sure you will
concur). Among them, what would be the pieces that you would be interested
in on working through formation of WG etc. This way, we can prioritize the
specs and work on them (through forming WGs).
All
The above comment applies to every interested participant in this OGSA SEC
WG.
Some of the topics that came out of the last GGF and Krishna's notes are:
identity translation (practical mappings around certificates, assertions,
GSI, etc), authorization, policy expression/exchange,
federation/extra-grid, etc.
Comments/suggestions are most welcome and appreciated.
Thanks
Nataraj Nagaratnam
----- Forwarded by Nataraj Nagaratnam/Raleigh/IBM on 01/29/2003 09:20 AM
-----
|---------+------------------------------->
| | Nataraj |
| | Nagaratnam/Raleigh/I|
| | BM@IBMUS |
| | Sent by: |
| | owner-ogsa-sec-wg@gr|
| | idforum.org |
| | |
| | |
| | 01/27/2003 11:22 AM |
| | |
|---------+------------------------------->
>-----------------------------------------------------------------------------------------------------------------------------|
| |
| To: <ksankar@cisco.com>, <ogsa-sec-wg@gridforum.org> |
| cc: |
| Subject: [ggf-ogsa-sec-wg] Re: [security-wg] Virtualized channels as abstractions for the Ws-xxx specifications and |
| beyond |
| |
>-----------------------------------------------------------------------------------------------------------------------------|
Krishna
Thanks for sharing your view. These are good and important ones. We should
continue having these discussions under OGSA-Security WG as well - given,
OGSA builds on Web services concepts and hence, the WS-* are more relevant
to the OGSA workgroups (the others are not restricted to WS concepts).
Therefore, IMO, security discussions pertaining WS-* are more relevant to
OGSA--Security workgroup and are dealt with under that workgroup (and other
OGSA WGs). So, I have cc'ed ogsa-sec-wg mailing list as well.
Also, there were two papers we put forward last year; a paper on OGSA
Security architecture that dealt with how OGSA Security could build on Web
services security and some of the WS-* specs and a paper on the roadmap
that lists some of the specifications of interest to the group. These were
discussed in the past GGFs.
One place where they are posted at this time is ->
http://www.globus.org/ogsa/Security/
Take a look at those and that maps out some of these ideas at a supercial
level. Getting into the next level of detail is needed and with many of
specs in WS-* out there, this is a good time to start them.
Thanks
Nataraj Nagaratnam
IBM
|---------+------------------------------->
| | "Krishna Sankar" |
| | <ksankar@cisco.com> |
| | Sent by: |
| | owner-security-wg@gr|
| | idforum.org |
| | |
| | |
| | 01/26/2003 01:33 AM |
| | Please respond to |
| | ksankar |
| | |
|---------+------------------------------->
>-----------------------------------------------------------------------------------------------------------------------------|
|
|
| To: <security-wg@gridforum.org>
|
| cc:
|
| Subject: [security-wg] Virtualized channels as abstractions for
the Ws-xxx specifications and beyond |
|
|
>-----------------------------------------------------------------------------------------------------------------------------|
Hi all,
Ever since the GlobusWorld conference, I have been thinking
how
we can add the required concepts and abstractions to leverage and
consume the WS-XXX proposals. Here are some of my thoughts. Would
appreciate feedback - the good, the bad and the ugly.
The first question is - Are the ws-xxx proposals relevant to
the
Grid architecture and infrastructure. Do they offer good abstractions
that can be leveraged ? The second one is if so, how so ?
Rationale:
----------
I think they do offer some nice abstractions we can leverage.
To
answer the second question, IMHO is the virtualization of the
communication channel between 1-n services. I look at a channel as the
aggregate path from a client to a porttype. Am not sure if we want to
tie in the bindings - one side it is easier to manage, as we know the
bindings at the configuration time one could make sure that the policies
would definitely be supportable by the bindings; the other side of the
argument is that there are bindings neutral policies like payload
encryption and related syntax and semantics
Summary:
--------
I am sure you all would agree that virtualization is not
hiding
an abstraction but exposing an abstraction as a service to a resource
and exposing enough controls and properties of a resource as interfaces
to the service(s). The proposed idea is to abstract the communication
channel/network path as a service and have ServiceData elements and
associated behavior. If we look at specifying network channel properties
and behaviors, then we have direct synergy with WS-XXXX proposals. One
of the ways we can leverage the WS-xxx proposals are by treating them as
XML vocabulary and associated protocols to express communication channel
security and related policies.
Some (positive) side effects :
------------------------------
1. If we allow fork, join and parallelism of
channels, we
could express routing - may be using the WS-Routing proposal - which
also is aware of the various policies and requirements.
2. We could also expose controls for properties like
bandwidth (with spatial and temporal dimensions), QoS and even latency.
These could be implemented to appropriate network elements. For example
if two services require a low latency channel, the underlying network
might see if it can provide two ports from the same switch.
A few Details:
--------------
Now moving on to a few pragmatic specifics, let us try to map
the WS-XXXX proposals. From a top level, the WS-Secure Conversation
corresponds to context policies, the WS-Policy as the framework,
WS-PolicyAssertion for ChannelPolicy and WS-Secure-Policy and QoSPolicy
the two specific instances for WS-Security policy and QoS Policy.
Without going deep into information modeling, namespaces et
al,
we would have
<Channel ID='www.xyz.com/123'>
<SecurityContext>
<Type>
http://schemas.xmlsoap.org/ws/2002/12/secext (The
schema
for WS-SecureConversation)
</Type>
<SubTypes>
<SubType>
BySecurityTokenService (could be BySender or ByReceiver or
ByNegotiation. By understanding the subtype, the communicating parties
would trigger the correct protocols for example if they see a
'BySecurityTokenService' the service would look to contact a token
service but if they see a 'ByNegotiation', they would start negotiating
with each other)
</SubType>
</SubTypes>
..
.. More elements describing this abstraction
</SecurityContext>
<ChannelPolicy
Schema='http://schemas.xmlsoap.org/ws/2002/12/policy'>
.. (Any general channel policy assertions expressed in
WS-PolicyAssertion)
</ChannelPolicy>
<WS-Security-Policy>
..
.. (Based on ws-Security-Policy proposal, specify how
Ws-Security would be applied to this channel - what are the elements
that one wants to see, which can be encrypted, ...)
</WS-Security-Policy>
<Privacy>
''
'' (Could be based on the yet to be released WS-Privacy
proposal)
</Privacy>
<QosPolicy> (Would be expressed as extension to WS-Policy)
<Bandwidths>
<BandWidth>
<StartAt>...</StartAt>
<EndAt>...</EndAt>
<Source>...</StartAt>
<Destination>...</EndAt>
<Properties>
<Latency>..</Latency>
..
..
</Properties>
</BandWidth>
</Bandwidths>
</QoSPolicy>
</Channel>
To Do:
------
1. The above is just a very preliminary starting point.
2, We would need to provide abstractions for attaching policies with
elements (using the WS-PolicyAttachment) with rules of priority and
inheritance.
3. The whole establishment and maintenance of trust need to be
addressed. The WS-Trust, WS-Federation, WS-AuthZ would play in this
space. Have some ideas, will leave it for later - the e-mail is getting
longer and the night is not that young anymore :o)
Conclusion:
-----------
For brevity sake, I haven't included more details. First want
to
seek synergies and start a discussion of the various ideas around these
concepts. Also we should strive for evolutionary concepts - if we have
the right abstractions and layers and progressively provide features (as
required by the users as grid becomes more and more prevalent) that
would be fine.
I am convinced that this would not be a security issue alone
and
so would have to collaborate with other groups. May be others are
already working on this and because of my limited visibility, haven't
yet come across them.
I think it is too late (or for that matter not even relevant)
to
discuss this at the GG7. GG8 onwards - may be, and if folks find this
interesting.
cheers