Alternative authentication methods?

[PaulHomes]

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

[PaulHomes]

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

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

[FrankPoppe]

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

[VicA]

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

[LarryNoe_SAS]

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.

[FrankPoppe]

@Larry and @Vic: thanks for the additional input.

For the time being we have our external users defined as local accounts on the Windows machine that hosts the metadataserver. But in order to get rid of the need for Microsoft CAL's somebody is investigating the alternative scenario's that have been suggested.

That make take a few weeks. I'll report back on what we have chosen (and why).

Frank