locked
Alternate Security - 2 Questions RRS feed

  • Question

  •  

    I'm working on the design of a web-facing PAS installation, and have a couple architecture questions about the alternate security:

     

    1. Using the (unsupported) alternate security approaches (i.e. PImpersonate.dll), is it possible in any fashion to do the impersonation *without* providing the user's password?  I ask because the "standard" approach in this environment is for an SSO solution to pass the _username_ in a session variable, but not the password.  Just want to know if the lack of a password is a show-stopper for the SDK-based impersonation.

     

    2. Is the PImpersonate.dll method of impersonation also compatible with ProClarity Dashboard Server?  Again the reason is that this installation would put PDS behind an SSO, and the desired outcome is that the SSO layer would handle authentication so some means of passing authentication through PDS would be needed.

     

    Thanks for advice!

    Rob

    Wednesday, December 3, 2008 3:32 PM

Answers

  • The trick with any alternate security implementation involving ProClarity is getting the user authenticated as a Windows user, because this is what Analysis Services requires for a valid "user".  This can of course happen in many ways, but using the sample alternate security method, it does in fact require a password.  If there were a way to have this happen before the user gets to IIS/ProClarity, and IIS can simply consume the Windows user that has been authenticated upstream, then of course you wouldn't need the alternate security method in the sample.  This upstream logging in often happens when a user logs into their machine, or when they authenticate to IIS via a basic authentication prompt, or etc, but it does need to happen at some point.  How and when that's done is tremendously varied in these types of implementations.

     

    Regarding the Dashboard, you may either choose to use Windows authentication and validate the user upstream, or you may use forms authentication (with an optional connection to the Windows domain so the Windows creds can be used to login via the form), in which case you may pass the username and creds in on the URL.  To do this, within the login.aspx page of the Dashboard Server there is a section near the top of the page that is commented out with '//' for each line. This is the "Page_Init" section of the web page. You will notice within the code snippet you should see the following: protected void Page_Init(object sender, EventArgs e) { if (!string.IsNullOrEmpty(Request["username"]) && !string.IsNullOrEmpty(Request["password"])) { username.Text = Request["username"]; password.Text = Request["password"]; Login_Click(sender, e); } } By uncommenting this code, you can then use a username/password combination in the URL to send the credentials. Here is an example. http://localhost/PDS/login.aspx?username=MyUsername&password=MyPassword This will then send those credentials to the dashboard and the user will be logged in without being prompted. Please keep in mind that the credentials will be in plain text and viewable, so taking best practice security measures in your code will be very important.  (Thanks to TJ for this research and writeup)

    Thursday, December 4, 2008 5:20 PM

All replies

  • Hi Rob,

     

    I'll forward this question to our SDK engineer and post his response.

     

    Thanks,

     

    -Joey

    Wednesday, December 3, 2008 11:02 PM
  • The trick with any alternate security implementation involving ProClarity is getting the user authenticated as a Windows user, because this is what Analysis Services requires for a valid "user".  This can of course happen in many ways, but using the sample alternate security method, it does in fact require a password.  If there were a way to have this happen before the user gets to IIS/ProClarity, and IIS can simply consume the Windows user that has been authenticated upstream, then of course you wouldn't need the alternate security method in the sample.  This upstream logging in often happens when a user logs into their machine, or when they authenticate to IIS via a basic authentication prompt, or etc, but it does need to happen at some point.  How and when that's done is tremendously varied in these types of implementations.

     

    Regarding the Dashboard, you may either choose to use Windows authentication and validate the user upstream, or you may use forms authentication (with an optional connection to the Windows domain so the Windows creds can be used to login via the form), in which case you may pass the username and creds in on the URL.  To do this, within the login.aspx page of the Dashboard Server there is a section near the top of the page that is commented out with '//' for each line. This is the "Page_Init" section of the web page. You will notice within the code snippet you should see the following: protected void Page_Init(object sender, EventArgs e) { if (!string.IsNullOrEmpty(Request["username"]) && !string.IsNullOrEmpty(Request["password"])) { username.Text = Request["username"]; password.Text = Request["password"]; Login_Click(sender, e); } } By uncommenting this code, you can then use a username/password combination in the URL to send the credentials. Here is an example. http://localhost/PDS/login.aspx?username=MyUsername&password=MyPassword This will then send those credentials to the dashboard and the user will be logged in without being prompted. Please keep in mind that the credentials will be in plain text and viewable, so taking best practice security measures in your code will be very important.  (Thanks to TJ for this research and writeup)

    Thursday, December 4, 2008 5:20 PM
  • Ben, thanks so much for the detailed response.  Also please pass my thanks to TJ for the research and write-up.  This is exactly what I needed!

     

    Wednesday, December 10, 2008 4:09 PM