we have a big distributed and multitenant system with all sorts of accounts :
- admin and backoffice users account
- customer account
- cashier account (tenant : there is one or many more cashier for each client tenant)
All this account are sharing more or less the same lifecycle (account created, grant on some ressources, deny account, password reminder...)
But they are not used in all applications of the system : some account would be used on specific or just two application for example.
Furthermore our system should have the possibility to have a bridge with a CMS for the customer management, or the backoffice users account could be authorized one day against a ldap...
So the question : we are searching for the best way to model our right and authorization service(s).
One idea is to create one service in order to manage all types of accounts of any kind : that is a SOA way to modularize our system
And one idea is to create different services : perhaps much more a micro-service oriented way of thinking...
What are your opinion ? I am searching some advices and feedback on this two different approach or perhaps an alternative that we habve not thought about...
If you are looking for any open-source solution for your problem, you can have a look into keyclaok.
Keycloak also got place in Thoughtworks Technology RADAR.
It is very promising solution and has LDAP, Multi Tenancy support also. checkout keycloak features.
There is paid solution like ForgeRock is also avaible.
Coming to feedback which you have asked about SOA or microservice way of implementation here (You will get different feedback/advice on this)
It will be better if you have a service to take care of access and authorization management and other to look into user details. If you meant that having different services for different account then note that Having one service for taking care account is still considered as Microservice approach as there is one dedicated service to perform single set of tasks.
You can have User-Service for user information management and a authService to handle access and authorization of users. check.
Related
I started reading microservices architecture and got confused with one below point.
Each service should have a separate database.
Does each service mean a single web(rest) api having its own database?
For example if I take motor insurance claim operation as a business scenario where I modelled business domain services in 3 part Insurance claim services , partner (automobile service providers) services and customer services.
Insurance claim settlement operation in claim api will require other information like incident , survey done by an inspector, policy detail , documents etc.
Now I can create 5 web(rest) api in Insurance claim services and will store its data in common db and other services like partner and customer service will have their own web apis and db
What is correct ?
All web api (claimAPI, PolicyAPI, IncidentAPI, SurveyAPI and DocumentAPI) in claim insurance services should have their own db or they can keep data in single data base ?
Thanks.
To follow microservice best practice, it is correct that they should each have their own database and be exposed solely by APIs. This is because every service in your architecture should be independent and de-coupled from other services. If 2+ services share a database, then there may arise problems in operation or upgrade.
One big issue with a shared database is each service would need to trust that another service doesn't modify it's information. But since they all have access to the same database, one of the others could in fact modify the underlying data and make things unstable or insecure.
Further, with 2+ services relying on a shared database, then you're forced to use the exact same database/version with all. You lose the freedom to independently use MySQL for one and MongoDB for another. Even if the same tool is used for all, when you do maintenance or migration on one you're forced to do it for the rest. All this adds up to some coupled services that make them harder to maintain and scale.
you can have common database for all microservices, it is one of the microservices patterns:
https://microservices.io/patterns/data/shared-database.html
https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-data-persistence/shared-database.html
check those links to see advantages and disadvantages of this approach.
We are developing a multitenant application with shared schema for a web application. I would like to know the best practices for designing UI strategies.
We will have different roles for saas owners like Adminsitrators, Helpdesk, Account Manager so The SAAS owner may need to have multiple users who will acess the application and do their job.
HelpDesk: If a tenant put up a ticket, helpdesk team shall be able to view and solve.
Account management: Account Managers may need to access the payment information of the tenants for following up the tenants.
ServiceManagers: To perform maintenance and upgrades etc.
In this case
Do we need to have different UI for "Saas owner" and "Tenants" or is it better to manage it with permissions and roles?
Any best practices?
There are many facets to decide on the mode of delivery
In case you prefer to use Micro FrontEnds, admin and tenant functions can be separate. However, the individual functions like help desk,Accounts management can be a separate micro frontend
There should be options for a tenant to white label the UI (custom logo, custom theme, custom layout (more development effort)) etc.
With or without micro frontends, your UI layer should be working based on the permissions that comes as an aggregation of the user's roles (even across tenants).
The UI always has probes to the API to get the permissions and render the various UI components based on the granted permissions to the user.
We used to build custom UI components like custom grid, custom forms etc so that the permissions could be used to show or hide the various UI elements based on the permissions that a user might posses.
Ex: In the context of a Administrator, I will be able to see all the team members, but in the context of a Service Administrator, I will be able to assign members to various tenant functions like help desk, accounting etc which the Administrator will not be able to perform, but can view the mappings.
Similarly, your business requirements will drive the UI, hence if you follow using the permissions for the UI, it is always very fine-grained and easy to manage than depending upon higher levels of abstraction like Roles.
HTH
I have three client-facing web applications all on different subdomains (one of these web applications actually has 700+ different subdomains that are changing all the time). I've written an oAuth server that I was going to use to allow users to login to each of these systems; this works, but I've begun running into differences between what's happening and what I would like the behavior to actually be when writing the logout code.
Some of my requirements for single sign-on are:
If logged in on one system, you are logged in on all systems (obviously).
If logging out of one system, you are logged out of all systems. Even across subdomains.
If you are logged in on two different machines, for example -- a cellphone and a desktop. When logging out on your cellphone, do NOT logout on your desktop.
We already have written the oAuth provider and we'll be using it for projects not coupled to our domain (API's, etc.), but I'm not entirely convinced that oAuth is the best solution to use to meet the requirements outlined above. I'm thinking that maybe a shared session would be better. The shared session idea would involve a cookie stored on the main domain that has information about the currently logged-in user.
What are the pros and cons of either approach? Are there other approaches you might take? Are there security risks to consider? Concurrency and scalability considerations? Please help!
I would have taken oauth route with a variance.
Oauth :
The approach I would prefer is - access token issued at a device level (User- Application/Device) .
Ie there will be a process for registering your device and granting access for it.
This will result in the generation of an access token specific to the device and stored in it as the case may be. (For eg:- for mobile you may need a longer expiry access token and webpage a lesser duration one).
This way you can decouple the login/log-out across devices.
However the con of this approach is:
More complicated implementation, as it involves device registration
Tracking the action of each user will be difficult as you have two or more access token tied to a user.
Pros :
This is a fairly standard way
The Con 2 can be worked around (Adding access token attributes etc).
Session based SSO management
Pros :
Simpler than OAuth
Cons :
Security constraints around -session/cookie handling
Extendability at later point to add more use-cases is limited
I am looking to learn a little more about Oracle Identity Analytics (OIA) and how it works in conjunction with other Oracle Identity Management (OIM) products. For example, what is it's role in Identity/Access Management and how do companies typically utilize it?
You can think of OIA as of an accounts and entitlements warehouse where you'd go to figure out who has access to what, when OIM is more oriented to providing automation in managing (granting and revoking access).
Where I work we utilize it mainly for Identity Audit. It covers prevention and reaction to Segregation of Duties violations. ( For example developers shouldn't have direct, high-privileged access to production environment - that would be a violation ). It's done by designing and executing Identity Audit Policies and Rules against set of employees.
Unfortunately the tool has a lot of deficiencies, so one needs to test it thoroughly before making final decision. Some of them you will be able to solve by writing some small scripts, but some of them are fully on Oracle (scaling, performance, WebUI) so you might want to wait to find out more details about OIG (Oracle Identity Governance suite) that they've announced in Oct'12 ( http://www.oracle.com/us/corporate/press/1859216 )
Oracle Identity Analytics (OIA) augments the provisioning, re-certification and privileged access components of OIM by allowing you to run Audit Policies and Role Management.
OIM allows you to define roles to automate and simplify provisioning, but it does not have the role mining capability to suggest roles based on Who has access What already. Therefore in OIM you have to manually define the roles for users. OIA can partially automate the process by looking at the data bottom up to find commonality. Oracle suggest a hybrid approach, a combination of the two.
The audit polices are aimed at Separation of Duties (or toxic combinations) which allow you to prevent access being granted where there is a conflict of interest. A typical example would be the permissions to raise a payment request and permissions to approve a payment request in some software. This is particularly important in highly regulated environments such as banking and the health sector.
In OIM for Privileged Access you would not normally use a SoD constraint for a user to have both a non-privileged and a privileged account. In fact you would want a user to by default use the Standard account and then Step-Up through a break glass process to get their password and use a Privileged Access manager to maintain the audit trail. I am more familiar with CyberArk than the Oracle product included as part of OIM.
Under Oracle Identity Governance 11g PS 2 the licence agreement should give you all the products in the suite. Over time Oracle are further integrating the two products.
My manager keeps talking about how I will be "developing" an Application Express "security module", however from what she told me we need to have, I don't see what there would be to develop, seeing as Apex already has authorization/groups which allow for various groups of people to see various content.
Is there something that I am missing? What does she mean by a "module", or is it just general wording?
APEX provides several different ways to authenticate users. One approach is to use the "Application Express" authentication scheme and just to create APEX users. Another approach is to use the "Database Account" authentication scheme and to create Oracle users. A third option is to create a custom authentication scheme and to implement your own user management functionality.
Application Express authentication tends to be the easiest to deploy for a small application but tends to get unwieldy over time. It's hard, for example, to give an application administrator the ability to create APEX accounts. You can't tie an APEX account in to a single sign-on solution. It's not easy to integrate with the permission management systems that other applications use. If you're deploying an application in a large company, the last thing the security department needs is one more place where they need to create user accounts, manage privileges, de-activate accounts when someone leaves or changes roles, etc.
Database authentication tends to be more scalable than APEX authentication since Oracle database account provisioning is likely already part of your organization's authentication and authorization infrastructure. On the other hand, that still means that you're creating an Oracle database user for every user you want to create in your application which probably involves a call to a DBA (technically, you could create database users from your application, but most DBAs are going to be concerned about the security implications of that). If you intend to create an internet-facing application with tens of thousands of users, database accounts may get unwieldy.
I'd wager that the vast majority of medium to large-scale APEX applications use a custom authentication scheme. That may involve creating a USER table where you store the username & the hash of the password or a query against an LDAP/ AD repository. That sort of approach provides the most flexibility since you can code whatever you'd like into the authentication system. You can hook into whatever custom authentication/ single sign-on solution the organization happens to use. It probably makes creating new users from within the application much easier (obviously depending on how the authentication system is designed).
My assumption is that your manager is expecting that you'll be writing a custom authentication scheme for your APEX applications.