We are looking to take an approach where there are service accounts in MarkLogic, but not accounts for all actual users. We would use a custom authentication token, JSWT in this case, and then via xdmp:login, elevate the calling user to the appropriate roles.
This is all fine if we create a custom HTTP server with our own rewriter to our modules. If we want to leverage the already built out REST API, is the only option to essentially create a wrapper around each of the XQuery modules that get dispatched to from the REST rewriter, in order to call the xdmp:login flow prior to fulfilling the rest of the REST api workflow? I did not see any way with the enhanced HTTP rewriter configuration to run arbitrary XQuery code before the dispatch flow.
Is this a feasible idea, or just a bad idea?
Best practice with the REST API is to use a middle tier. Exposing the REST API directly to your end users is analogous to doing so with an ODBC connection -- something you generally wouldn't do.
My suggestion is to set up a middle tier and use that gather credentials, then login as needed.
You can modify the out-of-the-box REST API endpoints to perform an xdmp:login, but of course that creates complexity when performing an upgrade, and when deploying an app. That's really a worst-case scenario.
Are you able to map all of your users to a much smaller set of ML users, perhaps on the order of dozens? Then a middle tier can do something similar to xdmp:login - it can look at the user's profile and determine which ML user to connect to ML with. That's not quite as flexible as xdmp:login, which lets you pick any roles you want without creating a user as a holder for them, but it may do the trick.
Related
I have an application where right now a user could work in different context : in the same client application he could switch his context and work either for a company1 as "Administrator" or if he switch to the second context , he could work as "Editor" for the company2…
This was done by using a custom homemade authorization module, but we are trying to use openid-connect now so we are trying to find some solutions with KeyCloack.
Is it possible to assure the same kind of thing in Keycloack ?
It's possible. BUT it's not something that anyone who doesn't know the internal of your custom implementation could give you a solution.
Authorization services provided by Keycloak is quite flexible and of course complex. I suggest you to take a look at the following link and see which of of authorization solution can answer your requirements and would also be possible to adopt your system to use it (e.g. RBAC, ABAC, CBAC, etc.).
As an example, one solution could be to consider each company a resource and then each user of the application, can have different roles/permissions on each resource. So in Keycloak you define who has what roles on which resources (companies) and then in your app, you check those to see if user is authorized or not. But I'm pretty sure when you get a better overview of the Authorization Services in Keycloak, you would come up with a much better idea.
Keycloak Authorization Services
We're starting to migrate our Website to a REST Service based system and are in the process of developing the core right now.
In our current setup a user has one or more "accounts" assigned which define what data he can see on the website. Only one account can be active for a given user at any time. Right now we store the selected account in the database and use it to filter all queries.
Now I'm not sure how to handle this properly in a REST environment. Possible solutions I found are:
Sending the requested account with every request
Storing the current account in the auth token. (We're using JWT for that)
Having the current account stored on the server and calling a specific resource to change it
Each of these has its pros and cons for our setup. Currently we're using the 3rd approach in our Website. But what would be the correct way to handle such a thing in a REST environment?
Yea the design you are dealing with is fairly bad, and what you really want to do is remove the state completely out of this system.
For that reason the first option is by far superior:
Sending the requested account with every request
If this is simply an id, there's a very simple way to do this, just prefix all your (relevant) routes / uris with this account id. For example:
http://api.example.org/accounts/{id}/...
This way the 'state' is maintained by virtue of which url you are accessing, and the server can be unaware of the state.
My task is to implement a resource server(RS) for IdentityServer4(IS4). The RS should fetch data from a database and send the necessary information as a json object back to the caller (client). This is needed because we have to return complex objects.
I already setup IS4 succesfully and its already running in Docker for testing purpose. I also setup the needed database.
My understanding of the flow would be, the user requests data from the RS sending the access-token, the RS then validates the token, checking if the caller is allowed to access the api using the IS4, if everything is okay the RS returns the data to the caller.
My problem is, as I'm new to this subject, how would I implement a RS? Do I create an API which is added as a scope to the user? Or is there a RS already implemented in IS4?
So yes you'll need to write your own API to serve your own resources, IdentityServer will only manage your identities for you (as well as handling external logins if that's what you need). I'd recommend going to the IdentityServer docs and working through the quick starts in order as shown below:
This will give you a good start but you'll then need to go away and research APIs more generally, there's a tonne of good info online about building (RESTful) APIs. You may find it useful to sign up to something like PluralSight and work through a couple of their courses, they're often very good.
One other thing to bear in mind is that IdentityServer is for identity, in other words Authentication and not specifically for Authorisation so you may need to add something for this. You can of course use a users identity for authorisation purposes but in most cases you'll probably need to augment the info you store about their identity to authorise them for access. See this link for more info around this topic.
The basic architecture of my application is React front-end consuming a RESTful API sitting on top of a polyglot storage layer.
Front-end:
React consuming APIs
Back-end:
Python
Flask
Authentication
Auth0+OKTA
Everything is working great. However, I need to have different roles for the users. In other words, I need to control the actions that a user can perform on a resource based on the role.
Example:
-User A wants to add a new user
-He has a token in his request, so I know User A is Authenticated
-Now I need to make sure he can in fact add users base on his role.
I don't want to hard-code the user roles as suggested in other solutions, and I would like to allow for custom roles to be added.
Also, I want to be respectful of people's time, so if there is a resource that addresses my concern, please feel free to point me to it.
These are my questions:
1. Are there any best practices for implementing what I am trying to accomplish?
2. Could you point me to examples or tutorials discussing authorization(not authentication)?
3. Do I check at each service call if the authenticated user can also perform the action or do I provide the roles in some form after authorization, so a service request contains both the authentication and authorization token?(this seems pretty easy to hack so I am guessing no...)
If I sound confused on the topic of authorization, it is because I am. Please feel free to point me to any resource that have been helpful to you.
Thank you in advance for taking the time to help! I really appreciate it.
You can use a framework like Yosai that is based on Apache Shiro.
These are some features:
Enables Role-Based Access Control policies through permission-level and role-level access control
Two-Factor Authentication, featuring Time-based One-Time Passwords
Native Support for Caching and Serialization
Event-driven Processing
Ready for Web Integration
in SAML 2.0 you can use the AttributeStatement element to provide any kind of application specific information.
What I was wondering, is it really good design to pass business related information within a SAML assertion? Shouldn't this data be provided in a e.g. separate web services call?
I just want to ask for best practice in this case or any real world experiences.
Regards,
Andreas
It depends a lot on just what information you're conveying. For instance, on the application I work on, we use attributes to indicate what web site features should be shown to the user being logged on. That's clearly an appropriate use. Now, we also allow use of attributes to create a user profile, even though we have a web service that does the same thing (and in fact, the implementation calls the web service behind the scenes). It's not an ideal context for that sort of thing; there's no endpoint to convey the web service response to, or any errors resulting from the attempt. But we get a fair amount of resistance from customers, who don't want to have to call a separate web service before they can make an SSO call. So we've had to compromise. What we've done is require that if a customer wants to use this particular functionality, that they provide an endpoint (either email address or web page) to receive errors from the web service call. And if they're concerned about security of the information being conveyed, they can use standard XML encryption.