WSE 3.0 Clarification

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Techno_Dex - 06 Feb 2006 21:35 GMT

I have some questions that I have been unable to find answers to and hoping
someone here can enlighten me.

Q1)
Can someone explain the use and retention of Tokens for use on second and
third WebService Method calls. I'm wanting to Authenticate a user and assign
them a token for use when calling all remaining WebService Methods but I see
no documentation or information about this. WebSerivces are stateless by
nature so I'm assuming there is no "Token Store" on the server which is
maintaining all the authenticated tokens within the last X minutes etc... I'm
hoping that on the second and third method calls that the user is not
continuing to be reauthenticated passing back and forth the Username and
Password in the Token. Take for example the simple UsernameToken that is
passed back and forth in plain text. The Token gets validated on the server
and possibly is Authorization in an Overridden Token Manager where an
Identity/Principal is created and Roles are attached to it. Does this occur
on every WebService Method call?

Q2)
In the TokenManager, is the IIdentity and IPrincipal serialized and send
back to the client or only used on the Server to Authorize in a WebMethod? If
sent back to the client, How (they don't appear to be serializable)?

Q3)
From what I can tell it appears as though WSE tries to blur the lines
between Authentication, Authorization and Security. This is quite apparent
when investigating X509 Security and Kerberos, where the naming convention
uses Security when talking about Authentication, etc... I question the
effeciency of a lot of the procedures if a user has to be Authenticated and
Authorized on each WebMethod call. Am I missing a performance trade off
somewhere?

What is the difference between Authentication and Security when referenced
in WSE. It appears as though UsernameToken is used for Authentication where
as X509 and Kerberos are used to secure the message being sent rather than
authenticate the user. Why are these two being compaired to one another if
they aren't even doing the same job. Implementing Transport and Message Layer
Security just doesn't make sense as a comparable item for Authentication.

Say we are dealing with X509 MutualSecurity, the client has a Certificate
that was issued to them by Verisign, the server has a Certificate issued to
them by Verisign and the client some how gets a hold of the server's public
key certificate. The client calls a WebMethod on the WebService passing in
the client's public key certificate so the service can authenticate???
Authenticate what, that they have a common CA (i.e. Verisign)? What if you
didn't want this person using your WebService, but they happened to pass in a
certificate from a third party which you also trust? What steps do you take
to map this client certificate passed in for Authorization Roles or something
along those lines? The service didn't have the client's PK certificate before
the request came in so there is no way to map certificate to a user
account....

On a side note:
In my further quest for information about Tokens, I have discovered that
KerberosTokens are out of the question for use on a Internet WebService. They
are designed to work with Intranet applications where the user can directly
access the KDC on the network to request a Server Token to communicate with
the WebService. (It is possible to use them over the Internet but it's a pain
to implement and you take the chance of exposing your Security
Infrastructure)

The Authentication is where I'm getting hung up. A certificate verifies that
you are who you say you are as far as the certificate authority can
determine. Thus if you believe the Certificate Authority then the person is
to be acknowledged for who they say they are. The problem I'm having is just
because you trust your friend (i.e. the CA), doesn't mean want to trust your
friend's friends (i.e. whoever is handing you a certificate). For all you
know, the party handing you a certificate could be your competition. I guess
my concern starts to overlap into authorization and possibly mapping an
unknown certificate to a trusted list, may it be an ACL, mapped to UserCreds
in AD or a record in a Database.

I feel like I'm missing a few key points that might help fully explain WSE
to me. If anyone can enlighten me I would be greatful.

I'm sure to have more questions to come.

TIA

Reply to this Message

dustin.breese - 07 Feb 2006 13:45 GMT

I'll _try_ to help. I've recently gone through (read: still going
through) the WSE learning curve.

Q1) Check out the STS QuickStart. Tokens are valuable, especially when
issued from a Security Token Service which CAN do trusted
authentication, compex token issuance, authorization, etc. Typically,
a token service such as an STS will hand out SAML tokens. The SAML
tokens will have an expiration date/time. On every subsequent WS call,
the SAML token can be stuffed in the SOAP header. The WS can quickly
validate who the client is and if the STS has granted access to the WS
method.

Q2) I don't think these are serialized back to the client. Are you
seeing this with tracing turned on?

Q3) I think an STS/WS-Trust will help answer these questions. Purpose
of STS is to issue security tokens, validate them, and exchange one
token format for another (ie, x509 for SAML, etc). Your WS will
obviously still have to do some level of "authentication" just to make
sure the SAML token is there, and certain characteristics are upheld
(ie, hasn't been tampered with, conditions are met, ec).

WSE is just a jump-pad for any security implementation you may need.

I think you may be mixing several things. There are several
out-of-the-box implementations in WSE for authentication:
UsernameToken, Kerberos, and X509. X509 can also be used for
encryption and signing (because it is basically the public key of the
pub/priv key pair). Does this help?

The X509 is valuable for authentication. Here're some pts:
- Client and server can use X509/Public key for various things:
authentication and WS-Security (signing and encryption). (Encryption
will be done, of course, with the private key.)
- When a client or server signs/encrypts/authenticates using the X509,
the X509 is embeded in the SOAP envelope by WSE.
- When the message crosses the wire to the server, WSE (or whatever
technology) can retrieve the X509 and do things like verify any
signatures, use it for encryption on the response, or, query the X509
for common attributes such as Distinguished Name (DN).
- Not sure how to answer your question re: certs from OTHER CAs. It is
my understanding that you'd have to set up a trust relationship for CAs
in your application. That is, only allow certs from your corporate CA
to access the web service.

>From what I know about Kerberos (not much), sounds like your concerns

would also be valid with an STS.

I HOPE this helps and I haven't planted both feet in my mouth. :)

Reply to this Message

Techno_Dex - 07 Feb 2006 15:07 GMT

I haven't looked at the STS and SAML documentation very much as at first
glance, it appeared to add another layer of abstraction to the mix. After
another glance, it looks like I need to take a closer look as it appears to
be more along the lines of a B2B/Internet solution (that I'm looking for) as
opposed to most of the WSE examples which appear to be Intranet solutions. I
think part of my hang up is the fact that my webservices need to easliy
communicate across the Internet and domains. This means worrying about Proxy
Servers, Firewalls, etc... Most of the solutions I've seen in WSE appear to
be tied to a particular domain or forest where the user already has access
and/or tokens issued to them at network logon on the intranet. This starts
to eliminate solutions like the Kerberos token and AD options where you don't
want to expose your Domain Controller to the outside (Internet).
I'm not really worried about message level encryption, but I also don't want
to pass uid/pwd across the wire in plain text. For this reason I started
looking into X509 Certificates. In all actuallity, I just need
authentication upon first connection and then to be able to account for the
token being issued and let the user pass the token anytime they make a
request. Maybe you can answer a few more questions about this from the SAML
side.

So when the user requests a token from the STS and gets it, how is
authentication any different when the user passes the Token to the web
service vs the user passing a uid/pwd directly to the webservice? The web
service still has to check that the token is authentic by asking the STS if
it's valid, where as it would have to check the uid/pwd on it's own every
time. It just appears as though the use is being authenticated every time in
the web service. I guess though with an STS issued token, the authorization
roles/rules can be embedded in the token so the webservice wouldn't need to
pull authorization every time.

How secure should the SAML token be kept (i.e. is this something that a user
could modify if they got there hands on it, or is it encrypted, etc...) -
Forgive me if it's in the documentation but I haven't gotten to it yet.

Onto my questions on X509. I guess my questions were specific towards the
onsided X509 certificate solutions, as the mutual certificate solutions
require the pre-exchange of the public keys and installation into the
certifcate stores.

STS and SAML appear to be very similar to Kerberos but with a little less
security risk. I say with the assumption that STS doesn't use a domain
account with creds which could be used at some later time to access the
network and domain by customers.

Thanks for your help. You have cleared up some of my questions and pointed
me in a new direction of possible answers.

Reply to this Message

dustin.breese - 08 Feb 2006 15:22 GMT

Glad to be of help. Hope I'm not pointing you down a path with a cliff
at the end. :)

The authentication isn't much different b/w the two approaches. The
thing an STS/WS-Trust gives you is the "trust" in authentication. That
is, an identity authenticated in one domain can be vouched for in
another domain. Take for example the airline/rental car scenario where
a reservation web site can authenticate the user and help broker
reservations. Once the user is authenticated, the user is essentially
authenticated (via a trust relationship) with the airline and car
rental site.

You are right -- the other thing a SAML token can provide are
attributes (any you want) to assert as well. For example, perhaps a
student logging into a university system would get a signed SAML token
asserting that s/he was authenticated and also that the person is a
"STUDENT" versus "FACULTY". The token can provide other conditions
(<saml:Conditions/>) which can do things like authorization for a
particular web service, expirations, etc.

The SAML token will not usually have sensitive data (but it could).
Encrypt as you see fit. It can't be tampered with because it should be
signed by the issuing STS via its very own certificate. Therefore, a
single bit has been changed/altered and someone relying on the SAML
token will know.

Again, hope this helps. I'm definitely no expert, so someone pull my
feet out of my mouth if I'm talking smack. :)

-Dustin

Reply to this Message

Techno_Dex - 07 Feb 2006 16:21 GMT

After further investigation into the STS/SAML documentation, it appears that
Tokens are "Cached" by the TokenManager on the server and in the client's
proxy object of the webservice. I don't know that cached is the correct word
to use. I'm guessing this is the same for all WSE solutions. Can anyone
confirm this? If tokens are cached in the Server's TokenManager, how long
are they cached for? The solutions don't appear to have a service which
cleans out the cache after some time X... I'm also concerned after reading
that the .NET framework 2.0 has to read all of the X509 certs into memory in
order to parse. This creates a problem for a B2B solution using
MutualCertifcates where the client's public key must be stored in the server
store.... This would make me lean to UsernameToken over SSL to get a SAML
token for the remaining communication, except for the fact there are memory
leaks.....

Reply to this Message

WSE 3.0 Clarification

Free Magazines