> From:David Jordan > I am trying to work out how to identify who the person is > that is consuming a web service using the U2 web services > developer. I know techniques to do it in .Net. > > How do ensure that a person is authorized to consume that service. > What approaches have others taken to tackle this.
Why would the techniques be different depending on the tools you use? The whole point of a web service is that you should be able to implement various protocols on all sides independent of the technologies used in clients and servers. The following is not specifically related to the U2 web services but you should be able to implement it without special code. The simplest mechanism would be to use ID/password fields in your service signature or payload. You could pre-authenticate using the above, and return time-restricted transaction tokens for actual transactions. A more rigorous approach is not to use plaintext passwords but to use encrypted tokens. This requires clients to add special code to agree with your server, beyond basic WS connectivity. You can provide your encryption algorithm to trading partners or you can provide object-only encryption modules that agree with your BASIC algorithms. Service consumers send you data with a user ID and the token. You read the real password from a U2 file using their user ID and try to decrypt the token with it. Trash the transaction if you can't decrypt. Encrypting an entire transaction may be necessary for some purposes but it's an unwelcome performance hit for others. You could use true encryption for the above tokens plus simple munging for the payload just to deter prying eyes. If you only encode a single value then you need to make sure that someone can't just put that value into a different transaction. The value that you encrypt might be the IP address of the sender. If you decrypt the value and it's not equal to the IP address (perhaps one you have registered for the user) then the transaction is bad. I don't know if you can get the IP address of the sender from HTTP headers with U2 web services. If you encrypt the entire transaction then the transactions need to include a timestamp and the server should reject anything that looks old or like it's already been processed. David, I hope that helps, but if you're already on top of all of this, then please disregard and let's hope it helps someone else. Tony Gravagno Nebula Research and Development TG@ remove.pleaseNebula-RnD.com Nebula R&D provides tools and services for web development, including GUI and Web Services. remove.pleaseNebula-RnD.com/blog Visit PickWiki.com! Contribute! _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
