The school decided to create a new campus network, Authentication & Billing, not on a white paper, but by creating a new system next to the old certification system that has been running for years. Whether or not to connect with existing platforms directly determines whether students should keep two sets of accounts, how to hold two backstages and how to reconcile the data. There is no standard answer to this matter, but there are several common pits that need to be avoided early.
We'll split it up first."Connect"and"Replace"It's a different thing.
A lot of needs come up and write them."Connect to existing unified identification platform"No one said clearly whether the new system would take over authentication or just synchronize a portion of account properties. If it was replaced, the old platform's account system would move in as a whole and historical and dirty data would be treated separately; if it was replaced, standard protocols would be used to synchronize the number and certification results. The most embarrassing thing we've seen is that the old platform actually only regulates staff, the new system will cover all students, and the result is that the permission model is being changed."Who's the Lord?"Set it down and not work again.
The account master data source must be unique
The core contradiction is who will be the number of the account. It is common practice to use a school-wide uniform identification or a system of study and engineering as a primary data source, with the new system receiving the number and status of the account in time and simultaneously, keeping only copies of the authentication and billing requirements locally."Double"——Both sides allow the password to be changed, and both account numbers are allowed to be disabled, with two data moving over time. The secure boundary is that master data is synchronized in one direction, new systems are only modified, students are back on the main platform for such changes in confidentiality, and sellers are returned to their home platforms.
The one who's matured in the authentication agreement.
In campus settings, authentication docking is often not bypassed by several standard protocols. Wire and cable access devices are mostly accepted as generic certification protocols, portal jump-through authentication is verified by redirectional matching interfaces, and the Uniform Identification General Guidelines are used to see what interfaces are open to each other."Advanced"The last set of small crowds. We suggest that we have a list of protocols from each network centre and manufacturer, cross-checking the points. The smaller the convergence, the higher the implementation risk.
The billing data is mixed with authentication in the same library.
Certification and billing are a system, but the nature of the data is different."Who are you and if you can get online now?"- Pay attention."How much did you use, how much should I take?". The billing component is usually built on the new system if old platforms are only certified when docked, so that the cost results are not rewritten back to old platforms and can be co-ordinated. The cleaner method is to charge the domain independently and take it from authentication domains only"Time online, traffic, terminal"These facts that have occurred are translated in accordance with the school rules and the original accreditation log remains available for verification.
Synchronization failure requires a back-up, and students cannot be turned off.
Any connection to the web synchronization is supposed to break. The main platform maintenance, interface timeout, field changes will leave the new system without a current account number. The docking design must state whether the new system continues to be released or entered in restricted mode when the sync breaks. We are biased."Releases during cache and limits the duration of overstay"The policy is to write the acceptance, not by implementing it.
The standard for the calibration is to be able to get through.
A lot of projects."The interface's up."As a match, students use the new account to log in before they start running their speed limit. The real completion sign is: a test account from the main platform, to the student terminal online connection, billing, and time-limits, with the entire link passing through the testing environment at least once. The campus network Authentication & Billing docks existing platforms, which are not so beautiful as to be able to access interface files, while the student side senses smoothness and the lift of the dimensions is only one round.
Interface document requires both parties to sign confirmation version
The most scary thing about the hooking."Saying yes, falling on the ground is not right.". Before the formal interface is completed, both sides of the new and old are to write an interface field, protocol version, and anomaly code as a mutually confirmed document, which is attached to the acceptance. The old field is not available, the new value system is not recognized, it is reded in advance, rather than misreported at the time of implementation. This document is also a description from the later-time transporter when he takes over, and is far more valuable than the days that the link is made.
The match also has to be gray. Don't cut it all at once.
Even if you read a synchronised interface, it is recommended to take a campus or grade run first and see whether the account sync is timely, certified smooth and billed. The old platform remains available during the greyscale, and problems are immediately returned to the old path. The campus network Authentication & Billing system and existing platforms are connected, with steady word-pointing, and grayness is the most responsible approach for both parties.