[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ggf-ogsa-sec-wg] Re: [security-wg] Virtualized channels as abstractions for the Ws-xxxspecifications 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