Hitachi Vantara Pentaho Community Forums
Results 1 to 34 of 34

Thread: [Mondrian] xmla security header processing

Hybrid View

Previous Post Previous Post   Next Post Next Post
  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
    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>
    >>

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.