xml-xmlbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Campbell <noahcampb...@gmail.com>
Subject Re: xmlbeans xml security
Date Thu, 01 Jul 2004 19:09:06 GMT
Thank you for the explanation.  I went to the Advanced XML Schema with
XMLBeans last night (11:30pm) and got more insight into the project. 
I also appreciate your description.  It starting to make sense now.

The saver pattern is definitely the right place to start.  If
optimizations can be made in the store to help speed this process then
that can be refactored into the appropriate system with the intent of
not breaking any of the other functionality.

One thought would be that the XMLObject can be initialized with a
Subject and if a user is plugging through the data AND have the
correct permissions, they'll be able to get the data, otherwise an
exception or nothing is returned (in the case of encryption which is
the next step).  Just an idea, but it would be cool to allow granular
access control in this way.


Thanks for the architecture overview, I'll probably have more questions.

Noah

On Thu, 1 Jul 2004 09:10:17 -0700, Eric Vasilik <ericvas@bea.com> wrote:
> 
> The saver is a piece of code in the store.  You'll find it in Saver.java
> in the newstore2 source directory.
> 
> Basically, the saver is created when XmlBeans needs to turn a piece of
> the store into text.  This piece can be a whole document or any piece of
> the Infoset.  Note that the saver is used for producing text for
> XmlCursor and XmlObject.
> 
> The saver has been totally rewritten between v1 and v2.  The v2 saver is
> much cleaner.  Let me outline the architecture of the Saver.  First,
> there is an object in the new store called Cur which provides low-level
> cursor like access to the contents of a store.  The saver defines
> another, much simpler, cursor interface call a SaveCur.  The job of the
> various SaveCur's is to make the contents exposed by a Cur or another
> SaveCur look different.
> 
> For example, the PrettySaveCur's job is to take another SaveCur, and
> remove/introduce whitespace for the purposes of pretty printing a
> document.  The FragSaveCur takes a piece of the store defined to be
> between two low-level Cur's and simulate a well formed Xml document.
> There are others.
> 
> Then, the main Saver class takes a low-level Cur, and creates the right
> combination of SaveCurs to produce well formed output.  It also looks at
> the various XmlOptions.  The primary job of the Saver class is to
> add/remove namespace attributes so that the names of elements and
> attributes are preserved properly.
> 
> Then there is the TextSaver class.  The TextSaver derives from the Saver
> class.  Its job is to produce the actual characters, based on direction
> from the base Saver class.  There are a number of abstract methods on
> the Saver class which are called for various pieces of the Infoset.
> 
> What I think the right way to approach c14n is, is to implement a
> CanonicalTextSaver class.  This class would derive from the TextSaver
> and would modify how the TextSaver and the Saver produce the text to
> achieve c14n output.  The base classes would have to be modified to help
> here.  Specifically, dealing with namespace attributes could be tricky.
> 
> Take a look and please ask if you have questions about it.
> 
> - Eric
> 
> 
> > -----Original Message-----
> > From: Noah Campbell [mailto:noahcampbell@gmail.com]
> > Sent: Thursday, July 01, 2004 7:48 AM
> > To: xmlbeans-dev@xml.apache.org
> > Subject: Re: xmlbeans xml security
> >
> > My point exactly.  The store won't turn into a cananical
> > representation of the xml schema because you'll lose infoset fidelity.
> >
> > Sandboxes are fine my be.  Please post to the list when it's there.
> >
> > This functionality will also have to be available through XMLObject
> > since you might be required to cananocalize an arbitrary element or
> > document because it could be a general purpose c14n function on an
> > opaque xml document or it could be an anyType element where no hints
> > from the store (or output of the saver) will be available.
> >
> > Where can I find the saver interface?
> >
> > Noah
> >
> > On Thu, 1 Jul 2004 08:34:14 -0600, David Waite <mass@akuma.org> wrote:
> > > On Jun 30, 2004, at 10:45 PM, Eric Vasilik wrote:
> > >
> > > > I don't think the store is the right place to deal with c14n (you
> > > > mention c13n, I assume you mean c14n).  The store deals with
> storing
> > > > the
> > > > XML Infoset.  The saver is responsible for turning the contents of
> a
> > > > store into a stream of characters (which can, then, be turned into
> a
> > > > stream of bytes via encoding).
> > > >
> > > > Because the store can be mutated, trying to keep it canonicalized
> > > > dynamically would be a nightmare.
> > >
> > > Sure, but I'm wondering if the store could be optimized in how it
> gives
> > > that information to the saver.
> > > Keep in mind that I don't know which of these already exist, or even
> > > how appropriate they are; I'm still not finished reviewing
> newstore2.
> > > I am only proposing that if any of these are valid, they be tried
> and
> > > benchmarked in the sandbox.
> > >
> > > * putting attributes in sorted order rather than sequential order.
> > > * easier determination of the 'namespace axis', although much of
> this
> > > could/should be done via a symbol tracker in the store. In
> particular,
> > > the ability to summarize namespace declarations from the root to an
> > > ancestor, or between an ancestor and descendant
> > > * easier determination if xml: namespaced attributes were declared
> on
> > > an element, same basic rules as the namespace axis.
> > > * normalizing character and entity references as well as line breaks
> > > (should already be done by the sax parser)
> > > * access to schema for default attribute values, although I don't
> know
> > > if the store has his sort of access up
> > >
> > > -David Waite
> > >
> > >
> > >
> > > >
> > > > What type information, of which you speak, is associated with
> c14n?
> > > >
> > > > - Eric
> > > >
> > > > -----Original Message-----
> > > > From: Noah Campbell [mailto:noahcampbell@gmail.com]
> > > > Sent: Wednesday, June 30, 2004 7:37 PM
> > > > To: xmlbeans-dev@xml.apache.org
> > > > Subject: Re: xmlbeans xml security
> > > >
> > > > c13n specifies how to handle white space, attribute ordering,
> > > > stripping namespaces, etc.  As far as representation of the actual
> > > > byte stream is just needs to be unique, not necessarily infoset
> > > > complete.
> > > >
> > > > The store could pre-optimize for c13n and store space tokens in
> the
> > > > recommended c13n spec (again I'm not familar with the store so
> please
> > > > correct me, I want to know how it works).  That way the type
> > > > information can be extracted in c13n order and potentially speed
> up
> > > > the process (since it 'll be compiled on the schema compliation
> > > > instead of when it processed).
> > > >
> > > > Again, this would optimize well defined schemas minus the anys.
> The
> > > > cursor would have to be able to flip into c13n mode while it's
> reading
> > > > the doc.
> > > >
> > > > Noah
> > > >
> > > > PS.  What's the different between the xmlstore Cursor and
> newstore2
> > > > Cursor?
> > > >
> > > > On Wed, 30 Jun 2004 16:05:59 -0700, Christopher Fry <cfry@bea.com>
> > > > wrote:
> > > >>
> > > >> Hey Eric,
> > > >>
> > > >> The output of canonicalization is defined to be a set of utf-8
> bytes.
> > > >> See the canonicalization spec:
> > > >> http://www.w3.org/TR/2001/REC-xml-c14n-20010315.  One area that
> might
> > > > be
> > > >> tricky for the saver is roundtripping namespace prefixes.  Most
> > people
> > > >> actually use exclusive canonicalization:
> > > >> http://www.w3.org/TR/xml-exc-c14n/ .  One thing to note is you
> can
> > > >> actually canonicalize a document in a streaming fashion (you only
> > need
> > > >> local information and a stack to implement it).
> > > >>
> > > >> Most people are actually using exclusive canonicalization in
> XML-Sec
> > > >> impls.
> > > >>
> > > >> Here is a section from the original canonicalization spec:
> > > >>
> > > >> The document is encoded in UTF-8
> > > >> Line breaks normalized to #xA on input, before parsing
> > > >> Attribute values are normalized, as if by a validating processor
> > > >> Character and parsed entity references are replaced
> > > >> CDATA sections are replaced with their character content
> > > >> The XML declaration and document type declaration (DTD) are
> removed
> > > >> Empty elements are converted to start-end tag pairs
> > > >> Whitespace outside of the document element and within start and
> end
> > > > tags
> > > >> is normalized
> > > >> All whitespace in character content is retained (excluding
> characters
> > > >> removed during line feed normalization)
> > > >> Attribute value delimiters are set to quotation marks (double
> quotes)
> > > >> Special characters in attribute values and character content are
> > > >> replaced by character references
> > > >> Superfluous namespace declarations are removed from each element
> > > >> Default attributes are added to each element
> > > >> Lexicographic order is imposed on the namespace declarations and
> > > >> attributes of each element
> > > >>
> > > >> -Chris
> > > >>
> > > >> -----Original Message-----
> > > >> From: Eric Vasilik
> > > >> Sent: Wednesday, June 30, 2004 3:59 PM
> > > >> To: xmlbeans-dev@xml.apache.org
> > > >> Subject: RE: xmlbeans xml security
> > > >>
> > > >> I need a better understanding of what canonicalization means.
> But, I
> > > >> would think that one should be able to take an arbitrary store
> and
> > > >> persist it in a canonical manner.  If the state required to
> perform
> > > > this
> > > >> is not on the order of the size of the document being saved, then
> the
> > > >> saver should be able to be modified to perform this.  The
> advantage
> > of
> > > >> this would be that the store would not be modified for the sake
> of
> > > >> generating a canonical form.
> > > >>
> > > >> If we go this direction, then I recommend creating a new saver
> option
> > > >> and modify the saver to obey it.
> > > >>
> > > >> Question, is a canonical form always a byte stream, or can a DOM
> be
> > in
> > > >> canonical form?
> > > >>
> > > >> - Eric
> > > >>
> > > >>> -----Original Message-----
> > > >>> From: David Remy
> > > >>> Sent: Wednesday, June 30, 2004 3:48 PM
> > > >>> To: xmlbeans-dev@xml.apache.org
> > > >>> Subject: RE: xmlbeans xml security
> > > >>>
> > > >>>
> > > >>>
> > > >>>> -----Original Message-----
> > > >>>> From: David Waite [mailto:mass@akuma.org]
> > > >>>> Sent: Wednesday, June 30, 2004 12:37 PM
> > > >>>> To: xmlbeans-dev@xml.apache.org
> > > >>>> Subject: Re: xmlbeans xml security
> > > >>>>
> > > >>>>
> > > >>>> On Jun 30, 2004, at 11:04 AM, David Remy wrote:
> > > >>>>
> > > >>>>> David (Waite),
> > > >>>>> I got the chance to meet with Noah Campbell for dinner
Mon
> night
> > > >> at
> > > >>>>> JavaOne and he expressed an interest in contributing in
the
> are
> > > > of
> > > >>> xml
> > > >>>>> security.  I wonder if we should start a sandbox in cvs
with a
> > > >>> security
> > > >>>>> directory that we could use to start experimenting on
xml
> > > > security
> > > >>> over
> > > >>>>> xmlbeans.  Unless someone has an issue with that I will
go
> ahead
> > > >> and
> > > >>> do
> > > >>>>> it (specifically under xml-xmlbeans create a subdirectory
> called
> > > >>>>> sandbox and then a security directory under it).
> > > >>>>
> > > >>>> This sounds good to me, although I would suggest we try to
> > > > structure
> > > >>
> > > >>>> the sandbox so that we can keep up-to-date with v2 as easily
as
> > > >>>> possible. In particular, it would be nice to branch newstore2
> if
> > > > we
> > > >>> are
> > > >>>> adding options for c14n.
> > > >>>
> > > >>> i was thinking we would first look at doing the work on top of
> the
> > > > xml
> > > >>
> > > >>> store and look at what requirements might come up when doing an
> xml
> > > >>> security implementation.  i am not positive changes would be
> > > > required
> > > >> in
> > > >>> the store itself for c14n, after more thought it might actually
> be
> > > > an
> > > >>> option on the saver or a different saver implementation (eric,
> what
> > > > do
> > > >>
> > > >>> you think?).
> > > >>>
> > > >>>>
> > > >>>>> Perhaps we should get started on an XML Sig implementation
and
> > > > see
> > > >>> what
> > > >>>>> hurdles we run into.  I *believe* at some point we are
going
> to
> > > >> want
> > > >>> an
> > > >>>>> option on the xml store to keep things in the store
> canonically
> > > > so
> > > >>> that
> > > >>>>> the big c14n copy to create and validate signatures can
be
> > > >> avoided.
> > > >>> In
> > > >>>>> the meantime though we could get started and therefore
define
> > > > any
> > > >>>>> requirements that the store might get.
> > > >>>>
> > > >>>> My understanding is that there is no true 'canonical form',
> since
> > > >>>> canonicalization is just part of the transformation chain,
and
> > > >>>> canonicalization (especially exclusive canonicalization) can
> > > > differ
> > > >>>> based on the starting reference point(s).
> > > >>>
> > > >>> yep, you are right, no such thing as 'load' canonicalized.
> > > >>>
> > > >>>> I think the approach should
> > > >>>> be either to create a new store, or add options on the existing
> > > >> store,
> > > >>>> to make creation of the canonicalized format as efficient
as
> > > >> possible.
> > > >>>
> > > >>> agreed.
> > > >>>
> > > >>>>
> > > >>>>>
> > > >>>>> It only makes sense to have a security implementation
in
> > > > xmlbeans
> > > >> if
> > > >>> we
> > > >>>>> can take advantage of the xml store to improve efficiency,
> > > >> otherwise
> > > >>> we
> > > >>>>> should leave it to apache xml sec ...
> > > >>>>
> > > >>>> We probably should cannibalize as much of xmlsec as possible
> > > > within
> > > >>> the
> > > >>>> sandbox while experimenting, then figure out how to integrate
> with
> > > >> it
> > > >>>> as a separate project before leaving the sandbox.
> > > >>>
> > > >>> yep, i would think that would be the objective for the sandbox
> > > > effort.
> > > >>
> > > >>> since v2 will have a native dom implementation i assume xmlbeans
> > > > would
> > > >>
> > > >>> play well with xml sec pretty close to as is (is that a
> reasonable
> > > >>> assumption?).  if there are special optimizations we can do then
> we
> > > >>> would have to determine whether xml sec would want to/be able
to
> > > > take
> > > >>> advantage of these optimizations (xml sec is patched to take
> > > > advantage
> > > >>
> > > >>> of xmlbeans capabilities when present) or if they are unique to
> > > >> xmlbeans
> > > >>> (xml security becomes a feature of xmlbeans).
> > > >>
> > > >>
> > > >>>
> > > >>>>
> > > >>>> -David Waite
> > > >>>>
> > > >>>>
> > > >>>> -
> > > >>>
> > > >
> ---------------------------------------------------------------------
> > > >>>> To unsubscribe, e-mail:
> xmlbeans-dev-unsubscribe@xml.apache.org
> > > >>>> For additional commands, e-mail:
> xmlbeans-dev-help@xml.apache.org
> > > >>>> Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
> > > >>>
> > > >>>
> > > >>> -
> > > >>
> ---------------------------------------------------------------------
> > > >>> To unsubscribe, e-mail:
> xmlbeans-dev-unsubscribe@xml.apache.org
> > > >>> For additional commands, e-mail:
> xmlbeans-dev-help@xml.apache.org
> > > >>> Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
> > > >>
> > > >> -
> > > >
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
> > > >> For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
> > > > Apache
> > > >> XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
> > > >>
> > > >> -
> > > >
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
> > > >> For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
> > > >> Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
> > > >>
> > > >>
> > > >
> > > > -
> --------------------------------------------------------------------
> > -
> > > > To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
> > > > For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
> > > > Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
> > > >
> > > >
> > > > -
> --------------------------------------------------------------------
> > -
> > > > To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
> > > > For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
> > > > Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
> > > >
> > >
> > > -
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
> > > For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
> > > Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
> > >
> > >
> > 
> > -
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
> > Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
> 
> - ---------------------------------------------------------------------
> To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
> Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
> 
>

- ---------------------------------------------------------------------
To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/


Mime
View raw message