Hitachi Vantara Pentaho Community Forums
Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 34

Thread: [Mondrian] xmla security header processing

  1. #11
    Pappyn Bart Guest

    Default [Mondrian] Problem when compiling mondrian head revision

    Hi,



    After trying to pull the latest version from perforce (coming from the
    2.x age), I have the following problems building Mondrian :



    [ivy:resolve] [FAILED ]
    dom4j#dom4j;1.6.1!dom4j.jar(javadoc): The HTTP response code for
    http://repo.pentaho.org/artifactory/.../dom4j-1.6.1.j
    ar did not indicate a success. See log for more detail. (686ms)

    [ivy:resolve] [FAILED ]
    dom4j#dom4j;1.6.1!dom4j.jar(javadoc): The HTTP response code for
    http://repo1.maven.org/maven2/dom4j/....1-javadoc.jar
    did not indicate a success. See log for more detail. (587ms)

    [ivy:resolve] [FAILED ]
    dom4j#dom4j;1.6.1!dom4j.jar(javadoc): The HTTP response code for
    http://repo1.maven.org/maven2/dom4j/....1-javadoc.jar
    did not indicate a success. See log for more detail. (676ms)

    [ivy:resolve] [FAILED ]
    dom4j#dom4j;1.6.1!dom4j.jar(javadoc): (0ms)

    [ivy:resolve] ==== pentaho-rep: tried

    [ivy:resolve]
    http://repo.pentaho.org/artifactory/.../dom4j-1.6.1.j
    ar

    [ivy:resolve] ==== ibiblio: tried

    [ivy:resolve]
    http://repo1.maven.org/maven2/dom4j/....1-javadoc.jar

    [ivy:resolve] ==== public: tried

    [ivy:resolve]
    http://repo1.maven.org/maven2/dom4j/....1-javadoc.jar

    [ivy:resolve]
    ::::::::::::::::::::::::::::::::::::::::::::::

    [ivy:resolve] :: FAILED DOWNLOADS
    ::

    [ivy:resolve] :: ^ see resolution messages for
    details ^ ::

    [ivy:resolve]
    ::::::::::::::::::::::::::::::::::::::::::::::

    [ivy:resolve] ::
    dom4j#dom4j;1.6.1!dom4j.jar(javadoc)

    [ivy:resolve]
    ::::::::::::::::::::::::::::::::::::::::::::::



    All other downloads by ivy are working.



    Any ideas?



    Kind regards,

    Bart


    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  2. #12
    Julian Hyde Guest

    Default RE: [Mondrian] Problem when compiling mondrian head revision

    I cleaned dom4j from my ivy cache and built again. It worked for me:

    [ivy:resolve] downloading
    http://repo1.maven.org/maven2/dom4j/...om4j-1.6.1.jar ...
    [ivy:resolve] ........... (306kB)
    [ivy:resolve] .. (0kB)
    [ivy:resolve] [SUCCESSFUL ] dom4j#dom4j;1.6.1!dom4j.jar (3235ms)


    As you can see, dom4j comes from maven.org. I think it's the only version of
    dom4j we've ever used.

    Maybe just a glitch with your network or with maven.org. Check your firewall
    etc., and try again.

    Julian



    _____

    From: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org] On
    Behalf Of Pappyn Bart
    Sent: Tuesday, May 03, 2011 6:02 AM
    To: Mondrian developer mailing list
    Subject: [Mondrian] Problem when compiling mondrian head revision



    Hi,



    After trying to pull the latest version from perforce (coming from the 2.x
    age), I have the following problems building Mondrian :



    [ivy:resolve] [FAILED ]
    dom4j#dom4j;1.6.1!dom4j.jar(javadoc): The HTTP response code for
    http://repo.pentaho.org/artifactory/...om4j-1.6.1.jar
    did not indicate a success. See log for more detail. (686ms)

    [ivy:resolve] [FAILED ]
    dom4j#dom4j;1.6.1!dom4j.jar(javadoc): The HTTP response code for
    http://repo1.maven.org/maven2/dom4j/....1-javadoc.jar did
    not indicate a success. See log for more detail. (587ms)

    [ivy:resolve] [FAILED ]
    dom4j#dom4j;1.6.1!dom4j.jar(javadoc): The HTTP response code for
    http://repo1.maven.org/maven2/dom4j/....1-javadoc.jar did
    not indicate a success. See log for more detail. (676ms)

    [ivy:resolve] [FAILED ]
    dom4j#dom4j;1.6.1!dom4j.jar(javadoc): (0ms)

    [ivy:resolve] ==== pentaho-rep: tried

    [ivy:resolve]
    http://repo.pentaho.org/artifactory/...om4j-1.6.1.jar

    [ivy:resolve] ==== ibiblio: tried

    [ivy:resolve]
    http://repo1.maven.org/maven2/dom4j/....1-javadoc.jar

    [ivy:resolve] ==== public: tried

    [ivy:resolve]
    http://repo1.maven.org/maven2/dom4j/....1-javadoc.jar

    [ivy:resolve]
    ::::::::::::::::::::::::::::::::::::::::::::::

    [ivy:resolve] :: FAILED DOWNLOADS
    ::

    [ivy:resolve] :: ^ see resolution messages for details
    ^ ::

    [ivy:resolve]
    ::::::::::::::::::::::::::::::::::::::::::::::

    [ivy:resolve] :: dom4j#dom4j;1.6.1!dom4j.jar(javadoc)

    [ivy:resolve]
    ::::::::::::::::::::::::::::::::::::::::::::::



    All other downloads by ivy are working.



    Any ideas?



    Kind regards,

    Bart


    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  3. #13
    Manuel Darveau Guest

    Default Re: [Mondrian] Re: xmla security header processing

    Hi Michele,

    Sorry for the delay. I believe that the version of simba we are using
    is 4.3.6.14. If you look at the screen shot, there are additional
    options and the username/password are transfered to the authenticator.

    We had to put a custom org.mortbay.jetty.security.UserRealm into a
    org.mortbay.jetty.security.SecurityHandler and associate it to the
    org.mortbay.jetty.servlet.Context.
    The UserRealm receives the username/password from excel in it's
    com.eightd.ftk.jetty.configuration.DBUserRealm.authenticate(String,
    Object, Request) method.

    Manuel

    On Wed, Apr 27, 2011 at 6:28 AM, Michele Rossi <michele.rossi (AT) gmail (DOT) com> wrote:[color=blue]
    > Hi Manuel,
    > I have the latest (as far as I know) version of SimbaO2X, 4.3.6.14 and I
    > don't see anything like that in Excel.
    > I have Excel 2007 and I've tried with both the available login dialogs - see
    > attached screenshots.
    > In any case a mechanism handled solely by the container wouldn't be great
    > for me as it's very likely that the underlying servlet wouldn't have access
    > to the security credentials.
    > I want to use them to open an authenticated Olap Connection.
    > thanks,
    > Michele
    >
    > On 27 April 2011 04:39, Manuel Darveau <manueldarveau (AT) gmail (DOT) com> wrote:[color=green]
    >>
    >> Hi Michele,
    >>
    >> You might want to take a look at the latest SimbaO2X version since it
    >> does support authentication at the servlet container level. In the
    >> connection dialog, there are username password textfields and a new
    >> checkbox to support cookie and thus, keeping session information. We
    >> just implemented a custom authentication integrated with an embedded
    >> jetty. I can provide some source if you want to. The only drawback
    >> with this approach is that is the user does not check the "cookie
    >> support" (whatever it is actually called), the authentication will be
    >> done on every request so you should implement a cache somehow.
    >>
    >> Since we don't use security/privileges on dimensions provided by
    >> mondrian, I can't tell if the logged in user is passed to mondrian.
    >>
    >> I think it would be a good idea to put a how-to on
    >> SimbaO2X/authentication/mondrian somewhere on the wiki.
    >>
    >> Manuel
    >>
    >> On Wed, Apr 20, 2011 at 4:15 PM, Michele Rossi <michele.rossi (AT) gmail (DOT) com>
    >> wrote:[color=darkred]
    >> > hi,
    >> > at the moment DefaultXmlaServlet simply ignores the XMLA SOAP security
    >> > information.
    >> > If there was ever anything like that in the code before it's certainly
    >> > been
    >> > removed now.
    >> > In Excel (with Simba) you can type a username and a password in the
    >> > dialog
    >> > used to create a connection to an xmla server.
    >> > Simba puts those two strings in a SOAP "Security" header that looks like
    >> > my
    >> > example below.
    >> > I already have a working "mod" of DefaultXmlaServlet that I have been
    >> > using
    >> > for a while capable of reading and using that security header.
    >> > Going back to your question about containers: it's certainly possible to
    >> > protect access to "/xmla" using a standard http authentication
    >> > mechanisms
    >> > but Simba doesn't support any of that.
    >> > Also even if Simba supported it the container would certainly not pass
    >> > the
    >> > authentication information to the XMLA servlet.
    >> > And the biggest deal for me is using the credentials provided in Excel
    >> > to
    >> > open an authenticated Olap4j connection.
    >> > I will put together a prototype in the next few days, I think it will be
    >> > easier to discuss this with a piece of code to look at.
    >> > thanks,
    >> > Michele
    >> >
    >> > On 20 April 2011 21:19, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:
    >> >>
    >> >> I'd rather not spend hours researching this. But authentication
    >> >> problems
    >> >> have been solved countless times before in the XMLA server code base.
    >> >> Including authentication from Simba O2X. Can you look over the code and
    >> >> the
    >> >> checkin history and find out how the previous solutions did it.
    >> >>
    >> >> If there is someone on the developers list who has worked on these
    >> >> issues,
    >> >> please speak up now.
    >> >>
    >> >> Julian
    >> >>
    >> >> ________________________________
    >> >> From: Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    >> >> Sent: Wednesday, April 20, 2011 10:52 AM
    >> >> To: <jhyde (AT) pentaho (DOT) com>
    >> >> Cc: Mondrian developer mailinglist
    >> >> Subject: Re: xmla security header processing
    >> >>
    >> >> hi,
    >> >> as far as I know Axis is not a container but a library to create SOAP
    >> >> web
    >> >> services.
    >> >> There is nothing a container can do with that security information as
    >> >> it's
    >> >> not transferred in a standard http way.
    >> >> The username and password that you type in Excel when you create a new
    >> >> SimbaO2x connection are sent to the server in the request header xml
    >> >> element
    >> >> that I copied below.
    >> >> So we either modify the xmla servlet or create an xmla callback with
    >> >> the
    >> >> same features.
    >> >> Do you agree on the general principle that the client (excel)
    >> >> credentials
    >> >> should be used to open the olap4j connection?
    >> >> And that the session id should be used to retrieve existing
    >> >> connections?
    >> >> You certainly can't delegate any of these two features to the
    >> >> container.
    >> >> thanks!
    >> >> Michele
    >> >>
    >> >> Sent from my iPhone
    >> >> On 20 Apr 2011, at 18:19, "Julian Hyde" <jhyde (AT) pentaho (DOT) com> wrote:
    >> >>
    >> >> I'm not an expert on the HTTP/SOAP stuff. But the general goal should
    >> >> be
    >> >> to let the container (e.g. tomcat or apache axis) manage as much of
    >> >> this
    >> >> stuff as possible. Maybe you can see how people have made
    >> >> authentication
    >> >> work elsewhere in the XMLA servlet.
    >> >>
    >> >> Julian
    >> >>
    >> >> ________________________________
    >> >> From: Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    >> >> Sent: Wednesday, April 20, 2011 8:00 AM
    >> >> To: Mondrian developer mailing list
    >> >> Cc: jhyde (AT) pentaho (DOT) com
    >> >> Subject: xmla security header processing
    >> >>
    >> >> Hi,
    >> >> I am writing some code to handle the xmla security header:
    >> >> <Header>
    >> >>

  4. #14
    Michele Rossi Guest

    Default Re: [Mondrian] Re: xmla security header processing

    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  5. #15
    Pappyn Bart Guest

    Default RE: [Mondrian] Problem when compiling mondrian head revision

    Julian,



    Dom4j was in place in the cache, but the log complains that the download
    succeeds, but there is no success status reply, maybe due to our company
    proxy server.



    After deleting dom4j and trying build again, everything works ok.



    Thanks,

    Bart



    From: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org]
    On Behalf Of Julian Hyde
    Sent: dinsdag 3 mei 2011 18:47
    To: 'Mondrian developer mailing list'
    Subject: RE: [Mondrian] Problem when compiling mondrian head revision



    I cleaned dom4j from my ivy cache and built again. It worked for me:



    [ivy:resolve] downloading
    http://repo1.maven.org/maven2/dom4j/...om4j-1.6.1.jar ...
    [ivy:resolve] ........... (306kB)
    [ivy:resolve] .. (0kB)
    [ivy:resolve] [SUCCESSFUL ] dom4j#dom4j;1.6.1!dom4j.jar (3235ms)



    As you can see, dom4j comes from maven.org. I think it's the only
    version of dom4j we've ever used.



    Maybe just a glitch with your network or with maven.org. Check your
    firewall etc., and try again.



    Julian






    ________________________________


    From: mondrian-bounces (AT) pentaho (DOT) org
    [mailto:mondrian-bounces (AT) pentaho (DOT) org] On Behalf Of Pappyn Bart
    Sent: Tuesday, May 03, 2011 6:02 AM
    To: Mondrian developer mailing list
    Subject: [Mondrian] Problem when compiling mondrian head
    revision

    Hi,



    After trying to pull the latest version from perforce (coming
    from the 2.x age), I have the following problems building Mondrian :



    [ivy:resolve] [FAILED ]
    dom4j#dom4j;1.6.1!dom4j.jar(javadoc): The HTTP response code for
    http://repo.pentaho.org/artifactory/.../dom4j-1.6.1.j
    ar did not indicate a success. See log for more detail. (686ms)

    [ivy:resolve] [FAILED ]
    dom4j#dom4j;1.6.1!dom4j.jar(javadoc): The HTTP response code for
    http://repo1.maven.org/maven2/dom4j/....1-javadoc.jar
    did not indicate a success. See log for more detail. (587ms)

    [ivy:resolve] [FAILED ]
    dom4j#dom4j;1.6.1!dom4j.jar(javadoc): The HTTP response code for
    http://repo1.maven.org/maven2/dom4j/....1-javadoc.jar
    did not indicate a success. See log for more detail. (676ms)

    [ivy:resolve] [FAILED ]
    dom4j#dom4j;1.6.1!dom4j.jar(javadoc): (0ms)

    [ivy:resolve] ==== pentaho-rep: tried

    [ivy:resolve]
    http://repo.pentaho.org/artifactory/.../dom4j-1.6.1.j
    ar

    [ivy:resolve] ==== ibiblio: tried

    [ivy:resolve]
    http://repo1.maven.org/maven2/dom4j/....1-javadoc.jar

    [ivy:resolve] ==== public: tried

    [ivy:resolve]
    http://repo1.maven.org/maven2/dom4j/....1-javadoc.jar

    [ivy:resolve]
    ::::::::::::::::::::::::::::::::::::::::::::::

    [ivy:resolve] :: FAILED
    DOWNLOADS ::

    [ivy:resolve] :: ^ see resolution messages
    for details ^ ::

    [ivy:resolve]
    ::::::::::::::::::::::::::::::::::::::::::::::

    [ivy:resolve] ::
    dom4j#dom4j;1.6.1!dom4j.jar(javadoc)

    [ivy:resolve]
    ::::::::::::::::::::::::::::::::::::::::::::::



    All other downloads by ivy are working.



    Any ideas?



    Kind regards,

    Bart


    ______________________________________________________________________
    This email has been scanned by the Email Security System.
    ______________________________________________________________________


    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  6. #16
    Andy Grohe Guest

    Default [Mondrian] xmla security and Mondrian roles

    On a related note, how can you use Mondrian roles when connecting through the xmla servlet?_______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  7. #17
    Julian Hyde Guest

    Default RE: [Mondrian] xmla security and Mondrian roles

    > Andy Grohe wrote:
    >
    > On a related note, how can you use Mondrian roles when
    > connecting through the xmla
    > servlet?


    There should be a document on this. Can anyone point Andy to it?

    Julian

    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  8. #18
    Andy Grohe Guest

    Default Re: [Mondrian] xmla security and Mondrian roles

    the only thing I can find is that it is not possible.
    http://jira.pentaho.com/browse/MONDRIAN-507


    On Wed, May 4, 2011 at 6:26 PM, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:

    >
    > > Andy Grohe wrote:
    > >
    > > On a related note, how can you use Mondrian roles when
    > > connecting through the xmla
    > > servlet?

    >
    > There should be a document on this. Can anyone point Andy to it?
    >
    > Julian
    >
    > _______________________________________________
    > Mondrian mailing list
    > Mondrian (AT) pentaho (DOT) org
    > http://lists.pentaho.org/mailman/listinfo/mondrian
    >


    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  9. #19
    Michele Rossi Guest

    Default Re: [Mondrian] Re: xmla security header processing

    hi Julian and Luc,
    have you had a chance to take a look at the changes that I'd like to submit?

    Is there anything unclear about my code that you would like to discuss?

    If you don't think we should have these things in Mondrian I will try a
    different approach, for example using the "xmla callback" mechanism.
    It's a long shot at this stage though, I am not sure it can work yet.

    thanks,
    Michele

    On 21 April 2011 18:44, Michele Rossi <michele.rossi (AT) gmail (DOT) com> wrote:

    > hi,
    > I've made several changes to DefaultXmlaServlet / XmlaRequest etc making
    > them capable of using the SOAP credentials to create new OLAP connections.
    >
    > I've tested the code with the following configuration: Excel 2007 with
    > SimbaO2X --> A standalone tomcat server running Olap4jXmlaServlet --> olap4j
    > XMLA driver pointing to a standard mondrian installation running FoodMart.
    >
    > You will find a few bits which are to do with the way Excel 2007 and Simba
    > O2X behave.
    > Let me know if you think they are too specific and we don't want to have
    > them in the code.
    >
    >
    >
    > XMLA has a concept of session ID which I leverage to store new
    > OlapConnection objects and retrieve them when new requests arrive with a
    > session ID for which a connection is already available.
    >
    > This might sound unnecessarily complicated but I think it is essential, at
    > least for SimbaO2X.
    > Without this mechanism Simba would trigger the creation of lots of
    > connections and that would be slow and memory expensive.
    >
    > I've further refined this mechanism by creating a session id based on the
    > hashcode of the username and (when I finish it) the IP of the remote client
    > host.
    > This will mean that even fewer unnecessary connections are created and
    > things are a lot faster.
    >
    > My changes are mostly in XmlaHandler and DefaultXmlaServlet.
    > I didn't touch any of the MondrianServer classes.
    > I wanted this mechanism to be applicable to any OLAP4J provider.
    >
    > I am aware that I've made a high number of changes.
    > It wouldn't have been possible to do what I wanted with anything less
    > though.
    > Hope you don't find the changes too hard to review.
    >
    > As with my previous code changes, searching for [MROSSI] should help you
    > find my new code.
    >
    > Many thanks!
    > Michele
    >
    >
    > On 21 April 2011 00:41, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:
    >
    >> Don't change mondrian.server.Repository.getConnection; by that time, the
    >> user should be authenticated and a role should be known.
    >>
    >> Instead, create a method
    >>
    >> void MondrianServer.getConnectionUnauthenticated(
    >> String userName,
    >> String password,
    >> String catalogName,
    >> String schemaName,
    >> Properties properties)
    >>
    >> Note that it is like
    >>
    >> void MondrianServer.getConnection(
    >> String catalogName,
    >> String schemaName,
    >> String roleName,
    >> Properties props);
    >>
    >> except that 'role' is removed and 'userName' and 'password' have been
    >> added. MondrianServer should then authenticate, and call
    >> Repository.getConnection.
    >>
    >> If MondrianServer needs a database of usernames and passwords, and how
    >> they map to roles, please use JAAS for that. I believe it is the standard
    >> for such things.
    >>
    >> Julian
    >>
    >>
    >> ------------------------------
    >> *From:* mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org]
    >> *On Behalf Of *Luc Boudreau
    >> *Sent:* Wednesday, April 20, 2011 2:22 PM
    >>
    >> *To:* Mondrian developer mailing list
    >> *Subject:* Re: [Mondrian] Re: xmla security header processing
    >>
    >>
    >> Michele,
    >>
    >> I understand your requirement. You want to passthrough the credentials
    >> through the servlet down to the OlapConnection. The architecture of the
    >> Mondrian Server was not designed with that in mind, so my concern is that
    >> such a feature is integrated 'the right way'. The proper way to do this
    >> would be to modify the mondrian.server.Repository#getConnection method to
    >> take a user and password as arguments. One downside is that we will depend
    >> on Java Services Discovery to register the olap4j driver with the
    >> DriverManager. One thing I don't like about that approach is the fact that
    >> the server becomes 'aware' of the requests contents. I guess this was
    >> unavoidable as soon as we attempted to factor out the Mondrian Server in
    >> it's own project.
    >>
    >> Write up some code and send it to this list. As you said, better discuss
    >> over code than concepts
    >>
    >> Luc
    >>
    >>
    >>
    >> On Wed, Apr 20, 2011 at 4:15 PM, Michele Rossi <michele.rossi (AT) gmail (DOT) com>wrote:
    >>
    >>> hi,
    >>> at the moment DefaultXmlaServlet simply ignores the XMLA SOAP security
    >>> information.
    >>> If there was ever anything like that in the code before it's certainly
    >>> been removed now.
    >>>
    >>> In Excel (with Simba) you can type a username and a password in the
    >>> dialog used to create a connection to an xmla server.
    >>> Simba puts those two strings in a SOAP "Security" header that looks like
    >>> my example below.
    >>>
    >>> I already have a working "mod" of DefaultXmlaServlet that I have been
    >>> using for a while capable of reading and using that security header.
    >>>
    >>> Going back to your question about containers: it's certainly possible to
    >>> protect access to "/xmla" using a standard http authentication mechanisms
    >>> but Simba doesn't support any of that.
    >>> Also even if Simba supported it the container would certainly not pass
    >>> the authentication information to the XMLA servlet.
    >>>
    >>> And the biggest deal for me is using the credentials provided in Excel to
    >>> open an authenticated Olap4j connection.
    >>>
    >>> I will put together a prototype in the next few days, I think it will be
    >>> easier to discuss this with a piece of code to look at.
    >>>
    >>> thanks,
    >>> Michele
    >>>
    >>>
    >>> On 20 April 2011 21:19, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:
    >>>
    >>>> I'd rather not spend hours researching this. But authentication
    >>>> problems have been solved countless times before in the XMLA server code
    >>>> base. Including authentication from Simba O2X. Can you look over the code
    >>>> and the checkin history and find out how the previous solutions did it.
    >>>>
    >>>> If there is someone on the developers list who has worked on these
    >>>> issues, please speak up now.
    >>>>
    >>>> Julian
    >>>>
    >>>> ------------------------------
    >>>> *From:* Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    >>>> *Sent:* Wednesday, April 20, 2011 10:52 AM
    >>>> *To:* <jhyde (AT) pentaho (DOT) com>
    >>>> *Cc:* Mondrian developer mailinglist
    >>>> *Subject:* Re: xmla security header processing
    >>>>
    >>>> hi,
    >>>> as far as I know Axis is not a container but a library to create SOAP
    >>>> web services.
    >>>>
    >>>> There is nothing a container can do with that security information as
    >>>> it's not transferred in a standard http way.
    >>>>
    >>>> The username and password that you type in Excel when you create a new
    >>>> SimbaO2x connection are sent to the server in the request header xml element
    >>>> that I copied below.
    >>>>
    >>>> So we either modify the xmla servlet or create an xmla callback with the
    >>>> same features.
    >>>>
    >>>> Do you agree on the general principle that the client (excel)
    >>>> credentials should be used to open the olap4j connection?
    >>>>
    >>>> And that the session id should be used to retrieve existing connections?
    >>>> You certainly can't delegate any of these two features to the container.
    >>>>
    >>>> thanks!
    >>>> Michele
    >>>>
    >>>> Sent from my iPhone
    >>>>
    >>>> On 20 Apr 2011, at 18:19, "Julian Hyde" <jhyde (AT) pentaho (DOT) com> wrote:
    >>>>
    >>>> I'm not an expert on the HTTP/SOAP stuff. But the general goal should
    >>>> be to let the container (e.g. tomcat or apache axis) manage as much of this
    >>>> stuff as possible. Maybe you can see how people have made authentication
    >>>> work elsewhere in the XMLA servlet.
    >>>>
    >>>> Julian
    >>>>
    >>>> ------------------------------
    >>>> *From:* Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    >>>> *Sent:* Wednesday, April 20, 2011 8:00 AM
    >>>> *To:* Mondrian developer mailing list
    >>>> *Cc:* <jhyde (AT) pentaho (DOT) com>jhyde (AT) pentaho (DOT) com
    >>>> *Subject:* xmla security header processing
    >>>>
    >>>> Hi,
    >>>>
    >>>> I am writing some code to handle the xmla security header:
    >>>>
    >>>> <Header>
    >>>> <Security xmlns="<http://schemas.xmlsoap.org/ws/2002/04/secext>
    >>>> http://schemas.xmlsoap.org/ws/2002/04/secext">
    >>>> <UsernameToken>
    >>>> <Username>MICHELE</Username>
    >>>> <Password
    >>>> Type="PasswordText">ROSSI</Password>
    >>>> </UsernameToken>
    >>>> </Security>
    >>>> <BeginSession mustUnderstand="1"
    >>>> xmlns="urn:schemas-microsoft-com:xml-analysis" />
    >>>> </Header>
    >>>>
    >>>> Such header is sent out by XMLA clients such as SimbaO2X (Excel plugin).
    >>>> My idea is to pass user credentials down to the connection manager and
    >>>> use them to create new connections.
    >>>>
    >>>> I also think that connections should be associated with sessions.
    >>>> I am thinking of a Map that associates session IDs with OlapConnection
    >>>> objects.
    >>>>
    >>>> I can put all this logic directly in DefaultXmlaServlet or (probably) in
    >>>> a "XmlaRequestCallback" class.
    >>>> Which option do we want to go for?
    >>>>
    >>>> I also have in mind another more specific bit of functionality: hiding
    >>>> username / password in the session ID returned to the xmla client.
    >>>> This can be useful especially in the case of a server going down and
    >>>> forgetting a particular session id.
    >>>> (Your user leaves Excel open for a couple of days and when he tries to
    >>>> use the Pivot again he gets an error if the server has been bounced in the
    >>>> meantime).
    >>>>
    >>>> The other use case could be http load balancers.
    >>>> As Excel does not send any cookies most load balancers would fail to
    >>>> apply the "sticky session" policy and could redirect different xmla requests
    >>>> to different cluster members.
    >>>> Only one of those members would know about the specified session ID (in
    >>>> other words only one of those servers would have an OlapConnection object
    >>>> stored under the given session id) but the others could re-obtain the
    >>>> credentials by de-crypting the session id.
    >>>>
    >>>> I can make the encrypted session ID very secure - even to "clear text"
    >>>> attacks.
    >>>> I will discuss the details only if we think it's a feature worth having.
    >>>>
    >>>> Michele
    >>>>
    >>>>
    >>>>
    >>>
    >>> _______________________________________________
    >>> Mondrian mailing list
    >>> Mondrian (AT) pentaho (DOT) org
    >>> http://lists.pentaho.org/mailman/listinfo/mondrian
    >>>
    >>>

    >>
    >> _______________________________________________
    >> Mondrian mailing list
    >> Mondrian (AT) pentaho (DOT) org
    >> http://lists.pentaho.org/mailman/listinfo/mondrian
    >>
    >>

    >


    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  10. #20
    Luc Boudreau Guest

    Default Re: [Mondrian] Re: xmla security header processing

    Michele,

    Could you provide a patch file rather than a bunch of Java files? Please
    generate those diff files against //open/mondrian (the Mondrian 3.3 branch).

    Thanks!

    Luc

    On Mon, May 9, 2011 at 11:27 AM, Michele Rossi <michele.rossi (AT) gmail (DOT) com>wrote:

    > hi Julian and Luc,
    > have you had a chance to take a look at the changes that I'd like to
    > submit?
    >
    > Is there anything unclear about my code that you would like to discuss?
    >
    > If you don't think we should have these things in Mondrian I will try a
    > different approach, for example using the "xmla callback" mechanism.
    > It's a long shot at this stage though, I am not sure it can work yet.
    >
    > thanks,
    > Michele
    >
    >
    > On 21 April 2011 18:44, Michele Rossi <michele.rossi (AT) gmail (DOT) com> wrote:
    >
    >> hi,
    >> I've made several changes to DefaultXmlaServlet / XmlaRequest etc making
    >> them capable of using the SOAP credentials to create new OLAP connections.
    >>
    >> I've tested the code with the following configuration: Excel 2007 with
    >> SimbaO2X --> A standalone tomcat server running Olap4jXmlaServlet --> olap4j
    >> XMLA driver pointing to a standard mondrian installation running FoodMart.
    >>
    >> You will find a few bits which are to do with the way Excel 2007 and Simba
    >> O2X behave.
    >> Let me know if you think they are too specific and we don't want to have
    >> them in the code.
    >>
    >>
    >>
    >> XMLA has a concept of session ID which I leverage to store new
    >> OlapConnection objects and retrieve them when new requests arrive with a
    >> session ID for which a connection is already available.
    >>
    >> This might sound unnecessarily complicated but I think it is essential, at
    >> least for SimbaO2X.
    >> Without this mechanism Simba would trigger the creation of lots of
    >> connections and that would be slow and memory expensive.
    >>
    >> I've further refined this mechanism by creating a session id based on the
    >> hashcode of the username and (when I finish it) the IP of the remote client
    >> host.
    >> This will mean that even fewer unnecessary connections are created and
    >> things are a lot faster.
    >>
    >> My changes are mostly in XmlaHandler and DefaultXmlaServlet.
    >> I didn't touch any of the MondrianServer classes.
    >> I wanted this mechanism to be applicable to any OLAP4J provider.
    >>
    >> I am aware that I've made a high number of changes.
    >> It wouldn't have been possible to do what I wanted with anything less
    >> though.
    >> Hope you don't find the changes too hard to review.
    >>
    >> As with my previous code changes, searching for [MROSSI] should help you
    >> find my new code.
    >>
    >> Many thanks!
    >> Michele
    >>
    >>
    >> On 21 April 2011 00:41, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:
    >>
    >>> Don't change mondrian.server.Repository.getConnection; by that time,
    >>> the user should be authenticated and a role should be known.
    >>>
    >>> Instead, create a method
    >>>
    >>> void MondrianServer.getConnectionUnauthenticated(
    >>> String userName,
    >>> String password,
    >>> String catalogName,
    >>> String schemaName,
    >>> Properties properties)
    >>>
    >>> Note that it is like
    >>>
    >>> void MondrianServer.getConnection(
    >>> String catalogName,
    >>> String schemaName,
    >>> String roleName,
    >>> Properties props);
    >>>
    >>> except that 'role' is removed and 'userName' and 'password' have been
    >>> added. MondrianServer should then authenticate, and call
    >>> Repository.getConnection.
    >>>
    >>> If MondrianServer needs a database of usernames and passwords, and how
    >>> they map to roles, please use JAAS for that. I believe it is the standard
    >>> for such things.
    >>>
    >>> Julian
    >>>
    >>>
    >>> ------------------------------
    >>> *From:* mondrian-bounces (AT) pentaho (DOT) org [mailto:
    >>> mondrian-bounces (AT) pentaho (DOT) org] *On Behalf Of *Luc Boudreau
    >>> *Sent:* Wednesday, April 20, 2011 2:22 PM
    >>>
    >>> *To:* Mondrian developer mailing list
    >>> *Subject:* Re: [Mondrian] Re: xmla security header processing
    >>>
    >>>
    >>> Michele,
    >>>
    >>> I understand your requirement. You want to passthrough the credentials
    >>> through the servlet down to the OlapConnection. The architecture of the
    >>> Mondrian Server was not designed with that in mind, so my concern is that
    >>> such a feature is integrated 'the right way'. The proper way to do this
    >>> would be to modify the mondrian.server.Repository#getConnection method to
    >>> take a user and password as arguments. One downside is that we will depend
    >>> on Java Services Discovery to register the olap4j driver with the
    >>> DriverManager. One thing I don't like about that approach is the fact that
    >>> the server becomes 'aware' of the requests contents. I guess this was
    >>> unavoidable as soon as we attempted to factor out the Mondrian Server in
    >>> it's own project.
    >>>
    >>> Write up some code and send it to this list. As you said, better discuss
    >>> over code than concepts
    >>>
    >>> Luc
    >>>
    >>>
    >>>
    >>> On Wed, Apr 20, 2011 at 4:15 PM, Michele Rossi <michele.rossi (AT) gmail (DOT) com>wrote:
    >>>
    >>>> hi,
    >>>> at the moment DefaultXmlaServlet simply ignores the XMLA SOAP security
    >>>> information.
    >>>> If there was ever anything like that in the code before it's certainly
    >>>> been removed now.
    >>>>
    >>>> In Excel (with Simba) you can type a username and a password in the
    >>>> dialog used to create a connection to an xmla server.
    >>>> Simba puts those two strings in a SOAP "Security" header that looks like
    >>>> my example below.
    >>>>
    >>>> I already have a working "mod" of DefaultXmlaServlet that I have been
    >>>> using for a while capable of reading and using that security header.
    >>>>
    >>>> Going back to your question about containers: it's certainly possible to
    >>>> protect access to "/xmla" using a standard http authentication mechanisms
    >>>> but Simba doesn't support any of that.
    >>>> Also even if Simba supported it the container would certainly not pass
    >>>> the authentication information to the XMLA servlet.
    >>>>
    >>>> And the biggest deal for me is using the credentials provided in Excel
    >>>> to open an authenticated Olap4j connection.
    >>>>
    >>>> I will put together a prototype in the next few days, I think it will be
    >>>> easier to discuss this with a piece of code to look at.
    >>>>
    >>>> thanks,
    >>>> Michele
    >>>>
    >>>>
    >>>> On 20 April 2011 21:19, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:
    >>>>
    >>>>> I'd rather not spend hours researching this. But authentication
    >>>>> problems have been solved countless times before in the XMLA server code
    >>>>> base. Including authentication from Simba O2X. Can you look over the code
    >>>>> and the checkin history and find out how the previous solutions did it.
    >>>>>
    >>>>> If there is someone on the developers list who has worked on these
    >>>>> issues, please speak up now.
    >>>>>
    >>>>> Julian
    >>>>>
    >>>>> ------------------------------
    >>>>> *From:* Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    >>>>> *Sent:* Wednesday, April 20, 2011 10:52 AM
    >>>>> *To:* <jhyde (AT) pentaho (DOT) com>
    >>>>> *Cc:* Mondrian developer mailinglist
    >>>>> *Subject:* Re: xmla security header processing
    >>>>>
    >>>>> hi,
    >>>>> as far as I know Axis is not a container but a library to create SOAP
    >>>>> web services.
    >>>>>
    >>>>> There is nothing a container can do with that security information as
    >>>>> it's not transferred in a standard http way.
    >>>>>
    >>>>> The username and password that you type in Excel when you create a new
    >>>>> SimbaO2x connection are sent to the server in the request header xml element
    >>>>> that I copied below.
    >>>>>
    >>>>> So we either modify the xmla servlet or create an xmla callback with
    >>>>> the same features.
    >>>>>
    >>>>> Do you agree on the general principle that the client (excel)
    >>>>> credentials should be used to open the olap4j connection?
    >>>>>
    >>>>> And that the session id should be used to retrieve existing
    >>>>> connections?
    >>>>> You certainly can't delegate any of these two features to the
    >>>>> container.
    >>>>>
    >>>>> thanks!
    >>>>> Michele
    >>>>>
    >>>>> Sent from my iPhone
    >>>>>
    >>>>> On 20 Apr 2011, at 18:19, "Julian Hyde" <jhyde (AT) pentaho (DOT) com> wrote:
    >>>>>
    >>>>> I'm not an expert on the HTTP/SOAP stuff. But the general goal
    >>>>> should be to let the container (e.g. tomcat or apache axis) manage as much
    >>>>> of this stuff as possible. Maybe you can see how people have made
    >>>>> authentication work elsewhere in the XMLA servlet.
    >>>>>
    >>>>> Julian
    >>>>>
    >>>>> ------------------------------
    >>>>> *From:* Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    >>>>> *Sent:* Wednesday, April 20, 2011 8:00 AM
    >>>>> *To:* Mondrian developer mailing list
    >>>>> *Cc:* <jhyde (AT) pentaho (DOT) com>jhyde (AT) pentaho (DOT) com
    >>>>> *Subject:* xmla security header processing
    >>>>>
    >>>>> Hi,
    >>>>>
    >>>>> I am writing some code to handle the xmla security header:
    >>>>>
    >>>>> <Header>
    >>>>> <Security xmlns="<http://schemas.xmlsoap.org/ws/2002/04/secext>
    >>>>> http://schemas.xmlsoap.org/ws/2002/04/secext">
    >>>>> <UsernameToken>
    >>>>> <Username>MICHELE</Username>
    >>>>> <Password
    >>>>> Type="PasswordText">ROSSI</Password>
    >>>>> </UsernameToken>
    >>>>> </Security>
    >>>>> <BeginSession mustUnderstand="1"
    >>>>> xmlns="urn:schemas-microsoft-com:xml-analysis" />
    >>>>> </Header>
    >>>>>
    >>>>> Such header is sent out by XMLA clients such as SimbaO2X (Excel
    >>>>> plugin).
    >>>>> My idea is to pass user credentials down to the connection manager and
    >>>>> use them to create new connections.
    >>>>>
    >>>>> I also think that connections should be associated with sessions.
    >>>>> I am thinking of a Map that associates session IDs with OlapConnection
    >>>>> objects.
    >>>>>
    >>>>> I can put all this logic directly in DefaultXmlaServlet or (probably)
    >>>>> in a "XmlaRequestCallback" class.
    >>>>> Which option do we want to go for?
    >>>>>
    >>>>> I also have in mind another more specific bit of functionality: hiding
    >>>>> username / password in the session ID returned to the xmla client.
    >>>>> This can be useful especially in the case of a server going down and
    >>>>> forgetting a particular session id.
    >>>>> (Your user leaves Excel open for a couple of days and when he tries to
    >>>>> use the Pivot again he gets an error if the server has been bounced in the
    >>>>> meantime).
    >>>>>
    >>>>> The other use case could be http load balancers.
    >>>>> As Excel does not send any cookies most load balancers would fail to
    >>>>> apply the "sticky session" policy and could redirect different xmla requests
    >>>>> to different cluster members.
    >>>>> Only one of those members would know about the specified session ID (in
    >>>>> other words only one of those servers would have an OlapConnection object
    >>>>> stored under the given session id) but the others could re-obtain the
    >>>>> credentials by de-crypting the session id.
    >>>>>
    >>>>> I can make the encrypted session ID very secure - even to "clear text"
    >>>>> attacks.
    >>>>> I will discuss the details only if we think it's a feature worth
    >>>>> having.
    >>>>>
    >>>>> Michele
    >>>>>
    >>>>>
    >>>>>
    >>>>
    >>>> _______________________________________________
    >>>> Mondrian mailing list
    >>>> Mondrian (AT) pentaho (DOT) org
    >>>> http://lists.pentaho.org/mailman/listinfo/mondrian
    >>>>
    >>>>
    >>>
    >>> _______________________________________________
    >>> Mondrian mailing list
    >>> Mondrian (AT) pentaho (DOT) org
    >>> http://lists.pentaho.org/mailman/listinfo/mondrian
    >>>
    >>>

    >>

    >
    > _______________________________________________
    > Mondrian mailing list
    > Mondrian (AT) pentaho (DOT) org
    > http://lists.pentaho.org/mailman/listinfo/mondrian
    >
    >


    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Privacy Policy | Legal Notices | Safe Harbor Privacy Policy

Copyright © 2005 - 2019 Hitachi Vantara Corporation. All Rights Reserved.