Srinath, we haven't implemented every WSP assertion WSS4J policy parser yet. Mainly because of the ongoing activities in OASIS, on the other hand also because the WSS4J base method do not understand or are not able to handle some token types, e.g. Kerberos. Also SAML is somewhat weak in WSS4J (only basic support). AFAIK WSS4J does not support Issued Token - but WSS4J provides a sort of "plugin" mechanism that could be used to extend the processing for yet unknown security tags.
Regards, Werner Srinath Perera wrote: > Hi Werner; > > >>I'm not quite sure if I fully understand your use case. Maybe I >>need to have a look into the Axis2 module stuff. > > The usecase is really taken from University work, not Axis2. I will > try to explain the use case bit more. > > Our authorization model is based on Capability Tokens (SAML). Service > Providers requesters registers them in a Capability Manager and > Service Requesters should obtain them and send them with requests. > > In order to explain this senario with policy we are trying to use > Issued tokens assertion and providing a Trust STS (Security Token > Service) interface to the Capability Manager. > > Trouble I am facing is that IssuedToken assertion is not understood by > WSS4J but try to process it and after the failure WSS4J do not process > any policy assertion that comes after the IssuedToken Assertion. > > How do you think we should handle them? When Trust support is avalible > will WSS4J automatically obtain capability tokens (using a trust > client to call STS) some day? > > Thanks very much > Srinath > > > > > > > >>As you said, the WSP processor currently understands only tokens >>that are defined by the WSP specification. Pls keep in mind that >>the WSP policy processor implementation is in an early state. >> >>In principle the WSP is extensible. In the OASIS WS-SX TC we are >>discussing how extension assertions, that are not part of the >>WSP specification could be identified such that a WSP parser is able >>to detect and to process them. >> >>WSP only defines the message layout in terms of security, it does >>not define any types of authorization etc. Similary WSS4J does not do >>any type of authorization (its merely an authentication using the >>various tokens). What do you have in mind regarding an authorization >>module? >> >>Regards, >>Werner >> >> >> >>Srinath Perera wrote: >> >>>Hi Werner; >>> >>>I know Policy is still half way done. I doing some work regarding >>>Axis2 policy implementation and asked to know the current status. >>>Myself and Ruchith will be discussing this I will get back to you on >>>this. >>> >>>Let me add a thought? >>> >>> >>>what happens if there is a policy assertion(which fell under >>>WS-Security Policy NS) which is not identified by the WSS4J policy >>>processor and there are more assertions that are identified. Right now >>>as far as I know WSS4J reject the all the policy assertions if this >>>happens >>> >>>It is possible that users security solution consists of WSS4J together >>>with a custom authorization solution and Policy that WSS4J do not >>>understood is intended to authorization module. (Actually the >>>scenario is not hypothetical and I am trying to solve this problem in >>>a scenario involve capability tokens) >>> >>>In axis2 policy processing we allow multiple modules to bind to same >>>policy name space. How do you think this should be handled in terms of >>>WSS4J? >>> >>>Thanks >>>Srinath >>> >>> >>> >>>On 3/3/06, Dittmann, Werner <[EMAIL PROTECTED]> wrote: >>> >>> >>>>All, >>>> >>>>the support of WS SecurityPolicy (WSP) is not yet available in WSS4J. >>>>First of all the WSP spec itself is not yet stable and needs some >>>>more clarification to become usable in a praticable manner. This is >>>>an ongoing activity at the OASIS WS-SX TC. >>>> >>>>In anticipation of WSP support we refactored parts of the WSS4J code. >>>>This refactoring is not yet complete, expect another 2-4 weeks before >>>>that is done (including the tests). This refactoring implies new >>>>interfaces and modifications to the WSS4J Axis/JAX-RPC handler (no >>>>structural modifications, just new classes and some some parameter >>>>changes). >>>> >>>>After this refactoring is done and we have the same functional >>>>level as today we can start with the real WSP support. At that point >>>>in time we need the policy information that a WSDL contains and >>>>process it(a WSDL may contain policies at several points and these >>>>policies have to be merged to form one policy for a specific message). >>>>Policy processing would include several steps: >>>> >>>>- parsing the policy and set-up of an internal data structure that >>>> refelects the policy >>>> >>>>- using this data plus some additional configuration data a new module >>>> which is part of the Axis/JAX-RPC handlers can create the message. >>>> >>>>Having said that: pls allow some more time until we can bring in real >>>>policy support into WSS4J and the associated handlers. >>>> >>>> >>>> >>>> >>>>>-----Ursprüngliche Nachricht----- >>>>>Von: Srinath Perera [mailto:[EMAIL PROTECTED] >>>>>Gesendet: Donnerstag, 2. März 2006 21:35 >>>>>An: [email protected] >>>>>Cc: [email protected] >>>>>Betreff: [Axis2]Level of Policy Support at WSS4J >>>>> >>>>>Hi All; >>>>> >>>>>Right now, when a module is engaged with a AxisService that has policy >>>>>descriptions the Module.engageNotify() -> >>>>>WSSPolicyProcessor.processPolicy() called and the code try to process >>>>>the policy. >>>>> >>>>>What are the level of support from the WSSPolicyProcessor? and what >>>>>are the limitations and TODOs? any room to help? >>>>> >>>>>Srinath >>>>>-- >>>>>============================ >>>>>Srinath Perera: >>>>> http://www.cs.indiana.edu/~hperera/ >>>>> http://www.bloglines.com/blog/hemapani >>>>> >>>>>--------------------------------------------------------------------- >>>>>To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>For additional commands, e-mail: [EMAIL PROTECTED] >>>>> >>>>> >>>> >>> >>>-- >>>============================ >>>Srinath Perera: >>> http://www.cs.indiana.edu/~hperera/ >>> http://www.bloglines.com/blog/hemapani >>> >>>--------------------------------------------------------------------- >>>To unsubscribe, e-mail: [EMAIL PROTECTED] >>>For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> > > > -- > ============================ > Srinath Perera: > http://www.cs.indiana.edu/~hperera/ > http://www.bloglines.com/blog/hemapani >
