Jean-Sebastien Delfino wrote:
Venkata Krishnan wrote:
- Why did you need two authentication and wsAuthentication intents? is
it because you needed different policy sets on the client and service
side?
Yes, that's the reason. Since the policysets encapsulate things like the
username, password callback hander etc. which could be different for the
client and the server there needed to be different policysets. Having
the
same intent does no guarantee that the right policyset will be matched
i.e.
the client's policyset for the reference and the server's policyset
for the
service. Having unique intents will ensure this mapping.
After looking at this again today I think that having different custom
authentication intents defeats the purpose of intents, turning them into
disguised policySets as they become specific to the particular config of
authentication in parts of your network.
We need a different approach:
- keep intents abstract (authentication)
- declare where different policySets providing authentication should be
applied in the composition.
PolicySet/appliesTo already provides a way to scope the application of a
policySet. Can we just use that?
Some examples:
appliesTo="binding.ws"
appliesTo="[EMAIL PROTECTED]'AccountService']"
appliesTo="../[EMAIL PROTECTED]'AccountServiceComponent']"
Thoughts?
Following up as nobody has posted any further thoughts.
Is the above proposal clear?
Does anybody want to try to fix the policy story or do you want me to do it?
Also, in my opinion having two bigbank samples is overkill. I think we
should just add the policy configuration to the original bigbank instead
of having a secure-bigbank duplicating bigbank. Any objections?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
