I am working with gitlab rest API, and gitlab is connected to LDAP too.
Now I am facing an issue is that if I add a user to LDAP store, this user need to do at least one sign in via web UI to get access token through API (/oauth/token)
My requirement is any users whose are added directly to LDAP need to generate access token through gitlab API without doing any sign in via web UI, please let me know the possible solution.
Thank you
Good morning Jamsheer,
That makes sense, since otherwise you would automatically create accounts for all the users in your LDAP, with the possibility of running out of licenses.
Currently there is an open issue where this is being discussed, with the possibility of creating all the LDAP users as deactivated and active them after the first login.
Add a way for LDAP users to be created before first login
In any case, this is not in place yet.
Related
For example if i have build a mobile application and using the nodejs REST api for accessing the backend.
I want to restrict the access of the application with same login credentials on a maximum of two devices.
For example me and my friend can have have access to the application with same login credentials but a third friend must not be allowed to have access to the account with same login credentials.
Can it be implemented with some kind of token. Can anyone please help me in understanding the concept to implement this.
Posting as an answer, since it does appear to be a solution.
It can be implemented with a token, but I think it's important here to maintain sessions. Also, you need to keep track of who is connected to what account, and from what device. You'll definitely need unique identifiers, and to know how many logins the account is already utilizing. If a user logs out, remove that device from the list until they login again. Read up on session management. I have had good success using PassportJS for stuff like this :)
I've successfully integrated the saml2-js package with my node.js application, and I've confirmed that the authentication process is completing successfully. However, I'm not really sure how to properly put the app or routes behind the authentication. The saml2-js example doesn't cover that scenario (and maybe that makes sense). So how do I put the app behind the authentication?
I have successfully completed our SSO over SAML2.0 task in my organization, so I might be able to help you, at least I can share my experiences.
So here's how we did it
first of all you need to find out if a certain set of users want to do SSO. This isn't that trivial because before authenticating themself you don't know who wants to login to your system. In our case, we have big corporate users. So we can't just put a "Login by Okta" or "Login by ADFS" button for every customer, because some customer wants the IdP to be Okta, another wants it to be ADFS etc. We solved this by introducing subdomains, and we identify the corporate account by the url. Then we can check what IdP that corporate account wants to use and put a matching SSO button accordingly.
then, when the user clicks the SSO button you create the login request after which if the user successfully identified himself at the IdP you are ready to create a security context (a.k.a session). Then this session will guard you endpoints and app. When you created the session the user is actually "logged" in to your app.
I would like to use Active Directory with a REST API Express backend: users would fill out a username and login form on the client side, and get authenticated with their Active Directory credentials, through the backend. Then, based on their user groups, they would see certain information. I have tried the node package passport-windowsauth, but I am not able to authenticate, possibly because I don't know what the bindDN or bindCredentials are. I have also tried node-sspi, and had better luck with this, but the issue with this is that it's only server-side, and as far as I can tell, I can't create a form that would then allow the user to authenticate from the client side. I am hosting this site on IIS, and using iisnode for the backend. How can I can achieve this Active Directory authentication with Node/Express server-side and a client-side login form, or in other words, not a .NET application?
Active Directory (AD) authentication is accomplished by binding to the Active Directory with credentials (not the credentials from the User form) supplied by your AD engineers. After binding, AD is searched for matching credentials (from the User form).
Basically you need to talk to your AD engineers about what you should use.
Then you need a /login/ route the user form sends to, the route accomplishes the login (AD bind, authentication) and returns to the client.
A simpler workaround can be to bind to AD with the credentials entered into the login form - a successful bind means the user is logged in. I would, again, talk to your AD engineers about how they prefer this to be done. I've run into problems in the past where it's taken a long time to authenticate users after binding so we used this as a workaround.
You might ask if your AD already has single-sign-on options - maybe they use Shiboleth or something similar.
You should try that package : https://www.npmjs.com/package/ad I'm not sure it will meet your requirements, but it's a very easy t work with Active Directory in a node/express back end.
My requirement is like - When User is already logged into Sharepoint then he does not need to enter his/her credentials on application.
Here i am using Node JS and HTML page to fetch Sharepoint information and rendering on page.
Every time Site/application is refreshed then it's asking for user credentials.
It should not ask while user is already signed-in to Sharepoint.
I have not tried anything as i have no idea and also i never worked on Sharepoint.
Note :- users are signing using AD account.
What is the best way to achieve this?
Can you please clarify:
what sort of data it is (list/file/library/search/other?)
how you're accessing data
what version of SharePoint
what the auth configuration is for SharePoint? (NTLM, Kerberos, ADFS etc)
As a node dev, you may want to look at proxying the data using sp-pnp-node or this. This could bypass the issue, but lack of pass-through or user-based auth could accidentally over-expose info. Depends on your use case.
I'm trying to use Windows Azure Access Control to avoid the security risks in using usernames/passwords in my app and to simplify the authentication. However, this is a site that can be used by medium or large companies that may wish to "pre-authenticate" users. In other words, they may want to bulk create users by putting in the users' Windows Live IDs and create their accounts automatically, before that user has ever signed in through Azure ACS. I could accomplish this by sending that user an email with a link to a one-time-use page to create their account, but I am hoping to do something a little more seamless.
What I'm trying to do is equivalent to how Team Foundation Service (*.visualstudio.com) lets you add users to a team project just by putting in their Windows Live IDs and once you do, they can log in and access the project, even if that user had never signed in to TFS previously.
What I don't understand is how to do that using ACS and System.IdentityModel. I can use the nameidentifier claim to uniquely identify a user, but how do I get a nameidentifier for another user through a given provider?
I'm sorry if I'm not explaining this well, so feel free to ask questions.
Not really an answer but just wanted to share my thoughts on the issue.
The problem with ACS and Windows Live authentication is that ACS never returns the user's email address. All we get back from ACS is a token telling me that the user is authenticated. This token is created based on your ACS realm (i.e. if you change the ACS realm, a new token will be created by ACS for the same user). Again, the admins of the company who are using your application can enter the email addresses of the user but there's no way to get that email address back from ACS.
Just thinking out loud :), there're a few things you could do:
You use ACS for authenticating the user and then use Windows Live REST API to get more details about the user using the token sent by ACS. By using Windows Live REST API, you can get more details like name, email address etc. about a user. Or you could use just Windows Live API for authenticating the user. I'm not 100% sure but I think this is what Team Foundation Service does. Do take a look at http://zud.io as it does the same i.e. uses Windows Live API.
Another idea would be to create some sort of invitation tokens. In this approach, admins would "invite" folks. They would create invitation record by providing the name, email address of the users and the application would create unique invitation tokens. The application could then create an invitation link using which users would come to your application and authenticate themselves. Once authentication is done, you could look up the invitation record and retrieve user information from the database and create user record and associate the authentication token with the user record. The issue with this approach is that a user may not use the same Live Id as provided by the administrator. For example, I have at least 3 live ids and if I have that invitation link, I could sign with any of those live ids and the application won't be able to stop me from registering.
Yet another idea would be to use Windows Azure Active Directory (WAAD) instead of ACS. You could consume Graph API in your application to create new users for your clients. You're still not managing user names and passwords as that is done by WAAD. The two issues I could think of there are - a) As an end user, I have to remember one more username/password combination and b) At the time of login, I have to provide my credentials in myusername#yourtenantname.onmicrosoft.com which to me personally is a big hassle.
We too have been going through the same pain and for now we have decided to go with approach #2.
Hope this helps.