How saas app saml configuration fedaration works - authentication

Situation:
I have a SaaS application.it has saml configuration page where users can add configuration to bring their own idp providers like okta, etc. It has information like login url response url. It is also configured as app in okta too.
Question :
Now a user login into my saas app. they just enter email id and click login. In the backend do i have to build a api to read this user federation url from the data store to redirect/authorize and to the app.
like if users from a#comp1.com logins then the api has to bring the federation url of the comp1 company and then redirect and if user b#comp2.com logins then url of comp2
Just when users enter email how can i identify which idp and configuration they have linked and redirect them to the respective url
is this how generally done in SaaS saml login experience ?

Related

Connect additional Social account to logged in user

Currently, I have Google, Github, Twitter account registration/login (merge them by email). But I want to give a currently logged-in user ability to manually connect another social account (with a different email). For authorization, I use JWT and store them in localStorage on frontend.
The problem comes when we redirect user to some of social login providers and when he returns back we don't know who it is. It can be user that connects an additional social account to the main account or a new user that firstly login by some social provider.
What possible solution for getting logged-in user after redirect from Social login provider when using JWT for auth?
or
What best solution for linking social account to existing main account when using JWT for auth?
By "social login provider" I mean Github, Google, Twitter, etc
Ok, I just create separate routes for connecting and store JWT in cookies to ease auth check.

SAML between existing account and service provider

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.

Authenticating AD user automatically and manually - WebAPI 2 server and SPA client

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.

Using SAML in Portal to Authenticate with 3d party website

We are running a website where users need to be authenticated from the SAP Enterprise Portal.
Scenario:
User logs in into SAP portal via SAML Authentication. This user can view a link in the Portal he can click the link and will be transferred to a website on another domain. This domain will receive the a "ticket" and the user will be able to login.
Information from a friend:
If you have a setup that uses SAML, there are mechanisms to transfer that session between domains that basically rely on passing a ticket through the URL to the client from the authentication server, and that ticket is then passed to the site you want to authenticate against, which can use that to establish the identity of the user with the authentication server and establish the session.
Question:
Is this possible in SAP? If so, can anyone provide me some documentation for this?
The normal scenarion for SSO between domain in SAML is based on relayance on the same IDP. This is a typical flow for a SSO with two domains.
Sign-on on domain1
User accesses domain1
User is forwarded to IDP for authentication.
User authenticates and a session is created at the IDP
User is redirected back to domain1 and gains access
Sign-on on domain2
User accesses domain2
User is forwarded to IDP for authentication.
The IDP already as a session for the user and is considered as authenticated
User is redirected back to domain2 and gains access
This way the uer does not need to authenticate the second time.

How does SE's single signon work?

Basically I just want to know how does StackExchange's single signon system work?
In the SE network you need to login only once in one of the websites to be automatically logged in to the other sites upon visiting.
How should I implement such a feature in my own network of sites?
I assume it uses the cookie which resides on the user's browser and then authenticates it with the originating site. If it is legit then it logs the user in automatically.
You have to implement SAML or oauth2 to allow sso on your network.
In case of SAML your child websites will be service providers or resource servers.
While you need to setup and identity provider.
The sequence of events will be like this.
1. User hits a url of songs website, this site is resource server and does not handle authentication.
2.To authenticate resource server will construct a SAML authrequest and redirects to identity provider after signing it.
Idp verifies the signature after receiving authrequest.
3. User will be presented with a login form, user has to end login credentials.
4. After user authentication idp will generate a SAMl token and redirect back to resource server.
5. Resource server will extract identity information from SAML token, resource server will login the user with session or cookie.
Depends upon which technology you are working in i have implemented it in php using simplesamlphp.