I have a website, call it "Site One" in which users create accounts with a username and password. For security, I then salt and hash the user's password and store it in a SQL Database. It all works great.
Now enter "Site Two" which is written by a different company. We would like to integrate the two apps so that if a user is logged into Site Two, they would be able to:
Create an account on Site one through a Web API.
Have a one click seamless login from Site Two back to Site One.
Is this achievable without Site Two being able to Store and Retrieve the password from the user account that they created? The only way I can think of this working is that after Site Two makes the WebAPI call to Site One to create an account, Site Two would have to be able to store the password which was used to create that account in the first place, thus opening a big security hole in case someone was able to get a hold of the password.
I supposed as an added security layer, I could prevent that password from being used except when the login info is posted from a known IP address, but I'm not sure if this is enough protection.
Consider implementing single sign-on (SSO) using SAML 2.0, where Site One is an Identity Provider (IdP) a Service Provider (SP), and Site Two is a Service Service Provider.
Assuming that users will visit Site Two first, then you would want to implement Service Provider initiated SSO on Site Two. The effect of this would be that whenever a user requests a secured resource on Site Two, the user would be directed to Site One, which would prompt them for the user for a username and password. Once authenticated, the user would be re-directed back to Site Two to access the secured resource that the user originally requested.
An overview taken from OASIS SAML 2.0 documentation:
The user attempts to access a resource on sp.example.com. The user does not have a valid logon session (i.e. security context) on this site. The SP saves the requested resource URL in local state information that can be saved across the web SSO exchange.
The SP sends an HTTP redirect response to the browser (HTTP status 302 or 303). The Location HTTP header contains the destination URI of the Sign-On Service at the identity provider.
The Single Sign-On Service determines whether the user has an existing logon security context at the identity provider that meets the default or requested authentication policy requirements. If not, the IdP interacts with the browser to challenge the user to provide valid credentials.
The user provides valid credentials and a local logon security context is created for the user at the IdP.
The IdP Single Sign-On Service builds a SAML assertion representing the user's logon security context. The Single Sign-On Service sends the HTML form back to the browser in the HTTP response.
The browser, due either to a user action or execution of an “auto-submit” script, issues an HTTP POST request to send the form to the SP's Assertion Consumer Service.
An access check is made to establish whether the user has the correct authorization to access the resource. If the access check passes, the resource is then returned to the browser.
Related
I've implemented SSO using SAML authentication on Asure AD in my banking application. I have a scenario where I've to let a manager/supervisor log in to approve a transaction. A regular rep would not have authority to approve, the manager would come in and physically login in (keeping the rep's session intact) and approve a transaction and then logout. Is it possible to have multiple sign ins in the same browser instance through Azure AD?
UPDATE - Per what I researched and mentioned by Carl as well, Azure AD does not support multiple users to login in an application in the same browser instance.
Yes, in the same tenant, users with different roles can perform multiple logins in the same browser. Log in to the Azure portal and you can see that accounts with different roles in the upper right corner can be switched back and forth.
These identities have already validated their credentials for this session, and have an auth token. Switching between these accounts now will not prompt you for their passwords again.
Update:
Even if two accounts are in the same domain, they cannot be logged in at the same time. Currently, only two browsers can be used for two accounts in the same domain.
SAML SSO is a form of delegated authentication. The user is authenticated at the identity provider site (eg Azure AD) which sends a SAML assertion containing user identity information to the service provider site. The service provider trusts this information and establishes a local authentication session for the user using the information contained in the SAML assertion. SAML assertions often contain the user's email address but any user identity information may be included.
You can achieve multiple sign-ins on the same browser , Kindly check this link.
Currently we are a Service Provider (SP) which is currently using SSO Authentication using OpenAM and we are using Spring security to achieve this.
We have a login interface where user enter user name and password and authentication happens.
Now we have a requirement to allow users from an external identity provider (Azure) to access the SP in addition to the existing Open AM SSO. We are trying to use SAML 2.0 to achieve this.
For this we changed the login interface, to accept the user name and based on the user name, we either provide the password option (for local users ) or redirect to the azure portal (for idp users) to authenticate the user.
As part of this requirement, we added a variable userType into httprequest cookie and try to redirect to the respective authentication provider. But we always get redirected to azure even though the user is a local one.
We have gone through many examples from github to implement this but no luck.
Any pointers on this would really be helpful.
Setup:
My web application has OpenAM + OpenDJ interacting with a federation server in order provide SSO service through SAML2. The list of users who are authorised to access my application are part of the OpenDJ.
How it works-
When the user launches the link for the first time and the application determines that he has not logged in, the user is redirected to the IDP URL to authenticate. The IDP provides the SAML2 response through the Consumer URL exposed. On receiving the SAML2 response my application determines if the user is part of my LDAP and thereby allowed to access and shows up a home page if he has access.
Problem
When the user is not part of my LDAP, I would like to throw up an Access Denied Page, however, I find that OpenAM throws the default IDP initiated login page with a goto parameter to my URL.
I've tried to have success and failure URL configured but it result in the application not being completely accessible. The users are not shown even the IDO login screen.
Is there a property or configuration I need to set to enable OpenAM to show the Access Denied page instead of IDP Login?
I was able to get this working through changes/redirection on the web server. Though I am not sure if there is a place within OpenAM config to solve this.
I have a closed-registration site (set up as a resellers control panel).
There is no way to sign up externally as the admin creates the accounts and dishes them out to users.
I wanted to allow the user to attach their social accounts (fb/twitter/etc) to their logins after they have been created to make it easier for them to sign in to the website in the future.
The problem I'm seeing is that there doesn't appear to be a way to modify the third party providers to only allow login if the account already exists?
I've looked around the documentation and can't find anything eg,:
http://msdn.microsoft.com/en-us/library/microsoft.owin.security.twitter.twitterauthenticationoptions_properties(v=vs.113).aspx
So the question is - can you setup asp.net identity 2.0 so that external login providers can be used to login but are rejected if they aren't already registered to an account on the site?
I'm using the default MVC 5 template. I have a list of authorized users in a separate table from the Identity users table. When a user attempts to log in via Google, I check the user against that table in the AccountController's ExternalLoginCallback method prior to the SignInManager.ExternalSignInAsync() call. If they exist in the authorized users table, it continues the login process. If not, it redirects them back to the Login page. This of course requires knowing what their social login username or email address is in order to compare it, which in our case is not a problem because we are limiting login to specific users within our Google Apps domain.
We have a Windows Azure Active Directory, configured with a custom domain, linked to an on-premise ADFS (2.0) server for federated authentication.
When I go to https://manage.windowsazure.net in a clean browser session, I'm prompted by https://login.microsoft.online.com for just an email address. This asks for Organizational vs. Microsoft account, and if I select Organizational, I'm redirected to our ADFS server - all good.
On the other hand, on our own ASP.NET MVC applications which use ADAL, the login page (again login.microsoftonline.com) shows both a username and password box. If you type a username, then focus on to the password box, you then get redirect at that point to ADFS.
This can be a rather confusing user experience - often you've started typing your password by the time the redirect happens, then hit enter, and of course get an authentication failure.
Possibly a better demonstration in this screen recording:
http://www.youtube.com/watch?v=hZYPltSmcn8&feature=youtu.be
Is there any way of using the username-only page rather than username + password, or better yet, skipping the WAAD page and redirecting straight to ADFS? (Since all users will be using that for SSO anyway.)
The Azure portal has the email-only screen mostly because it needs to disambiguate between Azure AD accounts (organizational accounts) and Microsoft accounts (personal accounts, formerly LiveIDs).
If you provide the email address as the login_hint parameter in the OAuth 2.0 authorization request, Azure AD will do the lookup to find out if it's a federated domain, and if so, immediately redirect to ADFS.
With ADAL, you can provide this using AuthenticationContext.AcquireToken(String, String, Uri, String) to specify loginHint:
AuthenticationResult authResult =
authContext.AquireToken(resource, clientId, returnUri, loginHint);
You will, however, have to build your own page to collect the email address.