topic Alternative authentication methods? in Administration and Deployment

Alternative authentication methods?

FrankPoppe — Wed, 14 Sep 2011 08:11:54 GMT

Hi,

I wonder if there are any suggestions on the following authentication problem.

I'll need a few sentences to explain the situation.

We will have two sets of users.

The first set are internal users, with a username in the standard company domain. There are lots of differences between the users within that set (some do DI Studio work, others EG, or just use the Portal and WRS), but that is not relevant.

The other set are external users that only will access the Portal through internet, browsing information coming from tables and cubes. These users will not yet have a username, but they will need one because they have to be authenticated (users will have access only to specific subsets of data).

The question is now how to authenticate those external users. Assigning them an username in the company domain is, for different reasons, not an option.

An option that I have seen used elsewhere is to define users locally on the machine where the SAS Metadata Server sits. The SAS identities in the metadata for those users will be linked to accounts like MetadataMachineName\user, instead of CompanyAD\user.

In the current situation that is not an acceptable solution because it appears an additional Microsoft CAL (Client Access License) is needed for each user that will be defined on the server (although that username only will be used for authentication, the user will never have real access to the machine).

One of the ideas now is to set up a Linux server with an OpenSource LDAP server to manage those external users. But I cannot find much documentation on how to configure (in the metadata) a LDAP server that is not the standard one.

Some links are Direct LDAP Authentication and How to configure direct LDAP Authentication , both from the Security Admin Guide. But there really only give necessary configuration settings, and don´t give much background - which is what I need as well, being ignorant in this area.

One item I noticed however was that there can be only one LDAP server, which means I cannot have both the company LDAP server for internal users and this possible Linux LDAP server for external ones.

Is this correct?

Is there some way to overcome this? (Have the local LDAP server extract information from the central LDAP server?)

Are the any other option that we should look at?

Any suggestions are welcome!

Frank Poppe

Alternative authentication methods?

ShaneGibson_OptimalBI — Wed, 14 Sep 2011 09:56:33 GMT

Hi Frank

Does each external user have to have their own login? i.e are they accessing different content to other external users (so we need authorisation on the content?). Or can they all share the same login?

Cheers

Shane

Alternative authentication methods?

FrankPoppe — Wed, 14 Sep 2011 11:33:34 GMT

Hi Shane,

Yes, they must have their own login.

The content they'll see will differ: different portal pages and portlets, different information maps, different rows from a table, different cube slices, etc.

(We will have the users in groups, and the groups will have access to the items in different metadata folders. Also some information maps will have filters with row level security, and the cubes will have permission tables.)

Greetings,

Frank

Alternative authentication methods?

twocanbazza — Wed, 14 Sep 2011 19:55:00 GMT

There seems to be a lot of not an options comments, what are the reasons... as it seems to me you are making a complex situation way more complex...

Not only will you have to configure the metadata security, you also have to integrate your chosen authentication method with your file system as you are accessing data in your reports...

Paul Homes I am sure would have some good suggestions.

Barry

Alternative authentication methods?

LarryNoe_SAS — Wed, 14 Sep 2011 20:19:46 GMT

In the existing deployment with domain users (or proposed delpoyment if it has not yet been implemented), is the metadata server running on Windows or Linux? And the other servers? Are they on the same architecture as well? If it is Linux, is the Linux box set up to use AD for authentication or are you setting up the metadata server to talk to the AD server directly?

Re: Alternative authentication methods?

FrankPoppe — Thu, 15 Sep 2011 08:49:30 GMT

I should have mentioned this.

In the production environment we have 4 servers (metadata server, workspace, OLAP, web), all Windows 2008. That is already in place and running. The issue now is to authenticate individual external users of the IDP.

(We have a second set of four Windows servers for the development cycle. And all servers are virtual machines.)

So the metadataserver is running on Windows, and is configured to talk to LDAP (more or less by default I guess, but I haven't done the installation and configuration).

Alternative authentication methods?

FrankPoppe — Thu, 15 Sep 2011 09:08:38 GMT

I'll try to elaborate a bit.

For starters I am just a SAS consultant, not the boss. And we are in a small organisation, independent in the products it develops, but part of a much larger organisation. The larger organisation makes the ICT environment available and maintains things as the Active Directory.

So creating an account in the company wide AD is done through an authorisation procedure, and will mean the the organisation I work for starts to pay for additional users, for facilities they will never use. Even the change itself may be billed by the company to which this has been outsourced.

The cost and the loss of flexibity when new users have to be created, or e.g. when existing users have forgotten their password make that (IMHO) using the existing LDAP server is not option.

But although I can claim a fairly large experience in SAS, I never have done much in the area of authenticating web users, so I may have taken some things for granted which deserve more attention.

I don't see why you judge the initial setup as an already complex situation. Also I don't see what you mean with the need to integrate authentication with the file system? Of course, for all users that get access to certain data (tables or cubes) through the metadata the physical data source will have to be accessed as well. But I don't see a difference there between users that are authenticated through the existing LDAP database and other users.

But if I overlook something there, please enlighten me.

And suggestions from Paul Homes are always welcome!

Re: Alternative authentication methods?

ShaneGibson_OptimalBI — Thu, 15 Sep 2011 09:16:00 GMT

Hey Frank

Assuming its SAS 9.1 so we cant use SAS 9.2 internal (metadata only) id's? (i.e shane@saspw)

Alternative authentication methods?

FrankPoppe — Thu, 15 Sep 2011 09:34:39 GMT

Again something I should have mentioned.

It is SAS 9.2.

But:

1) The SAS docs state that you can't (or shouldn't) use internal ID for other then administrative tasks because they can't access data sources. This doesn't seem to be quite true, I did some tests and didn't run into problems but the tests weren't very extensive and given that text in the docs it seems too large a risk to take.

2) Those external users always will have to type the @saspw part. Users that are authenticated outside of SAS only will have to type the username, regardless of whether the metadata knows a MetadataMachineName\user account or a CompanyAD\user account. This will hardly be acceptable for the people here.

Alternative authentication methods?

ShaneGibson_OptimalBI — Thu, 15 Sep 2011 09:46:20 GMT

You can chnage some settigs to let the @saspw users inherit a trusted user id and run a workspace session etc, would probably be best to setup a seperate SASApp definition in this instance. And of course you then lose the ability to see the user id in the sas executable on the server which is a pain.

So not ideal.

Dont suppose setting up another web server, metadata instance and workspace server (and replicating Metadata ) is an option?

Alternative authentication methods?

PaulHomes — Thu, 15 Sep 2011 11:00:44 GMT

Hi Frank,

How is authentication currently configured for your web-tier and how are you planning on making the SAS web applications available to your remote users? The reason I ask is I am wondering how your organization is planning on exposing the SAS Information Delivery Portal to the remote users? Will it be accessible directly/publicly available over the internet, over a VPN, or via a secure authenticating reverse proxy server (webseal, siteminder etc.) Are you using the SAS Logon Manager for form based authentication or using trusted web authentication? If your remote users are already being authenticated by a reverse proxy server at the companies network border is there any chance that trusted web authentication can be used in your environment so you can reuse any existing authentication process?

Cheers

Paul

Alternative authentication methods?

PaulHomes — Thu, 15 Sep 2011 11:40:42 GMT

Hi Frank,

Some additional thoughts/comments...

My first thought was to use local accounts on the metadata server and then SAS token authentication for access to the other tiers. You mentioned that this is not acceptable due to the additional CAL requirements. My next thought, as Shane has already suggested, would be to use SAS internal accounts. Whilst I wouldn't normally suggest creating lots of internal accounts for 'normal' users if you cant use opsys accounts then it's an option that could be considered. You mentioned that the @saspw suffix would be an issue, but with local and domain accounts previously ruled out I am not sure what other alternatives you might have left?

With internal accounts they will be able to login into the portal and utilize pooled workspace servers and stored processes servers but will not be able to use standard workspace servers (if required) unless you take additional action since they have will not have operating system accounts. They will be able to use the standard workspace server if you convert it to SAS token authentication. Converting to SAS token authentication may have an impact on the existing use of the standard workspace server since the SAS processes will no longer be launched using the requesting users operating system identity but a shared identity instead (such as sassrv). Consider what changes might be required to file system access controls. You might also consider partitioning the internal/external users with different application servers.

Another possibilty for access to a standard workspace server for these SAS internal accounts without using SAS token authentication might be to put the remote internal account users in a group, create a single operating system account to use as a proxy account, and add that proxy account's credentials to the remote users group. The credentials for that proxy account will then be available for use by the remote users. However, I have experienced some issues with this type of config with an older SAS 9.2 installation when running a stored process configured to run in a workspace server (it worked fine with SAS Enterprise Guide but for some reason the SAS Stored Process Web Application was not picking up and using the outbound login on the group). I haven't tried this approach with SAS 9.2 M3 as yet.

Are your organization's security people comfortable with providing network access for external users to company resources using accounts that are maintained purely by a SAS admin team? I would have expected the preference to be for these types of accounts to be tightly controlled by the people who are normally reponsible for authorising and provisioning accounts. Would they not want to put the remote user accounts in a seperate area of the enterprise directory and implement a security plan to ensure they only have web access to the SAS platform?

Cheers
Paul

Alternative authentication methods?

LarryNoe_SAS — Thu, 15 Sep 2011 12:31:02 GMT

I don't have anything to add to Paul's latest response, but wanted to clarify one item from the original post where you had a question that had not been answered. You said:

"One item I noticed however was that there can be only one LDAP server, which means I cannot have both the company LDAP server for internal users and this possible Linux LDAP server for external ones. Is this correct?"

It is true that you can only specify one LDAP server using the options provided, but in your scenario if you were to set up an LDAP server, that wouldn't be a problem. You are using Windows as your back-end system, so the default of Windows host authentication is used for authenticating users. As you mentioned, whether the user is a local defined user or an AD user, it doesn't matter: they will be successfully authenticated. This is because we use a Windows API for authentication. We do not talk to AD directly. With a default Window AD setup, the AD server being used for back-end authentication does not count as an LDAP server. Your internal users can stll be authenticated against AD with their Windows accounts, and you could set up an LDAP server to authenticate the external users. That is perfectly acceptable and not uncommon.

Where this begins to have problems is your statement that adding "@DOMAIN" won't be acceptable. The authenticaiton system only authenticates an incoming user against a single provider. Without a domain qualifier, the system has no way to kow which provider the account is destined for, so it sends it to the default provider. That is typically "host" though it can be altered wuth the primaryproviderdomain option. Regardless, without a domain qualifier to determine where to authenticate a user in a system with multiple providers, the system will always send users to the default provider. Since the external users are purely web-based users, what I have seen done in the field, is for a domain to be added behind the scenes in the web app that the users are never aware of. They log in with just their user name, and before the username is sent off to the back-end for authentication, "@DOMAIN" is appended. With this, the authentication code will send the username and password to the correct provider for authentication. I am not a web app person, so I don't know where this is done, but I kow it has been done, so someone out there can probably explain the details. Of course, the internal users should not have this happen, and that may ruin this scheme. If the internal users are not using the externally presented web apps, this can work. If they are, you are back to a mix of users that cannot be distinguished. Maybe the external users are using a different deployment of the web apps?

Alternative authentication methods?

FrankPoppe — Thu, 15 Sep 2011 13:50:39 GMT

Hi,

Thanks for the questions and the suggestions. I now have several things to think (and read) about, one reason being that these are areas I until now knew existed, but never did have to know much about.

Some reactions already.

@Paul, the Portal is surfaced to the external users through public internet. Everybody can see the logon page (http://zorgportal.prismant.nl). So the SAS Logon Manager is the point where authentication starts (and ends).

The identity of the external users will have to be available when Information Maps are being processed (to be used in a filter using the SAS.IdentityGroups property) and when the permissions table for a cube is being used.

So the scenarios where some shared identity is being used are only an option if that still is the case. At this moment I am not familiar enough with the way this operates to judge this for myself.

@LarryNoe

I always thought that when more then one domain was being used it works like this. The user gives just the username, the metadataserver then searches for an identity that has an account with that username, and then sends off the username to the authentication domain given before the backslash in the account field.

But this does not fit in with your description of ‘always sends users to the default provider’?

I have been thinking of the option of adding the @DOMAIN (possibly @SASPW if that in the end will be the way to go) in the HTML-form, perhaps with Javascript or something like that, before the username is sent off to some authentication mechanism.

It should not be difficult (I think ) to provide the internal users with a logon page that does not add this suffix, and then starts exactly the same portal.

@Shane

I don’t see what would be gained with setting up another web server with metadata and workspace servers? If it would solve the problem, it would be an option, because it wouldn’t necessarily mean a new set of machines. I see no reason why they wouldn’t run on the same machines (providing you don’t mix up the port numbers).

Thanks again to all of you,

Frank

Alternative authentication methods?

LarryNoe_SAS — Thu, 15 Sep 2011 14:11:13 GMT

You must pass through the authentication system first before getting into the metadata server to search for your metadata identity. When just a username is presented to the authentication system, the default provider is called to authenticate the username/password. The default provider can be modified in 9.2 by using -primaryproviderdomain. In the case of Windows authentication, the username and password are provided to the Windows Logon API for authentication. Windows always tries to find the name in the the local security authority first, if it is not there, it does a domain search based on Windows search rules. Once the username is found in an either the local system or AD, authentication proceeds. Assuming success, we ask Windows for the name of the domain that authenticated the account (could be the local machine name). That domain name is then provided along with the username to the metadata server for the search to find the metadata identity. On Windows, the domain is always provided to the server, which is why you always have to domain qualify your usernames in metadata, even though you do not at login time because of the search done by the Logon API. Of course, not qualifying the name can present problems if your name exists in more than one domain. Not a good practice of course, but it does occur.

Alternative authentication methods?

PaulHomes — Fri, 16 Sep 2011 12:17:36 GMT

Hi Frank,

In the scenarios where a shared operating system identity is being used to run the SAS processes (pooled workspace server, stored process server, standard workspace server with SAS token authentication, standard workspace server with internal accounts and shared proxy account), then whilst the shared operating system identity is used at the level of the operating system for file system access controls, for metadata authorization the requesting users SAS identity should be used (except for a few situations with pre-assigned libraries). This means that the BI row level security config in your information maps should continue to operate as you expect.

Cheers
Paul

Alternative authentication methods?

PaulHomes — Fri, 16 Sep 2011 13:20:50 GMT

Hi Frank,

Thanks for providing the background info on your web tier authentication setup. I can see that your external portal access is via SSL and on the standard HTTPS port 443. The HTTP headers show that JBoss is used as the web application server. Do you know if this is JBoss directly listening on port 443 or a reverse proxy sitting in front of JBoss?

If you are already using a reverse proxy then you might be able to get the administrators of that to provide for the authentication of your remote users and then switch to using trusted web authentication rather than the SAS Logon Manager form based authentication.

If it is JBoss listening directly then you could potentially insert a reverse proxy between JBoss and the clients. This could allow you to move the web user authentication from the metadata server to the reverse proxy server and then use trusted web authentication. For example Apache web server could be used as a simple reverse proxy for JBoss. Apache can be configured with multiple authentication providers. It could authenticate against AD/LDAP and if the user is not found in AD/LDAP then fallback to a second provider. This type of config might allow you to use AD for your normal web users and then a second authentication provider for your external web users. Another benefit of using Apache as a reverse proxy is to offload serving the static content from JBoss to Apache. There's a SAS document available "Configuring Apache HTTP Server as a Reverse Proxy Server for SAS® Web Applications Deployed on JBoss 4.2.0-GA"

I haven't tried it myself as yet but it appears that you can also do password stacking over multiple login modules in JBoss itself. I would start researching this with the SAS document "Configuring JBoss Application Server 4.2.0 for Web Authentication with SAS®9.2 Web Applications" and then move on to the JBoss documentation.

Cheers

Paul

Alternative authentication methods?

FrankPoppe — Mon, 19 Sep 2011 12:02:50 GMT

Hi Paul,

Thanks a lot for the suggestions and pointers.

At the moment we don't have a reverse proxy, but it sounds like something to investigate.

I will try to familiarize myself further with these topics; or try to get somebody involved who feels already better at home here.

Anyway, it may take a few days before I report on our next steps.

Until then, thanks again to all of you.

Frank

Alternative authentication methods?

VicA — Tue, 11 Oct 2011 19:13:41 GMT

Frank,

I have an almost identical installation. Windows 2008 R2 Enterprise onthe java application server(s) running JBoss EAP 4.3. Windows 2008 R2Standard on the Compute tier and Windows 2003 Enterprise on the metadataserver(s). My metadata and web tiers are clustered for fail-over. Ihave authentication configured to use Active Directory for my domain users andLDAP for my external users. Actually the LDAP is Microsoft ADAM which isbuilt into Windows 2008. My AD account are spread across three domains butall are within the same forest. This is a simple configuration but inorder to work properly your users will need to login with two differentformats. Internal users will login with domain\username and externalusers will login with username@domain. The login manager looks at theformat of the login and decides which authentication provider to send therequest to. I am using IIS7 as a reverse proxy load balancer with six (6)instances of JBoss on each web tier server. I also have a cold sparecompute server that I have configured to impersonate the hot computeserver. This requires the first server to be completely shut down beforethe cold spare is started but that way I have this machine configured the SASmetadata server hasn't complained about either server authenticating. There are a couple of gotchas in using JBoss. SAS used to recommend usingJBoss GA (the free version). We found out the hard way that this versionhas a bug that consumes all of the available network connections then stops servingweb pages.

Something you may want to consider would be to replace the metadataauthentication providers entirely and switch to a JOSSO implementation. This will allow you to concurrently authenticate to SAS and IIS7. Thebeauty of this solution is that your authentication provider handles passwordresets and you can delegate new user account creation. JOSSO is a open source project. Google it.

Vic

Alternative authentication methods?

LarryNoe_SAS — Tue, 11 Oct 2011 21:00:50 GMT

I am not sure if this helps you at all, but in 9.3, your users who are logging in with name@domain could log in with domain\user instead since the authentication code was modified to allow the Windows backslash seperator in addition to the @ sign as a valid domain seperator. That might be more natural for them if they are used to logging in using that format. Just FYI.