Thanks to Mike G for an email about the coolest app we saw at PDC last year – the physics illustrator that was demo’d by Microsoft Research. Now anyone can get it (well anyone with a tablet…) here.
I downloaded it and played with the existing demos and look forward to more play time but back to WSE now.
But it’s cool cool cool. Big Kudos to all involved.
Timberline Interactive, Inc. is looking for a .NET contract development person for 4-8 weeks, full-time to work on a custom e-commerce platform. Requires 1+ years experience with ASP.NET and VB.NET, as well as some experience with MS SQL2000 stored procedures. Initially, the work would be on-site in Middlebury but the contractor could work off-site after the first week or so. Assignment could start as soon as next week (10/4/04).
Please, no moonlighters. The contractor needs to be fully available during normal working hours for the duration of the assignment.
Submit summary of experience, resume, three references, and compensation requirements to:
Rick Fitzsimmons
President, Timberline Interactive, Inc.
36 Main Street, P.O. Box 992
Middlebury, VT 05753
rfitz@tli2.com
This is from the policy tracing file created by my client where I am fiddling around and trying to use policy to sign with a use usernametoken. Here’s a screenshot and then just a copy/paste so you can read the actual message. My point here is not to get help ,but to show you the level of detailed information that is output by WSE2 so that if you need to do some problem solving, you’ve got gobs of info. Pretty educational stuff.
<wset:message action=”http://tempuri.org/GetUserInfoInit” messageId=”uuid:ef64131b-543d-4df6-a50e-ec90cd6a6e5d” appDomain=”FieldApplication_TESTS_UI.exe” time=”2004-09-28T11:21:45.7968275-04:00″>
<wset:compile qname=”wsp:Policy” wsu:Id=”#Sign-Username-1″ usage=”Required” canEnforce=”true”>
<wset:compile qname=”wsp:MessagePredicate” usage=”Required” canEnforce=”true” />
<wset:compile qname=”wssp:Integrity” usage=”Required” canEnforce=”true”>
<wset:annotation>Looking for a satisfactory token in the current message’s token collection…</wset:annotation>
<wset:annotation>Looking for a satisfactory token in policy enforcement token cache…</wset:annotation>
<wset:annotation>DerivedKeyTokenAssertion will never be satisfied with existing tokens during compilation or enforcement. Not satisfied with this token: Id=SecurityToken-8e8a551b-5120-4506-902b-8e3abd171fef, Type=UsernameToken</wset:annotation>
<wset:annotation>ISecurityTokenManager.PermitsPolicyEnforcementTokenCaching is set to false in the token manager registered for this token type. We will assume this assertion is enforceable. Failures will be revealed during enforcement.</wset:annotation>
</wset:compile>
</wset:compile>
<wset:enforce qname=”wsp:MessagePredicate” usage=”Required” satisfied=”true” enforced=”false” />
<wset:enforce qname=”wssp:Integrity” usage=”Required” satisfied=”false” enforced=”true”>
<wset:annotation>Looking for a satisfactory token in the current message’s token collection…</wset:annotation>
<wset:annotation>Looking for a satisfactory token in policy enforcement token cache…</wset:annotation>
<wset:annotation>DerivedKeyTokenAssertion will never be satisfied with existing tokens during compilation or enforcement. Not satisfied with this token: Id=SecurityToken-8e8a551b-5120-4506-902b-8e3abd171fef, Type=UsernameToken</wset:annotation>
<wset:annotation>Invoking ISecurityTokenManager.LoadTokenFromSecurityTokenAssertion from the token manager registered for this token type.</wset:annotation>
<wset:annotation>ISecurityTokenManager.PermitsPolicyEnforcementTokenCaching is set to true in the token manager registered for this token type. A token will be loaded from the token manager and cached for subsequent message enforcement.</wset:annotation>
<wset:annotation>Invoking ISecurityTokenManager.LoadTokenFromSecurityTokenAssertion from the token manager registered for this token type.</wset:annotation>
<wset:annotation>Could not find a security token.</wset:annotation>
<wset:annotation>Looking for a satisfactory token in the current message’s token collection…</wset:annotation>
<wset:annotation>Looking for a satisfactory token in policy enforcement token cache…</wset:annotation>
<wset:annotation>Found a token: Id=SecurityToken-0090e2a4-7f5e-4279-8292-6fcdc78a78f2, Type=UsernameToken</wset:annotation>
<wset:annotation>Found a token: Id=SecurityToken-2013f98e-5994-4a8b-87ed-2b80ade897f6, Type=DerivedKeyToken</wset:annotation>
</wset:enforce>
</wset:message>
(slaps herself in the forehead!)
I have been dancing circles around the fact that my client side policy was being totally ignored and I couldn’t get a trace file generated from WSE2 either.
Doh! I was configuring the component that was doing the web service call, but the configuration info needs to be with the main app!
I know this, but I suppose I have been too determined that I was doing something wrong in my WSE2 setup to have thought of it. So it’s here for future googlers.
When it is due to the fact that my web service and client application really ARE reading my policy files!
“Microsoft.Web.Services2.Policy.PolicyVerificationException: WSE464: No policy could be found for this message.”
I’m still in the middle of wiring this up. I have to say that the refactoring process is definitely time consuming (and very educational). It is MUCH easier of course to implement WSE2 when you are working with new projects.
I am working with a client app that has MANY components and many different web services. Even though it is working already, and seems foolish to attempt to tackle this, I know that if I can get this working with wse2 then I have accomplished and learned a lot.
Senior Programmer Analyst
Burlington, VT
6 months Contract
This position is responsible for design, development and implementation duties for a web based aircraft finance tracking application. This position will work closely with business personnel, as well as other IS and IT personnel to gather business and technical requirements needed to successfully design and develop new system features, enhancements to current functionality and defect fixes. This position reports to the Manager, Structured Finance Business Systems.
Requirements
5+ years systems development experience with a concentration in mission critical web based applications. Expertise in VB.Net, ASP.NET, VB6, ASP, XML, XSL, XSLT, HTML, VSS and JavaScript. In depth knowledge of Microsoft SQL 2000, database design, programming and architecture.
MCSD or MCAD required. MCDBA and other certifications a plus
4 year degree in Computer Science or MIS or equivalent industry experience
Background in Structured Finance or other financial industry experience a plus.Contact: Kishore Khandavalli
iTech US, Inc.
Tel: 802 383 1500
Fax: 802 383 1501www.iTechUS.com
This isn’t lookin’ good. It seems I may have to hand code my policies after all since my web service is not on localhost. When you click okay on this message you get a second one and finally enable policy flag gets unchecked. I’ve been trying to trick it, by creating the PolicyCache.Config file, by editing the web.config and more, but to no avail.
update ..and if I manually create a policy file, whether I name it with the extention config or xml, if I do anything in the wse2 settings config tool and save them (even if they have nothing to do with policy), the <cache name=“myconfigfile.xml“/> gets removed from the <policy> tags in my web.config. This can’t be right. I must be doing something wrong.
okay- I seem to have picked up this “jig” thing from Ted Neward, but I just noticed something – that is MUCH more obvious when working with code you know well, rather than fiddling little samples.
With WSE1.0, you have to modify your client’s proxy to the web service so that it inherits from Microsoft.Web.Services.WebServicesClientProtocol instead of the default System.Web.Services.Protocols.SoapHttpClientProtocol. Every time you update the web reference, you have to remember to go back into the proxy and make that change. I have gotten into the habit, but really it’s just one more thing I need to remember, cluttering up my brain.
I have just modified the client component that has been working with WSE1 to use WSE2. When I updated the web reference in that project, the inherited class was automatically changed to Microsoft.Web.Services2.WebServicesClientProtocol.
This makes me very happy. I can free up that little space in my brain now for more important things! And it is one less barrier to getting regular programmers to use this stuff. Thanks WSE folks!
(I should point out that you get TWO proxy classes and this happens to the WSE2 version…)
I am finally converting my web service login and authentication procedures for one of my big production apps. Currently it is using straight web services, with a combination of soap headers and a System.Web.Security.FormsAuthentication ticket which is returned to the client as an encrypted string to be sent back with future requests as well as cached on the server. Lastly, I have a little user class that stores some details about the user that are used for authorization on the client end.
It’s somewhat similar to a secure conversation model because my token also times out every two minutes and has to be regenerated, but I don’t have to authenticate on every single message.
But an interesting difference is that I am explicitly authenticating at the user login (like we always have done, right?) whereas with the ws-security model, I will authenticate along with my actual requests. So if I were CODING all of this (which I’m not sure if I choose between hand coding in order to drill the stuff in to my brain better, or if I will just use the config tool and let that and policies do the grunt work for me — and if you saw what a GORGEOUS day it is out – you’d probably vote for the latter, too! :-)) …where was that sentence? Oh yeah, I will basically strip out the authentication that happens at login.
Thereare some cases where I am doing application updating and I require authentication at login for that process also. But for the other apps, I get to just rip out SO MUCH CODE – yippee – on both the client side and the ws side. Currently, on the client side, I am stuffing the token in the header of every ws call, so I won’t have to do that any longer. On the ws side, every method takes that token and checks against the cache to see if it’s still valid. So I get to take that code out. If it’s not valid, I was returning nothing to my client and the client has to send back the login/pw (which is still available to the app) and get another token. So all *that* code can go, too.
Rip rip rip, delete delete delete.
Stay by that phone! Your parents/friends/aunts/neighbors are bound to be calling soon! 🙂