Scenario:
I have an OpenAM instance with only the default realm configured. I have set up my Organization Auth Chain with a single LDAP module that allows my users to self register.
I also have set up another chain, called adminChain and set as the Administrator Auth Chain, with a single Data Store module in order to allow the amAdmin user to login using the /console url.
Problem:
My problem is that this second chain allows also non-admin users from the LDAP data store to login, which actually makes sense because it's using the DataStore module. But then how can I prevent normal users logging in with the admin chain? I want them to be limited to a specific chain only.
You should use the root realm for administration and sub-realm for operations.
In fact OpenAM will use all configured user data stores in a realm when it's configured to support the requested operation.
As a workaround you could set the value of Authentication Naming Attribute in the user data store config to an attribute which does not exist in the entries. This will make 'datastore' authentication for regular users fail. AmAdmin can still authenticate because this identity is stored in a special data store which does not show up in OpenAM configuration.
Be aware that you may be subject of a bug, as in older versions the DN-Cache is leveraged during authentication.
Related
I am currently looking for a method to provide site wide authentication, for services exposed to the cloud, on the site I am responsible for. Some services are a Python based, some in PHP and some in Perl. Individual services would need to be able to get access to the user profile and the associated roles.
On the main page users are logged in and a cookie is created using a JWT token. The main site is using NodeJS for the auth system and is built in-house.
At this point I am wondering whether we should use OAuth2 across the site or whether there is another approach that may be simpler, where we don’t need to deal with inter domain requirements?
The approach you're currently investigating is the re-use of a JWT as an authentication token across multiple services. Although it's technically possible - it is not the ideal secure approach.
The most secure approach is for separation of application contexts, whereby each application should be tied to a different application credential (in OAuth2 terms). This is ensures that the user receives a credential unique to that application, allows the credentials to be managed/revoked separately and audited in isolation.
To implement this smoothly for UI flows requires an identity provider that supports SSO, and also assumes that each UI application can handle negotiation to the IDP to access that SSO session.
For interactions that are system to system authenticated, eg. Python, you would need to use system to system authentication (OAuth2 client credentials) that again have its own credential. In the case where you need access to the end-user's profile, a management api key (or similar) would be required.
I have a nodejs webapp with many users with a custom login process. I would like gitlab to accept that authentication and not force users to create a new app. What is the best way to accomplish this?
I would go for OAuth 2.0 Single Sign On (SSO). Below you can find the architecture diagram taken from here. As you can see the client is redirected to log in in the OAuth2 provider to get a valid token for authentication. The OAuth2 server must be configured for the application requesting access including the secret, the client id and the callback URL.
You can configure GitLab CE to sign in with almost any OAuth2 provider. Only be careful with the limitations:
It can only be used for Single Sign on, and will not provide any other access granted by any OAuth provider (importing projects or users, etc)
It only supports the Authorization Grant flow (most common for client-server applications, like GitLab)
It is not able to fetch user information from more than one URL
It has not been tested with user information formats other than JSON
You also need to configure your node js web application as an OAuth2 server. There are npm availables with the source code here.
Recommendation
I would install some open source Identity Management to separate the user management from your webapp, provides better integration with other third parties and forget about encryption and other stuff you need to take care in your webapp. There are multiple options such as KeyCloak for instance.
You have to define a dedicated user , and use the private_token of this user to login for ALL users that will use your application.
The restricition would imply all users will have the same rights ....
The other solution is to use the Private Token of the user at login. In this case , only the rights of these particular users will be used.
Is there a way to configure Tomcat 8.5 or 9 to allow the user to log in with either their username or their email address?
I am willing to consider using a 3rd party security container if this solves the problem.
Currently using Tomcat JDBC Realm but only with username. Do not see ways to modify this Realm to allow either username or email address.
Have a look at the Combined Realm which allows several authentication mechanisms. In your case, you probably need 2 DataSourceRealm (rather than 2 JDBC Realms) accessing the same table but with different userNameCol parameters.
It's interesting to note that you can mix an authentication based on a tier (database, LDAP) and an authentication based on a local file (UserDatabaseRealm). Then you can still log in with an administrator user even when your database is down and all of the application seems dead to the other users. If there are things that don't need the database, you still can work.
I have a cloud app that needs to access my Db2 database. It requires both read and write access to some tables. How can I restrict access to that specific app and the usage pattern? I don't want that userid have database access outside that context.
Db2 has the security feature of trusted contexts. A trusted context describes attributes of a database connection. It consists of the userid and can include the application's IP address or hostname and the required level of connection security, e.g., whether SSL is mandatory.
Within the cloud app use a userid (authorization id) that does not have any Db2 privileges. Revoke them if they exist.
Create a new database role. Grant the connect privilege and the required table privileges to that role.
Create a trusted context for that userid from 1). Provide the app's hostname and, if you want to enforce SSL, set the encryption attribute to a value of high. Assign the role from 2) as default role.
The userid can only access the data if connected in the way defined in the trusted context object. See this example on trusted contexts for SQL code snippets and more links.
Are both, your app (CloudFoundry or Kuberntes) and DB, inside Bluemix?
In that case, you can bind the app to DB and the platform will inject DB credentials directly into the app as environment variables or for some CF build-pack (Liberty), even modify the app to add configuration.
I have a main website running on AppEngine. It's on a subdomain like main.example.com. This main application is a content portal for our customers. It offers an Ajax application built on YUI. Customers can upload data to it. Users authenticate using Federated Login.
The Ajax application on it allows users to process the data previously uploaded. To do it it should use an webservice running on other subdomain like service.example.com. The webservice does not run on AppEngine but on our services - it's CPU heavy and built on other set of technologies. It would need to download the data on main application - but the downloading service - like everything on the main application - is behind the authentication wall.
I could programatically always allow the service to download wharever it wishes but I think this can turn into a major security problem.
How can I reuse the OpenID authentication "token" to allow it (the service) to appears to the main application as the authenticated user so it can download data? Or If I can do this what would be the best way to accomplish what I intend to do?
You can't really reuse the authentication token. What you should use is something akin to OAuth, though since you control both ends you can make it somewhat simpler:
Generate a shared secret, accessible by both main.example.com and service.example.com
When a user accesses service.example.com for the first time (no authentication cookie), redirect them to main.example.com/auth?continue=original_url (where original_url is the URL they attempted to access)
When you receive a request to main.example.com/auth, first log the user in the regular way (if they're not already). Then, take their user ID or other relevant credentials, and generate an HMAC from them, using the shared secret you established in step 1. Redirect the user to service.example.com/finish_auth, passing the computed HMAC, the authentication details such as user ID, and any parameters you were passed in such as the continue URL.
When you receive a request to service.example.com/finish_auth, compute the HMAC as above, and check it matches the passed in one. If it does, you know the request is a legitimate one. Set an authentication cookie on service.example.com containing any relevant details, and redirect the user back to their original URL.
This sounds complicated, but it's fairly straightforward in implementation. This is a standard way to 'pass' credentials between mutually trusting systems, and it's not unlike what a lot of SSO systems use.