Here are a few
customer scenarios we've encountered. They are pretty similar in concept.
1. One customer has
a a consumer profile service front ended by a portal. The consumers themselves
are allowed to make certain changes to their profile. The operations invoked
take a username token. Some other changes can only be made by internal
operators. These operators have been given certificates. The operations they use
take X.509 tokens. Its one consumer profile service, just that some operations
are more privileged and are available to only a smaller audience. They don't
believe its feasible to issue certificates to their
consumers.
We have another
customer with the same set up except the service has to do with financial
transactions.
2. Another customer
has a service that is only used within a controlled environment in the intranet.
Its provides some CRUD operations for some data that is used by several other
apps in the environment. There are a lot of reads and so performance is
critical. Since the environment is controlled the read operations don't require
any authentication at all, so no token needed. However the CUD operations do
require authentication, a username token, mainly for
non-repudiation.
We have multiple
customers with the same set up.
3. A utilities company has a metering service that was
initially set up for internal use only requiring only usernames. They then
decided to open up a couple of the operations to some partners. They used SAML
for them. So only some of the operations accepted SAML tokens in addition to
username tokens.
Although these are
not the majority of our customers we do run into these requirements very often
in POC environments. A lot of companies have still not gone production so they
are still evaluating what their security architecture will be. For this reason a
great many of them have voiced concerns about the inflexibility of only being
able to define the use of tokens at the service level.
Tony