[Mondrian] Re: xmla security header processing

Julian Hyde jhyde at pentaho.com
Mon May 9 14:30:26 EDT 2011


'p4 diff -du' should be good enough.


  _____  

From: mondrian-bounces at pentaho.org [mailto:mondrian-bounces at pentaho.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.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.1/manuals/p4eclipse/topics/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.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.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.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.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.org [mailto:mondrian-bounces at pentaho.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.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.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.com] 

Sent: Wednesday, April 20, 2011 10:52 AM
To: <jhyde at pentaho.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.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.com] 
Sent: Wednesday, April 20, 2011 8:00 AM
To: Mondrian developer mailing list
Cc:  <mailto:jhyde at pentaho.com> jhyde at pentaho.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.org
http://lists.pentaho.org/mailman/listinfo/mondrian





_______________________________________________
Mondrian mailing list
Mondrian at pentaho.org
http://lists.pentaho.org/mailman/listinfo/mondrian






_______________________________________________
Mondrian mailing list
Mondrian at pentaho.org
http://lists.pentaho.org/mailman/listinfo/mondrian





_______________________________________________
Mondrian mailing list
Mondrian at pentaho.org
http://lists.pentaho.org/mailman/listinfo/mondrian





_______________________________________________
Mondrian mailing list
Mondrian at pentaho.org
http://lists.pentaho.org/mailman/listinfo/mondrian




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20110509/c27a2f6b/attachment.html 


More information about the Mondrian mailing list