This is the first post on what we are working on at Safewhere™, formerly
CI Networks. (And we're not working on our web site either - will just have
to wait for the designers to start work in January.)
The problem is with authorizations in a world of autonomous and loosely coupled
web services. Autonomous in the sense that they live their own life and may
contact any other service they see fit, although most likely constrained to some
extent by the hosting environment. And loosely coupled in the sense that they participate
in higher level processes, that may be reconfigured or extended - or new ones may
be created and wired to use our service.
It used to be that users would be authenticated basically once and then the user interface
would restrict what a given user was able to do. And if things get a little
more complicated, which they normally do, the backend will check again in more detail
to see if a given request or transaction should be allowed to proceed. Determining
if a user is authorized to perform an action is mostly a matter of checking membership
of a group, and more rarely also of checking e.g. if the amount requested is below
the maximum allowance of a given user.
Enter
SOA. (And no matter what your more precise interpretation turns out to be, the
above scenario of autonomy and loose coupling probably sounds familiar.) How
do you make sure that the entity or person sending you (as a service) a message is
actually authorized to request you to carry out the implied actions? Messages
may arrive from any other service and user on the network.
Two issues here: Unauthorized context or just plain unauthorized.
The latter we are used to dealing with at a basic level, whereas the former
is a somewhat new experience.
The problems with just plain unauthorized are many, but as both the number and distribution
of services increases so does the difficulty of defining, managing, and understanding
access requirements. And in a world of messages, the message must carry sufficient
and credible proof of identity - or some other claim of right. This is not to
be left up to the transport (e.g. SSL), as there is no knowing where and how a message
may travel on its way.
As illustrated here it seems the context issue is simply matter of asking "as
part of which process are you trying to do this?", but it may really be broadened
to include also situations where
-
Authorization depends on contents of the message. This would be
the case when the message holds a request to transfer a sum of money, which may or
may not be too large relative to the allowance of the given user or service initiating
the request.
-
Authorization depends on something that really is not known until
sometime after the internal service logic starts to do its work. This would
be the case when the request message simply says transfer the remaining sum for this
customer, and the service logic would then dig out the amount and go to work.
In the case of all but the last type of authorization, the actual authorization check
may be moved into the infrastructure and out of the hands of the developer with two
immediate benefits: No need to worry about or decide on this issue at development
time. And authorization may possibly be configured after service deployment,
provided the infrastructure knows how. (The latter is illustrated in a limited
scope by my MSDN
article on AzMan and WSE 3.0)
So if you think this is an issue worth dealing with, please let me know - or if you
have opposing or clarifying views even more please let me know.
- and Merry Christmas, which around here is tomorrow night.
