I have come across a number of articles that discuss a similar matter but I cannot find a definitive answer.
My company would like to begin using Identity Server 3, however one of the requirements is to be able to authenticate an external user without them having to manually enter their credentials.
This must be capable of providing single sign on capabilities also as we have 3 different systems and our users should only have to sign in once.
Essentially, the external user has their own CRM.
The CRM holds their username and password for our software.
They then click a button in their CRM to launch our application
This redirects them to our website with a payload containing their credentials
We call a web service to authenticate the user
It is fundamental that we do not change this process for our partners.
Can I implement a custom service provider to provide the authentication or is there some other way of achieving this? If so, could you point me in the right direction for how this can be done?
Many thanks
Craig
I would assume that you'd create a mechanism for their CRM to get a token at the time the client logs into their site and then have them send that token via url to your callback page. This would use the machine-to-machine type grant, or the client-credentials flow. Then that page could validate the token and log the user in. There would have to be some sort of unique identifier between the two systems like email or something. Just an idea.
Related
I am building an enterprise app and federating signin using the Cognito Hosted UI solution, and people can sign up individually using any email, but they might also work for a company which has signed an enterprise deal with us and use SSO.
The desired workflow is one in which they input their signin email, then it is checked against our list of SAML Single Sign On providers, and if they match an enterprise client using SSO they are sent to the proper federation page; if they don't match any, they are taken to the general purpose login.
So far, I have successfully used the Hosted UI and the critical idpIdentifier parameter to create the desired behavior successfully. The following React code summarizes how this works:
hostedUILogin() {
const idpIdentifier = this.state.email.split("#")[1];
let url = `https://${domain}/oauth2/authorize?response_type=code&client_id=${clientId}&redirect_uri=${redirectSignIn}`;
if (idpIdentifier) {
url += `&idp_identifier=${idpIdentifier}`;
}
window.location.assign(url);
}
This produces the desired effect. When somebody signs in with an email address that ends in "#corporatecustomer.com" they are taken to the SSO page for Corporation's federation. When somebody signs in with "#gmail.com", they are taken to the Cognito Hosted UI.
Unfortunately, the Hosted UI seems to be unable to help itself but to show off our customer list on the left-hand side.
I am unable to discover in the documentation or tutorials any way to use the Cognito Hosted UI without advertising all available SAML providers on the left hand side, thereby giving away our customer list.
I have tried taking away the IDP for this Hosted UI App in the App Client configuration, but then it no longer captures through the idp_identifier successfully.
If it helps to you, one of the solutions I found was to create a single User Pool per Corporate Customer
You can create different App Client, and you can enable only identity provider on the first one, and native username/password on the other one.
For each App Client, you can dynamically change your AWS Config on the client side.
On our use case, SSO users may not have the same identity provider name on their email domains so we have "Login with SSO" button, which first handles kind of "Home Realm Discovery" by sending a request to backend with user's email and that endpoint returns the identity provider name belong to that user. Then the client initiates the federated sign in (or direct call to the hosted UI with identity provider parameter).
We have a need to secure our .net web api using open id and OAuth standards. IdentityServer 3 is perfect for us as we have to use our existing user store.
Edited for more clarity:
Our company services multiple customers. Each of our customers have their own database. In our home grown client application when a customer user enters their user/password, we do a lookup to authenticate and that also determines what backend database the app connects to.
We now have a need to allow a couple of trusted partners to access our database resource for specific needs. We have created a web api for them to make specific calls. The web api needs to know what customer the partner is making the call for. The partner is calling the api from services on their side so there is no user interaction.
I am trying to determine the flow to use to accomplish this. I found some pretty good info on flows at https://gist.github.com/jawadatgithub/638c11f08ecc0d76b05c.
If I define the client using the Client Credentials flow, I don't know how for them to pass the customer they are making the calls on behalf of. I don't think we want to definate a "Client" for every partner/customer combination, but is this the correct way?
What we had thought of initially is to give an additional user/password or secret key that would tell us the customer, but I am not sure what "flow" for the client would allow this.
Any help or direction would be greatly appreciated.
In case this helps anyone else, we decided to go with a Hybrid flow for these types of requests. We considered designating a service account (user/pw) for each of our customer databases that would give this trusted 3rd part access to them by requesting tokens with the Resource Owner Password Credential flow, but decided against it. We decided against it for all the reasons the standards say not to use it for this use.
If the 3rd party wants to interact with us on the behalf of one of our customers, then they will need to build the UI on their side to redirect to us for user/pw authentication and consent.
I'm working in a company that uses Microsoft Active Directory. We have an external company that provides an internal web site for a particular project. The site is external to the company. The sign on to the external site is the user's company email.
We want a system whereby the external site calls into the organisation's AD to verify if an email address is still valid or if the user has left the company. It should be a simple call to Active Directory Federation Services or some sort of SAML interface. The call would be a simple request 'here's an email, is it valid?' and the response is either yes or no.
Our IT department are trying to tell us that it's too complicated and I don't believe them. I think they just don't want to do it.
Does anyone know how easy it would be to create a simple system that would allow an external service to do the query outlined above.
ADFS is not meant to do that. However, a by-product of using it, would be the validation you are looking for.
The first question would be: what is the authentication method of your app? e-mail and what else? password? which password? Does the app keep a database of users/passwords?
ADFS works as an "identity provider" and would authenticate users in AD. ADFS would supply a security token that can be consumed by your app. Part of the information sent in the security token could very well be (and often is) the user e-mail address (that's why it is a "by-product").
For this to work, the app would have to be changed to accept security tokens (SAML tokens to be specific). If the app is .NET based, then it is done usually with WIF (WIndows Identity Foundation).
This approach would be the most elegant and secure because the app would delegate the responsibility of authenticating users to the authority of these employees: AD.
App --trusts--> ADFS --authenticates--> AD
Setting up ADFS, etc is not super-difficult, but it is not super-simple either, and might not be worth just for this app. There are other lighter weight alternatives: open source products like Identity Server, or products like the one I work on.
Now, if all you need to do is to validate that the e-mail actually exists, the best is to send a verification message to that address with some unique code that the user sends back. This is the same approach used in many common web apps.
Agree with everything #Eugenio said - have same questions about authentication.
But if you simply want code to query an user's email address in AD, you use the AD API's.
I want to make an app having financial Transactions for iPhone.So, my first target is to make a login page(and that's where my problem starts):-
The Admin or customer Details are stored in MSSQL DB.Now, when the client enters his username and password in my app, i want to verify these Credentials. So how can i do this?
Acc. to my little knowledge, i cannot connect to the DB directly, I need some web service or something as a middleware(but don't know what).I cannot parse the url directly to check the credentials as it will not be safe.Did we have to Encrypt the Credentials of client and if yes then how can i retrieve and verify the Login?
Any Sample, Links or anything will be helpful.
Create a .net site with a login.aspx web service page where you will handle authentication for the app. Make sure to get a HTTPS/SSL cert set up on your site as well.
Call me overly cautious, but I hate the idea of direct web server database access from a client app, I always like a middle layer of control/protection.
Edit
for example, you app can make server calls similar to this (using POST of course): yoursite.com/webservice/Login.aspx?username=chucknorris&password=somepassword&appkey=679384820473487746
Then on your Login.aspx page (or other pages for that matter) you would check for the POST variables (username, password, etc) and ask the database if they match. If they do then have the page return a success message, or do whatever additional processing you desire.
On multiple page requests within a certain amount of time, you can optionally use session states or go the more RESTful type of route, both are easily researched via Google.
POST + SSL is a must for basic security measures.
I'm working on a proof of concept app. The basic functionality works, where I can log into one website, link to another site that shares the same STS, and the partner site picks up the credentials properly.
However, the partner site only requests the token if the page that we link to requires authentication (which kind of makes sense I guess).
Ideally, I'd like to link to a partner page that does not require you to be authenticated, BUT if the user IS already authenticated, I'd like to at least be able to recognize them on the partner site.
Currently, if my partner landing page does not require authentication, it doesn't appear that the user is logged in when they arrive. As soon as the user requests a page on the partner site that does require authentication, it then grabs the token without requiring the user to log in.
I've tried playing around with the SecurityTokenReceived and RedirectingToIdentityProvider events, but so far I'm stumped.
Any thoughts are appreciated.
So, the problem you are running up against is in dealing with the SessionAuthenticationModule hijacking the request. This module is responsible for detecting if the user has a valid session (based on a cookie that is written upon a successful redirect from the STS) and if not, to redirect the user to the STS to fetch a valid token. The WSFederationAuthenticationModule supplies the eventing necessary to hook into various stages of the redirection/authentication process.
Based on your description, it sounds like you want the following to happen:
User clicks on a link that redirects to the partner site
At the partner site, the request is intercepted and the system determines if the user is signed-in to the STS or anonymous
If the user has a valid session with the STS, then pull the claims for that user
The problem is, your RP cannot know that the user has a valid session without sending the user to the STS first (the RP's do not talk to each other or the STS. The user's brower is used as the means of communication between the RP's and the STS in the form of WS-Fed directives and SAML tokens passed in the url during redirects). If the user is sent to the STS, then they must authenticate, which could be a problem for anonymous users.
So, I do not think there is a "trick" that you can pull via configuration or interception of the request to determine if the user has a valid session with the STS. You might be able to pass a hint, however, from the referrer that is intercepted by the partner site. This hint could take the form of a parameter on the url that indicates to the partner site that the current user has a valid session and to go ahead and redirect to the STS (absence of this hint would indicate an anonymous user). You could also build a system to "hand-off" knowledge of the signed-in user using a resource that both sites have access to (i.e. database).
As you are sure to learn soon, more often than not, WIF offers pieces to the puzzle, but every situation is different and you have to supply the other pieces on your own.
Hope this helps!