I am working on a project that needs to be integrating SAML2.0. I was thrown into this project suddenly, i need to make it work.
Here is the background: We have created the files and wanted Client Company to integrate using SAML2 to get to our web site. We have sent them the meta datafile.
Now the client company had sent their metadata file. I dont know how and what to do with that file. Any help will be appreciated.
ASP.NET, Framework 4.0
The metadata file basically provides you information of your client. Such as entityID, credential, and so on. If it is an IdP then it also contain couple URLs so that you know where to send different request, e.g. login request, attribute query request. You need to give this metadata to your SAML component so that it know which client it should talk to.
Another main purpose is to establish a trust relationship between SP and IdP.
It's kind of old question but I would like to add some additional information and resources for .NET.
SAML Metadata is used to exchange configuration information between Service Provider and Identity Provider and vice versa. The information can include:
Binging location
Organization name
Contact Person
Single Sign On Url
Single Logout Url
The Metadata can be signed and encrypted so that the information is sent securely. The other side may need the corresponding public key to validate and decrypt it and then can be used to understand and establish the connection with the SP or IdP.
You can see some more info at the following blog posts:
http://samlcomponent.net/constructing-saml-metadata-xml-for-single-sign-on-idp/
http://samlcomponent.net/how-to-create-saml-metadata-xml-for-service-provider/
Security Assertion Markup Language (SAML) is a standard for logging users into applications based on their sessions in another context. This single sign-on (SSO) login standard has significant advantages over logging in using a username/password:
1.No need to type in credentials
2.No need to remember and renew passwords
3.No weak passwords
It is easy to manage all applications in one tree using SAML SSO login.
How actually SAML works:
The user accesses the remote application using a link on an intranet, a bookmark, or similar and the application loads.
The application identifies the user’s origin (by application subdomain, user IP address, or similar) and redirects the user back to the identity provider, asking for authentication. This is the authentication request.
The user either has an existing active browser session with the identity provider or establishes one by logging into the identity provider.
The identity provider builds the authentication response in the form of an XML-document containing the user’s username or email address, signs it using an X.509 certificate, and posts this information to the service provider.
The service provider, which already knows the identity provider and has a certificate fingerprint, retrieves the authentication response and validates it using the certificate fingerprint.
The identity of the user is established and the user is provided with app access.
Take a look at the metadata SAML 2.0 specification to check what elements must be read by your implementation.
If you are looking for a SAML2 .Net Tookit, take a look to this thread of stackoverflow
Also take a look on SAML open source implementations to learn how others resolved this problem before:
SimpleSAMLphp (PHP implementation Idp/SP). (Metadata parser)
Shibboleth IdP (Java) (opensaml2) / SP (C)
spring-security-saml: SP (Java) (metadata files)
Jboss (Java)
Metadata is nothing but the xml file containing all the information required by your SAML implementation to talk with host. you can extract information from this meta to get the desired information required. Like public/private keys.
I hope you are also using certificate to talk with host on secure manner.
This key is required for handshaking with unknown host system.
Related
So, when management tells us our website needs to "support SSO through SAML 2.0", with no additional details, what are they thinking?
What will our customers expect?
Note - The is not an open website, where everyone can join. To log in you need to be a configured user in the system. The customer's admins need to create an account in our system for each user.
So we aren't going to let just anyone who has an account with an IdP in to our website. We'll have to have some mechanism for mapping a SAML identity to our users.
How would our customers expect that to work?
Based on hints in your question, I am going to presume that you will be acting as a service provider.
To be what I would call a "good" service provider, I would expect the following:
You sign your AuthnRequests.
You provide a metadata endpoint that is kept up to date with your SP metadata to include current public keys for encrypting attributes (if necessary) to be sent to you as well as validating your AuthnRequest signatures.
You support dynamic consumption of my identity provider's metadata endpoint to keep your side of the connection up to date, especially with concern to my signing certificate.
You expose management of my identity provider configuration inside of your service provider mechanism to my IdP administrators through a web or API interface.
You either support a mechanism to automatically manage my users (like via SCIM or Graph or something else), or you support Just-In-Time provisioning based on an incoming assertion.
You allow me to decide my SAML Name ID format, and that format is per-tenant. As an example, I may want to use email address as the identifier, while another IdP may want to use sAMAccountName. e.g., john.doe#domain.com vs. johndoe.
You support Service-Provider-Initiated SSO. That means that the user shows up to partner1.yourdomain.com and get redirected for authentication to that partner's IdP, and that going to the location partner2.yourdomain.com would redirect to a different IdP.
As a service provider, you should make using your service easy and secure. By shifting to SAML, it allows you to get out of the business of password and user management because you get to put that back on the identity provider. It allows your users to not have to type in a password (or more, if you're doing MFA) to use your service, removing friction caused by security. It allows you to put the onus of authenticating the user back on the organization that owns the identity.
Your customers would expect that if they have an application that uses the SAML 2.0 client-side stack then when the application sends an AuthnRequest, they will see a login page on your site and once authenticated, the application will receive a set of assertions (claims) from your IDP via an AuthnResponse.
One of these assertions is NameID. This is the "primary key" between their system and yours. Normally this is UPN or email.
This mapping is outside of the SAML spec. There needs to be some kind of "on-boarding" for the customers.
I've been provided a metadata.xml file from a client who is using ADFS, and had some questions getting this configured as an external SAML-based IdP. This is going to be integrated with a web application (LAMP stack, if that's relevant).
1) Can I extract the IdP Issuer URI from this xml file? I see entityID in the file, which is something like "http://sts.blablaba.com". Is this the same thing, or is this something I need to get separately from the client? Is this the same as "Relying party trust id"?
2) I see an <X509Certificate> element that looks like a public key. Is this the signing cert i need to verify the saml messages/asserts? Can I just copy/pasta this into a .crt or .pem file? "DigestMethod", "DigestValue" and "SignatureValue" are also present.
3) With an oauth2 flow, for instance, since it starts at the site, i can store redirects in a session, and send users to different pages depending on what they were initially trying to access. It seems like this would be possible with an SP initiated flow, but the client says this is going to be IdP initiated. Is this type of post-login dynamic page redirection still possible, considering that the Relay State looks like a static value?
Let's say we have a service provider app called A hosted on tomcat, a user clicks a link to the SP A. SP A sees no token is provided so it redirects the user to the IdP for authentication (with a SAML Authn request provided by some means). The IdP then redirects the user to some common login page where credentials are provided, assuming that these credentials are correct the IdP creates a SAML response with a token and some assertions about the subject, and sends it back to SP A. SP A sees this and allows the user access into the application. Great!
I have a few questions though
How is the authorisation request/response sent, I understand there is a redirect binding and a POST binding where the SAMLResponse and request are encoded either as a query param, or sent as an XHTML form in case of a POST binding. But I'm not sure which is used where?
A service provider is the thing providing a service, so Office 365 or Sales force for example. Is each one a separate service provider? I ask as I watched a video where the guy said the service provider was the thing that hosted these services, so I'm not sure of the correct answer here?
How is the token stored on the client side? So for example I am now authenticated against SP A, the user then tries to use SP B from the same machine/browser window, how does SP B and the IdP know that the user has already authenticated and therefore doesn't need to re-authenticate. I.e. the SSO aspect of it.
Does SP B need to be hosted on the same tomcat instance for this to work?
I dedicated significant time to get SSO working for me. The most helpful document was this specification
The answers below are based on this experience:
Redirect or Post binding is used depending on a respective HTTP request header. The Post binding is recommended since it does not imply restrictions on data volume transferred.
A Service Provider in this context is anything that clients request. There may be many of them, participating in the same SSO scheme.
The service providers must be SSO-aware, which includes handling of the authentication response data. Usually you don't have to implement the protocol - there are ready-made frameworks that your SP can utilize.
Service Providers may reside on different servers.
From my own experience:
You choose your own SAMLBinding (redirect or post) depending on what your idp and sp supports. This binding type will be used both for the 1st step (SP -> Idp) and 2nd step (IdP -> SP). If you have some running environment, open your browser devtools and look at network tab to see what happens. It's just a way to send data from browser to SP/IdP.
Both Office 365 and Salesforce.com are cloud services, right? Let's take Office 365. it means that beyond "end-user" services (like Word, Excel) there is some technical SSO service which are common to the platform. It can be viewed as lower (or technical) service layers, I think that what you speaker meant.
The SAML token is stored by you SP application inside your browser, either hidden inside web page, cookie or web storage. It depends on how your SP is implemented.
SAML response can be validate by each SP based on shared private key, so it will decrypt the token using this key and be able to grant user without the help of IdP redirection.
Tomcat have some extension to support SAML. But SAML is designed to work without being on the same instance, as the opposite as basic JSESSIONID cookies.
So you have several instances, of course.
I am creating a service provider which talks to third party IDP for authentication. But I have a concern that I have a set of dedicated machines(Desktop,tab) which are highly trusted, so is their a way in SAML that when a request is sent from such machines user is directly authenticated without the need to type username and password.
you want that user that tries to access a resource from his desktop (which is trusted) will be automatically authenticated? if this is the case, it seems that you need to identify the user using the active directory or something.
if this is the case, search a bit about Kerberos, or ADFS - it might serve your needs.
We are service provider and support SAML based single signon. We want our customers to register us as Service provider in their OpenAm.
When they register us as remote SP, they need to provide us the Signing certificate. How can they easily get certificate so that they can provide us?
In OpenAm when we choose to register Google Apps / SalesForce, at one steps it gives option to download certificate which will be uploaded in Google Apps / SalesForce. But While Registering remote SP, it does not give any certificate.
So is there a way to get certificate easily while registering remote SP similar to Google Apps / SalesForce?
The standard way of doing this is that your customer provides you with SAML meta data. This is a standard format for sharing information about your SAML setup. This also contains the public key for the private key they use to sign.
SAML metadata can be exported from OpenAM. This can be done by the use of export metadata page.
Have your customer go to the following URL
https://<IdP_HOST>/openam/saml2/jsp/exportmetadata.jsp?entityid=IDP_ENTITY_ID
From there the metadata can be exported to XML.