We have two relying party endpoints that customers can configure in ADFS 3.0 for SAML 2.0 SSO.
https://blah/saml2/mylink
https://blah/saml2/mylink?redirect=differentpage
When they click on both connections, they get taken to the "mylink" page. Is there something in the ADFS relying party field that cannot handle the "?redirect" syntax, so that it defaults to the "mylink" page?
In short, SAML 2.0 specification doesn't support redirect url like that. IdP (ADFS in this case) always returns the consumer endpoint which is /mylink in your case. A common trick is to use relaystate. You can set the relaystate attribute to the url you want to return after login, e.g. /mylink?redirect=differentpage. Please note that you will need to write code to do that redirection yourself after your application receives response from ADFS and finishes processing it.
Related
Is it possible to configure a Relying Party in ADFS to send the SAML Response to a Destination URL while having the Recipient URL in the SubjectConfirmationData block be a different URL? I haven't seen anyway to configure those two to be different in the ADFS UI. Our use case is that we have a proxy we want to send the SAML Response through en-route to the service provider (us in this case) which is expecting the Recipient URL to be a certain value. We obviously can't manipulate that value in the SAML Response using the proxy itself since those responses are signed from the IDP.
I checked and there is no available way to configure the relying party in ADFS in the above way you have mentioned. URL must match the one that you specify in the Service provider ID field of the web server IDP configuration document.
I am implementing front-channel SAML 2.0 SSO golang Service Provider, with Okta as my Identity Provider (this is just a POC and should eventually work with any IdP).
Implementing the sign on process was straightforward with saml2 package. I've created the login endpoint that redirects to the SAML application login URL at the intended IdP, as well as the POST callback endpoint which is properly receiving the SAML assertion and is able to validate it. After that a session with a random cookie is created with the same TTL as the Identity Provider session TTL. So far everything works well (I haven't implemented Single Sign-Out yet, but I'm planning to).
However, when some time passes and the session expires, I'd like to renew it only if the user is still logged in with the Idp and hasn't been removed from the SAML Application. I would like to avoid redirecting the user to perform SSO again with IdP, because it would mean that if they are still logged in, they would be redirected back to the home page of my application. I wasn't able to find great sources on my options to go about it online.
Questions:
1.1 One solution that comes to mind is storing the requested URL in the RelayState parameter, whenever the session has expired, then redirect the user to the IdP SSO URL. When the redirect returns to the SAML callback POST endpoint, check the RelayState parameter and if set, redirect back to that (original) URL. That means that for users that use the system continuously, I would have to request Assertions very often. Does that make sense?
1.2 A second solution that comes to mind is to implement a back-channel of communicating directly from my SP to the IdP. That would allow me to verify a user is still logged in 'behind the users back'. If that's a sound idea:
a. Do I need to have dedicated code for each IdP?
b. Do I need to load an API key to the IdP which would allow secure communication?
c. Do I need to upload a public certificate to the IdP that would be able to verify that my SP signed the requests?
Will using the Assertion to get an OAuth 2.0 Access Token help me in achieving this?
I've chosen SAML 2.0 for now, since the environment is an enterprise oriented one and I thought it fits well with it based on what I read. Would using OpenID Connect instead help achieve my goals easier and fit well with enterprise oriented products?
I'm reading the SAML specification and experimenting with Keycloak and Shibboleth IdPs and I'm not sure how to implement one feature in an SP-initiated login.
I have a service that traditionally used to have an SP status information displayed on its login page (e.g. application version, status). After switching to using an IdP login page I'd like to keep displaying such per-SP additional information on the login page of the IdP. I'm interested in the data exchange, not in templating the login page itself.
Does SAML 2.0 specification allow for sending arbitrary data to the IdP for the purpose of logging in? If not, what are other options that can be used to decorate IdP login page using SP-generated data?
Sort of. The authentication request from SP to IdP is allowed to have "custom" extensions (the Extensions parent element), the content of the extensions is up to you. From the spec:
[Optional] This extension point contains optional
protocol message extension elements that are agreed on between the
communicating parties. No extension schema is required in order to
make use of this extension point, and even if one is provided, the lax
validation setting does not impose a requirement for the extension to
be valid. SAML extension elements MUST be namespace-qualified in a
non-SAML-defined namespace.
If you're writing your own IdP, you could certainly make use of Extensions and do whatever you wish with it. "Standard" (commercial/OSS) IdPs won't know what to do with your extension. It'd be an interesting test to see if Shibboleth or Keycloak libraries parse the Extensions element and give you the contents.
The other, more standard possibility is using RelayState. This is a spec-compliant way of passing some provider-specific state information around, incl. from SP to IdP:
3.1.1 Use of RelayState Some bindings define a "RelayState" mechanism for preserving and conveying state information. When such a mechanism
is used in conveying a request message as the initial step of a SAML
protocol, it places requirements on the selection and use of the
binding subsequently used to convey the response. Namely, if a SAML
request message is accompanied by RelayState data, then the SAML
responder MUST return its SAML protocol response using a binding that
also supports a RelayState mechanism, and it MUST place the exact
RelayState data it received with the request into the corresponding
RelayState parameter in the response.
Again, all IdPs or downstack libraries will parse RelayState but how they handle it from there depends on their reading of the spec. For one, the spec requires RelayState to be 80 bytes and integrity protection via a signature or "other means". This limitation is often ignored by IdPs and SPs.
What SP-specific information are you trying to display on IdP login page?
The only thing that an SP can send to the IdP is the Subject (see lines 585-589 of the spec).
Unfortuantely the built in AEM SAML Utility does not support the HTTP Redirect binding (only post binding). I have to perform SAML authentication to an external IDP which has HTTP redirect for both single sign on and single logout. Because of the AEM limitation I would like to configure ADFS to handle authentication with this external IDP and somehow get AEM to talk to that ADFS (either a federation service, or maybe an RP or claims provider). Does anybody know how this could potentially be achieved? I am assuming I could leverage the SAML utility or the SSO utility/modules in AEM (sling) to connect to ADFS somehow who will be responsbile to relay or proxy the IDP response to AEM. thanks
Using OOTB SAML Authentication Handler there is an option IDP HTTP Redirect, I was able to configure SAML authentication with a redirect to ADFS and then after giving credentials, IDP was redirecting back to AEM with SAML2 response containing all the data, however, that was handled by POST Binding.
EDIT:, OK, I have just noticed that IDP HTTP Redirect option is not present in linked official documentation however on the video in this tutorial you can see it available on AEM 6.1... I do not recollect now if the POST binding is used at the end so that please check first if that might work with this option as I have used that before.
If you would need other solution, the fastest option I see is checking the default implementation of SAML Authentication Handler by decompiling (it can be done following these steps, by at the same time I am only suggesting, not recommending that!) and base on it implementing custom handler adapted to your needs.
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.