We are in the process of upgrading to Domino 11.0.1 and using HCL's AppDev Pack 1.0.6. In our cuurnet website (Domino 9.0.1) we use an auxillary Domino addressbook to store our users login information and we do not use or create user's id files (ie: jsmith.id). If we use OAuth for authentication, do we need to create id files for our current registrants and store them in the IBM_ID_VAULT and can we still use an auxillary addressbook to store and retreive the information?
The "Functional IDs" (The ones that act as apps to access databases you give them permission in) will require an ssl certificate. Those IDs only need to be vaulted if you wish to do crypto or signing operations.
End users granting access to the app ids(functional ids) do not need to be vaulted, as we do not yet support signing/encryption on the user's behalf (yet).
Related
I'm using strapi.
User registered with local api getting all data same as super admin.
How to implement or which plugin setting restricts, non-admin user to access data that he has added. (Similar to author-admin role)
This depends. Do you mean access their own data via the default Strapi backend? if yes, you could give them the Author role. Authors can always onle edit their own content.
If you mean access via REST API, you should be able to accomplish this with a policy, where you can restrict specific access based on your code entirely.
I have made a Java ExtLib XPage custom REST service (CustomServiceBean) database basing on this solution: https://setza-projects.atlassian.net/wiki/spaces/RS/pages/363593730/IBM+Domino
I modified it though to use NotesCalendar class to create, update and delete events & resource reservations (so everything in fact is processed by the calendar, I'm only using raw documents for reading $Rooms in names.nsf and $Reservations in the reservations database). Everything works fine so far, it uses current session to open the calendar. I have some concerns regarding the permissions though.
What I want (and need):
Ability to create calendar events & reservations as SPECIFIC users, I don't want just one "main" user that will create everything. I want each IBM Lotus user to be able to login with their credentials and create or update their calendar events.
This database with XPage will be deployed on our client's servers, so I don't want to require some special configuring for each user in order to be able to access my REST service.
I set up a new local installation of Lotus Server and created a new application using my XPage database as template, and I couldn't access the API neither with admin account or other accounts:
HTTP JVM: CLFAD0229E: Security exception occurred servicing request for: /db.nsf/services.xsp/api - HTTP Code: 403. For more detailed information, please consult error-log-0.xml
As soon as I added my admin account to Server configuration -> Security -> Sign or run unrestricted methods and operations, it started working again. Not only for the admin account, but also for other accounts that were just created with an internet password and weren't assigned any specific roles or permissions. I didn't even sign the database.
So my question is, is this enough in order to get it working on client's production server? It kind of makes no sense to me, but it worked on my local server so I'm not sure, I'm new to IBM Lotus and I'm just doing an integration REST service.
If not, how could I do it, so I wouldn't really need to put the end client (Lotus server owner) into the hassle of configuring each user, while still being able to access the API as any Lotus user (providing the username and password)? I can either log-in as each indepentend user, or perform some impersonation with a "main" privileged account (create entries in someone else's calendar as him), although I think there is no way to do it in Java, because .getCalendar is a method of the Session class, I tried using createSession(), but I wasn't able to.
Every notes application needs to be signed by an administrator with an ID known to the customers environment. The Id which is used to sign the db must have the appropriate rights, through the security tab in the server document. If the app is not signed properly, the app won't run. Once the app is signed, it runs in the authorized users session with the users rights.
I'm new to couchDB and still reading tutorials. My question is if it is the normal way to represent every user of my application as a new database user, as it seems to be explained that way everywhere I look?
Let's say I have an online game with many different players - would I create a new "database user" for every player who registers? Or would I make my own database "players" and create a sign-in logic in the app? Not being used to document-driven DB's it seems strange to me not to distinguish between db-users and users of my application...
You could do it either way. First about couchdb users
Users in couchdb are stored in a special _users database
Database permissions are handled by a special _security document. This is specific to every database.
In security documents you add users that you have already stored in the _users database previously.
So you can certainly create a database per user. Before doing that ask yourself if the data that you store in each database is truly independent. Because you can't run map reduce queries across databases. So if you are planning to do aggregation across data for different users then this approach will not work.
Couchdb can also help you with app level authentication. Since couchdb uses a cookie based authentication:
Store your "business logic users" in the special _users database.
Authenticate it with the _session endpoint.
Extract the cookie header and sent it with your application headers.
All the logic for authentication is implemented for you by couchdb. All you have got to do is manipulate headers. Send the cookie from your application and when authenticating with couchdb send it with couchdb's headers.
If you prefer to write entire session management in your application that is fine too. In this case simply store the users in your database and verify that they exist before authenticating them. Like you would do with another database.
The benefit of using couchdb is that it is secure by default --using pbkdf2 encryption scheme to encrypt passwords.
If you instead want to manage all docs using a single database, but still implementing read/write ACLs, you can check the Chatty Couchapp Tutorial app from Smileupps App Store
It's a pure couchapp, relying on CouchDB only as its backend. The tutorial is still work in progress but the couchapp is fully working and you can download its source code.
It implements role/user based read/write ACLs using a single CouchDB database. This way you don't have to setup N replications where N depends on the number of your users. You only have one database containing all your data, easy to be queried on the fly(with temporary views) and for maintenance operations. Of course you can decide to increase the number of database, depending on type of your data and use cases.
A single couchapp contains all the necessary code for frontend, admin dashboard and server side API implementing business rules
The user, depending on his roles have different access to different sections. i.e. he can access the frontend website, but not the admin dashboard.
You can install the free trial, then download the source code with Smileupps deployment tools, change it, upload it back and check your changes.
I'm starting on a project to allow an existing web application to use active directory for authentication but leaving authorization within the application. I want to start off simple so I was thinking a user would type their AD username/password into my existing login form, I would then do an ldap bind against the AD server to authenticate the user.
Once the user is authenticated, I would pull that user from my database which has all the authorization information as to what functions the user can see.
My question is what is the best AD element to store in my table to make the association? In the past I've used username but after looking at some of the elements that AD returns I was wondering if I should use the security ID or GUID or something else?
I've been burned when a username changes like an employee gets married or divorced... so I know that is brittle.
I was targeting windows 2003 AD and above if that makes a difference; this is for a product where some clients have large AD forest and some are small networks.
Storing the SID is the most reliable approach; this is the unique ID that all Microsoft AD things use, security groups, permissions, etc.
If you're building on .Net you should seriously consider .Net 3.5, there's a new namespace System.DirectoryServices.AccountManagement that greatly simplifies code here and gives you nice neat objects to go against.
Unless users share computers, why not use Windows integrated logon? Much easier on the users, easier on yourself as developer, and more secure (one less place a password can be sniffed).
Need I mention that allowing user identities to change is poor corporate security policy? Makes traceability harder, permits some novel attack vectors, and gives you this headache.
As Nick mentions, the SID is a stable identifier, but not something you should ask a user to enter for him/herself!
First, a little background: We have an intranet site based on WSS 3.0 that is hosted on a server in DOMAIN_A.LOCAL and set up to use Integrated Windows Authentication to authenticate users against Active Directory user accounts of DOMAIN_A.LOCAL.
This setup works just fine for users who are logged into Windows using an AD account from DOMAIN_A.LOCAL, but when users try to access the site from a PC logged into Windows using an AD account from a different domain (i.e. DOMAIN_B.LOCAL) the following problems occur:
The user must manually enter their credentials as DOMAIN_A\UserName rather than just UserName because otherwise, Internet Explorer automatically inserts DOMAIN_B and causes authentication to fail.
Once logged in, if the user does something that requires the browser to pass their authentication through to a client app, such as clicking on a Microsoft Office document in a document library in order to open it for editing, it appears that invalid credentials (presumably DOMAIN_B) are passed automatically, thus forcing the user to manually enter their DOMAIN_A credentials again.
My question, then is this:
Is there any way to implement a "default domain" type of behavior when using Integrated Windows Authentication (as can be done when using Basic clear text authentication) so that if a user on DOMAIN_B does not enter a domain before their user name, DOMAIN_A is inserted automatically for them?
Of course, I realize this deployment may be fatally flawed, so I am also open to suggestions for a different implementation.
In summary, the main problem stems from two different kinds of users needing to access the same content on one SharePoint site. The users in DOMAIN_A all have their own full-time workstations where they log into Windows as themselves. The users in DOMAIN_B unfortunately have to use shared computers that are logged on using generic "kiosk" type accounts that have no permissions in SharePoint -- thus the requirement that the DOMAIN_B users must provide their credentials on demand when accessing a given page in SharePoint. I would like to preserve the convenience of the Integrated Windows Authentication for the "static" users of DOMAIN_A while minimizing the amount of manual authentication that the "kiosk" users in DOMAIN_B have to endure.
DOMAIN_A.LOCAL must trust DOMAIN_B.LOCAL, otherwise users from DOMAIN_B.LOCAL will receivie a credential prompt since their DOMAIN_B.LOCAL account is unknown within DOMAIN_A.LOCAL.
Given that DOMAIN_B.LOCAL is for kisok users, you probably do not want to trust this domain.
You will need to extend the web application into a new zone and either implement forms based authentication, or use Windows Authentication with a reverse proxy such as ISA server.
I was searching the internet for SharePoint user accounts with multiple domains and came across an interesting tool called Microsoft Front End Identity Manager. Have you heard of it?
So… If your using a multi forest deployment where user accounts are distributed across two or more forests. This is often seen when two organizations merge and need to access domains from both organizations. You can use the distinguished name (ms-ds-Source-Object-DN) attribute in the user object to create an association between the user accounts. In this association one account is considered the primary account and the others are the alternates of the primary account. There is a tool called Microsoft Front End Identity Manager to create this relationship between user account objects. One feature of Microsoft Front End Identity Manager is that SharePoint server can maintain a list of alternate accounts by which the profile is identified. When you use either account to find the profile of a user, SharePoint server returns the primary account profile example (domain\username).
Probably not what you want to hear, but you may want to resort to forms based authentication.
Unfortunately if you want to retain the Microsoft Office integration (which is what it seems you want), you will have to stick with Windows Authentication. Using Forms Authentication will remove most of the features you seem keen to preserve, there is more information here.
Ideally you want to use the suggestion that Jason mentioned, which would be some sort of reverse proxy. However there would probably be a cost implication if you don't already have something like ISA server, so in reality it's probably best for the DOMAIN_B's to learn to type DOMAIN_B\ before their username.