You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ode.apache.org by Greg Bluntzer <gb...@gmail.com> on 2007/09/05 18:27:27 UTC
Passing in Login and Password
Im sure this has been asked before but I could not understand the answers on
the forum.
The partner Link that I'm calling uses the HTTP Header Authorization to get
Username and Password
When using soapUI (my soap tester) I can just set the Username and Password
in the Request Parameters and when it does a post it sends thoses values.
I'm not sure what I should be doing when Invoking the Partner Link? Should
the assign be setting some variables or is it even possible to use security
in ODE?
Im using Eclipse BPEL to create my BPEL processes
Thanks for any help or links
-Greg
--
View this message in context: http://www.nabble.com/Passing-in-Login-and-Password-tf4386549.html#a12505870
Sent from the Apache Ode User mailing list archive at Nabble.com.
Re: Passing in Login and Password
Posted by Dan Kearns <da...@gmail.com>.
On 9/7/07, Assaf Arkin <ar...@intalio.com> wrote:
> Well, it is a header that's only applicable to some protocol, so it's no
> longer utilizing the WSDL protocol abstraction, it fixes the abstract
> message usage to the actual protocol bindings. And you need as many of
> these as there are authentication protocols.
Not at all. It's perfectly acceptable for wsdl to have policy which doesn't
translate easily to any particular binding. In this case, a username token
does bind reasonably well to http auth, but you could certainly create a
policy which just calls for a credential which is delegable, use that with
the bpel, and bind it however you like. Your binding layer just has to be
smart enough to do the mappings.
A magical authentication context just doesn't make any sense with bpel. If I
send my credentials to invoke the stereotypical dsl provisioning service,
why would the service I called presume my credentials would a) be
technically delegable b) have been granted my permission to delegate them or
c) have any meaning with some other partner in the process at all,
especially with a credential as simplistic as a username/pw? If any of those
things are actually true, then they are part of the both process logic and
the service interface and should be reflected in the wsdl initially.
-d
Re: Passing in Login and Password
Posted by Matthieu Riou <ma...@offthelip.org>.
On 9/9/07, Tammo van Lessen <tv...@gmail.com> wrote:
>
> > what we need is a way to pass those principles from one invoke to
> another,
> > so the process can be invoked on behalf of some principle (maybe admin,
> > maybe johndoe) and invoke another service on behalf of the same
> principle.
> > or we can bind it statically, so the partnerLink will always invoke on
> > behalf of johndoe.
> So you want to share the principle across partnerLinks without
> explicitly copying auth-data into the EPRs? Thats certainly not that
> easy without extending BPEL.
Exactly, which is why we might want to consider extending BPEL.
Otherwise my proposal would be having a WS-A-extension like that:
>
> <assign>
> <copy>
> <from>
> <literal>
> <sref:service-ref>
> <addr:EndpointReference>
> <addr:Address>http://example.com/auction/RegistrationService/
> </addr:Address>
> <addr:ServiceName>as:RegistrationService</addr:ServiceName>
> <basic-auth:user>admin</basic-auth:user>
> <basic-auth:password>secret</basic-auth:password>
> </addr:EndpointReference>
> </sref:service-ref>
> </literal>
> </from>
> <to partnerLink="auctionRegistrationService" />
> </copy>
> </assign>
Imagine a process for which you'd be dealing with several different
principles on the same service. If you have more than a couple of
invocations you'll need a lot of assignments. Add a flow and you'll start
having concurrency issues. Nothing that can't be solved (with more than one
partnerLink for example) but that's a lot of work and unnecessary complexity
in your process.
So I also believe that adding some sort of authentication context is a
better way. As for the wire format, WS-Security UsernameToken seems to be
something we can reuse
Cheers,
Matthieu.
Perhaps we're talking about the same thing with different words?
>
> Best,
> Tammo
>
Re: Passing in Login and Password
Posted by Assaf Arkin <ar...@intalio.com>.
On 9/9/07, Tammo van Lessen <tv...@gmail.com> wrote:
>
>
> > partnerLink roles are strictly invoker or invokee. whether you're admin
> or
> > johndoe, you are still going to interact through a limited set of
> operations
> > available on the interface (portType), and the partnerLink role tells
> you
> > which interface it will be,
> Hm, sure. My examples was a bit misleading. Better would have been:
> UserPortType and AdminPortType. The thing I wanted to point out was
> that at least for webapps the capabillities of a service often change
> depending on the credentials a user has. Translated to Web Services
> this would result in different interfaces/portTypes, so it would make
> sense to model it in BPEL as different partnerLinks (adminPL, userPL)
> which might be bound to the same EPR.
Yes, those would be different portTypes/partnerLinks/EPRs.
> what we need is a way to pass those principles from one invoke to another,
> > so the process can be invoked on behalf of some principle (maybe admin,
> > maybe johndoe) and invoke another service on behalf of the same
> principle.
> > or we can bind it statically, so the partnerLink will always invoke on
> > behalf of johndoe.
> So you want to share the principle across partnerLinks without
> explicitly copying auth-data into the EPRs? Thats certainly not that
> easy without extending BPEL.
I know, and it's something BPEL 2.0 doesn't deal with, and in my opinion
would warrant an extension if we want to make it easy to use.
Otherwise my proposal would be having a WS-A-extension like that:
>
> <assign>
> <copy>
> <from>
> <literal>
> <sref:service-ref>
> <addr:EndpointReference>
> <addr:Address>http://example.com/auction/RegistrationService/
> </addr:Address>
> <addr:ServiceName>as:RegistrationService</addr:ServiceName>
> <basic-auth:user>admin</basic-auth:user>
> <basic-auth:password>secret</basic-auth:password>
> </addr:EndpointReference>
> </sref:service-ref>
> </literal>
> </from>
> <to partnerLink="auctionRegistrationService" />
> </copy>
> </assign>
>
> Perhaps we're talking about the same thing with different words?
That would only work if you're using basic authentication all around, care
to store clear text passwords, and those passwords never change.
Assaf
Best,
> Tammo
>
Re: Passing in Login and Password
Posted by Eduardo Burgos <eb...@gmail.com>.
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 <ar...@intalio.com> wrote:
>
> On 9/11/07, Alex Boisvert <bo...@intalio.com> wrote:
> >
> > On 9/10/07, Noel J. Bergman <no...@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
> >
>
Re: Passing in Login and Password
Posted by Assaf Arkin <ar...@intalio.com>.
On 9/11/07, Alex Boisvert <bo...@intalio.com> wrote:
>
> On 9/10/07, Noel J. Bergman <no...@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
>
Re: Passing in Login and Password
Posted by Alex Boisvert <bo...@intalio.com>.
On 9/10/07, Noel J. Bergman <no...@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.
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
RE: Passing in Login and Password
Posted by "Noel J. Bergman" <no...@devtech.com>.
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.
--- Noel
Re: Passing in Login and Password
Posted by Assaf Arkin <ar...@intalio.com>.
On 9/10/07, Alex Boisvert <bo...@intalio.com> wrote:
>
> On 9/10/07, Assaf Arkin <ar...@intalio.com> wrote:
> >
> > 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.
>
>
> I would much prefer if we could assert the user/roles as a guard to the
> <receive> instead of having to use <if> later in the process and having to
> loop back to the <receive> in case the assertions aren't met.
Assertions are orthogonal to this.
The first question that needs to be answered is: do you stuff it in the
process, or in the service layer. I'm personally inclined to go with the
service layer. Whatever you invest there will work for your processes and
Java code and anything else you can put behind a service.
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. Credentials you can use
in HTTP Authenticate header, to open FTP connection, access e-mails from a
POP3 server, and so forth.
Assaf
alex
>
RE: Passing in Login and Password
Posted by "Noel J. Bergman" <no...@devtech.com>.
Alex Boisvert wrote:
> I would much prefer if we could assert the user/roles as a guard to the
> <receive> instead of having to use <if> later in the process
Not that anyone has asked, but for this I would prefer declarative, managed,
security, too.
> 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.
Is this something that should be developed by Ode, per se, or something to
be raised in BPEL working groups? What are the standardization efforts in
this domain?
I do come across
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4032037
http://portal.acm.org/citation.cfm?id=1173062
http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/proceedin
gs/&toc=comp/proceedings/icws/2006/2669/00/2669toc.xml&DOI=10.1109/ICWS.2006
.21
FWIW.
--- Noel
Re: Passing in Login and Password
Posted by Alex Boisvert <bo...@intalio.com>.
On 9/10/07, Assaf Arkin <ar...@intalio.com> wrote:
>
> 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.
I would much prefer if we could assert the user/roles as a guard to the
<receive> instead of having to use <if> later in the process and having to
loop back to the <receive> in case the assertions aren't met.
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.
alex
Re: Passing in Login and Password
Posted by Assaf Arkin <ar...@intalio.com>.
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
Re: Passing in Login and Password
Posted by Assaf Arkin <ar...@intalio.com>.
On 9/10/07, Alex Boisvert <bo...@intalio.com> wrote:
>
> On 9/10/07, Assaf Arkin <ar...@intalio.com> wrote:
> >
> > > Similar to correlation on a receive, assertions effectively guard the
> > > activity from executing until all the necessary conditions have been
> > met.
> >
> >
> > So basically:
> > 1. Receive with some principal, store in foo.
> > 2. Don't check.
> > 3. Invoke using foo, making assertion.
> > 3.1. Get response, or
> > 3.2. Crash
>
>
> Sorry, I misunderstood what you were asking. I was talking about
> checking
> security assertions on <bpel:receive>.
>
> For <bpel:invoke>, the extension would allow you to specify which
> credentials (roles) you want to have propagated. The recipient is
> responsible for checking your assertions.
I'm talking about invoke, not receive.
Receive is a separate issue, which apparently I lost track of through this
thread, so let's bring it back. Conceptually, a receive should use
authorization to limit access based on user or role. (You only ever need
one to grant access)
I'm saying conceptually so we don't go mapping these two into attributes on
receive. Practically the way you find the user/role to match against the
receive requires a lot more capabilities. Can I have a list of users?
Reference a group? Group with exclusion? Same combinations for roles? Can
I not say anything but point to a service that will answer that question?
Those all require a much more elaborate syntax.
What does this do?
> >
> > sudo ssh myserver.com
> >
> > Per RBAC concept I'm executing on remote shell as sudo assaf, same
> > activation.
> >
> > Per my SSH stack, I'm executing on remote shell as uncontrolled root.
> > Actually none of my servers allow me to sudo ssh into them.
>
>
> Actually, you can configure ssh (the client) to forward credentials for
> you,
> and you can use ssh-agent to create a security context that automatically
> forwards credentials that you explicitly define (ssh-add). Same
> principles, different implementation.
Automatically forwards credentials (principal) or security context? The two
are different. My point all along is that you're passing around principals
-- credentials happen to be one way of doing it but not the only one -- so
the invoke method only needs a way to map a principal into the invocation.
This can be done in the invoke, the way you assign an output value or bring
in a correlation, though should be it's own extensions for this specific
purpose, or brought in from the EPR.
Assaf
alex
>
Re: Passing in Login and Password
Posted by Alex Boisvert <bo...@intalio.com>.
On 9/10/07, Assaf Arkin <ar...@intalio.com> wrote:
>
> > Similar to correlation on a receive, assertions effectively guard the
> > activity from executing until all the necessary conditions have been
> met.
>
>
> So basically:
> 1. Receive with some principal, store in foo.
> 2. Don't check.
> 3. Invoke using foo, making assertion.
> 3.1. Get response, or
> 3.2. Crash
Sorry, I misunderstood what you were asking. I was talking about checking
security assertions on <bpel:receive>.
For <bpel:invoke>, the extension would allow you to specify which
credentials (roles) you want to have propagated. The recipient is
responsible for checking your assertions.
What does this do?
>
> sudo ssh myserver.com
>
> Per RBAC concept I'm executing on remote shell as sudo assaf, same
> activation.
>
> Per my SSH stack, I'm executing on remote shell as uncontrolled root.
> Actually none of my servers allow me to sudo ssh into them.
Actually, you can configure ssh (the client) to forward credentials for you,
and you can use ssh-agent to create a security context that automatically
forwards credentials that you explicitly define (ssh-add). Same
principles, different implementation.
alex
Re: Passing in Login and Password
Posted by Assaf Arkin <ar...@intalio.com>.
On 9/10/07, Alex Boisvert <bo...@intalio.com> wrote:
>
> On 9/10/07, Assaf Arkin <ar...@intalio.com> wrote:
> >
> > On 9/10/07, Alex Boisvert <bo...@intalio.com> wrote:
> > > That's not the point. You may still want to have only JohnDoe or any
> HR
> > > personnel invoke a specific operation, irrespective of whether the
> > > operation
> > > is a workflow task.
> >
> > .. or fail the activity? I'm totally missing how the activity expects
> to
> > behave.
>
>
> Similar to correlation on a receive, assertions effectively guard the
> activity from executing until all the necessary conditions have been met.
So basically:
1. Receive with some principal, store in foo.
2. Don't check.
3. Invoke using foo, making assertion.
3.1. Get response, or
3.2. Crash
Correlations on invoke are a necessary evil because it so turns out that the
killer feature, using the correlation to stuff values in the outgoing
message, is hard to implement. And the assignments are already problematic
enough that the least they could do is offer some checks and balances.
But checking roles on invoke? I would think that if the principal shouldn't
do something, you would check for it and either not start the process, or
not go down that path, rather than react to a fault.
Loosely coupled is different from distributed. In a loosely coupled
> > architecture you
> > a) never trust the client inputs but validate them yourself, and b)
> never
> > provide more information than you want a service to act upon
>
>
> Completely agree.
>
> That part we know works very well: HTTP basic/digest, WSSE security token,
> > SAML, JDBC, FTP, SSH, POP3, etc. How do we send roles with assertions
> > around? Can I send root (but treat as user) to a service that might
> then
> > end up being a JDBC call or SSH invocation?
>
>
> Speaking of Unix, "sudo" is a great example of role
> activation. Assertions
> don't require trust in the sender/invoker; they only require trust in the
> signer. Roles are a form of credential so it's legitimate to pass them
> around.
What does this do?
sudo ssh myserver.com
Per RBAC concept I'm executing on remote shell as sudo assaf, same
activation.
Per my SSH stack, I'm executing on remote shell as uncontrolled root.
Actually none of my servers allow me to sudo ssh into them.
Assaf
alex
>
Re: Passing in Login and Password
Posted by Alex Boisvert <bo...@intalio.com>.
On 9/10/07, Assaf Arkin <ar...@intalio.com> wrote:
>
> On 9/10/07, Alex Boisvert <bo...@intalio.com> wrote:
> > That's not the point. You may still want to have only JohnDoe or any HR
> > personnel invoke a specific operation, irrespective of whether the
> > operation
> > is a workflow task.
>
> .. or fail the activity? I'm totally missing how the activity expects to
> behave.
Similar to correlation on a receive, assertions effectively guard the
activity from executing until all the necessary conditions have been met.
Loosely coupled is different from distributed. In a loosely coupled
> architecture you
> a) never trust the client inputs but validate them yourself, and b) never
> provide more information than you want a service to act upon
Completely agree.
That part we know works very well: HTTP basic/digest, WSSE security token,
> SAML, JDBC, FTP, SSH, POP3, etc. How do we send roles with assertions
> around? Can I send root (but treat as user) to a service that might then
> end up being a JDBC call or SSH invocation?
Speaking of Unix, "sudo" is a great example of role activation. Assertions
don't require trust in the sender/invoker; they only require trust in the
signer. Roles are a form of credential so it's legitimate to pass them
around.
alex
Re: Passing in Login and Password
Posted by Assaf Arkin <ar...@intalio.com>.
On 9/10/07, Alex Boisvert <bo...@intalio.com> wrote:
>
>
> That's not the point. You may still want to have only JohnDoe or any HR
> personnel invoke a specific operation, irrespective of whether the
> operation
> is a workflow task.
.. or fail the activity? I'm totally missing how the activity expects to
behave.
Asserting that a user belongs to a role on invoke is pointless, the receiver
> > > > should never trust your assertion and should make up their own
> > > > determination
> > > > upon receiving the message.
> > >
> > >
> > > An important RBAC concept is that of role activation. If you happen
> to
> > > have
> > > administrator role, you may not want to assert this authority at all
> > times
> > > because you might unknowingly use a privilege that you don't intent to
> > > use,
> > > or you don't want to delegate all your authority to a process that
> does
> > > who-knows-what. Explicitly asserting roles allows you to control how
> > > much
> > > authority you're passing on.
> >
> > Except that concept brings with it the weight of a tightly-coupled
> > centralized architecture for which it was designed, and I'm not sure
> it's
> > a
> > good idea to do that.
>
>
> No it doesn't. How did you come up with that conclusion? RBAC with role
> activation can work in a distributed environment with, e.g., a web of
> trust
> without central root to the system.
Loosely coupled is different from distributed. In a loosely coupled
architecture you
a) never trust the client inputs but validate them yourself, and b) never
provide more information than you want a service to act upon. So the only
thing you're passing around are credentials.
That part we know works very well: HTTP basic/digest, WSSE security token,
SAML, JDBC, FTP, SSH, POP3, etc. How do we send roles with assertions
around? Can I send root (but treat as user) to a service that might then
end up being a JDBC call or SSH invocation?
Assaf
alex
>
Re: Passing in Login and Password
Posted by Alex Boisvert <bo...@intalio.com>.
On 9/9/07, Assaf Arkin <ar...@intalio.com> wrote:
>
> > A use-case for principal and role is when I want JohnDoe to approve his
> > report's leave of absence, or somebody with HR management role.
>
> Isn't that an issue for a workflow task manager?
>
> A workflow task manager would allow you to specify who can take ownership
> of
> (perform) the task through various means, so you can certainly say johndoe
> and/or HR. Also who can observe the task, admin it, and so forth.
>
> But those are separate, and an task manager would still require you to
> authenticate as the creator of the task. Authorization should be about
> the
> invoker, nor the performer.
That's not the point. You may still want to have only JohnDoe or any HR
personnel invoke a specific operation, irrespective of whether the operation
is a workflow task.
Asserting that a user belongs to a role on invoke is pointless, the receiver
> > > should never trust your assertion and should make up their own
> > > determination
> > > upon receiving the message.
> >
> >
> > An important RBAC concept is that of role activation. If you happen to
> > have
> > administrator role, you may not want to assert this authority at all
> times
> > because you might unknowingly use a privilege that you don't intent to
> > use,
> > or you don't want to delegate all your authority to a process that does
> > who-knows-what. Explicitly asserting roles allows you to control how
> > much
> > authority you're passing on.
>
> Except that concept brings with it the weight of a tightly-coupled
> centralized architecture for which it was designed, and I'm not sure it's
> a
> good idea to do that.
No it doesn't. How did you come up with that conclusion? RBAC with role
activation can work in a distributed environment with, e.g., a web of trust
without central root to the system.
alex
Re: Passing in Login and Password
Posted by Assaf Arkin <ar...@intalio.com>.
On 9/9/07, Alex Boisvert <bo...@intalio.com> wrote:
>
> On 9/9/07, Assaf Arkin <ar...@intalio.com> wrote:
> >
> > I think it should be principal or role on receive, principal on invoke.
> > Asserting that a user belongs to a role on receive is something that
> > authorization system should deal with, no need to change the process
> > definition each time an employee joins/leaves the company or changes
> jobs.
>
>
> A use-case for principal and role is when I want JohnDoe to approve his
> report's leave of absence, or somebody with HR management role.
Isn't that an issue for a workflow task manager?
A workflow task manager would allow you to specify who can take ownership of
(perform) the task through various means, so you can certainly say johndoe
and/or HR. Also who can observe the task, admin it, and so forth.
But those are separate, and an task manager would still require you to
authenticate as the creator of the task. Authorization should be about the
invoker, nor the performer.
Asserting that a user belongs to a role on invoke is pointless, the receiver
> > should never trust your assertion and should make up their own
> > determination
> > upon receiving the message.
>
>
> An important RBAC concept is that of role activation. If you happen to
> have
> administrator role, you may not want to assert this authority at all times
> because you might unknowingly use a privilege that you don't intent to
> use,
> or you don't want to delegate all your authority to a process that does
> who-knows-what. Explicitly asserting roles allows you to control how
> much
> authority you're passing on.
Except that concept brings with it the weight of a tightly-coupled
centralized architecture for which it was designed, and I'm not sure it's a
good idea to do that.
Assaf
alex
>
Re: Passing in Login and Password
Posted by Alex Boisvert <bo...@intalio.com>.
On 9/9/07, Assaf Arkin <ar...@intalio.com> wrote:
>
> I think it should be principal or role on receive, principal on invoke.
> Asserting that a user belongs to a role on receive is something that
> authorization system should deal with, no need to change the process
> definition each time an employee joins/leaves the company or changes jobs.
A use-case for principal and role is when I want JohnDoe to approve his
report's leave of absence, or somebody with HR management role.
Asserting that a user belongs to a role on invoke is pointless, the receiver
> should never trust your assertion and should make up their own
> determination
> upon receiving the message.
An important RBAC concept is that of role activation. If you happen to have
administrator role, you may not want to assert this authority at all times
because you might unknowingly use a privilege that you don't intent to use,
or you don't want to delegate all your authority to a process that does
who-knows-what. Explicitly asserting roles allows you to control how much
authority you're passing on.
alex
Re: Passing in Login and Password
Posted by Assaf Arkin <ar...@intalio.com>.
On 9/9/07, Alex Boisvert <bo...@intalio.com> wrote:
>
> At a more abstract level, I was thinking about BPEL extensions whereby you
> could assert identity (e.g. subject/principal/user) and authority (e.g.
> roles), such as
>
> <bpel:invoke>
> <rbac-ext:assert user="..." roles="..." /> <!-- propagate
> identity
> and/or authority assertions -->
> </bpel:invoke>
>
> (where propagation can happen through different protocols and types of
> credentials)
>
> and
>
> <bpel:receive>
> <rbac-ext:assert users="..." roles="..." />
> </bpel:receive>
>
> (to restrict operations to certain identities / authority groups)
>
> There's overlap here with some of the BPEL4People concepts (that borrow
> and
> extend the RBAC specs) so we might as well leverage the same semantic
> wherever possible. Credentials would be stored/accessed from the security
> context but would typically never be used directly in the process to
> maximize portability.
I think it should be principal or role on receive, principal on invoke.
Asserting that a user belongs to a role on receive is something that
authorization system should deal with, no need to change the process
definition each time an employee joins/leaves the company or changes jobs.
Asserting that a user belongs to a role on invoke is pointless, the receiver
should never trust your assertion and should make up their own determination
upon receiving the message.
Assaf
alex
>
>
> On 9/9/07, Tammo van Lessen <tv...@gmail.com> wrote:
> >
> > 2007/9/10, Assaf Arkin <ar...@intalio.com>:
> > > On 9/9/07, Tammo van Lessen <tv...@gmail.com> wrote:
> > > >
> > > > 2007/9/7, Assaf Arkin <ar...@intalio.com>:
> > > > > Well, it is a header that's only applicable to some protocol, so
> > it's no
> > > > > longer utilizing the WSDL protocol abstraction, it fixes the
> > abstract
> > > > > message usage to the actual protocol bindings. And you need as
> many
> > of
> > > > > these as there are authentication protocols. And it is holding on
> > to
> > > > > username/password, one of which might change before the process
> > > > completes.
> > > > >
> > > > > The proper way would be to add an authentication context that's
> > separate
> > > > > from the message definition, but can be carried across operations,
> > and
> > > > let
> > > > > the protocol binding deal with mapping it to the details of each
> > > > protocol.
> > > >
> > > > > I don't think extending PartnerLink is enough, that would only
> allow
> > you
> > > > to
> > > > > always authenticate as the same subject against the same
> > service. It's
> > > > > quite common to expect authorization to change, e.g. depending on
> > who
> > > > > started the process.
> > > > But wouldn't this imply to take another "role" in terms of
> partnerLink
> > > > roles? e.g. when I'm logged in as "admin" I'm taking another role as
> > > > when I was logged in as "johndoe", normal customer. And even such a
> > > > distinction cannot be modeled via 2 partnerLinks, one could <assign>
> > > > different credentials to a partnerLink. Or am I wrong?
> > >
> > > partnerLink roles are strictly invoker or invokee. whether you're
> admin
> > or
> > > johndoe, you are still going to interact through a limited set of
> > operations
> > > available on the interface (portType), and the partnerLink role tells
> > you
> > > which interface it will be,
> > Hm, sure. My examples was a bit misleading. Better would have been:
> > UserPortType and AdminPortType. The thing I wanted to point out was
> > that at least for webapps the capabillities of a service often change
> > depending on the credentials a user has. Translated to Web Services
> > this would result in different interfaces/portTypes, so it would make
> > sense to model it in BPEL as different partnerLinks (adminPL, userPL)
> > which might be bound to the same EPR.
> >
> > > what we need is a way to pass those principles from one invoke to
> > another,
> > > so the process can be invoked on behalf of some principle (maybe
> admin,
> > > maybe johndoe) and invoke another service on behalf of the same
> > principle.
> > > or we can bind it statically, so the partnerLink will always invoke on
> > > behalf of johndoe.
> > So you want to share the principle across partnerLinks without
> > explicitly copying auth-data into the EPRs? Thats certainly not that
> > easy without extending BPEL.
> >
> > Otherwise my proposal would be having a WS-A-extension like that:
> >
> > <assign>
> > <copy>
> > <from>
> > <literal>
> > <sref:service-ref>
> > <addr:EndpointReference>
> > <addr:Address>
> http://example.com/auction/RegistrationService/
> > </addr:Address>
> > <addr:ServiceName>as:RegistrationService</addr:ServiceName>
> > <basic-auth:user>admin</basic-auth:user>
> > <basic-auth:password>secret</basic-auth:password>
> > </addr:EndpointReference>
> > </sref:service-ref>
> > </literal>
> > </from>
> > <to partnerLink="auctionRegistrationService" />
> > </copy>
> > </assign>
> >
> > Perhaps we're talking about the same thing with different words?
> >
> > Best,
> > Tammo
> >
>
Re: Passing in Login and Password
Posted by Alex Boisvert <bo...@intalio.com>.
At a more abstract level, I was thinking about BPEL extensions whereby you
could assert identity (e.g. subject/principal/user) and authority (e.g.
roles), such as
<bpel:invoke>
<rbac-ext:assert user="..." roles="..." /> <!-- propagate identity
and/or authority assertions -->
</bpel:invoke>
(where propagation can happen through different protocols and types of
credentials)
and
<bpel:receive>
<rbac-ext:assert users="..." roles="..." />
</bpel:receive>
(to restrict operations to certain identities / authority groups)
There's overlap here with some of the BPEL4People concepts (that borrow and
extend the RBAC specs) so we might as well leverage the same semantic
wherever possible. Credentials would be stored/accessed from the security
context but would typically never be used directly in the process to
maximize portability.
alex
On 9/9/07, Tammo van Lessen <tv...@gmail.com> wrote:
>
> 2007/9/10, Assaf Arkin <ar...@intalio.com>:
> > On 9/9/07, Tammo van Lessen <tv...@gmail.com> wrote:
> > >
> > > 2007/9/7, Assaf Arkin <ar...@intalio.com>:
> > > > Well, it is a header that's only applicable to some protocol, so
> it's no
> > > > longer utilizing the WSDL protocol abstraction, it fixes the
> abstract
> > > > message usage to the actual protocol bindings. And you need as many
> of
> > > > these as there are authentication protocols. And it is holding on
> to
> > > > username/password, one of which might change before the process
> > > completes.
> > > >
> > > > The proper way would be to add an authentication context that's
> separate
> > > > from the message definition, but can be carried across operations,
> and
> > > let
> > > > the protocol binding deal with mapping it to the details of each
> > > protocol.
> > >
> > > > I don't think extending PartnerLink is enough, that would only allow
> you
> > > to
> > > > always authenticate as the same subject against the same
> service. It's
> > > > quite common to expect authorization to change, e.g. depending on
> who
> > > > started the process.
> > > But wouldn't this imply to take another "role" in terms of partnerLink
> > > roles? e.g. when I'm logged in as "admin" I'm taking another role as
> > > when I was logged in as "johndoe", normal customer. And even such a
> > > distinction cannot be modeled via 2 partnerLinks, one could <assign>
> > > different credentials to a partnerLink. Or am I wrong?
> >
> > partnerLink roles are strictly invoker or invokee. whether you're admin
> or
> > johndoe, you are still going to interact through a limited set of
> operations
> > available on the interface (portType), and the partnerLink role tells
> you
> > which interface it will be,
> Hm, sure. My examples was a bit misleading. Better would have been:
> UserPortType and AdminPortType. The thing I wanted to point out was
> that at least for webapps the capabillities of a service often change
> depending on the credentials a user has. Translated to Web Services
> this would result in different interfaces/portTypes, so it would make
> sense to model it in BPEL as different partnerLinks (adminPL, userPL)
> which might be bound to the same EPR.
>
> > what we need is a way to pass those principles from one invoke to
> another,
> > so the process can be invoked on behalf of some principle (maybe admin,
> > maybe johndoe) and invoke another service on behalf of the same
> principle.
> > or we can bind it statically, so the partnerLink will always invoke on
> > behalf of johndoe.
> So you want to share the principle across partnerLinks without
> explicitly copying auth-data into the EPRs? Thats certainly not that
> easy without extending BPEL.
>
> Otherwise my proposal would be having a WS-A-extension like that:
>
> <assign>
> <copy>
> <from>
> <literal>
> <sref:service-ref>
> <addr:EndpointReference>
> <addr:Address>http://example.com/auction/RegistrationService/
> </addr:Address>
> <addr:ServiceName>as:RegistrationService</addr:ServiceName>
> <basic-auth:user>admin</basic-auth:user>
> <basic-auth:password>secret</basic-auth:password>
> </addr:EndpointReference>
> </sref:service-ref>
> </literal>
> </from>
> <to partnerLink="auctionRegistrationService" />
> </copy>
> </assign>
>
> Perhaps we're talking about the same thing with different words?
>
> Best,
> Tammo
>
Re: Passing in Login and Password
Posted by Tammo van Lessen <tv...@gmail.com>.
2007/9/10, Assaf Arkin <ar...@intalio.com>:
> On 9/9/07, Tammo van Lessen <tv...@gmail.com> wrote:
> >
> > 2007/9/7, Assaf Arkin <ar...@intalio.com>:
> > > Well, it is a header that's only applicable to some protocol, so it's no
> > > longer utilizing the WSDL protocol abstraction, it fixes the abstract
> > > message usage to the actual protocol bindings. And you need as many of
> > > these as there are authentication protocols. And it is holding on to
> > > username/password, one of which might change before the process
> > completes.
> > >
> > > The proper way would be to add an authentication context that's separate
> > > from the message definition, but can be carried across operations, and
> > let
> > > the protocol binding deal with mapping it to the details of each
> > protocol.
> >
> > > I don't think extending PartnerLink is enough, that would only allow you
> > to
> > > always authenticate as the same subject against the same service. It's
> > > quite common to expect authorization to change, e.g. depending on who
> > > started the process.
> > But wouldn't this imply to take another "role" in terms of partnerLink
> > roles? e.g. when I'm logged in as "admin" I'm taking another role as
> > when I was logged in as "johndoe", normal customer. And even such a
> > distinction cannot be modeled via 2 partnerLinks, one could <assign>
> > different credentials to a partnerLink. Or am I wrong?
>
> partnerLink roles are strictly invoker or invokee. whether you're admin or
> johndoe, you are still going to interact through a limited set of operations
> available on the interface (portType), and the partnerLink role tells you
> which interface it will be,
Hm, sure. My examples was a bit misleading. Better would have been:
UserPortType and AdminPortType. The thing I wanted to point out was
that at least for webapps the capabillities of a service often change
depending on the credentials a user has. Translated to Web Services
this would result in different interfaces/portTypes, so it would make
sense to model it in BPEL as different partnerLinks (adminPL, userPL)
which might be bound to the same EPR.
> what we need is a way to pass those principles from one invoke to another,
> so the process can be invoked on behalf of some principle (maybe admin,
> maybe johndoe) and invoke another service on behalf of the same principle.
> or we can bind it statically, so the partnerLink will always invoke on
> behalf of johndoe.
So you want to share the principle across partnerLinks without
explicitly copying auth-data into the EPRs? Thats certainly not that
easy without extending BPEL.
Otherwise my proposal would be having a WS-A-extension like that:
<assign>
<copy>
<from>
<literal>
<sref:service-ref>
<addr:EndpointReference>
<addr:Address>http://example.com/auction/RegistrationService/</addr:Address>
<addr:ServiceName>as:RegistrationService</addr:ServiceName>
<basic-auth:user>admin</basic-auth:user>
<basic-auth:password>secret</basic-auth:password>
</addr:EndpointReference>
</sref:service-ref>
</literal>
</from>
<to partnerLink="auctionRegistrationService" />
</copy>
</assign>
Perhaps we're talking about the same thing with different words?
Best,
Tammo
Re: Passing in Login and Password
Posted by Assaf Arkin <ar...@intalio.com>.
On 9/9/07, Tammo van Lessen <tv...@gmail.com> wrote:
>
> 2007/9/7, Assaf Arkin <ar...@intalio.com>:
> > Well, it is a header that's only applicable to some protocol, so it's no
> > longer utilizing the WSDL protocol abstraction, it fixes the abstract
> > message usage to the actual protocol bindings. And you need as many of
> > these as there are authentication protocols. And it is holding on to
> > username/password, one of which might change before the process
> completes.
> >
> > The proper way would be to add an authentication context that's separate
> > from the message definition, but can be carried across operations, and
> let
> > the protocol binding deal with mapping it to the details of each
> protocol.
>
> > I don't think extending PartnerLink is enough, that would only allow you
> to
> > always authenticate as the same subject against the same service. It's
> > quite common to expect authorization to change, e.g. depending on who
> > started the process.
> But wouldn't this imply to take another "role" in terms of partnerLink
> roles? e.g. when I'm logged in as "admin" I'm taking another role as
> when I was logged in as "johndoe", normal customer. And even such a
> distinction cannot be modeled via 2 partnerLinks, one could <assign>
> different credentials to a partnerLink. Or am I wrong?
partnerLink roles are strictly invoker or invokee. whether you're admin or
johndoe, you are still going to interact through a limited set of operations
available on the interface (portType), and the partnerLink role tells you
which interface it will be,
admin and johndoe are not roles either, but principles. an authorization
system may grant access based on role, in which case admin may be both
principle and role; johndoe will likely be a principle associated with some
generic role (like 'user') or even several roles.
what we need is a way to pass those principles from one invoke to another,
so the process can be invoked on behalf of some principle (maybe admin,
maybe johndoe) and invoke another service on behalf of the same principle.
or we can bind it statically, so the partnerLink will always invoke on
behalf of johndoe.
Assaf
Cheers,
> Tammo
>
> --
> Tammo van Lessen - tvanlessen@gmail.com - http://www.taval.de
>
Re: Passing in Login and Password
Posted by Tammo van Lessen <tv...@gmail.com>.
2007/9/7, Assaf Arkin <ar...@intalio.com>:
> Well, it is a header that's only applicable to some protocol, so it's no
> longer utilizing the WSDL protocol abstraction, it fixes the abstract
> message usage to the actual protocol bindings. And you need as many of
> these as there are authentication protocols. And it is holding on to
> username/password, one of which might change before the process completes.
>
> The proper way would be to add an authentication context that's separate
> from the message definition, but can be carried across operations, and let
> the protocol binding deal with mapping it to the details of each protocol.
> I don't think extending PartnerLink is enough, that would only allow you to
> always authenticate as the same subject against the same service. It's
> quite common to expect authorization to change, e.g. depending on who
> started the process.
But wouldn't this imply to take another "role" in terms of partnerLink
roles? e.g. when I'm logged in as "admin" I'm taking another role as
when I was logged in as "johndoe", normal customer. And even such a
distinction cannot be modeled via 2 partnerLinks, one could <assign>
different credentials to a partnerLink. Or am I wrong?
Cheers,
Tammo
--
Tammo van Lessen - tvanlessen@gmail.com - http://www.taval.de
Re: Passing in Login and Password
Posted by Assaf Arkin <ar...@intalio.com>.
On 9/7/07, Dan Kearns <da...@thekearns.org> wrote:
>
> 2007/9/6, Alex Boisvert <bo...@intalio.com>:
> > I've just added experimental support for HTTP authentication in the
> > 1.1branch
> On 9/6/07, Tammo van Lessen < tvanlessen@gmail.com> wrote:
> >
> > Yes, I agree. Introducing an extra message part for credentials is
> > IMHO quite a hack. Since BPEL itself actually deals only with the
> > abstract part of WSDL
>
>
> It isn't a hack, it's the obvious way to create a process which actively
> operates on credentials or other assertions, yet allows the implementor of
> the wsdl binding layer to turn those assertions into some useful behavior.
> Most times, it is just a convenient circumstance that the same wsdl port
> type can be used both for a process and for the (for example) Axis service
> sitting in front of it.
Well, it is a header that's only applicable to some protocol, so it's no
longer utilizing the WSDL protocol abstraction, it fixes the abstract
message usage to the actual protocol bindings. And you need as many of
these as there are authentication protocols. And it is holding on to
username/password, one of which might change before the process completes.
The proper way would be to add an authentication context that's separate
from the message definition, but can be carried across operations, and let
the protocol binding deal with mapping it to the details of each protocol.
I don't think extending PartnerLink is enough, that would only allow you to
always authenticate as the same subject against the same service. It's
quite common to expect authorization to change, e.g. depending on who
started the process.
Assaf
Which of these are you trying to support?
> - http basic auth used as authorization gate before passing a message to a
> process
> - http basic auth used to bootstrap an implicit security context (eg jaas)
> for receiving the message
> - http basic auth used to bootstrap an implicit security context for the
> entire process
> - http basic auth used to implement the binding for a username token
> mentioned in the wsdl message, to be used by the process elsewhere, eg
> sending a message later
> - Make an Ode-centric axis-enabled distro, where you configure axis
> indirectly via Ode
>
> -d
>
Re: Passing in Login and Password
Posted by Dan Kearns <da...@thekearns.org>.
2007/9/6, Alex Boisvert <bo...@intalio.com>:
> I've just added experimental support for HTTP authentication in the
> 1.1branch
On 9/6/07, Tammo van Lessen < tvanlessen@gmail.com> wrote:
>
> Yes, I agree. Introducing an extra message part for credentials is
> IMHO quite a hack. Since BPEL itself actually deals only with the
> abstract part of WSDL
It isn't a hack, it's the obvious way to create a process which actively
operates on credentials or other assertions, yet allows the implementor of
the wsdl binding layer to turn those assertions into some useful behavior.
Most times, it is just a convenient circumstance that the same wsdl port
type can be used both for a process and for the (for example) Axis service
sitting in front of it.
Which of these are you trying to support?
- http basic auth used as authorization gate before passing a message to a
process
- http basic auth used to bootstrap an implicit security context (eg jaas)
for receiving the message
- http basic auth used to bootstrap an implicit security context for the
entire process
- http basic auth used to implement the binding for a username token
mentioned in the wsdl message, to be used by the process elsewhere, eg
sending a message later
- Make an Ode-centric axis-enabled distro, where you configure axis
indirectly via Ode
-d
Re: Passing in Login and Password
Posted by Tammo van Lessen <tv...@gmail.com>.
Hi all,
2007/9/6, Alex Boisvert <bo...@intalio.com>:
> I've just added experimental support for HTTP authentication in the
> 1.1branch
[...]
> I've taken the simple approach of passing a extra message part to carry the
> authentication credentials. Using partnerLinks or some other form of
> extension would be cleaner but would have required additional
> infrastructure. I'd be curious if other developers have feedback on which
> approach we should adopt for security in general. My sense is that we need
> way to abstract security protocol concerns out of the BPEL whenever
> possible.
Yes, I agree. Introducing an extra message part for credentials is
IMHO quite a hack. Since BPEL itself actually deals only with the
abstract part of WSDL, endpoint releated information should not be
part of the process model and therefore also not necessarily part of
the message payload. I think the deployment descriptor would be more
suitable, alternatively or additionally the user credentials could be
placed in the service-ref element to be copied into a partnerLink.
This could be either some proprietary stuff or based on
WS-Addressing/WS-Policy.
What do you guys think on that?
Cheers,
Tammo
PS: I moved that message from user to dev
Re: Passing in Login and Password
Posted by Greg Bluntzer <gb...@gmail.com>.
I downloaded the ode 1.1 branch and tried to compile it on Windows XP
I have never built from source before but tried and failed with this error
running
rake TEST=no package
...
Downloading
http://pxe.intalio.org/public/maven2/commons-logging/commons-logging/1.1/commons-logging
-1.1.jar
100% |.........................................| 51.7KB/ 51.7KB Time:
00:00:01
Downloading commons-logging:commons-logging:pom:1.1
Downloading
http://pxe.intalio.org/public/maven2/commons-logging/commons-logging/1.1/commons-logging
-1.1.pom
100% |.........................................| 6.0KB/ 6.0KB Time:
00:00:00
rake aborted!
No such file or directory - svn status -v
C:/Documents and Settings/gb/workspace/APACHE_ODE_1.1/rakefile:527:in ``'
(See full trace by running task with --trace)
Alex Boisvert wrote:
>
> Greg, Robin,
>
> I've just added experimental support for HTTP authentication in the
> 1.1branch and added a new
> section<http://cwiki.apache.org/confluence/display/ODExSITE/User+Guide#UserGuide-HTTPAuthentication%2528Axis2%2529>in
> the user guide to document it: If you're comfortable enough to build
> Ode, could you give it a try?
>
> I've taken the simple approach of passing a extra message part to carry
> the
> authentication credentials. Using partnerLinks or some other form of
> extension would be cleaner but would have required additional
> infrastructure. I'd be curious if other developers have feedback on
> which
> approach we should adopt for security in general. My sense is that we
> need
> way to abstract security protocol concerns out of the BPEL whenever
> possible.
>
> thanks,
> alex
>
>
> On 9/5/07, Greg Bluntzer <gb...@gmail.com> wrote:
>>
>>
>> Im sure this has been asked before but I could not understand the answers
>> on
>> the forum.
>>
>> The partner Link that I'm calling uses the HTTP Header Authorization to
>> get
>> Username and Password
>>
>> When using soapUI (my soap tester) I can just set the Username and
>> Password
>> in the Request Parameters and when it does a post it sends thoses values.
>>
>> I'm not sure what I should be doing when Invoking the Partner
>> Link? Should
>> the assign be setting some variables or is it even possible to use
>> security
>> in ODE?
>>
>> Im using Eclipse BPEL to create my BPEL processes
>>
>> Thanks for any help or links
>>
>> -Greg
>> --
>> View this message in context:
>> http://www.nabble.com/Passing-in-Login-and-Password-tf4386549.html#a12505870
>> Sent from the Apache Ode User mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Passing-in-Login-and-Password-tf4386549.html#a12528790
Sent from the Apache Ode User mailing list archive at Nabble.com.
Re: Passing in Login and Password
Posted by Alex Boisvert <bo...@intalio.com>.
Greg, Robin,
I've just added experimental support for HTTP authentication in the
1.1branch and added a new
section<http://cwiki.apache.org/confluence/display/ODExSITE/User+Guide#UserGuide-HTTPAuthentication%2528Axis2%2529>in
the user guide to document it: If you're comfortable enough to build
Ode, could you give it a try?
I've taken the simple approach of passing a extra message part to carry the
authentication credentials. Using partnerLinks or some other form of
extension would be cleaner but would have required additional
infrastructure. I'd be curious if other developers have feedback on which
approach we should adopt for security in general. My sense is that we need
way to abstract security protocol concerns out of the BPEL whenever
possible.
thanks,
alex
On 9/5/07, Greg Bluntzer <gb...@gmail.com> wrote:
>
>
> Im sure this has been asked before but I could not understand the answers
> on
> the forum.
>
> The partner Link that I'm calling uses the HTTP Header Authorization to
> get
> Username and Password
>
> When using soapUI (my soap tester) I can just set the Username and
> Password
> in the Request Parameters and when it does a post it sends thoses values.
>
> I'm not sure what I should be doing when Invoking the Partner
> Link? Should
> the assign be setting some variables or is it even possible to use
> security
> in ODE?
>
> Im using Eclipse BPEL to create my BPEL processes
>
> Thanks for any help or links
>
> -Greg
> --
> View this message in context:
> http://www.nabble.com/Passing-in-Login-and-Password-tf4386549.html#a12505870
> Sent from the Apache Ode User mailing list archive at Nabble.com.
>
>