Hitachi Vantara Pentaho Community Forums
Results 1 to 34 of 34

Thread: [Mondrian] xmla security header processing

  1. #1
    Michele Rossi Guest

    Default [Mondrian] 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">
    <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

  2. #2
    Julian Hyde Guest

    Default [Mondrian] RE: xmla security header processing

    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>
    <Security
    xmlns="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

  3. #3
    Michele Rossi Guest

    Default [Mondrian] 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>
    > <Security xmlns="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

  4. #4
    Julian Hyde Guest

    Default [Mondrian] RE: xmla security header processing

    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: <mailto: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

  5. #5
    Michele Rossi Guest

    Default [Mondrian] Re: xmla security header processing

    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

  6. #6
    Luc Boudreau Guest

    Default 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

  7. #7
    Julian Hyde Guest

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

    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: <mailto: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

  8. #8
    Michele Rossi Guest

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

    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

  9. #9
    Manuel Darveau Guest

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

    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=blue]
    > 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:[color=green]
    >>
    >> 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>
    >>

  10. #10
    Michele Rossi Guest

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

    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:

    > 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:
    > > 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>
    > >> <Security
    > >> xmlns="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

  11. #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

  12. #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

  13. #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>
    >> >>

  14. #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

  15. #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

  16. #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

  17. #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

  18. #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

  19. #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

  20. #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

  21. #21
    Julian Hyde Guest

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

    Sorry, I missed this. I got your email of April 21st, and will review in the
    next couple of days.

    Julian


    _____

    From: Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    Sent: Monday, May 09, 2011 8:27 AM
    To: jhyde (AT) pentaho (DOT) com; Mondrian developer mailing list; Luc Boudreau
    Subject: 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: <mailto: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

  22. #22
    Michele Rossi Guest

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

    Hi Luc,
    I am currently unable to generate patch files with perforce and I am not
    sure why.

    I found the following link on the subject
    http://www.perforce.com/perforce/r10...ics/patch.html

    <http://www.perforce.com/perforce/r10.1/manuals/p4eclipse/topics/patch.html>but
    such menu item does not exist in my p4 windows client (v 2009.1/212209) nor
    it does in my eclipse p4 plugin.

    I have to leave for the day now but I will try to find a way to generate
    patch files tomorrow.

    thanks,
    Michele


    On 9 May 2011 17:30, Luc Boudreau <lucboudreau (AT) gmail (DOT) com> wrote:

    > 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
    >
    >


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

  23. #23
    Luc Boudreau Guest

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

    If you are using Eclipse, does the Perforce plugin add the "Create patch..."
    option in the "Team" contextual menu? If so, then you could use this.



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

    > Hi Luc,
    > I am currently unable to generate patch files with perforce and I am not
    > sure why.
    >
    > I found the following link on the subject
    > http://www.perforce.com/perforce/r10...ics/patch.html
    >
    >
    > <http://www.perforce.com/perforce/r10.1/manuals/p4eclipse/topics/patch.html>but
    > such menu item does not exist in my p4 windows client (v 2009.1/212209) nor
    > it does in my eclipse p4 plugin.
    >
    > I have to leave for the day now but I will try to find a way to generate
    > patch files tomorrow.
    >
    > thanks,
    > Michele
    >
    >
    > On 9 May 2011 17:30, Luc Boudreau <lucboudreau (AT) gmail (DOT) com> wrote:
    >
    >> 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
    >>
    >>

    >
    > _______________________________________________
    > 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

  24. #24
    Julian Hyde Guest

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

    'p4 diff -du' should be good enough.


    _____

    From: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org] On
    Behalf Of Luc Boudreau
    Sent: Monday, May 09, 2011 9:01 AM
    To: Mondrian developer mailing list
    Cc: Luc Boudreau
    Subject: Re: [Mondrian] Re: xmla security header processing



    If you are using Eclipse, does the Perforce plugin add the "Create patch..."
    option in the "Team" contextual menu? If so, then you could use this.




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


    Hi Luc,
    I am currently unable to generate patch files with perforce and I am not
    sure why.

    I found the following link on the subject
    http://www.perforce.com/perforce/r10...ics/patch.html


    <http://www.perforce.com/perforce/r10.1/manuals/p4eclipse/topics/patch.html>
    but such menu item does not exist in my p4 windows client (v 2009.1/212209)
    nor it does in my eclipse p4 plugin.

    I have to leave for the day now but I will try to find a way to generate
    patch files tomorrow.

    thanks,
    Michele


    On 9 May 2011 17:30, Luc Boudreau <lucboudreau (AT) gmail (DOT) com> wrote:


    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: <mailto: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





    _______________________________________________
    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

  25. #25
    Michele Rossi Guest

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

    hi,
    I managed to create a patch file with all my changes using the command
    below.
    I've updated my perforce client to the latest version but there is still no
    trace of anything to do with creating patches in the context menus.

    thanks,
    Michele

    On 9 May 2011 20:30, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:

    > 'p4 diff -du' should be good enough.
    >
    > ------------------------------
    > *From:* mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org]
    > *On Behalf Of *Luc Boudreau
    > *Sent:* Monday, May 09, 2011 9:01 AM
    >
    > *To:* Mondrian developer mailing list
    > *Cc:* Luc Boudreau
    >
    > *Subject:* Re: [Mondrian] Re: xmla security header processing
    >
    >
    > If you are using Eclipse, does the Perforce plugin add the "Create
    > patch..." option in the "Team" contextual menu? If so, then you could use
    > this.
    >
    >
    >
    > On Mon, May 9, 2011 at 11:58 AM, Michele Rossi <michele.rossi (AT) gmail (DOT) com>wrote:
    >
    >> Hi Luc,
    >> I am currently unable to generate patch files with perforce and I am not
    >> sure why.
    >>
    >> I found the following link on the subject
    >> http://www.perforce.com/perforce/r10...ics/patch.html
    >>
    >> <http://www.perforce.com/perforce/r10.1/manuals/p4eclipse/topics/patch.html>but
    >> such menu item does not exist in my p4 windows client (v 2009.1/212209) nor
    >> it does in my eclipse p4 plugin.
    >>
    >> I have to leave for the day now but I will try to find a way to generate
    >> patch files tomorrow.
    >>
    >> thanks,
    >> Michele
    >>
    >>
    >> On 9 May 2011 17:30, Luc Boudreau <lucboudreau (AT) gmail (DOT) com> wrote:
    >>
    >>> 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
    >>>
    >>>

    >>
    >> _______________________________________________
    >> 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

  26. #26
    Luc Boudreau Guest

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

    Michele,

    Your patch only modifies code that is not part of Olap4j nor Mondrian. Was
    this a mistake?

    Luc


    On Tue, May 10, 2011 at 3:41 AM, Michele Rossi <michele.rossi (AT) gmail (DOT) com>wrote:

    > hi,
    > I managed to create a patch file with all my changes using the command
    > below.
    > I've updated my perforce client to the latest version but there is still no
    > trace of anything to do with creating patches in the context menus.
    >
    > thanks,
    > Michele
    >
    >
    > On 9 May 2011 20:30, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:
    >
    >> 'p4 diff -du' should be good enough.
    >>
    >> ------------------------------
    >> *From:* mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org]
    >> *On Behalf Of *Luc Boudreau
    >> *Sent:* Monday, May 09, 2011 9:01 AM
    >>
    >> *To:* Mondrian developer mailing list
    >> *Cc:* Luc Boudreau
    >>
    >> *Subject:* Re: [Mondrian] Re: xmla security header processing
    >>
    >>
    >> If you are using Eclipse, does the Perforce plugin add the "Create
    >> patch..." option in the "Team" contextual menu? If so, then you could use
    >> this.
    >>
    >>
    >>
    >> On Mon, May 9, 2011 at 11:58 AM, Michele Rossi <michele.rossi (AT) gmail (DOT) com>wrote:
    >>
    >>> Hi Luc,
    >>> I am currently unable to generate patch files with perforce and I am not
    >>> sure why.
    >>>
    >>> I found the following link on the subject
    >>>
    >>> http://www.perforce.com/perforce/r10...ics/patch.html
    >>>
    >>> <http://www.perforce.com/perforce/r10.1/manuals/p4eclipse/topics/patch.html>but
    >>> such menu item does not exist in my p4 windows client (v 2009.1/212209) nor
    >>> it does in my eclipse p4 plugin.
    >>>
    >>> I have to leave for the day now but I will try to find a way to generate
    >>> patch files tomorrow.
    >>>
    >>> thanks,
    >>> Michele
    >>>
    >>>
    >>> On 9 May 2011 17:30, Luc Boudreau <lucboudreau (AT) gmail (DOT) com> wrote:
    >>>
    >>>> 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
    >>>>
    >>>>
    >>>
    >>> _______________________________________________
    >>> 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

  27. #27
    Michele Rossi Guest

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

    hi,
    definitely a mistake, I'm obviously useless with patch files!
    I will try again tomorrow, sorry about it!
    Michele

    Sent from my iPhone

    On 11 May 2011, at 20:41, Luc Boudreau <lucboudreau (AT) gmail (DOT) com> wrote:

    > Michele,
    >
    > Your patch only modifies code that is not part of Olap4j nor Mondrian. Was this a mistake?
    >
    > Luc
    >
    >
    > On Tue, May 10, 2011 at 3:41 AM, Michele Rossi <michele.rossi (AT) gmail (DOT) com> wrote:
    > hi,
    > I managed to create a patch file with all my changes using the command below.
    > I've updated my perforce client to the latest version but there is still no trace of anything to do with creating patches in the context menus.
    >
    > thanks,
    > Michele
    >
    >
    > On 9 May 2011 20:30, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:
    > 'p4 diff -du' should be good enough.
    >
    > From: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org] On Behalf Of Luc Boudreau
    > Sent: Monday, May 09, 2011 9:01 AM
    >
    > To: Mondrian developer mailing list
    > Cc: Luc Boudreau
    >
    > Subject: Re: [Mondrian] Re: xmla security header processing
    >
    >
    > If you are using Eclipse, does the Perforce plugin add the "Create patch...." option in the "Team" contextual menu? If so, then you could use this.
    >
    >
    >
    > On Mon, May 9, 2011 at 11:58 AM, Michele Rossi <michele.rossi (AT) gmail (DOT) com> wrote:
    > Hi Luc,
    > I am currently unable to generate patch files with perforce and I am not sure why.
    >
    > I found the following link on the subject
    > http://www.perforce.com/perforce/r10...ics/patch.html
    >
    > but such menu item does not exist in my p4 windows client (v 2009.1/212209) nor it does in my eclipse p4 plugin.
    >
    > I have to leave for the day now but I will try to find a way to generate patch files tomorrow.
    >
    > thanks,
    > Michele
    >
    >
    > On 9 May 2011 17:30, Luc Boudreau <lucboudreau (AT) gmail (DOT) com> wrote:
    > 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
    >> 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">
    >> <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
    >
    >
    >
    > _______________________________________________
    > 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


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

  28. #28
    Michele Rossi Guest

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

    hi,
    did you have a chance to look at my xmla changes?

    The general ideas behind them are simple:

    1. Pass the credentials provided in Excel down to the method that creates an
    OlapConnection.
    2. Leverage the concept of Session ID (already present in XMLA) to store and
    retrieve the right authenticated connection for subsequent requests.

    What's currently missing is a connection clean up mechanism.
    I didn't want to invest time on it before my other changes were accepted.

    thanks,
    Michele


    On 9 May 2011 16:37, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:

    > Sorry, I missed this. I got your email of April 21st, and will review in
    > the next couple of days.
    >
    > Julian
    >
    > ------------------------------
    > *From:* Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    > *Sent:* Monday, May 09, 2011 8:27 AM
    > *To:* jhyde (AT) pentaho (DOT) com; Mondrian developer mailing list; Luc Boudreau
    >
    > *Subject:* 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

  29. #29
    Luc Boudreau Guest

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

    Michele,

    The last patch you sent didn't have any code changes related to Mondrian nor
    olap4j. You said you would submit a new patch. Maybe it didn't make it
    through, but still, I didn't get it.

    Luc


    On Wed, May 18, 2011 at 11:35 AM, Michele Rossi <michele.rossi (AT) gmail (DOT) com>wrote:

    > hi,
    > did you have a chance to look at my xmla changes?
    >
    > The general ideas behind them are simple:
    >
    > 1. Pass the credentials provided in Excel down to the method that creates
    > an OlapConnection.
    > 2. Leverage the concept of Session ID (already present in XMLA) to store
    > and retrieve the right authenticated connection for subsequent requests.
    >
    > What's currently missing is a connection clean up mechanism.
    > I didn't want to invest time on it before my other changes were accepted.
    >
    > thanks,
    > Michele
    >
    >
    > On 9 May 2011 16:37, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:
    >
    >> Sorry, I missed this. I got your email of April 21st, and will review in
    >> the next couple of days.
    >>
    >> Julian
    >>
    >> ------------------------------
    >> *From:* Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    >> *Sent:* Monday, May 09, 2011 8:27 AM
    >> *To:* jhyde (AT) pentaho (DOT) com; Mondrian developer mailing list; Luc Boudreau
    >>
    >> *Subject:* 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
    >
    >


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

  30. #30
    Michele Rossi Guest

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

    hi,
    apologies for that - I assumed that Julian was looking at my changes using
    the java files I sent.

    So I finally managed to make the patch file - hopefully with the shape that
    you expect.

    It might be possible to implement some of my changes as Xmla Callback
    handlers - it's something I can explore.

    thanks,
    Michele


    On 18 May 2011 16:47, Luc Boudreau <lucboudreau (AT) gmail (DOT) com> wrote:

    > Michele,
    >
    > The last patch you sent didn't have any code changes related to Mondrian
    > nor olap4j. You said you would submit a new patch. Maybe it didn't make it
    > through, but still, I didn't get it.
    >
    > Luc
    >
    >
    >
    > On Wed, May 18, 2011 at 11:35 AM, Michele Rossi <michele.rossi (AT) gmail (DOT) com>wrote:
    >
    >> hi,
    >> did you have a chance to look at my xmla changes?
    >>
    >> The general ideas behind them are simple:
    >>
    >> 1. Pass the credentials provided in Excel down to the method that creates
    >> an OlapConnection.
    >> 2. Leverage the concept of Session ID (already present in XMLA) to store
    >> and retrieve the right authenticated connection for subsequent requests.
    >>
    >> What's currently missing is a connection clean up mechanism.
    >> I didn't want to invest time on it before my other changes were accepted.
    >>
    >> thanks,
    >> Michele
    >>
    >>
    >> On 9 May 2011 16:37, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:
    >>
    >>> Sorry, I missed this. I got your email of April 21st, and will review
    >>> in the next couple of days.
    >>>
    >>> Julian
    >>>
    >>> ------------------------------
    >>> *From:* Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    >>> *Sent:* Monday, May 09, 2011 8:27 AM
    >>> *To:* jhyde (AT) pentaho (DOT) com; Mondrian developer mailing list; Luc Boudreau
    >>>
    >>> *Subject:* 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
    >>
    >>

    >
    > _______________________________________________
    > 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

  31. #31
    Michele Rossi Guest

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

    hi,
    I've just identified an issue in the code I've sent - in Rowset.java the
    OlapConnection are closed after use: that doesn't work well with the idea of
    caching the connection (storing it under the XMLA session id).
    I think we should have a clean up thread that closes connections after a
    period of inactivity.
    What do you think?
    thanks,
    Michele

    public final void populate(
    XmlaResponse response,
    OlapConnection connection,
    List<Row> rows)
    throws XmlaException
    {
    boolean ourConnection = false;
    try {
    if (needConnection() && connection == null) {
    connection = handler.getConnection(request);
    ourConnection = true;
    }
    populateImpl(response, connection, rows);
    } catch (SQLException e) {
    // TODO:
    e.printStackTrace();
    } finally {
    if (connection != null && ourConnection) {
    try {
    connection.close();
    } catch (SQLException e) {
    // ignore
    }
    }
    }
    }



    On 18 May 2011 17:50, Michele Rossi <michele.rossi (AT) gmail (DOT) com> wrote:

    > hi,
    > apologies for that - I assumed that Julian was looking at my changes using
    > the java files I sent.
    >
    > So I finally managed to make the patch file - hopefully with the shape that
    > you expect.
    >
    > It might be possible to implement some of my changes as Xmla Callback
    > handlers - it's something I can explore.
    >
    > thanks,
    > Michele
    >
    >
    > On 18 May 2011 16:47, Luc Boudreau <lucboudreau (AT) gmail (DOT) com> wrote:
    >
    >> Michele,
    >>
    >> The last patch you sent didn't have any code changes related to Mondrian
    >> nor olap4j. You said you would submit a new patch. Maybe it didn't make it
    >> through, but still, I didn't get it.
    >>
    >> Luc
    >>
    >>
    >>
    >> On Wed, May 18, 2011 at 11:35 AM, Michele Rossi <michele.rossi (AT) gmail (DOT) com>wrote:
    >>
    >>> hi,
    >>> did you have a chance to look at my xmla changes?
    >>>
    >>> The general ideas behind them are simple:
    >>>
    >>> 1. Pass the credentials provided in Excel down to the method that creates
    >>> an OlapConnection.
    >>> 2. Leverage the concept of Session ID (already present in XMLA) to store
    >>> and retrieve the right authenticated connection for subsequent requests.
    >>>
    >>> What's currently missing is a connection clean up mechanism.
    >>> I didn't want to invest time on it before my other changes were accepted.
    >>>
    >>> thanks,
    >>> Michele
    >>>
    >>>
    >>> On 9 May 2011 16:37, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:
    >>>
    >>>> Sorry, I missed this. I got your email of April 21st, and will review
    >>>> in the next couple of days.
    >>>>
    >>>> Julian
    >>>>
    >>>> ------------------------------
    >>>> *From:* Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    >>>> *Sent:* Monday, May 09, 2011 8:27 AM
    >>>> *To:* jhyde (AT) pentaho (DOT) com; Mondrian developer mailing list; Luc Boudreau
    >>>>
    >>>> *Subject:* 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
    >>>
    >>>

    >>
    >> _______________________________________________
    >> 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

  32. #32
    Julian Hyde Guest

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

    Michele,

    As promised, I've reviewed your changes.

    All in all, the change looks useful. I can see that we need to introduce the
    notion of 'sessions' due to the way Simba O2X sends its requests. But I am
    concerned at how many places username & password are now present in the API,
    and the result is so confusing it's difficult to say that there are not
    security holes.

    If you can address my concerns, I will commit your changes. I've changed
    quite a lot of the code; see the patch attached. Can you use that patch as
    starting point when fixing the issues I raise below. And when you have made
    changes, please generate a similar patch using 'p4 diff -du' from the
    command line.

    Detailed comments...

    0. Would it be simpler if the servlet looked for the <Security> tag and
    session information and copied these into the HTTP headers? Then we could
    use HTTP athentication and session lifecycle management. Just an idea.

    1. MondrianServerImpl.getConnection is not used. Removed it.

    2. It is a bad idea to pool connections. If you want to pool connections,
    use a connection pool. It is an even worse idea to pool connections based on
    session ID -- that implies that you are trying to make sessions stateful,
    and it is much better if the XMLA servlet is stateless.

    So, I removed ConnectionHolder and the "connections" member.

    I see why we need to save username & password so that they can be retrieved
    by subsequent requests in the same session. But your implementation never
    removed entries from that table. I added code to remove the entry when we
    see an 'end of session'. It would be nice if we could hook into HTTP session
    management (see #0 above).

    3. In removing the "connections" member, I may have broken the mechanism by
    which subsequent requests in the same XMLA session inherit the same
    password. (Difficult to tell without unit tests.) If so, I apologize.

    But it is not obvious how session context is conveyed along with the
    XmlaRequest. Would it make sense to replace 'String
    XmlaRequest.getSessionId()' (and getUsername() and getPassword()) with a
    'SessionInfo XmlaRequest.getSessionInfo()' method that contains all session
    context?

    4. Please convince me that you are not opening up a security hole, as
    follows. The context contains a role name. It also may contain username and
    password, if the client happens to be using basic authentication. Suppose
    that a malicious client specified a valid username and password in its HTTP
    headers, but also specified a role that had greater privileges than the
    username and password allowed. Would that client be able to gain greater
    privileges than it deserved?

    It needs to be clear and foolproof in the code whether the client is
    trusted. If trusted, it can adopt whichever role it choses. If not, it must
    take the role assigned by olap4j after authentication.

    5. What does your comment "we'd need to inject the HttpServletRequest into
    this method" mean?

    6. There is a magic id for un-authenticated session. Is this a security
    hole?

    7. Would it make sense for the servlet to refuse basic authentication
    requests if they were not over HTTPS? (And not just the first request, which
    carries username/password. Subsequent requests carry an authenticated
    session ID, so they must be protected also.)

    8. I fixed XmlaBasicTest. Maybe other tests are broken also. Can you please
    ensure that the tests run clean before you re-submit.

    9. Add unit test for basic authentication. (It's hard for me to review this
    code if it is not used in the test suite.)

    10. Is the security model assuming that session ids are hard to guess?

    Julian

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

  33. #33
    Michele Rossi Guest

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

    hi Julian,
    I've replied to some of your questions inline.

    thanks,
    Michele

    On 25 May 2011 00:43, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:

    > Michele,
    >
    > As promised, I've reviewed your changes.
    >
    > All in all, the change looks useful. I can see that we need to introduce
    > the notion of 'sessions' due to the way Simba O2X sends its requests. But I
    > am concerned at how many places username & password are now present in the
    > API, and the result is so confusing it's difficult to say that there are not
    > security holes.
    >
    > If you can address my concerns, I will commit your changes. I've changed
    > quite a lot of the code; see the patch attached. Can you use that patch as
    > starting point when fixing the issues I raise below. And when you have made
    > changes, please generate a similar patch using 'p4 diff -du' from the
    > command line.
    >
    > Detailed comments...
    >
    > 0. Would it be simpler if the servlet looked for the <Security> tag and
    > session information and copied these into the HTTP headers? Then we could
    > use HTTP athentication and session lifecycle management. Just an idea.
    >


    My main problem is to create an authenticated OlapConnection.
    Hence I need the credentials to be processed in the code that creates the
    connection and not by the container.


    >
    > 1. MondrianServerImpl.getConnection is not used. Removed it.
    >
    > 2. It is a bad idea to pool connections. If you want to pool connections,
    > use a connection pool. It is an even worse idea to pool connections based on
    > session ID -- that implies that you are trying to make sessions stateful,
    > and it is much better if the XMLA servlet is stateless.
    >
    > So, I removed ConnectionHolder and the "connections" member.
    >


    The problem is that Simba will create something like 15 connections before
    you can even start configuring a Pivot in Excel.

    In general I believe that creating a new connection for each request is an
    anti-pattern as it leads to a substantial waste of resources.

    In my case in particular this approach wouldn't work at all as I cache the
    metadata objects at the connection level.
    So before displaying a Pivot in Excel I'd have to populate the whole
    metadata cache N times, once for each connection I create.

    Connection pooling is the technique normally used by more traditional web
    apps that require access to a database for this problem and it can be
    implemented either at the application level (e.g. commons-dbcp) and or at
    the container level (tomcat can handle pool of connections to databases) .

    I am aware that my implementation didn't clean up un-used connections.
    I didn't want to submit too much code at once and risk wasting time if you
    didn't like all the rest of the work.


    >
    > I see why we need to save username & password so that they can be retrieved
    > by subsequent requests in the same session. But your implementation never
    > removed entries from that table. I added code to remove the entry when we
    > see an 'end of session'. It would be nice if we could hook into HTTP session
    > management (see #0 above).
    >


    We can definitely save the credentials in the Http Session. The new version
    of Simba supports Cookies too which means that this approach could work.
    I will start thinking about this approach.


    >
    > 3. In removing the "connections" member, I may have broken the mechanism by
    > which subsequent requests in the same XMLA session inherit the same
    > password. (Difficult to tell without unit tests.) If so, I apologize.
    >
    > But it is not obvious how session context is conveyed along with the
    > XmlaRequest. Would it make sense to replace 'String
    > XmlaRequest.getSessionId()' (and getUsername() and getPassword()) with a
    > 'SessionInfo XmlaRequest.getSessionInfo()' method that contains all session
    > context?
    >


    Yes definitely - although the end result is very similar this approach is
    probably more flexible.


    >
    > 4. Please convince me that you are not opening up a security hole, as
    > follows. The context contains a role name. It also may contain username and
    > password, if the client happens to be using basic authentication. Suppose
    > that a malicious client specified a valid username and password in its HTTP
    > headers, but also specified a role that had greater privileges than the
    > username and password allowed. Would that client be able to gain greater
    > privileges than it deserved?
    >


    I don't think the Xmla Servlet supports basic authentication - you could
    enable basic authentication at the container level but I really don't know
    much about this.
    The credentials I am interested in are provided in the SOAP payload by
    SimbaO2X, they don't come from HTTP headers.

    Also how are clients currently specifying their "role" ?
    What stops them from choosing anything they like as their role?
    (I will also start doing my own research on these points)


    > It needs to be clear and foolproof in the code whether the client is
    > trusted. If trusted, it can adopt whichever role it choses. If not, it must
    > take the role assigned by olap4j after authentication.
    >


    I don't fully understand the significance of the role - it's not something I
    use in my driver but I know that mondrian uses it. Is it a standard JDBC
    concept or something mondrian specific?
    I will find out more about it.


    > 5. What does your comment "we'd need to inject the HttpServletRequest into
    > this method" mean?
    >


    What I meant was that if we wanted to make the host name that made the
    request (IP of the client machine) available in the context, we would need
    to have access to the HttpServletRequest.
    I need that information for licensing reasons.


    >
    > 6. There is a magic id for un-authenticated session. Is this a security
    > hole?
    >


    Unfortunately Simba fires off the very first XMLA "DISCOVER" request
    (Discover Datasources) without providing any authentication credentials.
    It's as if Simba expected the server side to know about its data sources
    without opening a database connection.
    We could approach this problem in other ways, for example by providing the
    list of data sources in a different way.
    I will think about it.

    In any case an un-authenticated connection is not a security hole per-se.
    The behaviour depends on the particular implementation of Olap4j.
    Some drivers might refuse to execute queries on OlapConnections created
    without credentials.
    Other might not need authenticated connections at all.


    >
    > 7. Would it make sense for the servlet to refuse basic authentication
    > requests if they were not over HTTPS? (And not just the first request, which
    > carries username/password. Subsequent requests carry an authenticated
    > session ID, so they must be protected also.)
    >


    Again I need to go back and study the relation between the xmla servlet and
    basic authentication as I don't understand it yet.


    > 8. I fixed XmlaBasicTest. Maybe other tests are broken also. Can you please
    > ensure that the tests run clean before you re-submit.
    >


    Will do.

    >
    > 9. Add unit test for basic authentication. (It's hard for me to review this
    > code if it is not used in the test suite.)
    >


    Ok maybe by Basic Authentication you mean the SOAP authentication provided
    by Excel / Simba.
    I will look into it as discussed above.


    >
    > 10. Is the security model assuming that session ids are hard to guess?
    >


    Yes that is always expected by session IDs - you want to prevent an attacker
    from guessing a valid ID.
    So I can make the session ID generation algo a bit better.

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

  34. #34
    Michele Rossi Guest

    Default Re: [Mondrian] xmla security header processing

    hi Julian,
    sorry for the long delay, I've only just started working on this task again.

    I have been trying to apply your patch but unfortunately I get an error
    message, "Invalid patch file".
    I haven't found a way to apply your patch from the "p4" command line tool (I
    have googled for a considerable amount of time, no luck. I use the p4
    eclipse plugin 2010.1/275861, I couldn't do with the March 2011 p4v client
    either).

    Could we consider switching to "perforce shelving" instead of patches?
    Or some other way to allow non-authorised committers to deal with the
    mondrian perforce in a more efficient way? For example we could create a
    special branch where everybody can commit too.
    Then you could decide what things you want to merge back to the main branch.
    It's just an idea.. I am obviously not too good with patch files.

    Back to the XMLA servlet:

    1. it looks like we need very different connection creation policies: I need
    to create authenticated connections and I need to associate connections to
    sessions.
    If it's something that you don't want could we think about allowing the
    injection of different OlapConnectionFactory implementations?
    That way I could make an OlapConnectionFactory that caches connections and
    associates them with user sessions while the default behaviour would be what
    it is now.

    2. I am happy to use the container-level session to store authentication
    credentials - that is something that you suggested and that I will implement
    asap

    3. We have a problem with the first request that SimbaO2X sends without
    authentication.
    The request is "Discover Datasources".
    Are you happy if I allow users to provide their own hard-coded response to
    such request?
    It could go in the web.xml.
    When such configuration is not hard coded the system would behave as now and
    would try to obtain it from a OlapConnection object.


    many thanks,
    Michele



    On 26 May 2011 15:49, Michele Rossi <michele.rossi (AT) gmail (DOT) com> wrote:

    > hi Julian,
    > I've replied to some of your questions inline.
    >
    > thanks,
    > Michele
    >
    > On 25 May 2011 00:43, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:
    >
    >> Michele,
    >>
    >> As promised, I've reviewed your changes.
    >>
    >> All in all, the change looks useful. I can see that we need to introduce
    >> the notion of 'sessions' due to the way Simba O2X sends its requests. But I
    >> am concerned at how many places username & password are now present in the
    >> API, and the result is so confusing it's difficult to say that there are not
    >> security holes.
    >>
    >> If you can address my concerns, I will commit your changes. I've changed
    >> quite a lot of the code; see the patch attached. Can you use that patch as
    >> starting point when fixing the issues I raise below. And when you have made
    >> changes, please generate a similar patch using 'p4 diff -du' from the
    >> command line.
    >>
    >> Detailed comments...
    >>
    >> 0. Would it be simpler if the servlet looked for the <Security> tag and
    >> session information and copied these into the HTTP headers? Then we could
    >> use HTTP athentication and session lifecycle management. Just an idea.
    >>

    >
    > My main problem is to create an authenticated OlapConnection.
    > Hence I need the credentials to be processed in the code that creates the
    > connection and not by the container.
    >
    >
    >>
    >> 1. MondrianServerImpl.getConnection is not used. Removed it.
    >>
    >> 2. It is a bad idea to pool connections. If you want to pool connections,
    >> use a connection pool. It is an even worse idea to pool connections based on
    >> session ID -- that implies that you are trying to make sessions stateful,
    >> and it is much better if the XMLA servlet is stateless.
    >>
    >> So, I removed ConnectionHolder and the "connections" member.
    >>

    >
    > The problem is that Simba will create something like 15 connections before
    > you can even start configuring a Pivot in Excel.
    >
    > In general I believe that creating a new connection for each request is an
    > anti-pattern as it leads to a substantial waste of resources.
    >
    > In my case in particular this approach wouldn't work at all as I cache the
    > metadata objects at the connection level.
    > So before displaying a Pivot in Excel I'd have to populate the whole
    > metadata cache N times, once for each connection I create.
    >
    > Connection pooling is the technique normally used by more traditional web
    > apps that require access to a database for this problem and it can be
    > implemented either at the application level (e.g. commons-dbcp) and or at
    > the container level (tomcat can handle pool of connections to databases) .
    >
    > I am aware that my implementation didn't clean up un-used connections.
    > I didn't want to submit too much code at once and risk wasting time if you
    > didn't like all the rest of the work.
    >
    >
    >>
    >> I see why we need to save username & password so that they can be
    >> retrieved by subsequent requests in the same session. But your
    >> implementation never removed entries from that table. I added code to remove
    >> the entry when we see an 'end of session'. It would be nice if we could hook
    >> into HTTP session management (see #0 above).
    >>

    >
    > We can definitely save the credentials in the Http Session. The new version
    > of Simba supports Cookies too which means that this approach could work.
    > I will start thinking about this approach.
    >
    >
    >>
    >> 3. In removing the "connections" member, I may have broken the mechanism
    >> by which subsequent requests in the same XMLA session inherit the same
    >> password. (Difficult to tell without unit tests.) If so, I apologize.
    >>
    >> But it is not obvious how session context is conveyed along with the
    >> XmlaRequest. Would it make sense to replace 'String
    >> XmlaRequest.getSessionId()' (and getUsername() and getPassword()) with a
    >> 'SessionInfo XmlaRequest.getSessionInfo()' method that contains all
    >> session context?
    >>

    >
    > Yes definitely - although the end result is very similar this approach is
    > probably more flexible.
    >
    >
    >>
    >> 4. Please convince me that you are not opening up a security hole, as
    >> follows. The context contains a role name. It also may contain username and
    >> password, if the client happens to be using basic authentication. Suppose
    >> that a malicious client specified a valid username and password in its HTTP
    >> headers, but also specified a role that had greater privileges than the
    >> username and password allowed. Would that client be able to gain greater
    >> privileges than it deserved?
    >>

    >
    > I don't think the Xmla Servlet supports basic authentication - you could
    > enable basic authentication at the container level but I really don't know
    > much about this.
    > The credentials I am interested in are provided in the SOAP payload by
    > SimbaO2X, they don't come from HTTP headers.
    >
    > Also how are clients currently specifying their "role" ?
    > What stops them from choosing anything they like as their role?
    > (I will also start doing my own research on these points)
    >
    >
    >> It needs to be clear and foolproof in the code whether the client is
    >> trusted. If trusted, it can adopt whichever role it choses. If not, it must
    >> take the role assigned by olap4j after authentication.
    >>

    >
    > I don't fully understand the significance of the role - it's not something
    > I use in my driver but I know that mondrian uses it. Is it a standard JDBC
    > concept or something mondrian specific?
    > I will find out more about it.
    >
    >
    >> 5. What does your comment "we'd need to inject the HttpServletRequest into
    >> this method" mean?
    >>

    >
    > What I meant was that if we wanted to make the host name that made the
    > request (IP of the client machine) available in the context, we would need
    > to have access to the HttpServletRequest.
    > I need that information for licensing reasons.
    >
    >
    >>
    >> 6. There is a magic id for un-authenticated session. Is this a security
    >> hole?
    >>

    >
    > Unfortunately Simba fires off the very first XMLA "DISCOVER" request
    > (Discover Datasources) without providing any authentication credentials.
    > It's as if Simba expected the server side to know about its data sources
    > without opening a database connection.
    > We could approach this problem in other ways, for example by providing the
    > list of data sources in a different way.
    > I will think about it.
    >
    > In any case an un-authenticated connection is not a security hole per-se.
    > The behaviour depends on the particular implementation of Olap4j.
    > Some drivers might refuse to execute queries on OlapConnections created
    > without credentials.
    > Other might not need authenticated connections at all.
    >
    >
    >>
    >> 7. Would it make sense for the servlet to refuse basic authentication
    >> requests if they were not over HTTPS? (And not just the first request, which
    >> carries username/password. Subsequent requests carry an authenticated
    >> session ID, so they must be protected also.)
    >>

    >
    > Again I need to go back and study the relation between the xmla servlet
    > and basic authentication as I don't understand it yet.
    >
    >
    >> 8. I fixed XmlaBasicTest. Maybe other tests are broken also. Can you
    >> please ensure that the tests run clean before you re-submit.
    >>

    >
    > Will do.
    >
    >>
    >> 9. Add unit test for basic authentication. (It's hard for me to review
    >> this code if it is not used in the test suite.)
    >>

    >
    > Ok maybe by Basic Authentication you mean the SOAP authentication provided
    > by Excel / Simba.
    > I will look into it as discussed above.
    >
    >
    >>
    >> 10. Is the security model assuming that session ids are hard to guess?
    >>

    >
    > Yes that is always expected by session IDs - you want to prevent an
    > attacker from guessing a valid ID.
    > So I can make the session ID generation algo a bit better.
    >
    >


    _______________________________________________
    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.