_block.png)
Monday, August 8, 2016
Open browser. Go to BackOffice URL. Enter my username and password.
Username: Taivo
Password: ***************
Your account is locked. Please contact Tech Support to unlock your account.
Your password is expired. Please enter your current password and new password twice.
Your new password cannot contain your first name, last name.
Your new password needs to contain special characters.
Your new password needs to contain 10+ characters.
Your new password cannot be the same what you used previously within 10 passwords.
Finally, logged in. Good day, got to do my job.
Tuesday, August 9, 2016
Open browser. Go to a different BackOffice URL. Enter my username and password.
Username: Taivo
Password: ***************
Your account is locked. Please contact Tech Support to unlock your account.
Your password is expired. Please enter your current password and new password twice.
Your new password cannot contain your first name, last name.
Your new password needs to contain special characters.
Your new password needs to contain 10+ characters.
Your new password cannot be the same what you used previously within 10 passwords.
OMG not again. I can’t stand this.
Wednesday, August 10, 2016
I can't go through this every time: without central management, every update to corporate password policy yields manual password resets to my user on 50(50!) sites. Fifty sites means 50 different passwords with different password policies per site--my password manager goes crazy. And when I get new computer, forget it: I am the Sisyphus of password management.
To get rid of all this nonsense once and for all, I speak with Joel about what we can do. Can we have only ONE username and ONE password to log into all these environments? Can we have a Single-Sign-On solution? Yes, why not!? We can build it from scratch; it will take only a few months to accommodate all the security requirements. This must have business priority. What else? We need to make a new product, align it with everybody, and add it to our product portfolio.
What do we need? We need a team to analyse it, support it, and the capacity to run it. Not to mention we are running our products with a zero-downtime policy. Looking at the open source community, there are a lot of solutions out there: Authelia, Keycloak, Gluu, LemonLDAP, OWASP SSO, and more. They’re all great, but what do we need?
We need to consolidate 50 (50!) accounts under one federation, plus cover all audit and regulatory requirements. But what happens when a person changes position within the company or leaves the company? How does the account get closed, how can access permissions be changed without it being a hassle? We have already solution in place for internal tools, can we reuse it? We work in Java, so is there a solution out there that we can customize? Do we have a solution where we can add different multifactor supports because who really uses only a password nowadays? Users today already have passwords when they login to their workstations, can we reuse it?
Wednesday, September 7, 2016
We find something called Apereo CAS. It checks all our boxes, and it also provides additional security requirements. We still don’t have a team for it, but we are going for it anyway by making a new product called AAS: Admin Authentication System. It’s a nice name, AAS, which means “meadow” in Estonian.
Tuesday, October 18, 2016
Now we're rolling along with development: Git clone, wrote CSS, made some modifications and workflow changes, align this with infra and capacity management. Complete the proof of concept and--yes!--it works, so we rolled out the first implementation. While it covers all the sites and security needs, we are still far from our goal of a single account, single username, and single password. So far, we have AAS as local component deployed to each site, but it wasn’t far enough along to be managed centrally from one location. Just when I think that this project really needs an analyst, there’s Ave, an amazing analyst who joined Playtech, who is also finishing her bachelors and needed something for thesis. She comes aboard and maps our permission management and how we can move permission management from SQL database to LDAP database with tree structure.
Monday, December 12, 2016
Now we have a product that can manage permissions and users; also, we have an analysist to tackle migrating users to new structure, but we are still lacking a team, which is so far only myself, Joel, and Ave. Looking around the company, I found some support from the performance test team, Anu and Kristjan. They would love to learn more Java and they also have some time to help to bring Ave’s analysis live.
Friday, March 22, 2019
Before you know it, we have a central working solution with our own LDAP servers, our own data structures with our centrally managed user system, and we connect it with corporate Active Directory (AD). This product is connected to all our 50 sites, and it handles Single Sign On and user federation to those sites. We map user AD roles with groups in our Central AAS product: when a user logs in, we can easily see the user roles and automatically assign the needed user group to the user role. Wow! Here it is, we just met our requirements:
- When the user changes position, new permissions are assigned automatically to the user
- When the user leaves, the account is closed automatically
- When the new user comes to work, access is granted automatically
- The user has a single account for all 50 sites where we are running our product
The solution now is live, but we still don’t have a full team to support it…time for aggressive marketing!
Wednesday, April 24, 2019
Lots of meetings! These discussions result in people now noticing: why this product is not yet widely used …and why it is called AAS? This is when I learned that in English, “AAS” may not be perceived as the best name.
Monday, June 17, 2019
Decisions have been made! We have now a product called IMS OneLogin, better name, isn’t it? We also got ourselves a OneLogin product team with five members: myself, three developers (Joel, Mihkel, Venno), and one QA person (Ott).
Thursday, July 1, 2021
Change. The most difficult part. Changes are needed to get people on board with a new product flow. Now we’re running IMS OneLogin for end users, happily telling them about having only one AD username and password! Man, I have to say, auditors love that solution: one place, one account, every action is logged, easy for audits, full visibility but users—but they are reluctant to change workflows. What I am doing is going to one team then another, and slowly getting them to use our new product – IMS OneLogin. BUT the plans are bigger than that: we have more products than just IMS, so let’schange the name from IMS OneLogin to OneLogin. Perfect.
Monday, July 19, 2021
Users are using the product, and other products are also slowly integrating. This covers our internal needs, so now it’s time to go bigger: get our customers on board! The best way to do this is to start with new customers.
I go to teams who are introducing new customers to our platform and get an agreement that accounts and groups are now done only in OneLogin. Also, thanks to Idan and Egert, I get our trainers plus their teams and consultants on board to train users on OneLogin. New integrations are using only OneLogin for user federation and account management.
It took five years to get here and we still we have a long way to go. Why should our customers have users in Playtech systems with usernames and accounts (even if it is only in OneLogin) with the same problems what we had, like when a person leaves or changes position in the company? Unnecessary overhead!
Friday, December 3, 2021
OneLogin doesn’t only support user federation from OneLogin to different systems; it is not only an Identity Provider (IdP), but it can also be a Service Provider (SP). For Playtech, OneLogin served as a SP, but for customers it was an IdP.
Now we’re integrating with customers Azure accounts. You have in your Azure account dashboard link to Playtech OneLogin and you just click on it. Azure passes through the user parameters and roles and links it with user permissions in OneLogin. Poof! You can access Playtech services with the account that you use in your own company. When your position changes or you leave, access is automatically adjusted, no one needs to bother with your company account management and also user accesses in Playtech systems. We only need user details audits and regulatory requirements. Customers now have all password policies on their side. With new customers it is easy! Next up is existing customers and getting them to change their flows. Time to show them how change is good.
Monday, May 9, 2022
Browser. Go to OneLogin URL. Enter your corporate username and password.
Username: Taivo
Password: ***************
I have a dashboard, where do I need to go? All
I need to do is click on the link and BackOffice opens in a new window without
having to change my password and without having to worry if my account is
locked. Everything is managed in one location: OneLogin.