Cloud Computing and Identity Management - Live@edu

By far, one of the biggest and most talked about trends over the past few years has been the shift to cloud computing and the proliferation of SaaS across almost all vertical industries. Although, there is still much debate centering around security and how to best manage these new systems, it is apparent that most organizations are still eagerly moving forward to the cloud. 

Some of the biggest shifts and perhaps least surprising, have been the move to hosted email and storage solutions from Google Apps and Microsoft Live@edu and Outlook Live, especially in the education and government sectors.  The cost benefits here seem to be the driving factor in these markets and with good reason. However, this makes it much more imperative that these organizations employ measures to better manage user identity and data security to prevent unnecessary risks and a loss of functionality to their users. It makes sense then that these clients either leverage their existing provisioning solutions or employ a new process as part of their implementation.

A good number of these organizations have approached Tools4Ever in order to incorporate their Live@edu connector as part of the rollout of this hosted solution. A major component of these implementations is the use of Live@EDU Dynamic Distribution Groups (“DDGs”) which can be very powerful because they allow you to have large mailing lists without the need to maintain individual memberships.

As consultant Ivan Jouikov noted though, traditionally, if you wanted to maintain large mailing lists per-school, you would simply set up a group like BlackHawk@mydistrict.com, and then add all the students’ emails into that group.  You would also have to maintain that membership list, as students change the schools or graduate.

DDGs use filters to determine their members, rather than maintaining an actual membership list.  When an email is sent to a DDG, it finds its members by running a search like “all users whose Live@EDU Department is set to BlackHawk”.  This lets you maintain many various DDGs, without having to manage their membership lists.

However, what if the student changes their school?  Unless their Live@EDU Department is set to the new school, they will keep receiving mail from the old DDG, but not the new one.  This means that to truly leverage the power of DDGs, you need to constantly keep the “Department” attribute updated for all of the student accounts. These and other changes do occur, and this can create an overhead nightmare keeping updates in check and data consistent.

That’s where UMRA comes in and something the solution has been doing for some time now  -  provisioning accounts and their attributes.  In case of schools, we would constantly provision students’ Live@EDU Departments (from SIS data) to fully leverage DDGs.

This way you can have mailing lists like:

-          Per-school

-          Per-grade

-          Per-class

-          Per-any-SIS-attribute

-          Per-School & Per-Grade

-          Any combination of the above

-          …all with memberships maintained automatically

Take it one step further –with UMRA we can provision the DDGs themselves! This means we can set up something like class-driven DDGs that get created and deleted automatically, as classes are created and removed in the SIS. 

DDGs are a “hidden” feature of Live@EDU – they don’t appear on the administrator GUI (though they will show up in GAL (global address book), if that’s what we want).

A process as simple as this can really help you make the most of your Live@edu solution and greatly simplify the management of users and groups in this system.  I will be posting much more information regarding to Live@edu and Google Apps, so please follow this blog for future information.

New Account Request - Parent Accounts Becoming the Norm?

Though, I have not yet posted many entries, I do have a goal with this blog to highlight unique cases of identity management issues and the solutions chosen to solve these often complex problems.  The project write-up below was prepared by Dean Wiech from Tools4ever New York as he managed this “outside the box” identity management implementation.

One of the top 10 school districts in the State of Florida, and top 25 in the country, had an Identity Management issue that did not involve students or faculty/ staff but rather the parents. Legislation had been passed that required any parent wanting access to their child's on line learning environment present themselves in person with identification and request an account. With over 125 physical locations and 500 + users that would be handling the process, a paper system was out of the question.

The solution that was settled on was a combination of standard Tools4ever products and just a little bit of custom web work.

Tools4ever worked very closely with the technical staff of the district to insure the requirements were very detailed to avoid any missed components. In the end, a solution was delivered utilizing User Management Resource Administrator (UMRA ), in about 30 hours of consulting that fully met their needs.

Here is a brief overview of the solution:

•  A parent shows up at a school and requests an account to access their child(s) information.

• A secretary or administrator verifies their ID and enters relevant information into a web page including:

-Name

-ID type, number and expiration date

-Phone Number(s)

-Address

-E-mail

• The secretary then searches for the student(s) using name or student ID criteria and verifies with the parent the correct name is displayed.

• The individual then hits a “Create Parent Record” and, if no duplicate entries are found, the record is created in Active Directory and the student information system and a link between the parent and child is created.
  
  
• A temporary password is returned and the secretary records the information, along with the user name, and delivers it to the parent. 

As part of the project, Self Service Reset Password Manager (SSRPM ) was also deployed for the parents to allow them to enroll and reset their passwords via challenge questions and avoid an unnecessary burden on the help desk staff.

Additional web forms were delivered to allow administrative staff to reset passwords for parent’s accounts, check their SSRPM enrollment status, to run last logon reports, disable accounts, update accounts and SSRPM enrollment reporting.

Since deploying the system, over 100,000 parents have been successfully enrolled and can access their child’s records with ease. Paperwork that had previously utilized for the process has been eliminated and, through SSRPM, the additional burden on the help desk has been non-existent.

To learn more about Tools4ever solutions, please visit our website,
Tools4ever, Inc.

A flying start with Role Based Access Control (RBAC)

RBAC or Role Based Access Control is still an increasingly popular topic! Quite frequently, organizations I meet still stress the importance of finding a structured way to manage and grant authorizations across their network. Often, I run into situations where the organization is simply doling out authorizations, based on a copy of a colleague who has a "similar" job function. This will result in many new employees gaining access to systems and applications that they simply should not or do not need. Often then, little attention is paid to the removal of authorization access after copying a user which can greatly increase risks in information security and licensing fees.

Establishing an RBAC model is one possible way to solve this problem. RBAC should consist of a matrix of roles, functions and specific access rights. For example, when a new employee joins the organization, the RBAC matrix will determines what the new employee will be allowed to do in the network. That's the theory, though, in practice it appears populating such a matrix can be problematic. Clients are always telling me that within their organizations, there are so many special cases that it ends up seeming as if there are as many roles as there are employees. With this resulting in an infinite and unworkable matrix, it's no wonder so many companies have been afraid to implement RBAC. On the other hand, many organizations jump right in striving to get 100 percent of the employees in the RBAC matrix and fail. I feel, that in most cases, this is improbable and may require years of both management’s and the Security Officer’s time to implement.

Want a quick start with RBAC? It is quite feasible if you do not target 100 percent in the first instance. Based on information from the HR system, it is possible to explore the 50 most common combinations of departments and functions within the organization. This allows the completion of up to 80 percent of the RBAC matrix almost immediately. Then, a workflow application can be used to fill using the remaining 20 percent - manually entered by the manager of an employee.

It may still be a while before the RBAC matrix is completed 100 percent, but by leveraging existing systems and sources - such as the HR system - and the focus of the manager - the population of the RBAC matrix can be a manageable process with direct results. The result is a positive ROI with respect to the feasibility of RBAC and the amount of effort required to enforce positive IT auditing standards. An indirect benefit is often a reduction of licensing costs, storage requirements and security incidents. More information available at http://www.tools4ever.com/solutions/RBAC/