RE: Multiple Policies from one Web Service ?
- From: Steven L <StevenL@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 2 Aug 2006 15:16:05 -0700
Howard - how have you got on with this one?
I ran into this tonight and whilst both work great for me independently, i'd
rather just be able to say "if token is KerberosToken ... else if token is
UserToken ..."
I can see you can derive from SecurityPolicyAssertion, so cuold this not be
used to manually do this work depending on the token you are provided with?
Sounds like a heck of a lot of work, but the alernative of having
"internal.asmx" and "external.asmx" just doesn't feel right considering they
are the same "thing".
Sure, at the moment the differentiator is their authentication process, but
who know what other differentiators may come along and it sounds crazy to
create further endpoints to support this.
I'd rather (if possible) have something akin to a polymorphic security
assertion which is smart enough based on some config to use the "provider"
that does the security work (or whatever may come along). Then maybe i'm
missing something.
I'd be real interested in how you are getting/got on.
Regards,
Steven
http://stevenR2.com
"Howard Hoffman" wrote:
I've a WSE3 WebService that, for a particular customer, will be used by two.
types of clients -- one that is within the corporate firewall and one that
is outside the corporate firewall.
For the former, we use Kerberos Security, and the latter we are developing
toward UsernameForCertificate.
Is there anyway we could conceivably combine the two in a single web
service? I think this is the range of options we are looking at:
1) Two separate application installations; one uses KerberosSecurity policy,
one uses UsernameForCertificate policy.
2) Two separate web services within the one single application; one uses
KerberosSecurity policy; one uses UsernameForCertificate policy -- there is
a single wse3policyCache.config file for the application with 2 separate
<policy>elements. There is a single <extensions> element that contains both
the usernameForCertificateSecurity assertion and the kerberosSecurity
assertion.
3) Use UsernameForCertificate only, install the server's 509 certificate on
all clients.
The additional problem we have is that a released / deployed application
acts as our client for the 'within firewall' case, and it does not create
UsernameToken instances in its code -- it assumes Kerberos. We almost
certainly cannot re-release / re-deploy that application in time for our
need.
Thanks in advance,
Howard Hoffman
- Prev by Date: Re: friendly error messages for usernameForCertificateSecurity
- Next by Date: Re: Using WSE 3.0 Kerberos in a Web Farm
- Previous by thread: Re: friendly error messages for usernameForCertificateSecurity
- Next by thread: Re: Using WSE 3.0 Kerberos in a Web Farm
- Index(es):
Relevant Pages
|
