Identity Automation & CUES Project: Feedback Submission
We welcome your questions, comments, and suggestions regarding the Identity Automation & CUES Project. Your feedback is essential for us to improve and ensure the project effectively meets your needs. Please use this form to share your thoughts. Thank you for your valuable input!
CUES: Questions/Comments/Suggestions
What is RapidIdentity?
RapidIdentity is an identity and access management (IAM) platform designed to streamline user management, enhance security, and improve operational efficiency. It helps organizations manage user identities, automate access provisioning, and integrate with various systems and applications.
Accessibility
The student login options presented for young non-readers included scanning a QR code or selecting an image. Are there alternative login methods that would be more accessible for young learners who are blind or visually impaired?"
We recommend using a simple password, such as one containing only numbers. Pictographs are accessible and can be read by screen readers.
Administration
Will there be a dashboard to enter data and push it in Munis and/or IC?
In many instances, we push data back into Munis and IC, specifically email addresses. We haven't reached that part of the project yet, but it is not unthinkable for this to be fully automated.
Will there be an SSO to replace Clever?
We do have an SSO Portal that can replace Clever. The process of rolling that out is still being finalized. Integration with Clever is an anticipated deliverable.
Data Normalization
Adult User Questions
Looking at when staff is offboarded, are we looking at and active / inactive field to auto disable account from Munis verses end date? End Date may cause last check to not be processed? (conversation with another district).
This is being evaluated right now and will be sent out for validation this week.
How do Active Status work with Hire Date and Termination Date?
Users who have an active employment status and whose hire date is within a configurable number of days before today or earlier and whose termination date is in the future are considered active. If Termination Date is filled in, once it has hit, the user will be disabled in Rapid Identity.
If Termination Date has not been used in the past for all people that are not active in Munis, will a termination date have to be entered?
If their employment status is inactive, then no
Is there any way to prevent an active user from being provisioned? There are times that a payroll process requires employees to be activated, but they really are not working for the district?
Researching (will provide answer shortly)
Will staff user accounts in IC be synced with the accounts coming from Munis in any way? Currently, staff accounts SSO to Microsoft. Will Rapid ID be a new SSO source? If so, how will staff users in IC be changed to the new SSO(district use the user batch tool in IC ourselves or will this be done for us)?
The current plan is to sync adults in IC with MUNIS data. Also in Phase I the plan is to point O365, Google, IC and MUNIS to Rapid Identity for SSO. The team will work to assist districts and streamline as much as possible
Is there any expected timeframe for provisioning to occur once the required fields exist in Munis?
The day that the user meets requirements for account creation, they will be created along with their accounts in target systems. The frequency of evaluating Munis is currently expected to be every hour, but tuning may change that.
Is there any expected timeframe for provisioning to occur once the required fields exist in Munis?
The day the user meets the requirements for account creation, they will be created along with their accounts in target systems. The frequency of evaluating Munis is currently expected to be every hour, but tuning may change that.
Can other fields in Munis be pulled from to populate information about staff users (ie. Location Address, City, State, Zip)
We will evaluate requests and suggestions for additional data
What fields in Microsoft, Google, Clever will the required fields from Munis and IC be populated to from RapidIdentity?
This is outlined in the Solutions Document. If there is need for more description we can work to define it deeper
If Location Names differ in Munis and IC, but the location code is the same, will this be something that needs to be cleaned up in both systems?
RapidIdentity will pull location code from MUNIS and IC, and only pull the location name if it exists for display purposes
Districts currently populate additional fields and use those for dynamic group assignments and other security or distribution group uses. Will there be a way to have those also populated by RapidIdentity?
There can be multiple ways to accomplish this. Depends on the use case.
What is the process when a name change occurs? Is new email automatically created? Will old address still be available. Will more manual processes have to occur?
When a name change occurs Rapid Identity will determine an new email address, overwrite the Primary Email in both Google and O365 and make the 'old' email a secondary email. It will also write back to MUNIS/IC with the new email in both the mail fields respectively as well as a new username.
How would we handle staff accounts with email addresses if they would like a nickname instead of their legal name? For example, a staff member whose legal name is Joshua Smith would like to be called Josh. How will email address generation work?
In MUNIS, if we use the Employee Status of B-Benefits Only, for our folks on unpaid leave, they have no term/inactive date, I want to be sure their account will not be inactive with that status?
Will need to investigate.
Fired employee. if we fire someone and want them out NOW. but still need to pay, so end date may be a thing
Administrators in CUES can immediately disable user access.
I saw it was required to mark each staff member as inactive and terminated. Is that correct? Also, what about past staff members that don’t have a termination date (Past Finance may have not done this), but are marked inactive do we need to go back and put those dates in?
No, you will not have to go back in and add those dates. Users with an inactive employment status will not be made active in CUES
We have a staff member or two that goes by their maiden name in AD, Google, IC, but Munis has their married name. Will their email and all other areas of documentation need to be updated to the married name, or will there be a way that they can continue to use the maiden name for their email and such?
Email addresses and usernames that currently exist will be maintained. Moving forward, the Last Name field in MUNIS will be used as the second half of the prefix (and username).
When someone leaves the district through retirement, termination, resignation, etc. will we delete them from MUNIS, IC and from AD?
People will not be deleted from MUNIS and IC. AD accounts will be disabled and then deleted after a configurable number of days
Clarity: To ensure that the current staff member links between Munis, IC, and other platforms, do we need to ensure that the Munis field for email needs to be entered and the phone number is a cell number for MFA? I have checked the employeeID and matched them but I was also wanting to make sure that this data item is aligned as well.
We will use all available data to link accounts to the appropriate person information in CUES.
Student User Questions
Many districts do not have IC configured to automatically create user accounts for students as soon as the person is created in the system and a schedule assigned. Will KDE have a defined method for doing this? How specific will that be?
The student must have a 'user account' created for RapidIdentity to provision. We can create instructions on this process.
The process of automatically creating student accounts will have to happen prior to the email address being created and written back to the Census Contact Email field. The document says that Rapid ID will convert the user to SSO. All of my users currently use email address as the username and point to Microsoft for SSO. Will this conversion process replace that automatically created userid with the email address or would a second user account be created for each student?
Researching how we can assist with student 'user account' creation.
Also, will the SSO source be RapidID or still point to the source we currently have configured? If the SSO now points to RapidID, will the district setup that source?
Yes, the plan is during Phase I to have RapidIdentity be the IdP for O365, Google, IC and MUNIS.
Will all existing student accounts be switched to the new SSO source automatically, or will the district be tasked to run the user batch tool to convert those user accounts?
The current plan is to sync adults in IC with MUNIS data. Also in Phase I the plan is to point O365, Google, IC and MUNIS to Rapid Identity for SSO. The team will work to assist districts and streamline as much as possible.
What is the timeframe for when student account would be provisioned once required fields are populated?
The day that the user meets requirements for account creation, they will be created along with their accounts in target systems. The frequency of evaluating IC is currently expected to be every hour, but tuning may change that.
What fields in Microsoft, Google, Clever be populated by the data in RapidID for students. I expect this to be different from adult users.
This is outlined in the Solutions Document. If there is need for more description we can work to define it deeper.
The student's legal name is Samantha, but she would like to be called Steven. Parents call to have this information updated. How would this be handled in RapidIdentity?
Preferred names can be handled; we will work with KDE to discuss per-district configuration on preferred name handling. (We’ll revisit your questions as things progress to offer a more comprehensive answer).
Will it be possible for student accounts to be created BEFORE their 1st day of instruction?
Yes. When the student is created with a user account and enrolled in the current year, they will be provisioned at that time.
Students must have "active enrollment in the active year" - I am just confirming that students WILL have access to their accounts in the summer, even though technically there is no "active enrollment" during that time.
Thanks for the scenario. We will accommodate this and will work with each district on perferred way to handle.
Several places in the Normalization Guide and FAQ specifically mention AD, especially questions about synching data fields. None of our students and approximately 30 of our staff have accounts in AD. We only maintain accounts in Google. Is this going to affect our adoption of CUES?
No.
When students are initially entered into IC in a district, will the IC2AD (Charlie Box) be needed anymore?
All known functionality of Charlie Box will be replaced, there may be some unknown uses.
General Data Normalization Questions
Districts currently populate additional fields and use those for dynamic group assignments and other security or distribution group uses. Will there be a way to have those also populated by RapidIdentity?
There can be multiple ways to accomplish this. Depends on the use case.
What is the process when a name change occurs? Is new email automatically created? Will old address still be available. Will more manual processes have to occur?
When a name change occurs RapidIdentity will determine an new email address, overwrite the Primary Email in both Google and O365 and make the 'old' email a secondary email. It will also write back to MUNIS/IC with the new email in both the mail fields respectively as well as a new username.
Employee Number must match both IC and Munis
For existing staff in both MUNIS and IC, the Employee Number assigned in MUNIS must exist in Infinity Campus for that staff member. If that is not present today we can match off of the email address if it exists in both systems for the user and is unique.
Does the cell phone number need to have for Type Cell-Cell or since we use Home-Home for type will this work?
If cell phone is desired to be used for either claiming the account or as an MFA option it must be entered as type 'C' or 'CELL'. Rapid Identity will ignore any other type including 'HOME'.
Finally, email addresses much match, but there was alt email (Personal) will this need filled out to link existing users to their current email accounts or is this for just creating new accounts. I know that there are several personal accounts in the system already - Alt Email (personal) can be used for account claiming of the RapidIdentity account and setting the initial password.
Email address can be used to link existing users between IC, MUNIS and AD. If personal email address is present it can be used for claiming or as an MFA option.
I see on page 4 of the readiness guide at the bottom it gives two options for mapping, it states that employee # from IC and Munis respectivieyly should be populated in the employeeID field for each user in Active Directory. Does this mean we need to put the #s in AD for each user or will it map it for us? Also what about Google?
For existing users, as part of the normalization process, EmployeeID in AD should contain the emplyee number from MUNIS or the student identifier respectively. Moving forward Rapid Identity will write this in AD from the sources. Alternatively if this isn't filled in we can user email address if it exists in all three (AD, MUNIS, IC).
Option 2 states emails much match? Just want to make sure for staff.
Answer above
Can identities be customized? Will districts have any customizable fields? Example: Google Districts can only use FirstName LastName OR LastName, FirstName - Cannot use LastName, FirstName – District or Title Script to append last name – i.e., Woods (Technology Dept)
Some things can be customized on a district level, and some things will be set as standard across all districts. We do not have a list of those things yet, and we will utilize feedback from districts to help with those decisions.
I assume a name change will create aliases within Google and or Microsoft, so They can get emails sent to their previous address
Yes, the ‘old’ email will be created as a secondary proxy email.
We currently use Clever, and it pulls data from IC. Will Clever now pull data directly from RapidIdentity?
No. CUES will not be involved in rostering to/from Clever, as that process is well-defined and implemented across the state.
How should contracted employees be handled? Would they be added to Munis?
The plan is to have non-paid adults who require an identity be entered into MUNIS. We will determine the process and document it in the operations guide.
How are Acceptable Use Policies handled? Currently, with IC, we have a process that looks to see if it has been completed before a script enables the account. For Staff we assume that has been completed during onboarding.
There is a potential process to have an AUP to be signed off on as part of the authentication process.
How does the system deal with name changes (marriage, divorce, adoption, etc)?
This will be documented in the operations guide.
Can the Inactive field be used interchangeably with the Terminated field in Munis for account offloading?
‘Inactive’ will result in a disabled account in CUES.
We have two bus garages, so have created a 901L and 901M to identify each location. Will that create any issues since it is a slight variation from the KDE location code for 901 Bus Garage?
We will truncate the location code to the first 3 numeric numbers. In this case ‘901’ for both.
We provide quite a few accounts for student teachers; how would we handle that?
If they are paid employees, they will be handled the same as any staff. If they are not paid, we will have a process to create their identity as well from MUNIS
What data field determines which OU the account gets placed into? I'm asking about Google, but I'm sure AD districts would also like to know.
Placement Policies will allow for any consistent values in the IdAs can be used to determine OU placement. We will work with each district if this is a desire beyond the top-level ‘Staff’ and ‘Student’ OUs
Will "preferred" name in MUNIS also allow for preferred last name? The example provided related to a preferred first name, but we have multiple staff members whose legal last name is hyphenated but they prefer to use only one of the last names.
There is not ‘preferred’ last name available in MUNIS at this time.
In MUNIS, CELL is not listed as an option when adding a phone number. HOME is my only option. How do I fix that?
There is a screen where phone number ‘types’ can be created, then will show in the drop-down.
How would this work with dual enrollment students who have a home school outside of the district where they attend classes? Where it is using the state ID would it create two instances? Make a mess of things?
If a student is entered in your district’s Infinite Campus and ‘enrolled’ in the current active year, the system will create an identity for them with ..@stu.yourdistrict email.
What should we do if we have an unpaid Volunteer Coach or someone without an Infinite Campus account? Additionally, how should we handle a maintenance account in similar situations?
We are determining with our finance office in KDE what mechanism we can use to allow for unpaid adults in MUNIS.
When HR initially inputs folks into Munis. Should they leave the primary email address field blank and allow Identity Automation to write the email address?
Yes. CUES will determine and write it back.
Is there anything special that needs to happen for student workers that are paid through MUNIS?
We will test this, but the initial thought is to put the student email address (..@stu...) in the contact email field in MUNIS. We would not want to create a staff identity for them. We may reach out to you for clarification.
In the CUES Readiness Guide Slide Deck, you mention "Additional IdAs" as potential systems that could send data to the CUES Provisioning system. Can you please explain what "IdAs" stands for and give an example?
Identity Authorities (IdA). The system deemed authoritative for each user type (MUNIS for Staff, IC for Student, etc)
I was reviewing the FAQs and saw this question: "Can we choose to stay with Clever for app management? And keep Clever badges?" and read the answer to the question which stated that authentication will be handed through RI then you can access Clever. So my question is will the user first log into RI with a QR or badge (Example) and then have to use a clever login or will it be streamlined. Reason for the question is if RI can do the same thing as clever then why have two different sources to get students into a product.
Technically, Clever can point to CUES for SSO/login and the user will be able to access all 'Clever' apps.
Question on clean up: I've been cleaning up AD and noticed that some account accounts were created in the clould that are not on Prem. Also, I noticed some Munis and State accounts in the system. Will cues push to our local on Prem AD servers or to the cloud. And who do we need to contact about the Munis and State accounts to ensure they are good.
CUES will provision to Active Directory, and the AADCs will stay in place to then provision from AD to O365 (Entra ID). We will revisit this as the AD Deprecation project will look to retire AD
For MFA: In munis I see Home by phone number for staff, I didn't see Cell or C as an option. We will be wanting to use MFA by phones for staff. The question is do we need to create a drop down option with C or Cell as another option for Home?
There is a screen where phone number ‘types’ can be created, then will show in the drop down
For users who currently exist, does the user email munis need to be the same as the contact email in Infinite Campus?
The 'Email' field in MUNIS, the 'Contact Email' field in IC and the primary email address in AD will be used to match users who exist today.
When an account becomes inactive, it writes to AD or Google that the account is disabled I believe, how long will that account stay in those 3rd party devices. Or will termination delete them in a timely manager.
When a user is marked inactive CUES will disable the account in the 3rd party systems as well as disable the identity in CUES. We will work with each district to determine when to delete the accounts in the relying parties
I see that for AD we need to use employee ID for connection, what about Google accounts will that also be employee ID field. I have matched it in both AD and Google but are their others that need to be done to ensure that they connect?
We will work with each district to ensure the appropriate accounts are attached to the appropriate identities. Your efforts will greatly assist! Also you can utilizie email address instead of employee ID if desired.
On Tyler EERP data normalization, are there any data entry standards? For example, the Enrollment data standard for Campus says to not use punctuation, hyphens, etc. In addition to punctuation, are there standards for proper-, upper- or lower-case entry? If there is not, since most data in EERP is entered in uppercase, will the data flow as displayed in EERP, or will there be a conversion to a selected case? What about names that have camel case such as McDowell?
Discrete attribute handling will be published shortly.
Page 2 of the "CUES Normalization/Readiness Guide and Activities - v1.0" displays a CUES High Level Overview graphic and the bottom of that graphic shows "Students", "Teachers", and "Staff" each as individual boxes with data flowing from them to RI. These boxes are unique to one another as there is a Chrome icon in the Student box, Chrome and Windows icons in the Teachers box, and Apple and Windows icons in the Staff box. As these icons appear to be very intentionally placed, can you provide some additional explanation.
This was meant to be a simple graphic showing common ways users interact with the system.
Do we need to work on populating the preferred name in Munis for existing users that have a non-standard email address or is this only for new users moving forward after project completion?
Email addresses and usernames that currently exist will be maintained. Moving forward, the Last Name field in MUNIS will be used as the second half of the prefix (and username).
Is there a limit on the length of an email address that CUES can create for an individual? Our longest name currently, including the period in-between the first/last name is 35 characters. It could be longer in the future.
There are technical limitations to email address in the relying systems we will have to adhere to, but 35 characters will not be an issue.
If we do not enter a cell phone number for staff in Munis, will there be other MFA options?
Yes
Device Authentication
From the regional meeting: Melissa mentioned during a call that JAMF will be used for MacOS devices. What does this look like? Is there a MacOS agent, or will JAMF need to set the password on the MacOS device for the user?
We have an integration with JAMF. If you have JAMF, we will just need to set up the connectors, and then the RapidIdentity screen will be used to login to the Mac
Enablement/Support
I notice on linked in IA has 90 employees. Only 13% work in support. This comes out to be 11 full-time techs. How will IA be able to support districts with onboarding during the process with such a small quantity of support? Will we be able to utilize their support or will we rely on the KETS help desk?
IA’s enablement team will work closely with district stakeholders to ensure a smooth transition, offering guidance, resources, and training to address any challenges. We aim to empower the district with the knowledge and tools necessary for successful adoption and long-term sustainability. We will remain available for ongoing assistance, helping to troubleshoot issues, optimize processes, and ensure the implementation meets the district's needs and objectives before transitioning the district to support and customer success.
GO! View Portal
Can we make apps available in the IdentityPortal by school or even specific student groups within a school (e.g., by specific course/section, EL students/staff only, 3rd grade only)? Many of our apps are purchased by a handful of schools or even a small number of licenses within a school instead of district-wide.
Yes, they can be filtered down to user attributes, including grade levels and schools, as long as we are consuming the data from IC.
Offboarding
Will there be an option for email accounts to be available past their last employment/enrollment date? For example, 30 days for staff and 120 days for seniors.
Depending on the design and implementation of the state and district tenant. There will be an option.
For accounts that have an end date, when would these accounts be deleted versus inactivated?
We expect some sort of per-district configuration around a disable for x period of days then delete if not reactivated.
Onboarding
How fast will password sync occur when user makes the change in Rapid Identity?
The initial sync will be within minutes; some systems, such as AD, will have an additional internal replication delay.
Operational
What does RapidIdentity look like?
The current plan is to have an “all-day” strand at the KySTE Fall event specific to CUES with Identity Automation in attendance. While the agenda is not finalized yet, the intent would be to conduct a full demonstration of product features, architecture, and integration (sandbox).
Examples:
Login Screens:
Applications Go! View:
Does RapidIdentity have a LaunchPad like ClassLink LaunchPad or Clever Portal?
Yes, RapidIdentity does have a portal. The RapidIdentity portal is designed to give users a centralized location to manage their identities and access various applications. It typically provides features like:
Single Sign-On (SSO): Users can log in once and access multiple applications without needing to re-enter credentials.
User Management: Admins can manage user accounts, permissions, and roles from within the portal.
Self-Service: Users can perform tasks like password resets, profile updates, and account management.
The portal's design and functionality can vary depending on the implementation and the specific needs of the organization using RapidIdentity.
Does RapidIdentity have a rostering solution like ClassLink rostering?
RapidIdentity Studio Rostering is a component within the RapidIdentity suite designed to manage and automate educational institutions' rostering processes.
RapidIdentity Studio Rostering provides a streamlined solution for managing student and staff data, automating the creation and maintenance of user accounts, and ensuring that rosters are accurately synchronized across various educational applications and systems.
Key Features:
Automated Data Synchronization:
Syncs user data, including student and staff information, across multiple systems and applications, reducing manual data entry and errors.
Integration with SIS:
Integrates with Student Information Systems (SIS) to automatically import and update rosters based on the latest enrollment data.
Role and Group Management:
Automatically assigns roles, permissions, and groups based on predefined rules or data from SIS, ensuring that users have appropriate access to applications and resources.
Data Import and Export:
Supports importing and exporting data in various formats, making it easier to integrate with other systems or perform data migrations.
Customizable Roster Management:
Provides tools for customizing roster data and managing exceptions, allowing for flexible handling of unique cases or specific institutional needs.
How fast will provisioning occur once someone has been put into the "source of truth? How often will provisioning occur? Every 15 minutes? Every hour? Once a day?
Target systems can be implemented as soon as they're created in RI based on the schedule we set. The schedule can be set as frequently as needed, depending on how the state and district are implemented.
If RapidIdentity is the IDP, will we be able to customize the fields we need filled? We know we can do this with Infinite Campus.
RapidIdentity is a fully customizable IDP that allows for various attributes to be sent for each application.
One of the big jobs we have to do early in each school year is updating the pictures of students in IC and other applications like our LMS. Will there be a way to connect CUES to school picture companies like Lifetouch to automate picture updates?
There are possibilities, but this would be a per-district implementation outside of the scope of phase 1.
How does this work with Entra?
RapidIdentity will federate and become the IDP for Entra from a sign-on perspective. RapidIdentity is not an Entra replacement; it is an enhancement. There may be some pieces of functionality that move from Entra to RI.
Can we choose to stay with Clever for app management? And keep Clever badges?
You can still use Clever as usual, but your authentication will be handled through us. Instead of logging in directly through Clever, you'll first log in with a QR code and badge to access RI. Then, you'll be able to access Clever.
Password Management
Since a self-service password reset is part of the product, is there an option to send password expiration emails to users if their password is within x days of expiration?
An authentication policy can be crafted to warn users that their RI passwords will expire in X days.
What platforms is the passwordless student login compatible with? I'm thinking about a student putting their email on a smartphone.
Identity Automation supports WebAuthN standards. WebAuthn, or Web Authentication, is an open standard that enables secure, passwordless authentication on the web. Here is more info on WebAuthN - https://webauthn.guide/
Readiness
What things do I need to do to start preparing for this project?
More details will be provided soon, but data cleanup will definitely need to be addressed, especially concerning staff. Where are your staff accounts located? Are they in Munis, IC, or both? Do you have old, inactive accounts that need to be cleaned up?
Service Accounts
How should "service accounts" be handled? Are these accounts sponsored (without an expiration or with)? Or should we use Azure/Google/AD to create accounts and manage them outside of RI?
Service accounts are not in Phase 1 scope.
We have many service accounts for various technology processes. FAQ says these won't be handled in "Phase 1". Will there be a way to maintain these accounts?
Individual service accounts (also known as privileged accounts) used for administration of targeted systems are to remain contained within each respective system. (additional information forthcoming....)
Sponsorship
How will RI impact vendor VPN access? Will we leverage sponsored account with VPN group access?
This specific use case would have to be investigated.
Does Rapid Identity have a way to connect to an NAC (network access control - IE Extreme NAC / rgNET / Fortinet NAC ) for identity? This would be used for Guest registration for personal devices but allow the Lightspeed content filter to properly identify the end-user.
This would not be in the scope of Phase 1, but it could be investigated on a district basis.
How about Homeschool students that want to attend an ATC site? These students may or may not be listed in IC.
Homeschool students will need to be designed for.
How does this affect accounts for users that are not listed in Munis since they are not paid?
Adults who traditionally have not been in Munis but need some level of access will either have to be input into Munis or have a sponsored account created for them.
Unique Student Use Cases
I currently have an issue where 15 or so of my students who are enrolled in my SIS are part of an educational academy in another district. This requires them to have that district’s email domain. Currently, I have a script that I run nightly that will overwrite the email addresses for those students so they are able to access everything they need in the academy. Are there any processes currently in place to handle this type of situation, or is this something I will need to continue to manage as I currently am?
This is a use case that will need some clarification and investigation.
How to handle Homeschool students who are going to the Area Technology Center. Some homeschooled students are inactive in IC, and some are not.
This is a use case that will need some clarification and investigation.
We auto-provision student accounts. We have a library of passwords that is age based for complexity level. Once the password is assigned to a user it cannot be assigned to another user. The district maintains a database of student passwords to distribute to students, to troubleshoot issues a student may be experiencing as well as investigate student use. We do not allow students to change their password. Does Rapid Identity have a similar capability?
This specific use case would have to be investigated.