I have a web application. Currently we have a portal that authenticates the user and then redirects to our webpage. I know the issues with identity provider initiated single sign on, however this is the path the site owner wishes to go.
The site is successfully authenticating the user, and redirecting to my ASP.net core application. However I cannot seem to get any of the authentication data. I have checked contacts.user.claims as well as security principal all appear to be null. I do know sample information is being returned in the request by using the Google tool saml tracer.
I am looking for any samples retrieving the sample information from my application after it has been redirected from a identity provider.
In the end I am trying to get the userid once the identity provider sent to me.
Thank you for any assistance or suggestions.
Related
I have the following projects:
Identity Server 4, with ASP.NET Identity as a user store for all users of all my apps.
.NET Core 5 Web API
Xamarin app
The flow goes like this:
User logins from the Xamarin app (3) and is authenticated against IdentityServer (1)
User receives an access token from Identity Server, that contains the sub claim
User makes a request to the Web API (2) using the access token
The Web API (2) checks its own database for user permissions
----QUESTION/PROBLEM IS HERE-----
Should the Web API add these user claims (permissions) to the access token, OR should the Web API always check the database for the user permissions on every request made from the client?
Maybe I could add the claims before authenticating with IdentityServer, but this would mean that IdentityServer would have access to the Web API's database. I believe this is not a good practice because of separation of concerns.
Another solution would be to introduce a caching mechanism when the Web API validates the token, so that it doesn't always check the database.
Using claims transformation, it is my understanding that I can add the claims to this 1 request only, meaning that the next time a client makes a request, claims transformation should happen again, since it doesn't return a new access token to the user.
Ideally, I would like the Web API to add the claims to the access token so that the Web API can trust these claims on all subsequent requests. I cannot find a way to do so, though. I've searched for Claims Transformation, IssueJwtAsync (IdentityServerTools), IProfileService, but I think none of these are solutions to this problem.
Is this good architecture? Please do share your opinions on this subject and potential solutions.
Thank you very much!
You need to add these permissions in web api, because users need to access the corresponding resources according to these granted permissions. And permissions are granted when the user logs in for the first time, without the need to access the database in every request.
In this case, you can use Claims Transformation. This link has more detailed steps which can solve this problem.
Background:
I have a basic user database with username(email) and password. The users are able to sign in to a website of mine with these credentials. From the website they get a link to different services they have access to, but with different username/passwords. So they click the link "Open My Service X" and they have to login with their service unique login credentials. I do have the users service login-username. So I can map local-user <=> service-user.
I want SSO between service X which has support for SAML and my website.
Question/Problem:
I want the users to login with their user/password in my database, then single sign on towards service X where service X has support for SAML. I don't want a user to be able to sign up for a new user account to my website using the SAML support in service X. The user must already have an account in my database.
So my question might be rather vague, but I'm having a hard time to grasp how this can be achieved?
I was thinking of letting my webapp become a SAML identity provider, so that the SSO request are transferred back to my webapp and verified for their service-user. Would that be correct approach?
You're on the right track with your SAML IdP. There are basically three parts involved. Your email database (the identities), your existing application front end and the remote services which support SAML. Usually it's SAML2 these days.
To get single sign-on (SSO) across your portfolio of apps (your own app and the remote services) you could install an IdP like the Shibboleth IdP and convert your app to use it instead of using email/password to login. That would take a fair amount of work as you'd have to convert your app into a SAML SP, just like the remote services.
An easier way might be to only use the IdP for SAML to the remote services and get the IdP to recognise that your users are already logged in with their email/password. Cookie? So the IdP should never display a login page as it would recognise your app's cookie and match that with a user in the database. It then releases SAML attributes to the remote service based on that user's information. That also covers your use case of not allowing account creation via SAML from a remote service.
That would mean you might end up with the following URLs:
https://yourapp.com/
https://yourapp.com/idp/
Your users login with the first URL as normal and the remote services use the second URL. That way your app cookie will be visible to the /idp endpoint but you'd need to write code to match that with a user in the database.
I'm developing an Enterprise/Internet Application with WebAPI 2 RESTful server and SPA web client (Angular2) —So I have two separated projects created using ASP.NET 4.6 Empty template and both use OWIN and are IIS hosted.
The requirement for Authentication is:
Active Directory user which is logged in to the workstation will authenticated automatically once she opens any page from app in the browser if user id/name found in the database, with no need to enter her user/pass. Let name this as auto-login. Else if it's not found in the DB it will redirected to the login page.
Also there should be a logout option which redirects user to the login page after logging she out.
In the login page any AD user can enter her/his AD user&pass and after successful check against database (existed) and AD (valid credential) she/he will logged in to the system (Obviously it may be different than user currently is logged in to the workstation)
In addition to the web client it will have other clients such mobile apps which will connect and be served by the WebAPI back-end. Users will login there using their AD user & pass too. Let name it manual-login.
According to the REST architecture and having both AD enterprise and internet/mobile users together, the authentication should be token based —this is what I found till now but I'm not sure.
I read about OWIN Authentication architecture and Windows Authentication and I checked MixedAuth, Now I think it is the nearest solution for this requirement as it lets app-defined users to authenticate side by side of windows/AD users. But even after dig into it and its SPA sample I didn't found my way yet and confused.
Anyone can help?
What should I actually do on the WebApi server and SPA Client to accomplish those authentication requirements?
Which middlewares should I add and how should config/manipulate them?
UseCookieAuthentication ?
UseExternalSignInCookie ?
UseOAuthBearerTokens ?
Can I rely just on Bearer tokens (using OAuthBearerTokens MW) and get same token for authenticated windows users to unify authentication model based on bearer tokens? If so, how?
How and where should I put my code for checking that AD user exists in the DB and if not so reject the authentication?
Thanks a lot.
We have an existing MVC application which is used by multiple customers.
Currently, each customer is given a URL to our application e.g. https://myapp/mycustomername.
When they go their, they are presented with a login screen.
For some customers (not all) we want to implement SSO, and authenticate their users against their active directory, so that they never see the login screen (unless the SSO authentication fails).
Most customers won't be using this functionality.
My first question is: is this do-able? Is it possible to have an MVC application which uses both SSO and forms authentication?
If so, can anyone point me to any links explaining the process?
I've seen some good information, such as this tutorial but I can't find anything that matches my scenario.
Thanks.
This is surely a do-able task.
The steps would be
Identify the tenant name from the URL
Get the Identity Setting
If forms authentication, show them the login page
If SSO enabled, redirect to their ADFS URL
When you onboard your tenant, you will have to maintain the following metadata
TenantName
AuthenticationType : {forms / ADFS}
SSO Url
SSO Federation Metadata URL
etc
We did one such implementation that supports ADFS, Social Logins with Forms Authentication too.
I have a C# MVC5 website on Azure in which I'm trying to add a variety of identity providers (e.g. Google, Twitter, Facebook, Microsoft).
Having followed a simple guide on the asp.net site on adding Microsoft Live as an authentication option, I'm finding that when I try to authenticate with a Live account, I'm always bounced to my login page. My site users should instead be directed to the "Register" (MYSITE.azurewebsites.net/Account/Register) page upon first successful authentication from a new provider, or to the home page as an authenticated user if previously registered. However, I seem to always be sent to the login page.
I'm not encountering any authentication errors from the Live provider - username and password are being accepted and the provider does seem to be redirecting as if an authentication was successful.
I haven't encountered this problem when integrating with Facebook, Google or Twitter.
In the Live Connect Developer Center, where my authentication app is configured, I'm required to provide a "redirect domain":
You only need to enter the domain, for example http://www.contoso.com
For this I've entered the URL for my Azure site http://MYSITE.azurewebsites.net
The field doesn't appear to acknowledge any routes such as /Account/Something/ on the end of the URL, but I'm not clear that it should need to.
Does anyone know if I require some additional configuration in my site to work with Microsoft Live or is there some restriction on using the Live provider on free Azure sites?
I've fixed this. Unfortunately it transpired that I was missing a preceding hyphen character from my clientSecret which I had specified in my StartUp.Auth.cs
I'm surprised an error wasn't thrown to say that the client secret was invalid, as I was going on the assumption that any incorrect clientId or clientSecret values would have rejected my request when clicking the 'login with Microsoft' button.