Hi Amila, On Tue, 30 Aug 2011 00:15:19 +0530 Amila Jayasekara <[email protected]> wrote:
> Hi Marc, > > > > I went through your initial proposal in detail. > > > > After going through it i understood following, > > 1. SWSSF implementation is no longer using DOM based processing Right > > 2. SWSSF is also doing security policy processing Also correct > > > > I am having few questions related to this. > > As i understood you are no longer using xmlsec or wss4j. So i am > particularly interested how this works. Also according to your initial > description you are no longer using DOM based object model. So what is > the xml processing, object model SWSSF is using ? How it is handling > streaming behaviour ? It will be great if you can give us an overview. > A reference would be sufficient. (If you already have one). In short: StAX iterator API In detail: As far as I know there are three main XML API's in Java: - DOM - SAX - StAX (Cursor and Iterator API) As we all know DOM is not streaming capable because the whole XML will be parsed and hold in the memory. SAX is a streaming model but has the following disadvantages: - Push; The xml-events are pushed to the application - No write API StAX is also a streaming model and has the following advantages: - Pull; Application can request the next events - Write API Because of this and also because CXF (and AFAIK Axis) are build around StaX, I decided to use the StAX model. StAX itself is split again into two API's: The cursor (XMLStreamReader/XMLStreamWriter) and the iterator API (XMLEventReader/XMLEventWriter). When you use the cursor API you are operating directly on the XMLStreamReader/Writer and it's not easy possible to buffer,replay, etc any events. Also if you have built a chain of responsibilities you have to pass the XMLStreamReader through the whole chain. In contrast to the cursor model, the iterator model allows you to store, replay, etc the events. Also you get for free an abstraction between the Reader and the events. In a chain of responsibilities you just have to pass the XMLEvents. So intern in swssf the iterator model is used. Every XMLEvent the application requests from the swssf-stream-reader will be pulled through the swssf chain. swssf analyses every XMLEvent and looks for interesting events. If one is found a new processor will be instanciated and inserted in the chain. A swssf processor is a handler with a specific WebServiceSecurity functionality. E.g there is a DecryptionProcessor which takes care of the decryption. Or a SAMLTokenProcessor to process SAML-Tokens. If you need custom functionality, just write a processor and register it in swssf. > > > SWSSF also implements a security policy processing part. In a previous > mail you mentioned that policy processing cannot be isolated from > security processing part. I agree with you. But in the existing > Rampart implementation the policy processing is build within Rampart. > Rampart is responsible for reading policies from services and > validating them against requests. So with SWSSF i believe this logic > is carried out within WSS4J (Once SWSSF is integrated into WSS4J). If > i am wrong please explain how you expect policy processing should > happened. Also, is policy validating logic built into SWSSF ? Perhaps I did not express myself very well. The policy part of swssf is extremely loose coupled. This was an important design decision. To follow the principle of the streaming model, low resource usage and fail-fast behavior, the just in time evaluation is needed for policy relevant events. This is not supported by Rampart. Up to now, in CXF as example (Please correct me, if I'm wrong), WSS4J is applied to a DOM-Tree and then, when the security-processing is finished, the policy will be verified with the WSSecurityResults-Vector. Most of the needed informations to verify the policy can be looked up in this WSSecurityResults-Vector. swssf emits policy-relevant events just in time. So as example, if swssf finds a X509Token it will be emitted immediately, the Policy-Engine picks it up and throws an exception if it detects that it doesn't meet the policy. Of course there are constelations possible (Cross-Policy-Alternatives) where the policy relevant event can not be verified finally just in time. So there is always a finally verification needed when the security processing is finished. If you compare this behavior with the classic DOM model, this can be a a very big win with regard to memory, cpu and time consumption. But I don't see any reason why not to use Rampart for this job when it supports the just in time evaluation. Also I did use the Rampart and Neethi classes as a starting point. It would be nice if the just in time evaluation could be kept. > > > > I have more questions related to streaming behaviour of SWSSF. But i > will ask them once i get a high-level overview on how SWSSF works. I hope my explanations helps a bit to understand swssf. I will be glad to answer further questions you may have. Kind regards Marc > > Thanks in advance. > > > > AmilaJ > > On Wed, Aug 24, 2011 at 2:05 AM, Daniel Kulp <[email protected]> wrote: > > On Tuesday, August 23, 2011 9:01:27 PM Marc Giger wrote: > >> Hi Dan, > >> > >> On Tue, 23 Aug 2011 13:04:40 -0400 > >> > >> Daniel Kulp <[email protected]> wrote: > >> > Actually, one more grant related things... > >> > > >> > The ip-clearance form mentions making sure the granted files > >> > have the proper Apache license header which the current files do > >> > not. I'm not sure if that can be done after the vote and import > >> > or not. It would be simpler if the granted dump and checksums > >> > and all pointed to a version that had the headers already > >> > updated. > >> > >> The latest revision of the files in the svndump attached in the > >> jira have the following header: > >> > >> /** > >> * Licensed to the Apache Software Foundation (ASF) under one > >> * or more contributor license agreements. See the NOTICE file > >> * distributed with this work for additional information > >> * regarding copyright ownership. The ASF licenses this file > >> * to you under the Apache License, Version 2.0 (the > >> * "License"); you may not use this file except in compliance > >> * with the License. You may obtain a copy of the License at > >> * > >> * http://www.apache.org/licenses/LICENSE-2.0 > >> * > >> * Unless required by applicable law or agreed to in writing, > >> * software distributed under the License is distributed on an > >> * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY > >> * KIND, either express or implied. See the License for the > >> * specific language governing permissions and limitations > >> * under the License. > >> */ > >> > >> AFAIK this should be the correct one, right? Also I added the > >> NOTICE file to the tree. > > > > Ah. OK. I was just looking at the raw dump and I guess was > > ending up looking at previous versions of files. > > > > > > Looks fine. > > > > Thanks! > > Dan > > > > > > > >> Kind regards > >> > >> Marc > >> > >> > Dan > >> > > >> > On Tuesday, August 23, 2011 12:50:20 PM Daniel Kulp wrote: > >> > > On Sunday, August 21, 2011 9:41:42 PM Marc Giger wrote: > >> > > > > There are a few other things to think about with it as well > >> > > > > like > >> > > > > interactions with FastInfoset (which CXF can currently > >> > > > > support, > >> > > > > but this wouldn't due to operating on the OutputStream > >> > > > > directly > >> > > > > instead of an XMLStream/EventWriter). Mapping all the > >> > > > > current > >> > > > > CXF configs in may take a bit as well, but nothing too > >> > > > > major I > >> > > > > would expect. > >> > > > > >> > > > I was just to lazy and had no time left to implement the > >> > > > XMLStreamWriter. At the time, I noticed that a simple > >> > > > OutputStream > >> > > > matches perfectly for the CXF integration. But you are right, > >> > > > this > >> > > > will be a requirement. For the FastInfoset case, maybe we > >> > > > find a more efficient way as writing to an XMLStreamWriter > >> > > > and then translate to FastInfoset... > >> > > > >> > > That's pretty much how fastinfoset works. We have an > >> > > XMLStreamWriter that writes fastinfoset instead of regular XML. > >> > > Thus instead of creating a normal Woodstox (or other Stax) > >> > > XMLStreamWriter that wrappers the OutputStream, we create an FI > >> > > version of an XMLStreamWriter that wrappers the OutputStream. > >> > > It's pretty simple if things can be set to write/read to the > >> > > Stax things instead of raw streams. > >> > > > >> > > > > Filing a grant requires an Apache member to help out, but > >> > > > > Colm > >> > > > > and I are both members (and there are other around here as > >> > > > > well) that would > >> > > > > be more than happy to help out. If you have any questions > >> > > > > about it, > >> > > > > let me know and I'd be happy to help. > >> > > > > >> > > > I prepared the form as far as I could. Please have a look at > >> > > > http://gigerstyle.homelinux.com/downloads/swssf/swssf.xml > >> > > > >> > > OK. I've started with this. Major thanks. I'll get this > >> > > added to the ip- clearance page shortly. > >> > > > >> > > > Also I filled out the grants.txt : > >> > > > > >> > > > http://gigerstyle.homelinux.com/downloads/swssf/grants.txt > >> > > > http://gigerstyle.homelinux.com/downloads/swssf/grants.txt.asc > >> > > > > >> > > > You will find my gpg public key for signature-verification on > >> > > > the > >> > > > key-servers or under the following URL: > >> > > > > >> > > > http://gigerstyle.homelinux.com/?page_id=28 > >> > > > > >> > > > It's not entirely clear to me: Do I have to send some > >> > > > documents to the apache office or secretary? > >> > > > >> > > You need to send the grants.txt file to secretary@ , digitally > >> > > signed. Once they process that, I think we can proceed with the > >> > > rest of the grant. > >> > > > >> > > > Did I everything correctly so far? What are the next steps? > >> > > > >> > > So far, so good. > >> > > > >> > > > > Also, you should file an Apache ICLA: > >> > > > > http://www.apache.org/licenses/#clas > >> > > > > > >> > > > > That's the first step in getting an account created for you > >> > > > > to > >> > > > > become > >> > > > > a committer. Doing that sooner can help speed things up. > >> > > > > >> > > > Also done. I already got an ack from secretary. Should I > >> > > > forward the acknowledgment to you? > >> > > > >> > > I see your name now listed at: > >> > > http://people.apache.org/committer-index.html#unlistedclas > >> > > > >> > > That's all I need. :-) > >> > > > >> > > > > > Do you have some more questions? > >> > > > > > >> > > > > I think that's it for me. Let me just say "very nice > >> > > > > job". :-) > >> > > > > >> > > > Thank you Dan! > >> > > > > >> > > > Kind regards > >> > > > > >> > > > Marc > >> > > > > >> > > > > Dan > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > > -- > > Daniel Kulp > > [email protected] > > http://dankulp.com/blog > > Talend - http://www.talend.com > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Lesson 1: Cryptographic protocols should not be developed by a committee. -- Niels Ferguson and Bruce Schneier -- --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
