[MUSIC PLAYING] All the new possibilities of the new Angular-based web stack that you can use to both configure and customize how the application behaves. So first of all, there's going to be the configuration layer-- sp for the very easy use cases of just configuring and flipping switches, changing values in the system towards the more complex scenarios of customizing both the API and customizing the UI layer-- you'll notice that these are separate topics, because they are technically very different things-- and finally, some roadmap summary of what we're going to be doing over the next few years.
So with customization we're basically changing how the application behaves. With that entity manager, we've seen that most customers-- I hesitate to say every customer-- but certainly most customers will have some degree of customization about this system.
And we've had a lot of successes over the last 10, 15 years with having Web Designer as a tool to allow implementation partners to easily change how the system looks, how the application presents itself to the user, how it behaves.
And over time, we found that Web Designer was all well and good, but it's had its time. And maybe in today's world of having client-based JavaScript modern architectures, it's maybe not the right framework anymore. So we decided to rethink this from the start, to basically start with blank page and think about how we would do customization.
And we came up with three layers, basically, of approaching this problem. So this pyramid at the bottom would have the configuration layer. If you're just looking to switch-- to make easy changes to the system, we have a very powerful configuration layer that doesn't require any coding but uses the built-in tool set of Identity Manager.
If you want to enable or disable features, if you want to do theming of your UI, just basic color changes, basic changes of text of terminology in the UI, that is doable through configuration. You don't need to get into coding. You don't need to start a development project if you want to-- if you want to do things.
So simple things should be simple. Same thing for property lists-- if you have a schema extension in your system and you have an additional attribute somewhere, and you just want to show it next to the other attributes of an identity, for example, that's also configuration.
Getting to the next stage of the pyramid where things get a bit more complex but also more powerful, you can write plugins. So still you're not changing anything about what's there. But you're adding to it.
You can write plugins that hook into the system and extend it, extend the behavior. You can extend the API, build new API endpoints as well as build new UI functionality. So if you have an additional page that you want to show in the UI to represent some kind of process, if you want to add just a menu item or some more information on the dashboard, that's a plugin. That's also very powerful approach.
But still for some scenarios, it's not sufficient. We're seeing this many times that customers have a requirement to change something about what's already there and change what's there and to really tailor it to expectations and requirements. So at the top of the pyramid is the most complex and most powerful way to approach this is really write custom code. And as with Web Designer, the Angular stack allows you to do this.
You could write completely custom apps, completely custom APIs. And speaking of the UI, that doesn't even need to be Angular, you could write a React application that talks to the API and still have it hosted and deployed as part of the Identity Manager deployment process.
So configuration and customization are different things. And also the API and the UI are different things. So keep this in mind as we go through this presentation. Web Designer was kind of a monolithic way to look at things, which combine both of these. But it's important to know that we really made it very sharp-- we're drawing a very sharp line between the API side and the UI side.
And for UI, of course, our technology of choice is Angular. And for the API, it's very simply C-sharp.NET in the interest of being consistent with the other parts of Identity Manager.
Taking a look at the configuration layer first, so the configuration layer is shared between the API and the UI. So in this part of the presentation, there is no distinction there. If you want to add extra attributes to lists, you have lists of column names in the configuration layer that you can configure. If you want to filter what the API returns in terms of data, if you want to add filter classes, you do you also do that through the configuration layer.
You want to enable or disable certain application features that are irrelevant for your users, you can do that in a configuration layer. Also tailoring the web application in terms of security, how are the security settings going to look like, that part of the system gets more complex every year as the world of web security just keeps inventing new stuff. So we're putting all of that in the configuration layer as well.
And the configuration data is, at its core, it's just a json file that stores all the settings. You can edit it manually. But the way to edit it in a more friendly, more intuitive, more accessible way is the Server Administration UI.
So that's web-based. You can just pull up the web page of the API server component of Identity Manager and take a look at everything that's there. This is just a small subset. We have lots of configuration keys that can be changed and drive the behavior of the API.
And just to walk through some interesting samples of how things could be done, so for example, you can configure things about every API method that exists in the system. And by API methods, you can think of it as anything that returns data, whether it's the address book, the attestation approval, the access request page, everything is exposed in terms of API. And everything is open to be configured and changed.
So it's very simple in the Server Administration UI. You add new configuration settings, put in the name of the API endpoint that you would like to change, and then get a new configuration object in the UI that you can make your changes on.
Let's take a concrete example. So in the address book, by default, we show inactive identities. And a sample requirement would be well, I don't want to see these inactive identities in the address book. How do I do this? Very simple. You find the API that exposes the data for the address book. It has a URL. You take that URL, and you add a filter.
Oops, sorry. I should go back a bit. Just add a SQL filter on the property. It's inactive that represents the state of the identity. Put in that filter. And you're done. The address book will not show inactive identities anymore. And you can do this with everything in the portal.
Another example would be, well, every user can change their main data, the culture, their preferred language setting, for example, in the portal. And we see that quite a lot, that the customers come to it with the requirement, well, it should not be editable. We don't want to use-- we don't want our users to be able to change this property or that property.
That's also very simple. Again, you find the API that exposes this information. And you add the property. So in this case, it's a different example. So only internal employees can be assigned as managers of an identity. So that's a filter.
You find the data property that represents the manager of an identity. And you can add a filter there. It's external equals zero. So from then on only internal employees, only internal identities will be displayed to the user in the pic list, the dropdown list for manager assignment. So this is what it looks-- you can get a specific configuration object in the UI. And you can put in the SQL clause in here to filter these object sets.
So another thing that's being asked quite a lot is how do I how do I put in my own logo in the application? It's a simple thing. And it's supported in the administration portal. There's a dedicated setting. You just put in the URL to a different logo. And that will be used both in the masthead of the login screen.
So it's a quick but quite efficient way to get some form of branding, of recognition. And there's going to be more about theming and how to tailor the look and feel to integrate it to an existing branding in just a moment.
How do I go about adding additional columns, adding additional fields to lists or to tables in the portal? As you can see here, everything is exposed as lists that you can add things to. You can remove items from the list. So if you have a property-- it could be a custom property or an out-of-the-box property that we don't show by default, you can add it in this view.
By moving from Web Designer to Angular, one of the things we did is that we removed a lot of the clutter that filled up the screen. If you look at Web Designer, it shows a lot of information in many places. And we decided to reduce that a little bit. So if you have a property that was there and it's now missing, it's pretty easy to extend it using this feature.
So in this case, you can see additional properties that get displayed on the table right after you make the change. One other interesting thing is the ability to test the changes, to simulate the changes. Any change you make can be made in a kind of simulation mode where you click the Apply Locally checkbox or radio button.
If you just want to test out a change and see what it looks like in the portal when you make that change, just say Apply Locally. Make your tests. And when you're done, you can save that configuration as a global change.
Just a quick note about running the API server-- so people don't really know about this. So I make it a point to address this in every talk. There's a very cool, quick way to set up an API server and run the different web applications locally without having to have admin rights, without having to install anything anywhere.
It's the IMX client exe, very powerful to run an API server from the command line. And then by default, you will have a server running on this URL. And you can do mostly everything. There's a few very obscure limitations to what it can do. But you can do most of the relevant scenarios from the command line on your local host.
Moving onto to now real customization of the API layer. So again, why do we make the separation of customizing the API layer versus the UI layer? First of all, they serve different purposes. It's the API layer's job, on the left-hand side, to communicate with the back-end to communicate with the database or the application server.
The API has to make the decision about what objects can be read, what objects can be written. It integrates with the back-end, meaning that it's based on .NET and supports .net plugins. And it should be independent from any UI. If once you have an API, there's no reason why you shouldn't be able to call it from a service, for example, or from a script.
So the API is really independent from the client technology, whereas the UI layer doesn't see the database at all. Everything that it talks to is the API server. So it only it doesn't care about the physical database schema. All it cares about is the API schema.
And that is based on Angular and based on supporting Angular plugins. And it also should be independent from any specific API technology. So there's no reason why the UI layer shouldn't communicate with other services also if that's the requirement.
So you can see here that these two customization parts. Sometimes you need one of them. Sometimes, you would need both of them. I would, from what I see, I would say a lot of times you need both. But they require different technologies. So if you go down this route, these could be different people. These could be different developers each specialized on their respective technology that's required.
So as soon as you have Identity Manager 8.2.1 or later, you can get started with this. So it's been in the product for a few versions now. Prerequisites-- I would say a basic knowledge of C-Sharp and .NET. But some knowledge about the OneIM object layer which the API is going to be very tightly integrated with is required. And in terms of writing the actual code, you can use Visual Studio. Or you can use Visual Studio code. But basically any IDE that supports .NET development is fine. We don't have a strong preference for one or the other.
And as you can see, one of the things that changed compared to web designer is that we're completely open about which technology to use. We do not want to force developers into the proprietary model that Web Designer was. So it's really a big change if you were using-- if you were doing Web Designer before.
And the way to create a plugin in DLL is very simple. We have just-- can use any C-Sharp project. You fire up Visual Studio or any IDE, create a new C-Sharp project. Give it the right name so that it will be picked up as a plugin. That's a very important point.
And we have sample code. So the way to get started with this is to look up the API sample code that are part of the installation set. And you can walk through those. And then finally compile the project to a DLL and drop the DLL into the system so that it will be picked up by the API server and loaded as a plugin.
I mentioned the API samples, so a quick list of everything that is covered there from simple object model queries, completely custom methods-- so methods that return any kind of object any kind of data structure, you can add APIs to return that. Even if it's not directly represented in the data model, you can calculate, transform your data and put out exactly the data structure that the consumers of the API require.
You can run reports. You have access to statistical data from the OneIM statistics data set. You can run scripts right to the log in, run customizer methods. You can access the file system to kind of attach a data store to your API methods. That's a very interesting addition for some scenarios.
But you can also add-- as you can see here, you can also use the plugin to extend existing APIs, so extending-- oops, wrong button-- extending properties on default endpoints, adding filters, adding constrains, adding additional validation that runs as part of the API processing, run additional checks if the consumer of the API sends data, or adding access control.
It's very powerful as to what you can do inside of the API in terms of modifying the behavior of the out-of-the-box API. So here's just a quick look at a very simple helloworld kind of example. It's just a few lines of code to define the URL.
In this case, would be a very simple helloworld URL. And you connect to the person table in One Identity Manager. You say that this is a read method. You define a filter clause to limit the set of identities. And you say that you want to return just the internal name property in this example. And you're done. So again, simple things are very simple. Complex things are possible.
So once you have a custom API and you want to integrate it, you want to host it inside of the big picture, inside of the API itself, you have to associate it with an API project. And what the API project is, you can think of it like an application. And we have actually the four different applications that run on top of the API server. Today, it's the portal that most end users will be using, the operation support portal for the operators, the password reset portal, and the administration portal to do the configuration.
And with each of these APIs projects, there is a mode of authentication that is associated. So the way you authenticate to the portal doesn't need to be the same authentication. It can be completely independent from the operations support portal or any of the others.
And the way that the API server manages this is that every API call has a prefix that tells the API server which session to use. So you can be logged into several of these applications in different ways. But if you have a custom API, you have to make a choice to associate it with one of these. Or you could add your own API project. There's also the possibility to extend this list.
So taking a closer look at how plugins work, what the API server does is it looks in the program folder where all the DLLs, all the program code is stored. It will find the custom DLL that works as a plugin. And there is a special builder interface, the API builder that the server will be looking for. And it basically just runs all of those classes. And there's a little build method as part of the interface. And it runs all of the build methods that it can find to extend the API.
And if you attach one of these classes to your custom code, that's a very easy way to tell the API server, hey, I have a custom endpoint for the portal. Or I have a new endpoint for the password reset portal.
We already talked about this. So how do I debug from within Visual Studio? That's also very simple. So you can see that in Visual Studio, so this sample only works for Visual Studio. This kind of like a debug profile.
And you give it the path to the IMX client exe, which as I just mentioned, you can use it to run the server. And you just press a F5 into Visual Studio. Start the server. Start a debugger. Load the plugin. And you can do everything that you would expect as a developer to be able to debug the code, to troubleshoot, to analyze, et cetera.
Moving on to customizing the UI layer-- so completely different technology now. We're switching to Angular. And again, the profile is a bit different. The set of prerequisites is a bit different. Because now if you're talking Angular, there's a whole baggage of-- there's a whole bag of technologies, of base technologies that comes with it-- things like NPM, things like node.js that will be familiar as soon as you get started with Angular.
And if you get started with this, I can really recommend the official tutorial of Angular. It's one of the better ones that I've seen. It's the way that I've learned-- that I've used to learn about Angular. In our applications, we also rely heavily on the Angular Material Implementation.
So what is material? So very briefly, it's a design language. Material is a design concept and a set of patterns. And Angular Material is an implementation of that design language. And it provides base components of the primitives like buttons, text boxes, tables, tabs, et cetera. So we rely on that.
Then GitHub access, of course, to get access to the out-of-the-box code-- and again, we don't really have a strong preference. We don't want to force anybody into using any particular IDE even though, from what I've seen, Visual Studio code seems to be the kind of de facto standard for Angular development.
We decided to open up the source code of all of our Angular-based web applications and put it on the official GitHub repository of One Identity. So everything-- the portal, the operation support portal-- everything is there, can be looked at. And you can use this to just learn how things work internally. If you're curious about how certain things are done, what components are used, you can just look it up.
But where it gets really interesting is that you can take this and create your own copy. It's one-button click in GitHub. And say you're forking this repository. And now all of a sudden, you have your own copy, your own managed copy of the set of web applications. And you can use this as a basis to get started to step-by-step integrate the customizations that you need for your project.
If you ever have a problem with this, in the event that you have something to report, something doesn't work right, there's also the possibility to open so-called issues on GitHub. So for anything that is directly GitHub-related, it's the preferred way, the fastest way to get an answer to a question is just to open a GitHub issues. And that gets directly to the developers. We see these. And we can respond.
If you ever do a bug fix, if you ever create a great feature and think this should be in the standard, pull requests are also welcome. So a pull request is where you provide code, and you your request this could be integrated into the default-- into the default product code. And we've now been running this for, I think, close to a year now. We've had a couple of great pull requests already through that channel.
So how do you get-- what options do you have to actually approach this? You could write a plugin. Again, a plugin is something that extends, but it does not modify. It extends the existing HTML5 app. If you just want to add a tile on the dashboard, if you just want to add a menu item but you don't want to touch any of the stuff that's already there, just write a plugin. It will keep your code strictly separated from the rest. And you will have a very clean separation.
But as we all know, that's sometimes not enough. And there's also the possibility to touch any of the code that's there. That's why it's there. It's in order to be able to modify it. And what you can do is that you can do your customization and then have a modified version of the portal, for example, your own customized version of the portal that you want to give to your users. And that's pretty powerful, of course, because you can change everything about the UI. You could use completely different controls in places.
Let's stay with writing a plugin for the moment. So Angular supports the notion of Angular libraries. And the set of projects in a folder is called a workspace. So if you look at the Angular documentation, there's a lot of resources on how workspaces work. And the plugin is nothing more than one citizen in the village, so a library within a workspace.
There's a little declaration-- sorry, declaration file that will tell the application that, hello. Here is a plugin. Please load me and integrate me into this application. And the basic application will pick up the plugin, run the instantiation, and expose the additional functionality like menu items.
So for example, yes, this is the Angular json file that manages all the projects in the workspace. So there's quite a lot of boilerplate code. But there's actually a command to run this. So it's default Angular stuff. It's nothing that we invented. It's just proven technology from within Angular that we are using and enabling everybody to use.
So for example, how would I use a plugin to add a menu item? Actually, this is all the code that's required to do that. If it's too small to read, don't worry. So it's just a few steps. First of all, there's something called the menu service that manages the user's navigation menus.
So you get the menu service through the dependency injection of Angular. You can check the user's group memberships. So you could limit the menu item to be visible to some users but not others based on their group memberships.
And if you find that the user is assigned to any one of the necessary groups, you return an object that tells the system, hey, here's the new menu item. Here's its title. And here's the page where the menu item should go. That's it. And here's-- if you want to look it up, that's actually taken from the real product code.
Creating a library-- so again, there's a default documentation on that. So I'm not going to spend too much time on that. I should mention elemental UI. Element UI is a component library that One Identity created to extend angular material with some other components that are missing in the base library.
So if you stumble across elemental UI, there's documentation available on the One Identity's website. So if you want to find out about what that is-- if you come across it, and you're wondering what is this, then we have documentation available for that as well.
We also have an API client service. So if you're making any calls to the API, don't make a network call directly. Or you can, but there's a package that does a lot of the heavy lifting for you, which is the API client, which basically contains methods that wrap the API calls. So you don't need to worry about typos in URLs.
You don't need to worry about which parameter types the API would expect. Because it's all there precompiled in a TypeScript library that you can use. So those are the IMX API and then followed by the module name Angular packages.
So basically just, if you have the URL of the API endpoint plus the HTTP method, so whether it's Git or put or post or other things, that will translate to a TypeScript method following a certain schema.
And there's actually more to it. You can actually work with objects through the API client service. So imagine that you have an object. You create it. You make changes to it. You make other changes to it. And finally, at the end, you save it. That's a series of APIs calls.
But the API client has a class that we call type client that has typed objects that you can create and talk to them like in-- like you would in the back-end, talk to an entity-- so getting values, putting values, deleting, committing. And actually in the back, that entity will go and make the right API calls, make the right calls to the server.
And if the server finds that some other value changes, it will reflect those changes back onto the client. So that's a pretty nice way to work with entities in TypeScript without having to worry about what network calls to make in the background. And we use that quite a lot. So all the pages that you see with managing identities, making requests, et cetera, they all use this.
If you have a plugin and you want to deploy it, well, you basically zip up and make a bundle out of the compiled Angular plugin and upload them with the software-loaded tool to the right location in the software repository. And what will then happen is that the API server will pick up the plugin and start deploying it if you call the web application. The IMX web folder is where all of that lives. So make sure that the plugins are all deployed to the IMX web folder.
OK. Modifying the code for an existing app-- again, we've already seen this. But this is from the GitHub page where you have a set of apps that you can modify. To get started, again, we've already had this in the other presentation. So there's a series of videos on YouTube, on the official One Identity YouTube channel that I really recommend you walk through if you're new to this if you want to get started. It really starts from the very beginning of installing a proper environment to do development.
And the last time I checked, it was eight videos. It probably has eight new ones by now. And that's going to be-- we're going to keep on adding new ones here. The development guides are separate for HTML5 development and API development. So we spent a lot of time in the last half year to make sure that these address all the use cases that developers encounter when they get started.
Also, don't be afraid to ask questions. Whether it's on the Identity Manager community or on the GitHub page, we're there. We're listening. We're seeing everything that gets posted. And that goes right to the development team. So we can get back to you with responses.
Another thing that's-- oh, yes, this is a fairly recent addition. What about if I just want to have an application, I want to start building it from scratch without having to worry about all these things that are already existing in the portal? I really just want basic authentication, a login screen, and then an empty template that I can fill with whatever I need for my application.
There's a dedicated app for that, again, on the GitHub repo. It's called the Custom app, which doesn't really do anything besides authenticating the user and showing a blank page with, I think, there's one API call that's being made. So use this just if you want to build a new application but you want to reuse the basic infrastructure, take a look at the Custom app.
Moving onto branches and forks. So how will the deployment model-- what will the deployment model look like? What will updates look like once I start customizing? The big question is always, how will you handle migration? What will that entail?
So if you look at the upper line, that's basically what we provide. That's what the One Identity GitHub will have. There will be an initial commit at some point. And there will be a service packs. They might be major releases, minor releases. And at some point, you're going to start working on a copy. At One point, you're going to take this and make a clone and start working from there to work on customizations.
And in this model, what you have to do in order to keep up with the changes on the upper side, you have to do-- you have to merge the changes from the what-- an open-source terminology is called the upstream. You have to merge those changes down to your customizations.
And you're in charge of this. If you go with this model, Identity Manager doesn't dictate when you do this. It doesn't dictate what to do in case of any problems. It's a very default, open-source development process to merge upstream changes. Same with bug fixes. Any bug fix that we provide will only appear on the upper line until you merge it to the copy.
That's very important to keep in mind. So as far as a CI/CD pipeline, so again, that's something that GitHub can provide. But we don't dictate that it has to be GitHub. Identity Manager does not really care about where the source code is stored, how builds are run. The only thing that-- where the entity manager comes back into the picture is when you upload the build artifact.
And you could also automate that process. There's nothing that keeps you from running a build on GitHub and automatically push that build of the application back into your Identity Manager if you want to do a release, if you want to deploy a new version. So completely different model than was the case with web designer, a lot more powerful with some choices, additional choices that have to be made in every project.
And of course, one of the big questions now will be, well, which strategy is the right one? Which one should I use? And of course, the answer is if you can achieve what you need simply through configuration, then that will be enough. Don't go for the big picture of running a custom plug. Just do the minimum of configuration. And you're done.
And some other questions is, what is my deployment process, which I just showed an example picture of? What is that going to look like? What is the factor that will trigger a new build? Identity Manager will not do that for you, because Identity Manager doesn't know about your CI/CD process or your pipeline or your GitHub project. That's really separate. So it's a question that you have to answer if you want to-- if you want to go with this model.
When to deploy an application of an update of an application-- when do I go and look at the upstream changes and merge them into my copy so that I get the latest features and the latest bug fixes? The great thing by the way, you don't have to do it as part of the migration. You could do it before.
You can do it even before. You migrate your main system you can take you can take your code, merge the changes, and see if there are any problems, any conflicts. And once there are conflicts, who is going to be resolving them? And how do I go this?
If some piece of code changes in the copy, that's also changed by us in the vendor code, that's going to be the conflict. I'm running short on time. So very quickly, some roadmap items-- we already mentioned this. In 9.2, we will still be having web designer. But we're going to be closing the remaining feature gap of what the Angular application cannot do today.
Theming support-- we get a lot of requests about being able to support custom themes, custom color schemes, fonts, font sizes, all of that. It's not that easy to do. So it was quite a bit of work. But as you can see here, we already have a dark mode theme. So every application, the latest thing is now to have a dark mode. So it looks pretty nice I think.
And we also want to have a WC/AG-compliant high-contrast themes. So if you have high-accessibility requirements, that particular theme that you can give to users will also help there.
Redesign of access requests-- so by popular demand, we're bringing back the tree view of service categories, which are titles today. And again, if you want to see this in action, it's not just a screenshot-- well, actually, it's not just a mockup It's an actual screenshot from working code. If you want to see this code and click through it, book a slot at the Whisper Suite. Go to the front desk and they will reserve a slot for you we have this running in the room just next door.
And again, this is your chance to provide input. This is not a released version. This is product-- this is code under active development. So if you have any contribution comment to make, now's your chance. One of the big pieces of that was missing is the entire analytics in KPI part of the portal. And so I can say today, that that's also coming back, that's also going to be probably the largest missing piece in 9.2 for Angular.
And Ted's already mentioned this. I'm going to be skipping over this. More documentation, more sample code-- yes, developer support is absolutely important. We get a lot of questions regarding to this. So we're well-aware that developing a solution like this can be very challenging, can be very complex. And we're there to listen. We're keeping an eye on the community on the GitHub page. And we want to make sure that all of these projects are as successful as they can be. And with that, thank you very much.
[MUSIC PLAYING]