Is there a JBI solution on the way too? For example, if some endpoint A invokes an ode endpoint B, that it could be possible that the process invoked by endpoint B could pass to it's jbi bound partnerlinks the same credentials it got from endpoint A when it got invoked (i.e. the same securitySubject from the incoming NormalizedMessage) ?
example: Endpoint A (credentials: johndoe) => Endpoint B (ode process) => Ode Process => Partner Link => Endpoint C (jbi bound WS, same credentials as endpoint A) Please think as if the process could propagate the securitySubject (principals) it got from the jbi invoke to its own partnerLinks. I tried to do it myself in my svn checkout but its taking too long for me. Regards, On 9/12/07, Assaf Arkin <[EMAIL PROTECTED]> wrote: > > On 9/11/07, Alex Boisvert <[EMAIL PROTECTED]> wrote: > > > > On 9/10/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > > > > > > Assaf Arkin wrote: > > > > Alex Boisvert wrote: > > > > > I would also suggest using the standardized NIST RBAC terminology > > > (user, > > > > > role, permission) because it's most widely used and more intuitive > > > (and > > > > > business friendly). "Credential" seems to be the most common > term > > > used > > > > > for proof of identity and authority. > > > > Credentials are proof of identity, not authority. > > > > > > I believe that's what Alex said. Credentials are for authentication. > > > Roles/permissions are for authorization. > > > > > > > > Credentials are proof of both -- especially in non-centralized systems. > > My > > driver's license is proof of my identity (if you're willing to trust the > > DMV) *and* certifies that I can legally drive a car or a motorcycle with > > some vision correction apparatus. > > > Our topic is the extent to which you can pass a security context, as > opposed > to credentials used to reconstruct one internally, from one service to > another. Real world analogies are interesting mostly because they can > prove > two opposing points without contradicting themselves, all the while > distracting you from focusing on the matter at hand. > > In the US, for example, driver licenses are actually a subclass of state > ID > and therefore serve dual purpose, in itself derived from federally issued > credentials (social security, proof of residence), enacted through a > coordinated effort at the federal level (try speeding in Nevada and claim > it > doesn't affect you for living in California), with a lot of contextual > nuances (a CA license is not valid for Nevada residents, but is honored > for > visitors), granting you explicit (vehicle class) and implicit (drinking > age, > a state law governed through federal funding) roles, none of which are > transferable outside the US (try opening a bank account in the UK), the > point of which is to say that we don't have time to map out all the > federal > and state agencies, their acts of coordination and the legislature through > which it all happens. > > Because, until such time that we actually get the WS-DMV working group to > issue a spec that we can implement on our State Coordination Engine > 2.0Federal Edition, we need to stick to the relevant technologies we > have today > for passing messages from one service to another. > > Assaf > > > And take my Advanced PADI card... It also has my name and picture on it > but > > I doubt I could use it for identification anywhere. Regardless, when > I'm > > traveling to Belize I can rent scuba gear with it. The scuba shop > doesn't > > really care who I am, they just care that I have some sort of > > certification. > > > > Saying credentials are for identification only is a pretty narrow > > definition. > > > > alex > > >
