10-31-2014 07:38 AM
I implemented SSO for our IDP Portal and of course the IWA works great and logs you in automatically based on your windows credentials. Prior to this implementation we had local SAS account with certain privileges for adding content to the BI Dahsboards and reports, now we can't get the login screen anymore. Is there a back door to get the login screen so the local admin accounts to SAS can login and still have SSO implemented in our environment.
One option is to give the Domain account all the credentials the local SAS account has but we really don't want to do that.
Hope that makes sense.
11-01-2014 05:46 AM
With SSO you should have a RBAC process in place. Do you have that RBAC process?
Segregation on high priviledged accounts, multiple accounts per user (admin) but not having shared accounts.
Each organizational roles/functions to be translated into some technical authorization steps.
It is seeming to me you started at the other end. Beginning with some technical tricks (SSO) and than trying to go for the RBAC process.
Being confronted with the mismatches on your way.
11-04-2014 03:49 PM
for Rbac: Role-based access control - Wikipedia, the free encyclopedia this is better to follow http://csrc.nist.gov/rbac/sandhu-ferraiolo-kuhn-00.pdf InfoSec (rbac)
You find in ISO/IEC 27002 code of practice as being part of isms (Information Security Management Systems)
-----------to be cited:---------
Management should define a set of policies to clarify their direction of, and support for, information security. At the top level, there should be an overall “information security policy” as specified in ISO/IEC 27001 section 5.2.
The organization should lay out the roles and responsibilities for information security, and allocate them to individuals. Where relevant, duties should be segregated across roles and individuals to avoid conflicts of interest and prevent inappropriate activities. There should be contacts with relevant external authorities (such as CERTs and special interest groups) on information security matters. Information security should be an integral part of the management of all types of project.
Starting to do this you can build some data model like: 1: <Keys> 2:<Groups> 3:<business applications> 4:<middleware/tool> with some n-m relationships.
The OS is not directly visible but can be defined when needed as some support (folders/files) as some tooling part.
All the other part of the OS are enablers for this process.
With the AD approach of Windows there is marvelous security implementation that is centralized. AD is an extended LDAP implementation. The technical approach in this is trying to integrate the behavior as one central service. You can also propagate passwords from a central service to all kind of managed servers/services. It is a different approach of getting password aligned, so it acts like SSO, These issues in all this are the privileged and service accounts (system usage) that should not into the same policies as common users.
11-07-2014 06:09 AM
I don't think we are on the same page here. I was talking about the login screen you get for the Information Delivery Portal instead of getting logged in automatically via the implementation of SSO.
11-07-2014 07:07 AM
Kkhelif, All starts with RBAC the logical process, business requirements. Than you go for the technical implementation. Starting at the technicals can look interesting but thos ways are leading to surprising questions. The SSO is part of authentication options
- SAS(R) 9.4 Intelligence Platform: Middle-Tier Administration Guide, Second Edition (Web Authentication change xml configs logon))
- SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition (How to Configure Web Authentication)
- SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition (Web Authentication)
Review the figures as architectural choices and what their consequences are.
While changing to SSO you did modify the login functionality, the impact and consequences you did a question on.
It was adviced to do that on forehand whether is an appropriate choice to do and with that what is coming with that.
11-07-2014 09:41 AM
good remark from Jaap, focused on the strategic implementation of IT. I think it answers your question, but it is not giving you the solution you were expecting, right?
Hereby a practical/tactical answer but it is advised don't forget the other comment :
As of the SSO is based on some (big list of) requirements, if any of those requirements fail, you will be redirected to the failback, if the failback it is implemented. Right?
2 workarounds that I can quickly think of right now:
- You can access with a web browser that is not supporting SSO-IWA-Kerberos (just go into the browser configuration and disable it).
- You can try to access from a different domain... if you can reach the server from a different domain, of course, normally only with a Reverse Proxy in front for security reasons.
By the way, those 2 are only workarounds, not solutions. And you need the fallback implementation!
11-19-2014 02:34 PM
It was as simple as changing the <SAS_CONFIG>\config\Lev1\Web\WebServer\conf\sas.conf and add a redirect / http://xxxxx.xxxxx.xxxx.xxx/SASPortal
Restart the web server.
Thanks to all that replied