nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Windows Authentication for Datasource

AlanC

We have a number of reports currently deployed to our Iserver Express server. These are accessing SQL Server databases to extract data via the com.actuate.jdbc.sqlserver.SQLServerDriver (Actuate SQL Server Driver). 
 
At the moment, we use a specific Username and Password for all of these connections. However, we now wish to use Windows Authentication to provide access to the databases. 
 
Can anyone tell me 
i) If this is possible, and 
ii) How do I do it? 
 
Thanks

Find more posts tagged with

Comments

johnw

Your getting into a whole new painful region.

iServer can authenticate and authorize against a Windows domain server. Not sure if it does it out of the box though, I'm almost inclined to say that it does, but if not, there are ties in the API to do it. Its been a few years since I've had to do that though. I am also not sure with the commercial Actuate product, but I believe there is a way to grab the username, in which case you would set that in your data source using Property Binding. Not sure about the password. Like I said, its been a few years.

Now the question is how do you pass in the user credentials. Are you talking about doing a NTLM or something through the browser? I know in the past with iServer, we were able to tie it into a single sign-on system such as Siteminder. If its BASIC auth, that should be a piece of cake, but with NTLM, thats a whole other issue.

AlanC

Thanks for your reply John. However, we're getting into an area about which I know very little. I'll have to take advice from more technical people here.

In the meantime, are you aware of any documentation that can point us in the right direction?

Thanks

johnw

Well, if your looking to do NTLM or something, no, there isn't any documentation I could point you to. The only problem I can think of is if it is NTLM, your limited to IE only. I know you can use something like Siteminder to get your user credentials via the request header params, but I don't have specifics.

If our just looking to have your iServer authenticate against a Windows domain, there should be something in your documentation entitled RSSE (Report Server Security Extensions) and APSE (Active Portal Security Extensions). What you would do is build an RSSE extension to handled the authentication and authorization routines to your Windows DM or an LDAP server someplace. Then you would use some scripting inside of BIRT to get the users profile. This might be in reportContext.getAppContext(), or it might be in some other additional object that the commercial BIRT has extra. It should be there because I remember these routines being present in ERD Pro. It's been a few years since I've worked on the commercial platform, so take what I'm suggesting with a grain of salt

So I guess we should take a step back. Is the user logging into iServer to run the reports?

Regardless, this should bump this thread to the top, so maybe Michael, Jason, or Virgil have more input.

AlanC

Thanks again John.
At the moment, users login to the IServer using a separate userid to their Domain Id. Our technical department are keen to change this but the impact of this, if I'm reading your notes correctly, is potentially huge, if we have to change individual reports.
It may be that we have to take a different approach to the problem.
Thanks again for your input.
Regards
Alan

johnw

OK, so the desired behavior, if I understand you correctly, is that you want to be able to have the users log into iServer using their domain ID's, and have those domain ID's once logged in passed through to the report and used in the data source, is that correct? Is there any reason why you still couldn't use the domain login to iServer (which would require only an RSSE change, not impacting reports, and would eliminate the separate ID) and use a service account in the report to connect to a database? Or are there security entitlements in the database tied to users accounts?

John

AlanC

Yes John
The users are given the appropriate authorisation on each database by the DB administrators. There are some highly sensitive data, to which some users should not have access. Currently, we use a single userid to enable the reports' access to the data and then control the user access by Portal permissions on their BIRT userid. Unfortunately, I am not exceptionally technical and don't understand the implications of RSSE - I would have to take advice on whether this is feasible
Thanks

johnw

Is single sign-on a requirement?

AlanC

<blockquote class='ipsBlockquote' data-author="'johnw'" data-cid="66397" data-time="1279080654" data-date="13 July 2010 - 09:10 PM">
Is single sign-on a requirement? </blockquote>
 
Hi John 
Thanks again for looking at this. I feel I'm rather getting out of my depth here. I've talked to our DB Administrator, who has told me that what we want, ideally, is that once the user has logged into the network, it is that userid that determines access to the database. However, I don't understand how this can work, with BIRT Iserver having it's own userids/passwords and permissions. 
 
The area of contention is in the userid/password used in the set up of the Data Source. Currently, this is a single userid, specifically set up for BIRT reports to have access to the databases. Our DB Administrator wants this to be taken from the user's network details. 
 
Given that we don't particularly want to have to amend all of our existing reports to alter the userid/password combo via Script, I'm not sure what our options are. 
 
Our DB Administrator assures me that SQL Server Reporting Services, which is used here also, has a similar set up to BIRT, with a central userid to control access to the databases, BUT he can alter that by a single setting, which would then ensure that network details were used instead. 
 
Not sure where that leaves us! 
 
Thanks again. 
Alan

johnw

The RSSE component in IServer takes care of bridging the IServer user IDs with your Windows domain. So essentially, instead of logging in with a different user ID and password, they would log in to iServer with the same credentials that they use to log into their desktop. 
 
If you set up your reports to use a library in BIRT, then you would only need to change the library itself to add in the login for username and password. I'll have a better answer for you either later today or tomorrow how this works since, oddly enough, I have a request that came in this morning to set up an iServer instance and take a look at a few things with the commercial product. I plan to look into your request as one of my task items. 
 
John 
 
<blockquote class='ipsBlockquote' data-author="'AlanC'" data-cid="66452" data-time="1279178881" data-date="15 July 2010 - 12:28 AM">
Hi John 
Thanks again for looking at this. I feel I'm rather getting out of my depth here. I've talked to our DB Administrator, who has told me that what we want, ideally, is that once the user has logged into the network, it is that userid that determines access to the database. However, I don't understand how this can work, with BIRT Iserver having it's own userids/passwords and permissions. 
 
The area of contention is in the userid/password used in the set up of the Data Source. Currently, this is a single userid, specifically set up for BIRT reports to have access to the databases. Our DB Administrator wants this to be taken from the user's network details. 
 
Given that we don't particularly want to have to amend all of our existing reports to alter the userid/password combo via Script, I'm not sure what our options are. 
 
Our DB Administrator assures me that SQL Server Reporting Services, which is used here also, has a similar set up to BIRT, with a central userid to control access to the databases, BUT he can alter that by a single setting, which would then ensure that network details were used instead. 
 
Not sure where that leaves us! 
 
Thanks again. 
Alan </blockquote>