Our requirement is simple. We have a web application that requires users to sign up for a new account in order to use the service.
We would like to offer users to login using their AD or LDAP credentials, provided that an AD/LDAP connector was already installed on the client premises.
Is there any service that does exactly that (providing connectors and a REST interface to programatically verify user credentials), and perform a one time API integration so that users will be presented with a login form on our web application www.mywebapp.com/login, they will then enter their AD/LDAP username and password, which we would verify against their user directory using OneLogin API
I went through the API documentation for OneLogin but i have not see any method for doing that, although i can see at https://www.onelogin.com/active-directory-integration that it is a feature of OneLogin
After users are synchronized to OneLogin (via the Active Directory Connector or the LDAP Connector, for instance), an authentication call over the REST API will tunnel the username/password down to the Directory being synched for validation -- this should satisfy your use case.
For example you can use a function like https://developers.onelogin.com/api-docs/1/users/create-session-login-token, or just make an LDAP query against the LDAP endpoint.
Take a look at this new(ish) API from OneLogin -
https://developers.onelogin.com/api-docs/1/users/create-session-login-token
Although it's designed for developers to build their own front-end on top of OneLogin, it can also be used to validate a user's credentials (if you get a session_token, you've successfully authenticated the user)
This should 'reach back' through OneLogin to validate the users against whatever directory is configured to handle auth.
This call has the added benefit of supporting 2nd factors if they are configured.
Related
Our application allows users to authenticate via Azure Active Directory using OpenID Connect.
However, some organizations do not allow users to approve applications, and require administrators to approve the application first.
Right now, this means that if a user wants to connect using their work account, we have to first send them to Azure, where they then enter their password, and then are told that our application requires administrator approval. Not a great experience.
Ideally, I would like to give only users whose tenants allow them to approve new applications (or those that already have) the option of logging in via AAD. Is this possible to do through an API call?
Microsoft does not provide such an API for this purpose.
As a workaround, you can quickly check it using auth code flow: Request an authorization code.
Enter their password is necessary. Sign in to this url with customer's credential:
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=query
&scope=https%3A%2F%2Fgraph.microsoft.com%2Fmail.read%20api%3A%2F%2F
&state=12345
&code_challenge=YTFjNjI1OWYzMzA3MTI4ZDY2Njg5M2RkNmVjNDE5YmEyZGRhOGYyM2IzNjdmZWFhMTQ1ODg3NDcxY2Nl
&code_challenge_method=S256
Then they can see if they need admin consent or not.
The essence is the same as the steps you described. But it can save a lot of time.
Based on the code sample mentioned at URL: https://github.com/Azure-Samples/active-directory-dotnet-webapp-wsfederation , I implemented an application that uses WS-Federation (ASP.Net WS-Federation OWIN middleware) to authenticate users from an Azure AD tenant. Now I am looking for an approach to query the Graph API later in my application to fetch additional claims information required from application point of view.
Here in this scenario, I would like to know whether it is possible to query the Graph API or not. Do I need to update the existing WS-Federation protocol to OpenId Connect.
Can anyone help me to provide their guidance here.
The ideal would be to move to OpenId Connect, which would allow you to take care of both sign in and API in a single setup and flow.
If you want to stick with your current ws-fed setup, you can layer oauth2 on top of your implementation and retrieve the access token you need any time after the sign in. We have a sample showing exactly that, see https://azure.microsoft.com/en-us/resources/samples/active-directory-dotnet-webapp-webapi-oauth2-useridentity/
New to Azure AD... So please don't be too harsh if this is off target. :-)
Technology Stack - Latest Angular 2 with C# Middle tier and latest .Net Framework.
Ideally, What we want to do is use Azure AD B2C to store user credentials and to do the authentication - but we want our 'own' forms on our site to do the login Forms capture and logging - then pass the credentials through an API (REST?) Call (using MS Graph SDK?) to Azure AD B2C and then check the call return for the Authorization content message.
Couple of reasons - control of the application flow, Logging and the "flickering of the URL" (i.e. going from our site URL to login.microsoft... URL and then back to our sites URL).
Is this doable without doing a hack?
Thank you in advance for your help and patience!
You are looking for the "Resource Owner Password Credentials".
This is not currently supported for Azure AD B2C, but you can give user feedback to the B2C team that you want this through the Azure Feedback Forum: Add support for Resource Owner Password Credentials flow in Azure AD B2C and headless authentication in Microsoft Authentication Library
You should also see updates at that location if and when they implement this feature.
The resource owner password credentials flow is now in preview.
In Azure Active Directory (Azure AD) B2C, the following options are
supported:
Native Client: User interaction during authentication happens when
code runs on a user-side device. The device can be a mobile
application that's running in a native operating system, such as
Android, or running in a browser, such as JavaScript.
Public client flow: Only user credentials, gathered by an application, are sent in
the API call. The credentials of the application are not sent.
Add new claims: The ID token contents can be changed to add new claims.
The following flows are not supported:
Server-to-server: The identity protection system needs a reliable IP
address gathered from the caller (the native client) as part of the
interaction. In a server-side API call, only the server’s IP address
is used. If a dynamic threshold of failed authentications is exceeded,
the identity protection system may identify a repeated IP address as
an attacker.
Confidential client flow: The application client ID is
validated, but the application secret is not validated.
From here.
Note that one disadvantage of doing what you're requesting is precisely that you can do "login forms capture and logging", so your application has a chance to see the credentials and perhaps take copies of them; thus your users have to trust you to behave.
The normal web-based flow means that your application doesn't need to be trusted; it never even sees the password at all.
My current setup is a fairly simple one. I am running Identity Server 3 which is used to provide oauth access tokens which can be used against and a number of our web api endpoints. The identity server has custom user service which authenticates requests against a custom user table in our sql database.
We have a new 3rd party software provider, this provider requires that our users (staff in our call centre) logon to their application via a proprietary login, not against our existing user accounts. We have built an api for this 3rd party which they required for their integration, as with the rest of our api's this is secured using oauth bearer tokens via identity server.
Our staff are all locally logged on to an active directory domain. Is it possible to configure identity server to issues auth tokens for a user who is already authenticated against active directory? I like to achieve this without prompting the user for their credentials again.
I've read around and at this point I'm very lost as to the correct approach, some form of federation seems appropriate, but I couldn’t find a reasonable introduction / walkthrough to help me get started.
What is an appropriate approach and are they any relatively easy to consume primers on the subject?
Yes, you should be able to make it work. The samples contain a windows auth provider. Using this, your identity server would authenticate people in without prompting for a password. Once authenticated, it would then issue tokens same as any other auth. You may need to a bit of experimenting to get it working, but from what you've said it should work in your situation.
I'm tried to build a new rich application and i'm having some problems designing the authentication process.
I've only two requirements :
An API needs to be available
An ADFS needs to be used to authentication
My first thoughts was to build the API and to use Angular.js for the frontend. However, I can't see how the authentication should work.
My API needs to be available though scripts. As far as I saw, the ADFS authentication always display t the webpage for the authentication process.
API are usually secured with OAuth2. We used an client id and a client secret to generate a token. But I can't have this behavior with an ADFS.
The only solution I see is to provide two authentications behavior with my application. One with the ADFS for the web access and in the web interface, add a possibility to generate a client id and a client secret associated with an user account that could be used for the API to the headless authentication.
Someone has already faced this kind of scenario?
Thanks a lot!
I assume the 'ADFS needs to be used for authentication' really means 'users should be able to use their Active Directory domain credentials to authenticate'.
If that is the case, you should take a look at Thinktecture IdentityServer. It's an OAuth2 authorization server that you can use with a Active Directory identity provider.
P.S. ADFS 3.0 that comes with Windows 2012R2 only supports the authorization code grant, which is not suitable for JavaScript apps.