I have 3 different web applications.
A,B and C
now when user enter site B or C in web browser then if user already logged in site A then i want user to use the site B or C without any login.
now if user not signed in and trying to access site B or C then first redirect user to site A for login and then redirect to site which he want's to use.
You need to configure applications A, B and C as Relying Parties in ADFS.
All applications need to have a client side stack supporting either WS-Fed (WIF) or SAML 2.0.
If you used ADFS 2016, you could also use OpenID Connect.
That gives you SSO across all applications.
Once you have logged into A, you will not have to login to B and C.
Related
I have an Asp.net website for domain A users with Integrated Windows Authentication.
Now users from domain B need to access the website.
But Domain B users receive a pop-up window to input the authenticated information when they access the website
My question is:
How to configure the IIS or Windows Server to allow Domain B users to access the website without the pop-up windows for authentication, just like the users from Domain A.
There are two requirements:
Domain A needs to trust Domain B, and
On the users' computers, the website needs to be added to the Trusted Sites in the Windows Internet Options. This tells Chrome and Edge that they can automatically send the credentials of the logged in user. Firefox can do it too, but has its own setting for it.
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.
My MVC 4 application (https://testapp.com) with WIF and windows authentication is on Domain A and my ADFS and users are on domain B.
Requirement: Users in Domain B will browse my application https://testapp.com which is hosted in Domain A and my application should use their local windows user creds and redirect to the ADFS in Domain B.
I believe I dont require a AD cross Domain trust between A and B and that is what ADFS and SAML authentication is meant for.
I dont see such much materials for reference in such scenarios also. Kindly help understand how to configure such an MVC application in Domain A.
You need to establish a trust between your MVC4 application and your ADFS. In ADFS lingo this is called "Relying Party". You will need to have an endpoint in your application that accepts a HTTP POST message and processes the payload generated by ADFS.
I had to recreate these a long time ago but you can spare the pain. There are more options available -
http://saml2.codeplex.com/ (open source)
http://www.componentspace.com/Products/SMLv20.aspx
Configuring ADFS can be tricky but there are lot of guides out there.
I have an application in domain A and would like it to use domain B credentials to access domain B content. These domains have no trust. Is it possible to challenge a user in domain A, and get them to input credentials for domain B? Then use these credentials to authenticate in domain B. Meaning we bypass domain A's Kerberos Distribution Center (KDC).
I have no problem getting this to work inside a single domain, meaning impersonating the challenged user and maintaining an impersonation level of delegation. However, MS documentation says that the application in domain A will use its KDC to issue a ticket (or fail to issue the ticket) and this will cause my service in domain B to drop to NTLM.
Is it possible to force my service in domain A to use domain B's KDS? I could be way off base here.
The architecture is Microsoft WCF services.
Thanks,
Kevin
The quick answer is NO you cannot pass credentials across domains without the 2 domains having some level of trust.
However, I got around this by using asp.net forms authentication. When the users credentials from domain A fail I effectively get them to input the credentials from domain B and redirect them to an "Authentication" MVC controller that scrapes the user identity and then encrypts it in a Asp.Net forms authentication cookie. This is returned in the response header. All subsequent requests are made with this cookie and I check for the the authenticated user in the session cookie. Not as elegant as delegation but it works.
What is the best/proper technique to share login between two sites.
I have website A, and some websites B. Both types belong to the same company, but B is running on the customer premises. What I would like, is that users login in B, and when redirected to A for some reason, they don't need to login again, and they can work with their account in A.
Of course, the company will make logins for each 'B' user. The problem is that the user could initiate the login in A or B.
Would OAuth do? Or OpenID would be more suitable?
Another option is pass a GUID token in the GET string, with a sort time to live and only valid for the IP address of the requester, but it is not sure the user would access the web sites through the same gateway.
Thanks
OAuth is exactly what you need. OpenID offers discovery which is only useful when the user gets to choose who to authenticate with (not your use case). Also, OpenID is much more complicated and is a dying protocol.
In your scenario, Server A is the OAuth server (or authorization server in OAuth 2.0) and Server B is the client. There are many ways to implement this, but I would suggest you start by looking (and trying) how Facebook OAuth 2.0 implementation works. It will give you a good idea of what is involved and some of their extension (e.g. display) which make it more user-friendly.
You are talking about single sign-on. Does the company who owns Website A provide remote sign-on in their api?
You need to make sure that the log-on information is encrypted when it is passed to website A. The last single sign-on I built required me to pass the user's AD name encrytped via RSA and hashed with MD5. The third party had a database of the user's AD name and their password to the third party site. When the user clicked a link, their encrypted information was sent to the log-on api of the third party and the third party redirected them to the welcome page with the log on process complete.
If you are building a single sign-on API yourself, as in you have control over website A, OAuth is a respectable choice. It is fairly easy to impliment.