Hitachi Vantara Pentaho Community Forums
Results 1 to 5 of 5

Thread: Bypassing login from ASP.Net

  1. #1

    Default Bypassing login from ASP.Net

    I am trying to integrate a new Pentaho site with an existing web application written in ASP.Net. It is strongly preferred that we use a single sign on for both applications. We are using a database to hold the user information (user name, password, roles, permissions) and I have both Pentaho and the ASP.Net application using the same data. So both apps authenticate against the same data.

    It seems to me that there are several ways to get the two servers to talk. First, we could have the instance of IIS that is hosting the ASP.Net application act as a proxy server and figure out how to use basic (or perhaps digest) authentication to pass in the user credentials. The BasicProcessingFilter would then be able to handle authentication.

    A second way would be to have the ASP.Net application write a cookie so that the RememberMeProcessingFilter could authenticate the user. In order to do this, I need to know the precise contents of the JSESSIONID cookie. From a description of TokenBasedRememberMeServices for the right version of ACEGI, I can see what is in the cookie. But I need to understand:
    1) how to use the same salt in ASP.Net as is used in the ACEGI implementation ( I guess this means I need to know what
    <property name="key" value="pentahoSecurity" /> means (is 'pentahoSecurity' the string I tack onto the other parameters or is it a reference to so something else?)

    and

    2) the expirationTime is supposed to be date an time in milliseconds. Is that milliseconds since the beginning of the 'Unix epoch' on midnight of 1 Jan 1970?

    There could be other approaches. I could do something dreadful and pass in the user name and (hash of salted) password in the URL. I call this dreadful because it would mean that I have to have every xaction handle security rather than ACEGI. This seems like the worst sort of hack that would probably undercut security and multiply the amount of code that I have to write.

    Is there a better way or would it be better to use IIS as a proxy? If the cookie trick works, I'll be happy to share the C# that writes the cookie as this should be useful to others that have to access Pentaho from .Net applications.

  2. #2
    Join Date
    Oct 2006
    Posts
    817

    Default

    Using Basic Authentication seems like the best approach to me. And here's why I say that. Although, I really like your cookie approach, I think it might suffer when you go to share the cookie across domains.

    I've solved a problem similar to yours (i.e. home-grown SSO between two apps) by using Acegi Security's remember me in a different way. Hopefully I'm remembering this accurately. Instead of using a cookie to store authenticated status, I used a shared database table. The table had two columns--a unique ID and an expiration time. When someone logged into one app, a table row was written; when they crossed over to another app, the key was appended to the URL; the remember me filter in the destination app would accept the query parameter, look in the database, and auto-login if the key was found and not expired.

  3. #3

    Thumbs up Thanks Matt

    That helps: it least it is a sanity check on what I was trying to do.

    One fundamental problem I have is that the user name is not unique in the home grown system. (The ASP.Net application uses a bunch of custom code to bypass standard security so it could be compatible with an even older application that had this home grown security.) You need an account number and password to identify the user. (yes, if a user changes as password you have to cascade over foreign keys just to be able to identify the user, but I shouldn't get started on all of that...)

    So lots of standard solutions for username/password just break if you try to use our account/password. I can use password/password (cringe) or invent a username for Pentaho that is not the username in the other application. I can see how to do this with the cookies, but I'm not sure how to pass a made up user name via basic authentication. I know its just strings in the HTTP header, but I can't see how to mess with the header in the client browser and the client browser doesn't know the right username/password. So, I think I need either a cookie or your DB solution. (Or I have to convince the powers that be to use a 'proper' user name.)

    Once again, thanks for the suggestions.

  4. #4
    Join Date
    Oct 2006
    Posts
    817

    Default

    So why can you not use the account number everywhere a username is requested? Is it because at the point when you want to hop over to Pentaho, you don't have the account number, just a username?

  5. #5

    Default

    There are multiple user accounts that use the same account number. So we can't identify the user account from the acount number. So "Joe" and "Mary" could both have an account number of "1" but Joe and Mary would have to have passwords that are guarenteed to be unique by a database constraint. At login we get accountNumberasword pairs like 1:JoeRulz007 or 1:MaryRulz02 and we have to use the password to identify the user.

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.