Alternative authentication methods?

[FrankPoppe]

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

[ShaneGibson_OptimalBI]

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

[FrankPoppe]

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

[twocanbazza]

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

[FrankPoppe]

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!

[LarryNoe_SAS]

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?

[FrankPoppe]

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).

See also my reaction to Barry.

[ShaneGibson_OptimalBI]

Hey Frank

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

[FrankPoppe]

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.

[ShaneGibson_OptimalBI]

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?

[PaulHomes]

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

[PaulHomes]

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

[LarryNoe_SAS]

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?

[FrankPoppe]

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

[LarryNoe_SAS]

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.