I'm having difficulty finding guidance on the implementation of SAML alongside an existing, traditional authentication system.
I have created a SaaS application in CodeIgnitor which has the typical, run-of-the-mill authentication system using a local users table with hashing and salting etc.
I'm looking to add SAML SSO to attract more enterprise customers. I have a question however where my Google Fu is falling short.
How can I integrate SAML authentication so that it works along-side my traditional, local authentication? If my customers choose SAML then I will require them to bind their existing local accounts to their SAML federated identities. What do I do to cater for my non-SAML users?
Do I need two login URL's such as https://app.com/saml/login for my SAML users and https://app.com/login for my non-SAML users, and just expect customers to choose the right one? Or perhaps I ask for their email/username first, and then require them to submit that value to see if they're SAML or not - and route them accordingly?
You need to install an Identity provider (IDP) that supports SAML.
You use the IDP Initiated SAML profile.
Your app. is connected to the IDP via a SAML stack.
Other enterprises can then federate with your IDP i.e. login to your web site with their credentials via SAML.
The IDP Initiated SAML profile provides a URL that you give to customers that takes them to your IDP with their customer credentials and thence to your app.
Users going direct to your website use the local connection.
That said, rather use OpenID Connect - it's much simpler but the principles are the same.
Related
I was already looking for quite some time for my issue:
have Several Independend Apps implemented in Symfony
Each uses an centralized API
Login should be handled by an own central Application
My Idea is
domain security.xxxxxx.xxx handles the login form and app
domain frontend.xxxxxx.xxx handles the working customer stuff
domain cms.xxxxxx.xxx is the non loged in users stuff
domain backend.xxxxxx.xxx handles staff administration stuff
domain support.xxxxxx.xxx handles user support related stuff
domain api.xxxxxx.xxx handles the central database related stuff for internal and third party applications
domain reg.xxxxx.xxx handles new user registrations
domain job.xxxxxx.xxx handles the job worker stuff
domain monitoring.xxxxx.xxx handles the monitoring of app data etc.
the main idea is that each system is handles by an unique server.
All are connected within the same network but each have different resources and services connected to it.
I tried to use lightSaml for symfony. But don't get the point in how to implement the server component for providing identities.
The security should be provider and authentication interface.
Kind of handling like my.atlassian.net.
This is an Service like I would love to implement.
Any hints are appreceated.
SingleSignOn can ba achieved in many ways and protocols:
SAMLv2
Oauth2
JWT
OpenID
etc
There is two considerations:
Work with tokens
Work with users
For business constraints I could not use a third party provider (Auth0, Okta, etc) which I really encourage.
Implementations: https://en.wikipedia.org/wiki/List_of_single_sign-on_implementations
Work with tokens in symfony
You store the access and refresh token (It may change the name on each implementation). This has the limitation that as the Symfony app is not constantly running only when you have a request you have to reload/refresh the user per request (Request to the Identity Provider server).
Benefits:
Single sign out as once you logout to the Identity Provider you invalidate the sessions.
Risks:
You will get a request to the Identity Provider for each request in your app.(You can make workarounds there it is a Symfony implementation limitation)
Working with users
You authenticate and authorize the user on the Identity provider and create a user in the microservice you have.
Benefits:
Full control of the user data you store. Once authenticated you do not need access to the identity provider.
Risks:
Once you logout of your app if you have not logged out from your SSO/Identity provider the user will automatically logged in back.
You have to keep user details in sync or do not allow the user to update their personal details that comes from the Identity provider in your microservice.
My case: OAuth2
I've personally choose working with users on the symfony services as I want to have more freedom on how I store the user details, which details I store and keep most of the traffic on the service.
Ideally I wanted to use SAMLv2 but I could not find any solution that I was willing to carry over for a long time implemented in PHP, there is many in JAVA.
Technical stack on the Identity Provider
Symfony 2.7 (We have planned to upgrade but it is not a priority now)
FOSOAuthServerBundle : https://github.com/FriendsOfSymfony/FOSOAuthServerBundle
MySQL
MsSQL
Technical stack on the Microservice
Symfony 3.4
MySQL
FOSUserBundle
HWIOAuthBundle https://github.com/hwi/HWIOAuthBundle
If you decide to work with OAuth2 I recommend you this guide: https://alexbilbie.com/guide-to-oauth-2-grants/
I am a newbie in SSO implementation. We are looking at implementing SSO for a client that uses a php application (supported by us), for their employees to login to the application. We are in the process of setting up Simple SAML for this .. I have been reading articles on SSO, many of which are helpful. Pardon me for asking this, I know it is dumb. In this scenario, who is the IDP and who will be the service provider. The client apparently uses SSO for other applications as well. Can someone throw some light on what all I need to setup from our end.. I will research on how to do each of them..could someone please help by mentioning the things that need to be implemented.
who is the IDP and who will be the service provider.
IDP (Identity Provider) is the one who creates, stores, maintains and authenticates the identity of the user or principal in saml terms. So in your case it is the clients application.
SP (Service Provider) is the one who provides the service or resource to a user (authenticated by IDP) so in your case it is your application.
could someone please help by mentioning the things that need to be implemented.
As you can see in the above diagram when user will try to access a resource on your site you will have to redirect them to IDP to confirm whether this user is authenticated and if you should return them the resource/response they are looking for. The SSO url and other details are exchanged between IDP and SP through Metadata.
Once IDP has authenticated the user it will POST a response on your application url. This response contains an assertion through which you will know user details and whether user is authenticated or not. You will have to parse this response (xml). Also, these assertions are generally signed with certificate and are encoded base 64.
You will also have to think about SLO so when a user clicks on logout in your site you might have to clear their session from your application and redirect them to the IDP so they get logged out from there as well.
As suggested by smartin you can use some library which will make it easier to implement SAML. I am also learning about SAML as we are working on converting our current application into IDP :)
I found this SAML official documentation and some of the diagrams very helpful. http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0-cd-02.html
Your app is the SP, and the customer will provide to you the IdP metadata to register on your SP.
In order to add SAML support to a PHP application, you have 2 alternatives:
simpleSAMLphp
php-saml
LightSAML
All of them are well documented, you will need to spend some time reading/learning.
Im trying to use ADFS for SSO on a project. The project is on PHP and Im trying to use OAuth for this.
So what are the steps for setting up ADFS to work with OAuth2? I have no idea about ADFS and cant get any direct guide on OAuth2 settings there.
Thanks a lot.
I see that the question is quite old. But in case if other people will
get here, I have some answer which should be good for March 2019.
Let me start with a general overview.
SSO
SSO could be done with personal Google, Facebook, GitHub, Twitter, Microsoft accounts. After logging in to your account, you can log in to other systems (e.g. WordPress or any other) without password (if other systems integrated with that Identity Provider) and you give the consent (see picture below).
There are services whose main focus is to provide Identity Provider / SSO capabilities (e.g. Okta, Auth0, Google Cloud Identity, Azure Active Directory, AWS IAM).
In the corporate network, the user could be silently signed in based on the AD account without entering credentials via ADFS.
Actually, ADFS supports different authentication protocols like SAML, WS-Fed, and OAuth. But nowadays usually services implement OpenID Connect which works on top of the OAuth 2.0 protocol.
OpenID Connect flows
There is a number of authentication flows that OpenID Connect defines.
Most preferable ones are:
Authorization Code Flow with PKCE (single-page applications, native applications)
If you are using oidc-client-js, you should use response_type=code to use PKCE.
Public native app clients MUST implement the Proof Key for Code Exchange (PKCE RFC7636])
https://www.rfc-editor.org/rfc/rfc8252#section-6
Note: although PKCE so far was recommended as a mechanism to protect native apps, this advice applies to all kinds of OAuth clients, including web applications.
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-12#section-3.1.1
Implicit flow considered as Not recommended:
Clients SHOULD NOT use the implicit grant and any other response type causing the authorization server to issue an access token in the authorization response
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-09
Client credentials flow. For service-to-service communication.
How to configure ADFS?
You can find quite detailed documentation with illustrations for "Native app scenario" at Microsoft Docs: Native client with ADFS.
If you are not using ADFS, you can play with the PKCE flow setup in the playground.
JavaScript frontend
Never store client secrets in public applications like JS frontend or mobile apps. It's not applicable to PKCE flow but just in case.
If you have a modern SPA application (e.g. Angular or React), it means that frontend should have only client_id to enable end-user to obtain the JWT access_token in a browser via ADFS. You don't need any client_secret.
oidc-client-js could help you with that. Make sure that code_verifier is being sent along with a token request (it means that you are using more secured PKCE flow).
PHP backend
And on PHP side you'll need to validate the access token. You can implement the workflow on your own according to that article. But it's better to use OpenID certified library which you can find on this page (not only for PHP):
https://openid.net/developers/certified/
So, for PHP there is only one: phpOIDC.
Authentication
OAuth 2.0 can help you only with authentication (to identify the user's identity).
Most probably you would like to have different permissions for different users. And OpenID Connect implementation in ADFS provides you the ability to map AD groups to token claims. Therefore, you can decode JWT access token on the backend and implement claims-based authorization.
To use JWT claims be sure to properly validate the authenticity of the token and issuer:
Validate JWT signature using public key
Check issuer for the proper issuer (Identity Provider)
Check aud (audience) for the proper client ID
Check exp (expiration timestamp)
Check claims
My website is used by multiple companies. These companies want to implement SSO. So they log into their company portal and click a link to my website. They go to my website's home page without logging in. My website is in php. The different companies can have their website in any language. We want this to be as general as possible so all companies can use it. It also needs to be secure for obvious reasons and also because we are a health company with phi.
I've read through a lot on simpleSAMLphp, but I'm just not sure if I'm right about how to implement this.
Do I just set up my website as an SP with simpleSAML and say to other companies "this is what I use make yourself an Idp and send me the correct data" ? Is there another way to go about this ?
Well, if you wanna provide a good service, guess you would have to support multiple SSO protocols, and let the clients choose. Beside SAML there are OAuth OpenID Connect and JWT I would mention as relatively simple and well adopted. I find JWT especially simple and easy to use.
Regarding SAML PHP implementation, I have tried with simpleSAML but it turned out to be too complicated to integrate it into an existing app. I prefer the lightSAML library, which is actually v2 of aerialship/lightsaml, especially because my app was in Symfony and lightsaml had a security bundle.
Yes - pretty much.
You send the companies your SP metadata and they import it and then they send you their IDP metadata and you import it.
The trick is the "primary key" i.e. how does the user in another system match a user in yours. NameID is usually used for this and it can have a number of formats.
Again, this is all in the metadata.
Another very useful part of being the Service Provider (SP) in a SAML integration, is to have a IdP Discovery Service. Since each one of your partners will exchange metadata with your organization, each is essentially a point-to-point SAML connection. The IdP Discovery Service uses something in the request to identify the partner and invoke a SAML SP-Initiated SSO transaction. One of the common strategies is to use URL naming such as yourpartner.company.com. Then the IdP Discovery Service detects the subdomain "yourpartner" in the URL and then invokes the proper SP transaction. There are other strategies, but I find this one works best for most organizations.
So my scenario goes like :
I have two sites a.com and site b.com and one authentication server cauth.com.
what client wants is ...
When user lands on a.com or b.com user fills in the login form on respective site , but the action of form will be on cauth.com (cauth.com/authenticate). when user is authenticated on cauth he is loggined on the both sites.
I am thinking to implement SAML to achieve the same and flow is like
after authentication iDP(cauth.com) will send SAML response to the both the service providers and user will be given access to both the sites .
I am novice in SAML and unable to get proper documentation and comprehension for the same.
What I want to know is :
Is my solution to the problem worth implementation ?
Is it possible to make site (cauth.com) as identity provider.I have looked at thread Making your PHP website into SAML Identity Provider but not able to get proper solution.
SimpleSamlPHP should be pretty easy to set up. You'll want to make a copy of the folder modules/exampleauth/ and then alter the file modules/<yournewmodule>/lib/Auth/Source/External.php to work for your site. The documentation is good though and it's definitely the easiest thing for your need, and the right one.
I should add that following the instructions to set up SimpleSamlPHP should give you a basic understanding of which metadata files are most important and where they live and how things interact.
I am not sure which technology you are using for your application. If you are free to switch to JAVA then I can suggest you Spring-Saml because its very easy to implement and fulfill your requirement. Spring-Saml has good documentation and online support as well being it as open-source project.
You can refer this link for Spring-saml and for code-repo use this link
You can integrate spring-saml in your abc.com and xyz.com application to make it Service provider(SP) and you can deploy it on different domain as well. Then you need to have one IDP (identity provider server) for your SPs. So you can use either ADFS with Active directory or LDAP to act as IDP.
We had similar requirement for our customer. I recently integrated spring-saml in my project.
Please let me know for any help
A federated Single Sign On (SSO) mechanism like SAML or OpenID Connect will give you what you want.
This comes with the important distinction that the login form would not be presented on a.com or b.com but those sites would rather redirect to cauth.com and the user would authenticate there. cauth.com would then send a verifiable "assertion" to a.com and b.com that the user has authenticated successfully. This constitutes one of the major goals of federated SSO, namely that the user credentials should not be presented/stored-by foreign websites and makes the means of authentication independent from the target websites ("Relying Parties").
So what you should be looking for is a suitable implementation of SAML or OpenID Connect for your platform (don't write it yourself!) and leverage that.
Shibboleth is open source and one of the most popular SSO solutions. It includes a SAML Identity Provider which you can download here: https://shibboleth.net/downloads/identity-provider/latest/ .
If your client is willing, one approach would be to use a cloud SSO provider like Okta which has a developer program and could make things easier.
I think there is a subtle misunderstanding in your description. For SAML authentication, if a user at site a.com either clicks a login link/button or tries to access a secure page, that user will receive an http 305 redirect to cauth.com. There the user will enter their credentials, and the user will be redirected back to a.com. If that user then goes to site b.com and tries to access secure content, b.com sends the user to cauth.com with the same http 305 redirect. This time, as there is an active session for the user's browser at cauth.com, the user does NOT see the credential form. Instead, the IDP returns the user with a successful authentication to b.com. It appears to the user that they are automatically logged on to site b, but in truth a SAML authentication flow has occurred.
Hans Z's answer elides the fact the that IDP only sends the assertions on the request of a or b (the Relying parties or RPs, also known as Service Providers or SPs). It is not a broadcast to all RPs.
I'll reinforce that SAML does NOT support a.com receiving the credentials from the user and then passing them to the authentication engine. This is a pattern one may be familiar with from LDAP.
Take a look at the sequence diagram in the wikipedia entry on SAML.
Follow below instruction to get SAML implimentation with PHP.
SAML login setup is very easy in php.
First register on onelogin server
https://www.onelogin.com/signup and create demo app on it. After
it follow all instruction to set Idp (Identity provider setting ) and
sp (service provider setting) to settings.php
https://developers.onelogin.com/saml/php
It worked perfect for me with CI and and php