WSE 3.0 Clarification
- From: "Techno_Dex" <Techno_Dex@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 6 Feb 2006 13:35:14 -0800
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 linesbetween 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
.
- Follow-Ups:
- Re: WSE 3.0 Clarification
- From: dustin.breese
- Re: WSE 3.0 Clarification
- Prev by Date: Re: What are the benefits of WSE 3.0 for transport layer security?
- Next by Date: Makecert generated certificate problem
- Previous by thread: Re: Server unavailable.. message on WS-Secured Project
- Next by thread: Re: WSE 3.0 Clarification
- Index(es):
Relevant Pages
|