ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eduardo Burgos" <ebur...@gmail.com>
Subject Re: Passing in Login and Password
Date Wed, 19 Sep 2007 21:17:59 GMT
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 <arkin@intalio.com> wrote:
>
> On 9/11/07, Alex Boisvert <boisvert@intalio.com> wrote:
> >
> > On 9/10/07, Noel J. Bergman <noel@devtech.com> 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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message