BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
Slash
Quartz | Level 8

Hi, guys

OS: Windows server 2008 R2

Third part: Jboss 4.2.3

SAS Version: 9.3

I have deployed the SAS EM, and I can use the the URL to use the SAS EM through a Web Browser.

Now I need to through our company's web single sign-on to Log On rather than the EM's log on screen? Is that possible? If does and how deploy that?

1 ACCEPTED SOLUTION

Accepted Solutions
jakarman
Barite | Level 11

Slash, As you are using a web-browser to start EM there are more issues to review.

Using Em through a webserver: The java code is downloaded to the desktop, The java virtual machine known as part of the browser is used.

This scenario is the implementation that is validated as possible unsecure by java vulnerabilities. I have seen requirements (US) to disable java in the browser

To remember a browser should not have uncontrolled access to the desktop, it should not know files or the user running it.

Using the java Desktop client of EM would be easier and more trustworthy to implement.

You are mentioning a corporate webbrowser being used. How is the authentication being done at that part. Connected to AD or not (standalone).

How Em is working is that:

- the Rmi-server is having in a config-file the unrestricted admin with password. At (re)start it will check and possible change the metadata

- Using EM you are connecting to the SAS midtier first, this is your login-point.  Then it will go to the metadataserver and start a workspaceserver.

There is a trade off in needed security levels and ease of working. 

To achieve SSO you could eliminate all Security in metadata an for the workspaceserver opening up running processes at high-priviledged accounts.

Do you need more strict security levels auditing tracing preventing possible unwanted user actions. You can end up not allowing any access at all. Very secure but not functional.

This is the first thing you need to get clear

Within Windows AD, that is the way for SSO. You could use IWA (Integrated Windows Authentication) . There are limitations with that.

Caching user credentials is something to help achieve seemless SSO but then evaluate the risks on that. Caching credentials of the server in a user-home profile location should be no big issue. People having that high level access seeing everyones private data should be monitored and classified trustworthy       

Some links:

SAS(R) 9.3 Intelligence Platform: Security Administration Guide Summary for Single Sign-On
SAS(R) 9.3 Intelligence Platform: Security Administration Guide (web authentication) no intheritance to SAS-servers

SAS(R) 9.3 Intelligence Platform: Security Administration Guide How to Configure Integrated Windows Authentication

SAS(R) 9.3 Intelligence Platform: Security Administration Guide Integrated Windows Authentication

---->-- ja karman --<-----

View solution in original post

4 REPLIES 4
jakarman
Barite | Level 11

Slash, As you are using a web-browser to start EM there are more issues to review.

Using Em through a webserver: The java code is downloaded to the desktop, The java virtual machine known as part of the browser is used.

This scenario is the implementation that is validated as possible unsecure by java vulnerabilities. I have seen requirements (US) to disable java in the browser

To remember a browser should not have uncontrolled access to the desktop, it should not know files or the user running it.

Using the java Desktop client of EM would be easier and more trustworthy to implement.

You are mentioning a corporate webbrowser being used. How is the authentication being done at that part. Connected to AD or not (standalone).

How Em is working is that:

- the Rmi-server is having in a config-file the unrestricted admin with password. At (re)start it will check and possible change the metadata

- Using EM you are connecting to the SAS midtier first, this is your login-point.  Then it will go to the metadataserver and start a workspaceserver.

There is a trade off in needed security levels and ease of working. 

To achieve SSO you could eliminate all Security in metadata an for the workspaceserver opening up running processes at high-priviledged accounts.

Do you need more strict security levels auditing tracing preventing possible unwanted user actions. You can end up not allowing any access at all. Very secure but not functional.

This is the first thing you need to get clear

Within Windows AD, that is the way for SSO. You could use IWA (Integrated Windows Authentication) . There are limitations with that.

Caching user credentials is something to help achieve seemless SSO but then evaluate the risks on that. Caching credentials of the server in a user-home profile location should be no big issue. People having that high level access seeing everyones private data should be monitored and classified trustworthy       

Some links:

SAS(R) 9.3 Intelligence Platform: Security Administration Guide Summary for Single Sign-On
SAS(R) 9.3 Intelligence Platform: Security Administration Guide (web authentication) no intheritance to SAS-servers

SAS(R) 9.3 Intelligence Platform: Security Administration Guide How to Configure Integrated Windows Authentication

SAS(R) 9.3 Intelligence Platform: Security Administration Guide Integrated Windows Authentication

---->-- ja karman --<-----
Slash
Quartz | Level 8

Thanks! I really need to read these documents! If I have problems, I ask you.Smiley Wink

kkhelif
Obsidian | Level 7

Make sure your Kerberos is working properly first in order to get the rest of the document working. First half of single sign on is the Kerberos and the keytab section. The rest is pretty straight forward.
Good luck.

Unkie_SAS
SAS Employee

SSO for Enterprise Miner in SAS 9.3 is not supported, regardless of whether you are using Java WebStart (as described) or a locally installed Java client.

Basically this is because Enterprise Miner does not connect through SAS Logon Manager within the mid-tier which is the element that would normally be configured for Trusted Web Authentication such as Web Report Studio and Portal.

But is possible now with 9.4

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 4 replies
  • 1960 views
  • 0 likes
  • 4 in conversation