My web application is running on server(cloud) which is not part of my domain. I want to implement SAML based login to the web application with my domain(Intranet machines).
Is it allowed? If it is, any special configuration needs to be done?
Is it allowed?
yes
If it is, any special configuration needs to be done?
You need to implement/use a SAML Identity Provider.
In general SAML was designed as a Single Sign On technology for web-based applications without the use of cookies. You may only use so called 'front-channel' bindings (like HTTP REDIRECT and HTTP POST) to transmit the SAML messages between the SAML Service Provider and the Identity Provider if the Service Provider can not communicate with the Identity Provider.
Related
Is there a possibility to verify login+password in Perl via SAML at an Identity Provider (IdP)? If yes: how?
I am aware that this is not the usual way for SAML to work.
The background to this is that we have 4 different clients for our web application, which is supposed to enable a central password via SAML, which are implemented in completely different technologies.
Our product manager has decided that a SAML connection is too complex for the 4 clients and that authentication should therefore take place centrally in the web application.
The clients transfer login and password to the web application, just like without SSO, and the web application is supposed to verify the access data centrally.
Question 1: Is there a possibility to verify login+password in Perl via SAML at an Identity Provider (IdP)? If yes: how?
Answer:
Definitely No, from the cybersecurity perspective.
Question 2: I am aware that this is not the usual way for SAML to work.
Answer:
Yes. You are correct.
(I) The SAML specification defines three roles: a user, an identity provider (IdP), and a service provider (SP). In the primary use case addressed by SAML, a user requests to access a service or log in to a web application from a service provider. The service provider requests and obtains an authentication assertion from the identity provider. On the basis of this assertion, the service provider can make an access control decision for the user, that is, it can decide whether to allow the user to access the service or log in to a web application.
(II) Before delivering the subject-based assertion to the SP, the IdP may request some information from the user (such as a user name and password) in order to authenticate the user. SAML specifies the content of the assertion that is passed from the IdP to the SP.
(II.a) In SAML, one identity provider may provide SAML assertions to many SPs.
(II.b) Similarly, one SP may rely on and trust assertions from many IdPs. This will be the SAML scenario of your web application if your product manager decided to request all 4 different clients of your web application to develop their own SAML IdP. For example, some social websites allow their users to log in to their web account through identity authentication provided by the third-party IdPs such as Google, Facebook, LinkedIn via OAuth 2 protocol or OpenID Connect protocol/OAuth 2 (instead of SAML).
Question 3: The background to this is that we have 4 different clients for our web application, which is supposed to enable a central password via SAML, which are implemented in completely different technologies.
Answer:
If 4 different clients for your web application are supposed to enable a central password via SAML, they can implement their own SAML IdP in completely different technologies or programming language such as Java, PHP, or Scala.
(I) For example,
We developed our former version of Zero-Password Authentication and Authorization System in Java and leveraged Java-based Shibboleth IdP to provide SAML SSO for enterprise applications.
We developed our current version of Zero-Password Authentication and Authorization System with scalability and high availability in Scala to provide SAML SSO natively for enterprise applications without Shibboleth IdP.
(II) No matter which technology or programming language are used by 4 different clients of your web application to implement their own SAML IdP, their SAML IdP only needs to authenticate their users using a central password data store/repository (such as OpenLDAP or MySQL) locally and then deliver the user info using SAML assertion/SAML response to your web application/SAML service provider. Your web application/SAML service provider just needs to map the user info carried by SAML assertion to a local user info of your web application.
Question 4: Our product manager has decided that a SAML connection is too complex for the 4 clients and that authentication should therefore take place centrally in the web application.
Answer:
If the user identity authentication needs to take place centrally in your web application instead of in the SAML IdP, then 4 different clients do NOT need to implement their own SAML IdP from the cybersecurity perspective.
Instead you just need to create and assign different sub-domain to all 4 different clients, that is, all 4 different clients of your web application access different sub-domain, such as client-org1.your-web-app.com, client-org2.your-web-app.com, client-org3.your-web-app.com, client-org4.your-web-app.com.
Note that different sub-domain of your web application displays the same login webpage. Example #1: client-org1.box.com, client-org2.box.com if your clients also subscribe Box account, or Example #2: client-org1.my.salesforce.com, client-org2.my.salesforce.com if your clients also subscribe Salesforce account.
Question 5: The clients transfer login and password to the web application, just like without SSO, and the web application is supposed to verify the access data centrally.
Answer:
Different sub-domain of your web application displays the same login webpage.
4 different clients of your web application access different sub-domain of your web application, users of 4 different clients submit their login and password to your web application (through different sub-domain URL), just like without SSO, and the data store/repository of your web application is supposed to verify the access data (i.e., login username/password) centrally. Then 4 different clients of your web application do NOT need any SAML IdP.
Looking for direction.
I've got a single web application that I want to SSO into from multiple applications that all handle their own authentication. The web application wants to use SAML for SSO'ing. The web application requires IdP metadata (we've got one web service that is its own IdP, don't know what the other applications are using). The web application can also accept SAML Assertions with provisions to determine user access when it creates the new users after they SSO in.
I'm looking to get a one stop shop for the web application to hit to determine authentication and authorization.
I've got another web application (.NET Core) that runs Identity Server 4 to handle authentication for one of the many applications that wants to SSO into the web application. Can I use that? I would need to integrate SAML into it. How do I do that? Also, how can I easily integrate all the other applications to use this one web application to SSO into the SAML web application. Is this what Federating is?
Trying to do this with minimal work to all the other applications because that kind of integration work across multiple teams would be kind of a nightmare.
Any suggestions?
Thanks!
If you're already using Identity Server 4, you're probably best to stick with it and add SAML SSO support to it.
SAML SSO support isn't included natively in Identity Server 4 but there are two commercial offerings that add this support.
The following link has some good articles describing how to support SAML SSO in Identity Server 4.
https://medium.com/the-new-control-plane/tagged/identityserver4
We want to deeply integrate OneDrive with our web app in order to handle document and storage data. However, we want the users not to log in twice. I'm not sure whether this is possible, but I've been reading about SSO and SAML and it seems like it's the way to go.
Is it possible, and if so, is Single Sign On the way to go?
Single Sign-On (SSO) is a great solution for user experience when web applications are hosted on different domains. SAML as a standard was developed for cross domain authentication to solve this use case. You will need an Identity Provider (IdP) server that handles authentication of users to your web application and then the IdP Server issues SAML assertions to your web application and OneDrive. Your application in this architecture will be a Service Provider (SP) that will consume SAML assertions, as well as OneDrive is a SP that consumes SAML assertions. There are a number of SSO/Federation vendors that provide the IdP Server.
As far as implementation, once you have chosen and installed the IdP Server, you will need to implement your web application to consume the SAML assertion and configure the IdP Server as a connection. OneDrive will simply be a configuration as it already supports SAML and WS-Federation.
In addition to SAML as a protocol, there are other standards with respect to SSO/Federation such as OpenID Connect (OIDC) and OAuth2. When choosing a IdP Server solution you may want to look at these other protocols that can solve additional use cases. SAML works well for web applications and the use case you have described. OIDC and OAuth2 are better suited for secure APIs and native mobile applications.
Another consideration when looking at an IdP Server is how authentication is to be performed. Options for authentication could be using Kerberos/IWA if all clients are on a common domain, or authentication using a Login Form. You may also want to look at MFA support when looking at an IdP Server as part of the SSO solution.
presently we have ADFS 3.0 acting as federation gateway among multiple client IDPs and our web application. So in summary, for client IDPs our ADFS act as Relying Party, while for our in house .net based web applications (taking advantage of WIF framework), our ADFS act as IDP. Finally when user ends up on web application, we receive all transformed claims from client IDPs.
One of our client IDP uses SAML protocol, which is nicely converted to WIF claims by ADFS and web application can read these claims. But we have new requirement, where we will also need to read untouched SAML Protocol response which is http-posted to ADFS by client IDP during SSO handshake. During this HTTP POST on ADFS, we receive SAMLResponse and RelayState as 2 different parameters. Now this message is converted to WIF based params (wa, wresult, wctx) by ADFS and posted to our web applications.
Our web application acting as relying party on ADFS 3.0 is configured with WS-Federation Passive Endpoints. There is possibility of adding additional SAML Assertion Consumer. But I am not sure how I can mix and match multiple endpoints?
Any idea how I will get SAMLResponse parameter which was originally posted on ADFS. Is it achievable?
Thanks in advance!
The SAMLResponse is sent to only one EndPoint. Adding an EndPoint will not give you an extra copy.
ADFS does not have a "span" port (outgoing copy for Log). A reverse proxy/loadbalancer often has a "copy" port feature. But if the SAML token is encrypted then you still need the private key of the ADFS Decryption cert.
A lot of work.
I need to implement a SAML based authentication module and I am looking for answers to some basic question related to SAML. I tried searching for answers but couldn't find detailed information.
Resources to be protected is a SaaS based web application. Design I have received require4s building an authentication module using OpenAM, Ping, etc. Any access to web application will get authenticated through authentication system via SAML.
Questions that I have in this regard are:
If I understand correctly, SAML request contains a username. When someone first access web application, application has no information about user, how will it generate an SAML request then?
Once a SAML response is received by application, do subsequent access of web application by user also need to be routed and validated via authentication system?
Web application can interact with other sub-systems via web services or api calls. How can authentication context be passed to those systems.
No, the AuthnRequest does not have to contain a user name. It may, but in most cases it doesn't.
No, once the SAML response is received, the application typically set a cookie to create a local session.
The SAML Assertion can be passed to other services that the application uses. This is a non-trivial setup, but possible.