On XAF Architecture - How to develop and maintain develop many, independent and different apps in a corporate environment (with shared modules, security settings, etc.)

In an business environment where users have access to multiple apps, the ability to share the security systems would be a benefit.
On the top of my list would be the ability to have one set of login credentials, and the ability to assigned users first to an application and then privileges within the assigned application.

I cannot see that the those methods you mention solve the issue. This is not just about creating users initially but the maintenance of applications that are already in production. As I said before, I am asking the XAF development team to consider the question of what can be done to make it easier to to develop many, independent and different applications to run in a corporate environment. I do not know what might be the best solution regarding a security system but at least, I think it is very tedious to be forced to create users many times, once for each application. The use case of disabling user access is also a good example as it is necessary now to open up every application that the user has access to and disabling the access potentially 50 times or more.

May be it would be possible to have a version of the security system that is split up. In each application we could have roles and the configuration of role access to the application objects, navigations and actions. The centralized security system might then contain the users and the possibility of linking users to application roles. Making it easy to assign Active Directory groups to application roles would also be a huge benefit.

I think the scenario I am describing is extremely common and as I have now worked for 2 very different companies using XAF, I see exactly the same needs in both of them in this regard.

Best regards,
Ægir

Hi Ægir and Kris,

Thank you for describing your business needs. I don't have more to add to what Anatol said. The only reliable solution to have the users and roles in several applications is to connect these applications to the same database. Since XAF is designed for Intranet applications, it may be an appropriate option.

Good day.

My intentions for this ticket is really not about my business needs and how I can work around what I feel are shortcomings of the XAF architecture. Is is simply a suggestion how Devexpress can make their XAF better and more appealing platform for their customers in general.

Best regards,
Ægir

Thank you, Ægir. We see your point, and will definitely take your suggestion into account.
Please feel free to contact us anytime.

That is great!

Thank you and best regards,
Ægir

Hello Ægir and Kris

I think the scenario I am describing is extremely common and as I have now worked for 2 very different companies using XAF, I see exactly the same needs in both of them in this regard.

Absolutely agree - this is my experience as well. XAF is not for everything and many our existing enterprise customers use it with non-XAF .NET apps. For instance, our long-term customers (more than 10 years) from https://www.prakom.net/vendoc/ have XAF WinForms, WebForms apps + Xamarin, ASP.NET Core non-XAF apps all using the same or shared database with users, roles, business objects and XAF features like security, audit, validation, localization, etc. Some customers build a dedicated administrative XAF WinForms app to manage users, roles and other global settings. Overall, we have customers who successfully use the same architecture - that is also one of the reasons we promoted our security system in non-XAF apps lately: https://www.devexpress.com/products/net/application_framework/security.xml. I can confirm that this is a recommended solution and architecture for such scenarios.

This is not just about creating users initially but the maintenance of applications that are already in production. As I said before, I am asking the XAF development team to consider the question of what can be done to make it easier to to develop many, independent and different applications to run in a corporate environment. I do not know what might be the best solution regarding a security system but at least, I think it is very tedious to be forced to create users many times, once for each application. The use case of disabling user access is also a good example as it is necessary now to open up every application that the user has access to and disabling the access potentially 50 times or more.

No doubt that creating the same user or role or patching them 50 times is inconvenient. That is where a shared database with users, roles and other common business objects comes to rescue. I am trying to understand why this shared database does not meet your needs for a typical corporate environment with many XAF and non-XAF .NET apps?
I want to emphasize here that our Security System API is just a "player" that works based on user and role data store in a database or storage (see the architecture schema for more details). This "player" accepts basic input settings such as user, role, authentication and security policy type and can reside in any .NET app.

I know it is possible to create different modules in XAF that connect to different databases and I do have an experience with this but my experience was that it is complicated and full of all sorts of difficulties.

If you do not have solution preferences so far, what are the main issues you experienced with connecting to multiple databases? Exactly what you coded, for which scenarios and what did not work as expected or was inconvenient - we will be more than happy to look into these facts and see how we can make it simpler.

Making it easy to assign Active Directory groups to application roles would also be a huge benefit.

What are your current steps here and what are the main issues with them? If you are using example code from How to: Assign the Same Permissions for All Users of an Active Directory Group, we would love to hear how you want it to be improved.

I will look forward to hearing back from you. I have also reposted a link to this public thread in our Gitter community chat so that other XAF customers could share their experience.

Hello Dennis,
You his upon the answer right there.
Using active directory is the solution because it is one "database" of users.
However, security in xaf is such that there are roles and if you designed a new app, you would need to give the same user different roles.
While the list of users and credentials are available in AD, the roles have to be rolled again which is a tricky job.
Also, what if the customer doesn't have access to AD?
Here is something you taught me to do when requesting a feature or change.
As a developer of xaf apps, I would like to implement one user security application, so that it can be used by several xaf applications to manage the roles of the same users across multiple applications.
For example, I have a task application, I have a crm application and I have a logistics application.
Instead of implementing the security module three times for the same users, I would like one central place to manage all users and roles for all three applications.
Now it is possible to implement all three applications in the same one large enterprise application but it gets annoyingly complicated very fast especially around UX, UI and troubleshooting.
Maybe it is time we talked about multiple people developing different parts of a large enterprise xaf application using CI, CD and some form of version control because, to be honest, most xaf devs are agile cowboys

@James: Thank you for your feedback. In your scenario, all the corporate apps (Task, CRM and Logistics) can use the same database (Microsoft SQL Server or anything else) and thus share the same user, role and other data. You do not need to create users, roles and permissions 3 times in this case, because this data lives in a shared database. This is the recommended solution I descried above.

To manage users, roles and other global settings, XAF developers can show the "Users" and "Roles" navigation items for Administrators in these 3 apps. Or, they can create a dedicated administrative XAF app for this. In both cases, any user or role data changes made in one app will be reflected in others automatically. If you create a new app, you will NOT need to create new users and roles for it - existing user and role data will work just fine. That is because all apps will connect to the same shared corporate database. I hope this makes sense, because I feel that this important part about security data sharing is somehow missing from the discussion. Thanks!

Good Day. This is getting interesting :)

I will need to read this better and think through what has been said here before any serious response but let me just ask you quickly @Dennis, are you suggesting that all XAF, applications, developed for a corporation, share the same database? That sound a bit messy to me but maybe that is the way to go. Maybe the applications could be separated with different schemas to make the database less messy - is that possible or useful with XAF. Then again, I admit that I do not have much experience with using other schemas than just the default dbo in SQL Server so might be wrong here.

Best regards,
Ægir

@Ægir: If you are within one enterprise, then why not?;-). We do this with our internal apps often, sometimes using different database schemas/namespaces. Of course, it is possible to specify a different schema for an XAF app with one event and one property: How do I map persistent classes to another schema, e.g. other than the default "dbo" in MS SQL Server?.

This is indeed turning into a truly fascinating conversation.

I can see the logic behind an enterprise having several different applications (which might in reality be subsets of one over-arching 'model' that allows the enterprise to function) and thus by extension sharing the security side of the underlying database. For a large company this makes perfect sense , and even more so in the case of DX where you have the developers on hand to implement it.

Now let us suppose for a moment that Dev Express did not have a large pool of in house developers to create their back end administration and instead needed to buy those 'apllications' in. Let us equally suppose that they then purchase those applications from a number of different vendors who just happen, through choice, to use XAF and XPO as they base development platform. The person in our imaginary Dev Express devoid of in house developers, tasked with administering user access to each of these disparate applications will then find themselves having to repeat the same security tasks over and over again.

As a one man operation I have a couple of products targeted at very different markets, so much so that I would never expect to have the same client express an interest in both. However I can foresee a situation where they might well want to purchase a product produced by fellow XAF developers. I don't doubt that it would soon become apparent to the end user that they are using two different applications built upon the same foundation and having exactly the same type of security system. Equally I don't doubt that at some point that end user would start to ask why they have to go through the same routines in order to set up security for their users.

This leads me to poise the following question. Might the time not be right for Dev Express (the real one this time with it's raft of in house developers!) to consider actually hiving off the security aspects of an XAF application to it's own separate database but done in such a way that that security application was capable of controlling more that one application at once.

I realise that this is a strategy fraught with potential problems. For it to have any chance of success it would require that all xaf developers planning to take advantage of it follow some pretty clearcut rules about their interaction with this database, It would equally require some fairly specific search routines at the time on installing any application (which of course rather negates the advantages conferred by Xcopy). It would require that the first person to install an XAF based application on an end user's machine takes the responsibility for installing the security database and all followers then use the existing installation and do not attempt to install one themselves. On the plus side though you get a common security feature which end user's only need to learn once and, were Dev Express to provide the application that interacted with said database as well, would always look the same.

I'm not suggesting for one moment that this is what should be done, or even that it's advisable. I see this as simply one obvious conclusion that can be drawn from the nature of the discussion as it has progressed thus far. In my opinion the inbuilt security system is one of XAF's strongest selling points. I venture to suggest that devising a way to allow its application across several different XAF applications created by different XAF developers on an end user's machine could only enhance that selling point further.

Dom

@Dom:

I venture to suggest that devising a way to allow its application across several different XAF applications created by different XAF developers on an end user's machine could only enhance that selling point further.

Thank you for sharing this scenario with different XAF developer teams that are not part of the same enterprise. I am aware that it exists - just did not consider it due to much lower popularity as compared to the case with in-house developers (based on our own internal and customer figures).

I realise that this is a strategy fraught with potential problems.

I agree with the issues of the option you listed. I can also add that application programming for regular developers will be more complicated when you use different databases because users are typically referenced in business classes for CreatedBy, ModifiedBy properties, and the like. This complication with multiple databases occurs regardless of whether you use XAF, XPO, or any other tools, and it is hard to avoid it. That is another reason why a shared database will likely be preferred by developers.

On the plus side though you get a common security feature which end user's only need to learn once and, were Dev Express to provide the application that interacted with said database as well, would always look the same.

I want to emphasize that this benefit is also available to end users and developers when they use a shared database in their enterprise. One of XAF advantages is that it allows developers expose user and role configuration capabilities to Administrator directly in the application UI - it is just two code lines in ModuleUpdater written once (without any duplication), but which will affect all different XAF UI apps automatically. The aforementioned issues are also unlikely to occur within an enterprise for different application developers using a shared database.

@Dennis

" did not consider it due to much lower popularity as compared to the case with in-house developers (based on our own internal and customer figures)."

That statement intrigues me. Are you saying that the vast bulk of your licensees work within large enterprises and that they vastly outnumber independents, or would the correct interpretation be that, in terms of work location, the vast number of queries about the security system emanate from those employed in large enterprises, which obviously makes a great deal of sense.

@Dom: Yes, based on internal statistics, we know that development teams prefer XAF much more than one-person-shops. Very often 1-3 developpers from such enterprises work as a point of contact for the rest of the development team. It is generally true for XAF, not only for specific modules like security.

However, I am not focusing on this and wanted to refer to your specific scenario:

…instead needed to buy those 'apllications' in. Let us equally suppose that they then purchase those applications from a number of different vendors who just happen, through choice, to use XAF and XPO as they base development platform.
…I can foresee a situation where they might well want to purchase a product produced by fellow XAF developers"*.

I rarely observed such situations with enterprise and one-person-shop customers. It is especially true for enterprise developers who prefer to minimize external dependencies as much as they can. They prefer to have full ownership of their code-base - I just thought of the most typical XAF teams of size 3-5, 7-10, 12-15, 27-40 (you can find typical representatives of our target audience here and here).

@Dennis

That's a very fair point. My original observation was more by way of playing Devil's Advocate. From experience I know only too well it's very difficult to get large / enterprise institutions to even consider products from small one man shops (even if those single individuals actually understand the clients business sector better than the client does!) Most are of the belief that they can do a better and potentially cheaper job in house themselves.