topic Re: User self service interface in Administration and Deployment

User self service interface

cpare — Wed, 03 Jun 2015 21:14:05 GMT

In the past I supported a large Business Objects environment, we were able to eliminate the requests to create user accounts by providing users with a self-service portal that allowed them to create accounts and notify Super-Users for group (security) assignment, once implemented it reduced our turnaround time to get a user access from days to seconds! I would like to do something like this with SAS - Is there a Java SDK or Web Service we could leverage to automate user creation and group assignment?

Hoping someone can help, or even provide a community developed (open source) sample - thanks in advance!

Re: User self service interface

ronan — Thu, 04 Jun 2015 13:17:52 GMT

If you follow this link, you'll find a previous thread which dealt with this question somehow :

Some context : the internal security provider inside the SAS Metadata (MD) Server is called "@saspw" Authentication Domain. Logins with @saspw suffix have their corresponding passwords stored in the SAS metadata repository.

So that users with internal accounts authenticate 'against' the SAS MD Server.

https://support.sas.com/documentation/cdl/en/evug/67886/HTML/default/viewer.htm#n1hqkzr5rsoxgln114bntk81fpgx.htm#p1bhl79nwpfzj3n14ibklr66s6ja

SAS has taken a different approach than BO : user management identity & credentials are administrative tasks that usually only the Admin team

can perform; It's not user-centric, rather centralized management. To carry ou thes tasks, Admins rely on the SAS Management Console (SMC) User Plug-in

or also in the Web console named Environment Manager.I am not sure this will do with non-administrative users,

Managing User Access :: SAS(R) Environment Manager 2.4: User's Guide

Consequently, SAS doesn't provide out of the box a tool or a set of tools with a user friendly interface (Web) that fit your need, namely that can create/update/purge SAS user account along with their internal login password.

SAS provides the Open Metadata Interface (OMI) available as a JAVA API or XML/SAS language API and, depending on your offer Web capabilities to create the identy management tool (SAS Stored proces server etc.).

In the above-mentioned discussion, it seemed workable to create such a tool, namely to update @saspw passwords using sas code. I am still unsure if it is supported by SAS Institute so be careful

Other options to consider :

1) Reuse previously created user identity and automate synchronisation process between company Directory server (Active Directory, LDAP) and SAS MD

https://support.sas.com/documentation/cdl/en/bisecag/67045/HTML/default/p1ar98lajfgm4jn1wa1h6e19jjre.htm

http://www.metacoda.com/en/2015/05/metacoda-identity-synchronization/

2) create some user-centric web interface enabling the final user to enable her/his directory account in the SAS Metadata Server, using the LDAP interface provided by SAS :

https://support.sas.com/resources/papers/proceedings12/377-2012.pdf

Usually, the company Directory authentication provider (MS Active Directory for instance) comes with password mangement tool already set up so that

once the user (external = Active Directory in this example) login has been created in the SAS MD Server, the user can open the SAS session without having

to manage any extra password for SAS.

This kind of tool can be further extended to copy the user's attributes (1st name, email etc) stored in the company directory into SAS MD server

Personnaly, I would't recommend assigning the final user the privilege to authorize himself on the SAS Server using @SASPW accounts : too difficult to maintain.

But authorizing the user in the Company Directory with a specific group (Company\SASUSER etc.) and providing a simple web identity manager that can propagate this access into SAS looks like a good solution.

Re: User self service interface

jakarman — Thu, 04 Jun 2015 21:23:55 GMT

Your situation could be a public shared data access. Than there is no need for any creation of accounts. Use a shared generic one like "guest".

With that there is not need for creation of additional accounts. It will just add unnecessary complecity.

You are doing more serious work and the data-access does matter. Than you are into something that is called RBAC. Role-based access control - Wikipedia, the free encyclopedia

There are ICT systems to organize the RBAC process as those are often set as mandatory by regulators. A basic start is like http://csrc.nist.gov/groups/SNS/rbac/documents/design_implementation/Intro_role_based_access.htm Having those tools in place the technical roll-out of any account can be very quick. The problem is finding the correct accountable persons to approve the relevant requests. That is a necessary part not to be avoided.

As you can see technical focused guys are too often only focussed on the technical toy and forgetting business requirements.

What is you business requirement? Public classified data (guest) or having are more trusted setting as of a CIA rating applying some data-governance on that?

Re: User self service interface

cpare — Thu, 11 Jun 2015 14:08:48 GMT

The goal is to develop this web interface in JAVA preferably, the workflow would happen as follows:

User visits website, provides LDAP/ Active Directory ID to be added and selects the groups they would like to be members of.
Submits form <click>
Application authenticates to LDAP/Active Directory to verify ID exists, queries for attributes and adds attributes as needed.
Application authenticates to SAS and creates user, populating some information (Full Name, Email, Login ID) - this is a login with no security rights (pass-through authentication assumed).
Application sends email to administration team containing new user details with request for user group assignment (this is a security step to ensure users can't request data they are not authorized to access).
Application informs requestor of account creation success/failure, and informs them that security will be assigned shortly.

Sounds like we need to start to learn the Open Metadata Interface (OMI) - If anyone is interested in partnering on this let me know - I have all the source code from the Business Objects version, I expect much of it can be repurposed.

I didn't get a reply on a Web Service - does SAS have one that we could use for our interface?

Re: User self service interface

jakarman — Thu, 11 Jun 2015 19:11:49 GMT

Your description is a full fit to a common generic rbac process approach.

There are many suppliers offering that as it as far more than just SAS usage.

As I have often makes those notes SAS is not aligned to those more common processes. Still strange you did build something that should be covered as some enterprise service not a tool implementation.

Re: User self service interface

ronan — Fri, 12 Jun 2015 16:30:17 GMT

cpare wrote:

I didn't get a reply on a Web Service - does SAS have one that we could use for our interface?

Not exactly. That might depend on your SAS offer : if you have a SAS BI Server platform, for instance, then the Web interface you might use with SAS is called a SAS Stored Process. It's a Web J2EE application running inside the SAS Web Application Server (SAS embedded Tomcat) listening on the Web server . If you have a more limited product (eg SAS Office Analytics), then you'll have to use a third party web tool (Tomcat) for your interface

You could use a Web Service perhaps if you follow another path, more complicated (in my view, I am not a Java/Web developer). It would require developing a SAS stored process (SAS code executed server-side) published as a Web Service :

https://support.sas.com/documentation/cdl/en/wbsvcdg/64883/HTML/default/viewer.htm#titlepage.htm

To help you code your XML OMI request, there is a special feature hidden (since 9.2) inside the SAS Management Console, called the XML Metadata Interface. In order to enable this tool, follow the steps described in this paper :

page 18, §2. http://support.sas.com/resources/papers/proceedings12/009-2012.pdf

HTH

Re: User self service interface

jakarman — Fri, 12 Jun 2015 17:02:39 GMT

Any reason not to align to your in house rbac strategy.

That is a system - programmer question.

That role is different to an application programmer or a statistical programmer.

Re: User self service interface

cpare — Fri, 12 Jun 2015 19:02:46 GMT

This does align to the rbac strategy, we utilize Active Directory integration for our users, however a SAS profile still needs to exist in for native SAS group assignment, that profile creation is the part I want to automate (as well as a few steps external to SAS).

The javalib com.sas.services.user provides UserServiceInterface that will allow us to create the user profile - I am planning to load AppDev Studio today or Monday to see if I can create a basic SAS profile as a PoC.

createProfile

ProfileInterface createProfile(UserContextInterface user, java.lang.String application) throws ServiceException, java.rmi.RemoteException

Create a new profile. This will create the new repository entry, and return the ProfileInterface to the user.

Parameters:: user - The UserContextInterface of the user for whom the Profile is being created.; application - The application string for the new profile.
Returns:: The new ProfileInterface.
Throws:: ServiceException - in the event of a service failure.; java.rmi.RemoteException - in the event of network failure.

Re: User self service interface

cpare — Fri, 12 Jun 2015 19:05:00 GMT

@Ronan - I agree, after researching the REST options, it only allows users to call stored procedures, and I am not a SAS Coder. For me the faster/better option is to go the Java route until SAS matures the REST services to include administrative tasks.

Re: User self service interface

cpare — Fri, 12 Jun 2015 19:19:06 GMT

Off topic, but that Common login Interface is also on my list

The sample I have been tinkering with (yellow border has focus):

Re: User self service interface

jakarman — Fri, 12 Jun 2015 19:44:04 GMT

On topic is the appendix A of the security admin guide.

Assuming you have your rbac in place for ad or LDAP. LDAP preferable is you are using Unix types.

http://support.sas.com/documentation/cdl/en/bisecag/67045/HTML/default/viewer.htm#p0z36im6qsfk3ln1advg12dn5lls.htm

That is how user Synchronisation and authorization is solved with an associated act implementation on all the artifacts. You will need to understand Sas coding and the Sas infrastructure.

Re: User self service interface

ronan — Mon, 15 Jun 2015 13:15:15 GMT

Thanks, this looks nice, indeed.:smileycool:

You might be also interested with the HTML5 Data Adapter for SAS - h54s in short - (soon) provided at no cost (!!!) by Boemskats, talented people with great ideas :

https://boemskats.com/h54s/

https://boemskats.com/build-apps-with-sas/