In a scope you can define a principal:
<principal name=NCName>
The scope semantics are similar to variables, partner links and
correlations.
To invoke/receive activity we add a principal attribute that can reference a
principal. On recieve, assigning from inbound message to the principal, and
on invoke assigning from principal to outbound message.
Given a principal, you can also access its name and determine if it belongs
to a certain role using the XPath functions:
getPrincipalName(ncname)
getPrincipalInRole(ncname)
And, of course, it should always be possible to instantiate a principal:
Statically:
<principal name=NCName value=string>
Dynamically:
<principal name=NCName>
<expression>
</principal>
In assignment:
<to principal=NCName>
On the endpoint reference at deployment (and don't use principal attribute
on invoke).
Ideally, using a principal in invoke is sufficient for the process engine to
figure out the credentials to use for authentication. Practically, we'll
get there at some point, but meanwhile need a solution to pass credentials
ad-hoc basis:
getPrincipalCredentials(ncname, realm, protocol)
The realm can be use to get credentials for a particular security realm, and
the protocol to easily wrap them up into a set of notes useful for a
particular protocol (e.g. a WSSE passwordToken). Without protocol, we get
back the elements username/password.
Assaf
