I'm trying to configure Google Apps as SAML IdP with Zoho as service provider.
After authentication, the SAML response xml from Google always contains NameID Format as unspecified.
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">email#company.com</saml2:NameID>
Google Apps does have the option to change the NameID Format. Refer this screenshot :
Service Provider details
But even if EMail is selected as NameID Format, the above response is present in SAML Response xml.
The expected NameID Format in response is as follows :
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">email#company.com</saml2:NameID>
Is there a way to achieve this ?
Check if Zoho-SP sends <AuthnRequest /> with Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" to Google-IdP. If yes, send <AuthnRequest /> with Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" from Zoho-SP side and try.
Setting NameID format in IdP is for default configuration. That setting won't be taken, if AuthnRequest specify which NameID format to used to identify the user between IdP and SP, upon authentication.
Related
I want to know if there is a way to only use GET type requests in the exchanges with the IDP. I don't want to use a POST method to exchange with the IDP. Is there a parameter that allows this ?
Take a look at section two of the "Conformance Requirements for the OASIS Security Assertion Markup Language (SAML) V2.0" specification.
The SAML authn request sent to the IdP may be sent using HTTP-Redirect, HTTP-Post or HTTP-Artifact. The SAML response sent to the SP may be sent using using HTTP-Post or HTTP-Artifact. HTTP-Artifact is rarely used which means the IdP will send the SAML response using HTTP-Post.
There isn't an option to send the SAML response using an HTTP GET. The reason for this is that SAML responses are generally too long to be encoded as query string parameters.
We're using SAML 2.0 for SSO, and want to improve the UX by allowing a user to enter their email only once (to identify they need SSO). Is it possible to pre-fill the SAML SSO email field when authenticating with Google's SAML IDP?
I know that the AuthnRequest has an optional Subject field that can pass the principal information to the IdP, but so far I haven't managed to have Google's SSO form pre-populate. Either it's not supported from the IdP, or I'm sending the wrong configuration.
The existing configuration I've been trying to use looks like this:
<AuthnRequest xmlns="urn:oasis:names:tc:SAML:2.0:protocol" ID="_cd...." Version="2.0" IssueInstant="2019-01-01T00:00:00Z" Destination="https://accounts.google.com/o/saml2/idp?idpid=...">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">(issuer_name)</saml:Issuer>
<Subject xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">me#example.com</NameID>
</Subject>
</AuthnRequest>
I would expect the Google SSO form to autopopulate me#example.com, but nothing happens.
The Subject element is optional in an authentication request and even when included, it's ignored by most IdPs. Since authentication request can be sent to the identity provider by an anonymous party, performing a UX action like you're thinking about would certainly lead to an easy phishing vector.
I'm knew to SAML and i'm trying to understand how a clients details are stored for SSO.
If select a link in a browser to a service provider and I haven't been set up on the IDp after I have my account created at the IDp and authenticated to the SP what is stored? is it my ipddress? if I tried to connect to the same SP from a different machine would I need to be registered on the IDp again.
Or is it done another way?
Thank You
An IdP creates a SAML assertion about an authenticated subject.
Based upon the NameID format being used an opaque handle could be transmitted ("transient NameID format") or an email address ("email NameID format") or even some other id can be transmitted from the IdP to the SP. Furhtermore attribute statements could be used to transmit additional information about the subject.
Authentication happens on the IdP, however it's not defined in the SAMLv2 spec how this has to take place.
If authentication happened a "session" is established at the IdP. Most IdP implemenatations use a cookie to track the "session". So when you return to the IdP again there is no need for re-authentication unless an SP mandates this. ("ForceAuth" in the SAML AuthnRequest).
This is only a quick overview, reading the SAMLv2 tech overview (https://wiki.oasis-open.org/security/Saml2TechOverview) certainly gives you more insights.
When initiating a SAML authentication request (from the Service Provider), is there any way to give the Identity Provider a hint as to which username to use? In my application I know which user it wants to authenticate (based on a unique link the user clicked in an e-mail), and I'd like that username to be prefilled in the IdP's username box.
Using SAML 2.0 with Active Directory Federation Services (AD FS) 2.1.
Yes, you can use the optional <saml:Subject> field in the AuthnRequest message sent from the SP to the Idp to request a specific subject from the Idp. See section 3.4.1 in the SAML2 spec.
I have no idea if ADFS respects that field though.
I am new to the concept of Single Sign On(SSO). I came to know that SAML request and response is the best way to achieve SSO process. I then started reading about SAML2.0. I came around a term NameIdPolicy in saml2.0 which was not there in saml1.0.
Definitions say that It is the format of the NameID we request from the IdP.I want to know what is that format is? I mean what data from IDP should come in the format NameIDPolicy specify? Can anyone brief me on this NameIdPolicy concept?
From the SAML 2.0 core spec, the NameIDPolicy
Specifies constraints on the name identifier to be used to represent the requested subject. If omitted,
then any type of identifier supported by the identity provider for the requested subject can be used,
constrained by any relevant deployment-specific policies, with respect to privacy, for example.
When performing identity federation, the affiliated parties must agree upon an identifier for the principal's linked accounts. The identifier string is called a NameID and its specification, including format, is the NameIDPolicy.
For example, a Service Provider (SP) initiates federation by sending an AuthnRequest to the Identity Provider (IDP) containing
<samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
This tells the IDP that its response Assertion XML should contain something like
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">user#example.com</saml:NameID>
where the email address represents the subject being authenticated.
You can learn more by reading SAML 2.0 Wikipedia page (well-written), the SAML 2.0 core spec and the SAML 2.0 Name Identifier document.