It is quite common for large distributed application to ask the questions:
"Should all services perform user authentication?"
"Can we afford this in terms of performance?"
Well usually, we can not afford to repeatedly authenticate.
Services are autonomous ! We all know that this is of the most important tenets of SOA. Business activities are rarely implemented in one service only.
Business activities are composed of several services working together.
The services are autonomous, they can "grow" and can switch technologies but never the less they are linked and dependent business wise.
Around this link we can draw a line and call it: The business domain line.
We should ask "What kind of authentication info is needed for the members of the domain?"
To enter the domain there are few known entrance points (The first step in the business activity) where proper authentication should be performed and the authentication data (name ,role etc) should be created.
Now this entrance point will create a token out of this data and pass it forward.
If I am a member of this business domain I should not authenticate the user myself. all I need to know is that I get a proper token from a legitimate entry point. Then I can create another token (maybe with some more data) and pass it forward.
Certificates and digital signatures can help here to verify the tokens but sometimes it is too expensive. so we can use one time passwords.
"One Time Password" means that the secrete is not the password itself but the algorithm that created it. When two services want to assure their trust they have to agree on an algorithm. One service takes an input that the other is aware of (like the time of sending the message in ticks) and computes the password which is sent with the message.
The reciever can use the same algorithm again and check the password.
On the next message a whole new password will be sent and thus it is called "One Time Password".
If you choose a good algorithm which produces results that distribute well you can even give up encryption and gain performance as it is very difficult to go back from a list of passwords to the algorithm.
For example:
We define a business process, the business dependencies and trusts.
Each two services that should communicate agree an a table (Size 100) of random numbers. (This table can be changed every so often)
When I want to send a message to you I do the following:
1. I write the exact time in the message.
2. I take a certain part of the message and call it the "seed". (The token)
3. I take the (Time in ticks Mod our Table Size) and get to an entrance in the table.
4. I take the random number from the table, concatenate it to the seed and create a hash. This is our one time password !!!
The other side reads the time in the message and can easily check the password.
This can be very performant.
So as a part of the business domain all I need to know is that I speak to someone I trust.
He will give me the token with the data I need.
I can create more tokens (Authentication / Authorization data) and pass it forward to someone that will authenticate me (Not the user) very efficiently and use this data.
Manu Cohen-Yashar