Thanks Todd.
O.K I get where you were going with this
whole identity issue.
So I definitely agree with all your
arguments on knowing which user and which application is calling the service. I
have already fixed this using a combination of X. 509 certs + custom security
model. Each application gets issued an X5.09 Cert. An application always
authenticates w/ some AuthAuth service (also a Web Service in our case) and
gets a secure tkn (and user roles for that app.) over secure channel.
The tkn is unique combination of
user-application which expires after configurable time. When the user does access
a functionality of application that requires an app to make a call to the
service then the service is passed a tkn (as part of security header or
anywhere the service defined it to come from). When the operation call/request
comes to service that service is (using a common SOAP handler) decodes tkn and
app (again using the same AuthAuth service which issued tkn to the originating
application).
The thing that struck me was how you
related this to Versioning issue of services.
PS
From: [email protected]
[mailto:[email protected]]
On Behalf Of Todd Biske
Sent: Sunday, April 09, 2006 8:44
PM
To: [email protected]
Subject: Re:
[service-orientated-architecture] Re: SOA Versioning Issues and Issues around
mgmt. of multiple versions of same service.
> On point#1 COuld you
eloborate a little bit more? I did not get the
> issue you were trying to highlight.
As most of us have probably experienced, security
is often an
afterthought. If you've got services popping
up from tactical
projects where the developers never thought about
anyone else using
those services, they may not be passing over
identity credentials on
the service request (e.g. WS-Security with Basic
Username).
Even if you are using WS-Security with X.509, you
may still have a
problem. This information may tell you what
user initiated the
request, but it doesn't tell you what application.
If my input
messages didn't change between V1 and V2, I now
don't have enough
information on the message to properly
route. If that application
has made changes that require V2, and I send it a
V1 response,
there's a problem.
Another form of identity would be the location
that this request came
from. In a company that has many retail
locations, a slow-roll/pilot
strategy may be employed. I may want all
users of application A in
location B to use the new version, but all other
locations using
application A to use the old version. How do
I determine what
location the request came from?
>
> On point#6--Are you going towards a contract
mgmt infrastructure
> (under umbrella of WS Mgmt. infrastructure)?
If you want multiple versions in production, some
form of
intermediary will be required no matter
what. It could be a gateway/
broker, an ESB, an agent, etc.
>
> On point#4--What are some of the patterns for
WS-Clients to request
> specific versions of a service? Again are you
suggesting going
> towards version mgmt infrastructure which
routes requests based on
> client requests?
I don't know that there are any well established
patterns that are
widely accepted. Three basic ways to handle
it are:
1) Each new version gets its own URI (likely
required no matter what
in order to deploy multiple versions in
production, whether clients
are impacted or not depends on whether you utilize
an intermediary
for virtualization)
2) Use a custom SOAP header to indicate version
number
3) Implicit version number through inspection of
the request message
(won't work for all cases- if only the response
message changed, this
does no good)
4) Pass in the version number as part of the
operation (yuck)
-tb
**************************************************************************
This message and any attached documents contain information
which may be confidential, subject to privilege or exempt from
disclosure under applicable law. These materials are solely for
the use of the intended recipient. If you are not the intended
recipient of this transmission, you are hereby notified that any
distribution, disclosure, printing, copying, storage, modification
or the taking of any action in reliance upon this transmission is
strictly prohibited. Delivery of this message to any person other
than the intended recipient shall not compromise or waive
such confidentiality, privilege or exemption from disclosure as
to this communication.
If you have received this communication in error, please notify
the sender immediately and delete this message from your system.
*****************************************************************************
YAHOO! GROUPS LINKS
