I already have an existing user base (user, roles,user_roles table in database). How could I create custom authentication and authorization module to use this to interact with Jackrabbit repository which is file system transient repository.
I can create a custom login module extending the AbstractLoginModule but principal, usermanager, userimpl etc how will I get these?
User, Roles etc are nodes in repository so how can I use my user base from data base to create access control based nodes and files ?
Will I able able to achieve this at all?
This is JAAS authentication and Authorizations.
You can take a look in https://github.com/ehsavoie/Silverpeas-Core/tree/master/lib-core/src/main/java/com/stratelia/webactiv/jaas where we did ourown implementation.
Related
The goal is to get an access token with a custom set of roles.
My scenario is that I have an User Storage Provider SPI that looks into an Oracle DB for authentication. It also checks users permissions defined in other tables of that DB. I would set that permissions into the UserModel object returned by the SPI.
Now I would like to define in Keycloak (using the administration application) custom roles and configure them so they are included in the access token of the user depending on some rules over the user's permissions that I've set previously into the UserModel. The idea is to be flexible and allow to change the configuration between roles and the user's permissions found in DB.
I've read the theory about mappers and policies but I'm not sure how to manage it and I can't find an example that ilustrates the process.
I'm currently working on setting up Identity Server 4 as a centralized authn point for multiple products as well as a federation gateway. It's all pretty standard:
I have users that can authenticate into an SPA that uses the OIDC-Client js lib to interact with my identity server using the implicit flow. User stores are as follows:
a user store local to IDSRV (Asp.net identity). They'd enter their credentials into a form hosted in IDSRV, just as seen in the docs
an openid connect or oauth 2 store, either a social (google, linkedin, etc) integration or an IDP provided by one of our clients. Also working, just like in the docs.
a "destination key", described below
Destination key - the application in question has the ability to generate a unique link with a key (pretend it's a guid, for example purposes). This key maps to a specific destination in the app, and serves as a defacto authentication. It's a lot like the resource owner password flow, except that the key is the sole component needed to authenticate. (I'm aware that this isn't the utmost in security, but it's a business decision, taking into account the lower levels of protection).
Which brings me to my question: what is the proper "identity server" way of accomplishing this destination key authentication mechanism. Some things I've considered:
a custom authentication scheme configured in IDSRV. I added a generic scheme called "destkey", with accompanying AuthenticationHandler and AuthenticationSchemeOptions implementations. The HandleAuthenticateAsync method would use an injected service to validate the destination key. For some reason, it ignores this and continues to validate against Asp.Net identity
a custom grant type. I looked to create an implementation of IExtensionGrantValidator that would utilize the destination key service to validate the key. I haven't been able to get this working, at least in part because the OIDC lib doesn't allow the configuration of a grant type.
repurposing the "Login" method of the AccountController from the IDSRV Quickstart [HttpGet]
public async Task<IActionResult> Login(string returnUrl) This would basically strip the destination key off the URL and call HttpContext.SignInAsync using the dest key as the subject. This isn't working, as it seems to check the database for the existence of the subject (which is how I ended up attempting to create a custom scheme as described above)
Any thoughts on the proper extensibility point to accomplish this would be most welcome...
Not sure if this is the best approach, but I ended up creating a custom implementation of IProfileService. It wraps an instance of IdentityServer4.AspNetIdentity.ProfileService, and checks for the existence of a "destination_key" claim. If the dest claim exists, it references the destination key service for validation - otherwise, it delegates the logic to the underlying ProfileService instance, which uses Asp.net identity.
In the Login method of the AccountController, I simply check the acr_values for a destination key passed from the client. This is set in the signinRedirect method of the OIDC-Client.js lib.
I have a Web API project of ours that needs to be secured. I am planning to allow the user's that registered with my app to use the API [Forms Authentication], users with their own organizational accounts [ADFS] and Social Sign-In.
I have all the middleware available to plug-in and make available to the user's. However, in my application I do have custom roles and privileges that are to be provided so that my application authorizes the service calls based on the existing privileges. What is the best way to accomplish this.
I think that I will be required to provide my own custom implementation of the UserStore and UserManager with my own IUser Implementation.
Kindly suggest the best practice for this scenario.
With multiple authentication middleware registered, you can get multiple claimidentity's.
register each type of authentication you want to support.
I would be sure to add a claims transformation module at the end of the pipeline. Thinktecture has an example. ThinkTecture Owin Claims Transformer
This would give you one place to look up and add all the application type claims for an authenticated user in one spot.
Simple pseudo example (geared to webapi, but concept the same). Authenticate with bearer or basic or both then transform.
//identity 2.0 user manager stuff used in your modules
app.CreatePerOwinContext(ApplicationSession.Create);
app.CreatePerOwinContext<ApplicationUserManager>(ApplicationUserManager.Create);
// Token Authentication -> get a principle
app.UseOAuthBearerAuthentication(OAuthBearerOptions);
// Basic Authentication. -> get a principle
app.UseBasicAuthentication(app.CreateLogger<BasicAuthenticationMiddleware>(),
"Realm", ValidateUser);
// transform claims to application identity. Add additional claims if needed
app.UseClaimsTransformation(TransformClaims);
It sounds like you are looking for externalized authorization. Externalized authorization is the act of:
decoupling business logic from authorization logic
expressing authorization logic as centrally managed, centralized authorization policies
protecting your APIs through a common layer
enabling fine-grained & dynamic access control through the use of attribute-based access control (ABAC) which extends what's possible with RBAC (role-based access control).
Have a look at XACML, the eXtensible Access Control Markup Language. You can find some more information on OASIS's website.
Also check out NIST's project on ABAC.
Once you defined your authorization logic, you can decide how to enforce it. This can be done either via direct enforcement at the entry of your apps or can be done in a provisioning way whereby the permissions derived from the authorization policies are fed into an authentication token e.g. SAML as attribute assignments.
HTH
This is what I ended up designing for a system with similar requirements. The key is to separate the authentication and authorization logic.
Build Owin authentication middleware components that take care of establishing user identity based on various login methods you mentioned. Looks like you have this accomplished. Set ASP.NET identity based on the user.
Retrieve the roles/permissions for the logged in user from your store. This can be done as a separate Owin middleware or a part of your authentication. Add the permissions as Claims to your Principal.
Extend your roles/permissions store to map API service operations to the application permissions.
Implement a custom API Authorize attribute and apply it to every API operation. In this attribute you will have access to the operation name and the user Claims (permissions). Match the Claims with the permissions you mapped in the step above. If there is a match, return IsAuthorized=true, otherwise, return false.
Here is a similar issue at a simpler level.
How do you setup mixed authorizations for different authentications in .net (web api 2 + owin)
I am trying to protect a Java servlet with OpenAM + J2EE tomcat agent. I got this part working by using embedded OpenDJ of OpenAM.
Now I am trying to authenticate against a LDAP server, so I added a LDAP module instance for OpenAM, but I get "User has no profile in this organization" when I am trying use uid/password of an user from that LDAP store.
I checked OpenAM administration guide on this the description is rather brief. I am wondering if it is even possible to do this without using the data store configured for OpenAM?
The login process in OpenAM is made of two stages:
Verifying credentials based on the authentication chain and individual authentication module configurations
User profile lookup
By configuring the LDAP authentication module you took care of the authentication part, however the profile lookup fails as you haven't configured the user data store (see data stores tab). Having a configured data store allows you to potentially expose additional user details across your deployment (e.g. include user attributes in SAML assertions or map them to HTTP headers with the agent), so in most of the scenarios having a data store configured is necessary.
In case you still don't want to configure a data store, then you can prevent the user profile lookup failure by going to Access Control -> <realm> -> Authentication -> All Core Settings -> User Profile Mode and set it to Ignore.
This is unrelated to authentication but it's related to authorization ... you have to configure appropriate policies ... see OpenAM docs.
Agents will enforce authorization, OpenAM determines if the user has the permission to access a protected resource.
As Bernhard has indicated authentication is only part of the process of granting access to a user. He is referring to using a Policy to control access.
Another method is to check if the authenticated user is a member of the desired group programmatically. This can be useful when you want access control over resources that OpenAM doesn't know about (e.g. specific data).
For example, lets say that you want different groups to have access to different rows in a table in a database. You can retrieve the group information associated with the user and add that to your database query, thus restricting the data returned.
I'm sure that you could do this with OpenAM as well using custom modules to allow the policy to use information in the database as resource, but I've found it is much simpler to perform this fine grained access control in your code, and is in all likelihood significantly faster.
Simple situation. An existing project will need authentication and authorization and I need to design it. First of all, I choose to divide the whole thing into two modules, one for authentication and the other for authorization. Both will be seen as blackboxes for the project. For now, the authentication module will just use the Windows account of the user, link this to an unique GUID and offer this GUID to other modules as the user ID. Newer versions of this module will do more "magic" but for now, this will be enough.
The authorization module will be a bit more complex. It will use the GUID and link it to the access rights of the user. With the GUID, it could communicate with the authentication module and request more user information.
But next to roles, should the authorization module also manage some other user data, or would it be better to add them to the authentication module? (Think about name, address, phone, office name, gender and how they like their coffee...)
Basically, the authentication module will contain an interface and customers who like to use our software can use out default authentication module or use the interface to develop their own version. So I don't want it to keep too much information.
And would I need more information in the authentication module than just the roles?
If the applications using the authentication benefit from shared information, such as change in email address, it could be stored in the authentication system. In fact, the authentication call can be implemented as retrieval of the user information along with some credential such as password.
Authorization (roles, access rights, etc.) on the other hand could be more specific to the individual application and its capabilities.