In my environment I have presently two applications, lets call them portal and sso. Portal is where I manage user accounts and allow people to register. SSO is my implementation of IdentityServer. I want to require users to reset their password after 90 days or after they had their password recovered for them. I can check for this in the AuthenticateLocalAsync function, but the question is how do I redirect them to the portal password reset page? Or is it easier to add a custom page to the IdentityServer to handle password resets of this nature? Are there any examples of this, specifically where the identityserver is not embedded into the application using its login functionality?
Your best option is to create a "reset password" page in the same IdentityServer project, and issue a partial login redirecting to that page every time an user with expired password completes the sign on process successfully.
With this approach you can catch users with expired password before they are effectively logged in, without completely breaking the login flow.
You can find some details in the IdentityServer3 CustomUserService sample, specifically in the "EULA" sample which uses "EulaAtLoginUserService".
I do not think there is a way to directly redirect the user to an external endpoint (e.g. your Portal residing in another domain) during the IdentityServer login flow.
Related
With the use of IdentityServer4 and the OIDC protocol, I've managed to get my SPA and my .net core web api authenticating against a sql server user store, as well as ADFS which is great. However, when the user first clicks the 'Continue with ADFS' button, the login prompt is shown asking the user for their credentials. My understanding was that with the use of openId connect and IdentityServer, we could add external identity providers such as ADFS to our IdentityServer application and if ADFS is chosen for login with the user already logged in to ADFS via their local machine, then the authentication would happen seamlessly without the need to input windows user credentials again. There are other steps in order to achieve this of course, like linking the ADFS UserId with our SQL Database User Id table, but overall my understanding was that this would be entirely possible.
After a user logs out from an ADFS login, the next time the user chooses to log back in with ADFS, the 'Challenge' method that is run within my IdentityServer application to initiate the redirect to ADFS often recognises that the user has already logged in recently and therefore just logs them right in without the need for their credentials again.
My question is - is it actually possible to avoid the initial login prompt altogether? Or will the browser insist that credentials are provided if the user hasn't logged into the application for a while?
It certainly is possible but it may involve specific browser config in ADFS and also may require your IDP to be in the intranet zone in Windows Internet settings.
Check out these articles:
https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-intranet-forms-based-authentication-for-devices-that-do-not-support-wia
https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-browser-wia
How can I authenticate multiple applications with a single authentication mechanism?. These applications are having existing authentication within them, perhaps I need to authenticate these apps into my system which is isolated from others. Please suggest a better approach
When using OpenID Connect, the first application the user logs in to, will redirect the user's browser to the authorization server (AS). Since the user does not have a session between the browser and the AS, it will present the login screen. The user signs in and is redirected to the application (client) with an ID token and access token. The application will then establish a session between the browser and the application (typically a cookie)
When the user navigates to the second application, it will also redirect the user to the AS, but now the user already has a valid session between the browser and the AS, so the AS won't show the login screen (it may show the consent screen if the user has not consented to the requested scopes), and will issue an ID token and access token to the second application.
Now the user has a authenticated session with both applications with a single sign on (SSO).
If you use OAuth 2.0 with OIDC, you can authenticate your user once and verify the access token at each app the user visits. This is a typical single sign-on flow (SSO).
I am currently developing an SPA application that connects to a bunch of webAPI's. These API require that the user is logged in, so I started digging into Openid Conect and OAuth2 examples, mostly using IdentityServer.
They all require, for SPA reasons, that the implicit grant should be used for retrieving access_tokens. Token refreshes are handled connecting to authentication server using hidden iframe.
What I understand from this approach o renewing your access_token is that, sessions is maintained at authentication service. Hidden iframe goes to the authentication server, sessions is still active, new access_token is provided.
All that looks good for me, except (for UX reasosn) the fact that my user needs to be redirected to authentication server page for providing credentials.
Isn't it possible to have my SPA application send credentials to authentication server, getting the access_token, and then do the refresh using the hidden iframe for silently renewing (we, obviously dont want the user to keep informing credentials every 15 minutes or every hour..).
If this is not acceptable for security reasons, could you please explain why?
Technically it is possible with "resource owner password flow", but in that model identity provider can not trust your application and will not create a session for your user (to use silent renew later on). Thus such non-interactive approach is not truly SSO. For 2019 the recommended flow for any web app such as Angular SPA is Code flow with PKCE extension, as described here or there.
EDIT:
Editing this answer to correctly reflect the requirement.
If the requirement is not to show authentication server page and use your own SPA, the only possible way to do it is using "Resource owner password flow" with the constraints mentioned in the previous answer
This is discouraged for two reasons:
Security - Will the SPA have the same security controls as the "Authentication server" has in handling passwords of the user. Right from collection to management of the user password (safely securing for future calls ?). This will massively impact the scope of SPA and it is one of the main reasons why people prefer federated logins (outsourcing login complexity to the third party - in your case authentications server)
Trust - How would you convince the user to handout the "authentication server" password to a relatively new SPA app. Imagine if Google / Facebook allows this pattern for a SPA to collect password instead of redirecting to the Google / Facebook login page. This is a recipe for disaster.
This is exactly what oidc-client-js library does. Have a look at automaticSilentRenew settings in their wiki page. Understandably this only works as long as the session at the authentication server is still active.
I have a web site with an initial login page, on this page I'm using a claims based identity which is authenticated when a user successfully logs in.
This all works fine, from this main site I have a number of 'sub sites' (that also require logins), and I'm looking to use the same authenticated identity to log into these (e.g. so a user does not have to enter login details every time).
Is there a way to pass the initial authenticated claims-based identity to these sites securely? If so could someone point me in the direction of any useful material on this?
EDIT
Just to clarify in response to the answers below, I am currently using Single Sign On and have this working as follows.
User logins in to https://mywebsite.com/loginsite with Single Sign On. Claims-based identity is authenticated.
What I'm wanting to do is use this same authenticated Claims to log in to the following url in the same domain:
https://mywebsite.com/website1
But whenever I try to access the Identity the authentication is false. Is there a way to achieve this?
What you mentioned is generally referred to as SSO (Single Sign On). See the Auth0 page How to Implement Single Sign On for one way to achieve this.
Single Sign On works by having a central server, which all the applications trust. When you login for the first time a cookie gets created on this central server. Then, whenever you try to access a second application, you get redirected to the central server, if you already have a cookie there, you will get redirected directly to the app with a token, without login prompts, which means you’re already logged in.
(emphasis is mine)
Disclosure: I work at Auth0.
Good Evening,
My group is rolling out SSO - yay. We have several applications that directly authenticate with Box.com and all token refreshes are handled automatically. After we migrated to SSO, we didn't include these service (app) accounts in our AD, so they do not have access via the SSO gateway.
My (likely incorrect) understanding of how OAuth with an SSO provider in the loop works:
We can still start the OAuth handshake directly with box - but box will forward this request to the SSO provider. The SSO provider will then authenticate the credentials and pass back a "all good" to box, which will issue an auth_token.
This is based off of the following from box:
"If you authenticate your application via Box’s OAuth 2.0, your
application will automatically let the customer sign-on with their
company credentials, just like they do with every other Box
application. This also applies to popular commercial services like
Okta, One Login, and Ping."
https://docs.box.com/docs/oauth-20
As well as this photo:
So if the external applications' service accounts with Box aren't in the AD of the SSO (too many acronyms), they should not be able to authenticate right?
But these apps are continuing to be able to authenticate. They are able to refresh their token and continue accessing box, even after the migration to SSO.
Where is the flaw in my understanding? Will these apps need to be added to the AD, or does this roll out of SSO not affect any of our external dependencies?
Thanks!
Got an answer from box:
third-party apps and integrations use a persistent authentication
token model. This means that unless a user deliberately logs them out
of the app, or an admin inactivates or deletes their account, this
user will never have to re-authenticate after initial login. Instead,
the app/integration will refresh their tokens. Refreshing tokens does
not require stepping through the SSO login flow, while generating an
initial set of tokens does.
Changes in SSO status, whether between SSO Off, Enabled, and Required,
or between two different connections, have no effect on existing
authentication sessions. Users won't be forcibly logged out when SSO
is turned on.
Upon next login attempt will the new SSO flow come into play. In this case, these users were already authenticated into the integration
prior to SSO roll-out. The SSO change would have impacted behavior in
that these users would need to authenticate via SSO going forward;
however, due to the persistent authentication model, that "next login"
never actually happens, and these users can continue to refresh tokens
and retain access without ever being challenged to authenticate into
the IdP again.