I implement a SAML 2.0 SP.
I have a login servlet with endpoint https://my.domain.com/mng/samlLogin, so in the SP metadata file I define:
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://my.domain.com/mng/samlLogin" index="0" isDefault="true"/>
And send this endpoint in the AuthenRequest under the AssertionConsumerServiceURL.
Now, I have another servlet with a different functionality, and it needs to validate the user against SAML as part of its flow.
So I need to define the new servlet's URL as an additional endpoint, let's say https://my.domain.com/mng/myServletSamlLogin , which will get SAML authentication reponse.
Is this possible? Can I define multiple AssertionConsumerService elements for the same binding (HTTP-POST)?
Thanks!
Yes, you can include additional <md:AssertionConsumerService> elements in the SAML 2.0 SP metadata with the same binding, each with its own unique index. Alternatively you can choose to sign the authentication requests as the SP in which case you can freely specify an AssertionConsumerServiceURL without the requirement that it was published and configured earlier as part of the SP metadata exchange.
This is all spec compliant but be aware (as always with "advanced" SAML options) that your mileage may vary wrt. support across different SAML implementations.
Have a look at Assertion Consumer Service Glossary which will tell you that
Assertion Consumer Service
A SAML-compliant portion of PingFederate in an SP role that receives
and processes assertions from an IdP.
attributes
Distinct characteristics that describe a subject. If the subject is a
Web site user, attributes may include a name, group affiliation, email
address, etc.
attribute contract
A list of attributes, agreed to by the partners in an identity
federation, representing information about a user (SAML subject). The
attributes are sent from the IdP to the SP during SSO or STS
processing.
So you associate bindings to the Assertion Consumer Service (ACS) endpoint(s) where your SP will receive assertions.
Related
I'm doing a technical assessment for a job interview. It's called on me to walk through implementing a client using OneLogin (IDP) into our software (SP) with SSO.
The activity is asking me to include 3 things:
Service Provider
Identity Provider
Generate and distribute the sp metadata to the client
I'm using https://www.samltool.com/sp_metadata.php to generate the metadata but I'm wondering what the purpose of this doing this when this SP is already a verified app on OneLogin?
OneLogin's knowledge base here doesn't indicate the need for the SP metadata to implement. It doesn't even call for any SP entity's or endpoints. It seems like I would need the idp metadata as the endpoints use a unique value but not the opposite. So am I right in assuming that generating and sending the client the SP metadata is useless? Or is there a reason for it?
If you're using a Onelogin catalog app, you often don't need any instance specific metadata from the SP. The catalog apps are supposed to shortcut and simplify configuring a standards based SAML supporting SP. Some of the Onelogin catalog apps sometimes need some metadata, such as a RelayState parameter as per the SP requirements. If a catalog app doesn't exist and you're building a custom SAML app in Onelogin, you'll need the SP metadata in full.
So I'm trying to integrate single sign-on with Auth0 (being both the service provider and the identity provider) with the Atlassian stack.
Atlassian offer SAML single sign-on. However, it is telling me:
Your users won't be able to log in with SAML single sign-on until you've copied
the values for SP Entity ID and SP Assertion Consumer Service URL to your
identity provider.
I've put the assertion consumer service URL in place of the callback URL, I've done some research and I'm almost certain this is correct.
However, the issue is with the Entity ID. Where does this go?
I've not used Auth0 before, but I think you have to set it as audience in the settings, e.g. see https://auth0.com/docs/protocols/saml/saml-apps/heroku
IMHO but the configuration option is a bit misleading. Instead of using audience, using EntityID might be clearer, as this is also the term used in the SAML spec.
I am assuming that auth0 acting as a service provider.
Assertions Consumer service URL should be :
https://YOUR_DOMAIN/login/callback?connection=YOUR_CONNECTION_NAME
Entity ID of the service provider should be:
urn:auth0:YOUR_TENANT:YOUR_CONNECTION_NAME
You can download service provider metadata like below in the XML format and upload to IDP to generate configuration.
Navigate to https://YOUR_DOMAIN/samlp/metadata?connection=YOUR_CONNECTION_NAME
Additional:
URI: urn:oasis:names:tc:SAML:2.0:nameid-format:entity Indicates that
the content of the element is the identifier of an entity that
provides SAML-based services (such as a SAML authority) or is a
participant in SAML profiles (such as a service provider supporting
the browser SSO profiles). Such an identifier can be used in the
element to identify the issuer of a SAML request, response,
or assertion, or within the element to make assertions about
system entities that can issue SAML requests, responses, and
assertions. It can also be used in other elements and attributes whose
purpose is to identify a system entity in various protocol exchanges.
The syntax of such an identifier is a URI of not more than 1024
characters in length. It is RECOMMENDED that a system entity use a URL
containing its own domain name to identify itself
(SAML CORE specification, section 8.3.6)
https://www.oasis-open.org/committees/download.php/7473/sstc-saml-core-2.0-draft-15-diff.pdf
https://spaces.at.internet2.edu/display/InCFederation/Entity+IDs
A customer is currently trying to decide if they want a SAML 2.0-based SSO implementation for their application. However, their users have many different identity providers. I have build some SAML-implementations, but they were all for one identity provider only and I don't have any hands-on experience with one application using many different identity providers.
Question: can you generally build one configurable SAML-client for multiple identity providers or do you have to build multiple distinct clients in order to service them all?
A single Service Provider (SP) can use as many Identity Providers (IdP) as it wants. The only thing the SP needs to know is which IdP to use for a particular user. It does that in one of two ways. Either it displays a list of IdPs it knows about and the user selects one, or the user arrives at the SP on a 'WAYF-less' URL. WAYF means Where Are You From but is largely superceded by the SAML discovery process. Providing the entityID of the IdP to the SP bypasses the WAYF, hence WAYF-less URL.
e.g. you could have a URL scheme along the lines of:
https://yourapp.com/login?idp=https://someidp.com/shibboleth
https://someidp.com/shibboleth is the entityID of the IdP. Your SP looks up that entityID in its metadata store to find the SSO URL of the IdP and sends the user to their correct IdP for login.
Once your SP redirects the user to their IdP, SAML flow is normal after that. So the only thing the SP needs to do is work out where that SSO URL is. All the IdPs will return the same SAMLResponse format but with their own attributes etc of course.
I!ve a question similar to How To Become a SAML Service Provider, but it misses some part I would like to clear up.
The SAML SSP profile spec describes several possible bindings, and states that the usage depends on SP and IdP setups.
The SAML Conformance and Profiles specifications identify the SAML
bindings that can legally be used with these two messages.
Specifically, an Authentication Request message can be sent from an SP
to an IdP using either the HTTP Redirect Binding, HTTP POST Binding,
or HTTP Artifact Binding. The Response message can be sent from an IdP
to an SP using either the HTTP POST Binding or the HTTP Artifact
Binding. For this pair of messages, SAML permits asymmetry in the
choice of bindings used. That is, a request can be sent using one
binding and the response can be returned using a different binding.
The decision of which bindings to use is typically driven by
configuration settings at the IdP and SP systems. Factors such as
potential message sizes, whether identity information is allowed to
transit through the browser (if not the artifact binding may be
required) , etc. must be considered in the choice of bindings.
The first question I have: as a Service Provider, am I free to choose any one of the SP -> IdP bindings, and it will work with any IdP out there, or I should make this configurable in my implementation and support all the bindings? (Nota bene: I will probably integrate an existing saml library to help my life, but I should know what configuration options should I allow and support on my interfaces.)
The second question is about the SamlResponse coming back from the IdP upon successful authentication. As far as I understand, SAML just tells me that the user suucessfully authenticated with the IdP. As a result I would expect to give me back some user identifiers in the Response, like a uid, username or e-mail address that I can query from a local user db or LDAP and run app-specific authorization logics.
How can I ask the IdP the user identifier I need and how/where will it be returned? I can't see anthing related to this in the Wikipedia example
Depending on what bindings your SAML-IdP and SP server supports, you can choose any combination of binding pair. Typically all major SAML-IdP supports most of binding specified in SAML-spec. Also you have to take security and performance considerations. Artifact is more secure but take two round-trips to complete SAML-Authn process, because it make back-end call communication (unlike POST or Redirect) while sending and receiving SAML messages. If your SAML-IdP and SP server supports binding configuration, then you use those bindings in runtime.
NameID format identifies user between IdP and SP, which is sent in SAML Assertion by IdP. It can be emailAddress, unspecified, transient, persistent and few others. Check Section (8.3) Name Identifier Format Identifiers from SAML Spec for more details. Also you could request IdP to send user attributes (that exist in IdP identity-store) in SAML Assertion.
I've implemented my Service Provider and Identify Provider following the SAML Profile for Web SSO using HTTP POST Protocol Binding. However, I am a bit confused as to how the Identity Provider will provide an <AuthnStatement> if the HTTP POST coming from the Service Provider is not tied to a session on the Identity Provider.
Could someone enlighten me how one would be able to do this?
The other approach I could use is the HTTP Redirect Binding, but that requires User-Agent intervention (i.e., the browser), often using the User-Agent simply as a pass-thru intermediary to faciliate the Request-Response message exchange. I'd rather use HTTP POST for this reason, because the message exchange occurs server-side, so the user sees nothing happening on their screen.
However, using HTTP Redirect makes more sense to me with respect to how I'd be able to tie a session to a request. Since the HTTP Redirect is facilitated via a User-Agent, the request to the IdP will have a session (if previously authenticated). What I don't get though is how to send an <AuthnRequest> on a HTTP Redirect. Answered by JST
So I'm a bit confused and would love to hear what other people are doing. Here are my questions again:
Using the HTTP POST Protocol Binding with the IsPassive option the <AuthnRequest>, how do I tie a request made by the Service Provider to a session on the Identity Provider? In other words, how does the Identity Provider know who is making the request if the POST is coming from the Service Provider which is technically an anonymous session?
Using the HTTP Redirect Protocol Binding, how do I send an <AuthnRequest> to the Identity Provider if I am using a HTTP Redirect? Answered by JST
UPDATE
Sorry for the confusion if I was unclear in my explanation above. I am implementing both the IdP and SP (via a plugin). The IdP is an existing application for which I want the SP (a third-party system) to use for authentication (i.e., Web SSO). I am developing a simple PoC at the moment. The SP is actually a third-party Spring application for which I am developing a plugin to perform the SAML operations.
I should have mentioned that I am trying to do this using the IsPassive option, that meaning the User-Agent doesn't come into play during the message exchange. It is simply the catalyst that gets the SAML-party started. Right? With that in mind, given that the user is anonymous at Step 1, what does the SP send to the IdP to allow the IdP figure out whether the user is already authenticated? Because of IsPassive, the HTTP POST isn't sent via the User-Agent
UPDATE
Question 1 Revised: How does the IdP resolve the Principal when the AuthnRequset is sent with the IsPassive option on?
Straight from the SAML 2.0 Profiles document, page 15, lines 417 to 419:
In step 4, the principal is identified
by the identity provide by some means
outside the scope of this profile.
What I'm really after is an explanation how to implement some means.
The thing to keep in mind is that there's no connection between a session on the IdP and a session on the SP. They don't know about each other, and communicate only through the SAML messages. The general steps for SP-initiated SAML SSO are:
Anonymous user visits resource (page) at SP.
SP identifies that user needs to be authenticated at IdP.
SP constructs AuthnRequest and sends to IdP.
IdP does some sort of authentication, constructs SAML Response and sends to SP.
SP validates Response and, if valid, does whatever is necessary to identify user at SP and get them to originally requested resource.
Yes, there does need to be some way to connect the SP's AuthnRequest to the IdP's Response. That's covered by the SAML spec: the SP's AuthnRequest includes an ID value, and the corresponding response from the IdP MUST include an InResponseTo attribute (on its SubjectConfirmationData element) with that ID value. The Authentication Request Protocol also allows the SP to pass a RelayState parameter to the IdP, which the IdP is then REQUIRED to pass along unchanged with the SAML Response. You (in the SP role) can use that RelayState value to capture state information allowing the user to be relayed to the originally requested resource.
That implies that when you implement an SP, you'll need some mechanism for recording ID and RelayState values, and your Response processing needs to validate InResponseTo and RelayState values it receives. How you choose to create and interpret RelayState values is up to you, but keep in mind that there is a length limit. (We use random GUID values corresponding to locally saved state data, which has the extra advantage of not giving any hint of meaning to the RelayState values.)
How does the IdP know who is making the request? The AuthnRequest must include an Issuer element that identifies the SP. It might also contain an AssertionConsumerServiceURL (the URL to which the Response is to be sent), or the IdP may have a local mapping of the Issuer to the proper URL.
How do you send an AuthnRequest using HTTP Redirect? The only difference between AuthnRequest sent using POST vs. Redirect, besides using GET rather than POST, is that the AuthnRequest XML has to get compressed (using the DEFLATE encoding).
Hope that answers most of your questions.
John,
I might suggest taking a step back and doing some more research before you decide to write your own SAML IDP/SP Implementation. You appear to be mixing Bindings with Profiles, Unsolicited vs Solicited Web SSO as well as the fact that SAML requires that the User Agent (aka Browser) is the bearer of almost all the messages between the IDP and SP. There is also a ton of info in the spec that will will have to implement to ensure your solution is actually secure.
I would suggest starting with our SAML Knowledge Base and then moving on to the OASIS SAML 2.0 Technical Overview for information on these flows.
Alternatively, if you decide to go best-of-breed you can check out our PingFederate product which can enable ALL the SAML IDP/SP use cases for you in < a day.
Hope this helps -
Ian
Unlike Ian, I am not associated with a company producing SAML-related products. However, I'd give somewhat similar advice: step back and identify why you are implementing SP or IdP. Are you really acting as both SP and IdP, or are you really just one or the other? If you're implementing/acting as IdP only, then it's fairly likely that a product like PingFederate or something similar offers all you need through configuration rather than requiring you to write custom code. If you're implementing SP, then such a product MAY be able to help you out, but it depends to a large extent on the characteristics of the system you're integrating it into. I am speaking as a developer who has done both IdP and SP implementations, and evaluated several tools before determining that because of our specific system, clients, and requirements, a custom implementation was our best option. It's been in place for over a year, with several clients using it (including some using varying commercial IdP tools).
If you can identify your use cases in terms of SAML profiles/bindings, then you'll be better equipped to make a buy-vs-build decision.