presently we have ADFS 3.0 acting as federation gateway among multiple client IDPs and our web application. So in summary, for client IDPs our ADFS act as Relying Party, while for our in house .net based web applications (taking advantage of WIF framework), our ADFS act as IDP. Finally when user ends up on web application, we receive all transformed claims from client IDPs.
One of our client IDP uses SAML protocol, which is nicely converted to WIF claims by ADFS and web application can read these claims. But we have new requirement, where we will also need to read untouched SAML Protocol response which is http-posted to ADFS by client IDP during SSO handshake. During this HTTP POST on ADFS, we receive SAMLResponse and RelayState as 2 different parameters. Now this message is converted to WIF based params (wa, wresult, wctx) by ADFS and posted to our web applications.
Our web application acting as relying party on ADFS 3.0 is configured with WS-Federation Passive Endpoints. There is possibility of adding additional SAML Assertion Consumer. But I am not sure how I can mix and match multiple endpoints?
Any idea how I will get SAMLResponse parameter which was originally posted on ADFS. Is it achievable?
Thanks in advance!
The SAMLResponse is sent to only one EndPoint. Adding an EndPoint will not give you an extra copy.
ADFS does not have a "span" port (outgoing copy for Log). A reverse proxy/loadbalancer often has a "copy" port feature. But if the SAML token is encrypted then you still need the private key of the ADFS Decryption cert.
A lot of work.
Related
My web application is running on server(cloud) which is not part of my domain. I want to implement SAML based login to the web application with my domain(Intranet machines).
Is it allowed? If it is, any special configuration needs to be done?
Is it allowed?
yes
If it is, any special configuration needs to be done?
You need to implement/use a SAML Identity Provider.
In general SAML was designed as a Single Sign On technology for web-based applications without the use of cookies. You may only use so called 'front-channel' bindings (like HTTP REDIRECT and HTTP POST) to transmit the SAML messages between the SAML Service Provider and the Identity Provider if the Service Provider can not communicate with the Identity Provider.
We are a SaaS Service Provider with a SAML implementation. However, during the implementation with Okta, I got the impression that,
The Okta-to-SP leg is totally SAML standard Assertion Response. Period. No questions.
However the SP-to-Okta leg is not SAML standard AuthnRequest. It’s a proprietary HTTP Get request to the okta embed link like:
https://dev-xxxxx.oktapreview.com/home/xxxdevxxx_xxx/xxxx/xxx
Is this observation accurate? Is there anyway that I can make the SP-to-Okta leg SAML’s AuthnRequest? I assume no.
Okta supports SP-initiated SSO.
You send a SAML authn request to its .../sso/saml endpoint.
The SSO service URL is available in the SAML metadata which you can downloaded from the Okta console.
As of now the UI to get that piece of information for okta administrators is a little bit tricky:
Admin > Applications > XXX > Sign On > Settings > View Setup Instructions.
There you can find the IdP URL, issuer, and cert. The meta data profile is available for downloading as well.
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.
We want to deeply integrate OneDrive with our web app in order to handle document and storage data. However, we want the users not to log in twice. I'm not sure whether this is possible, but I've been reading about SSO and SAML and it seems like it's the way to go.
Is it possible, and if so, is Single Sign On the way to go?
Single Sign-On (SSO) is a great solution for user experience when web applications are hosted on different domains. SAML as a standard was developed for cross domain authentication to solve this use case. You will need an Identity Provider (IdP) server that handles authentication of users to your web application and then the IdP Server issues SAML assertions to your web application and OneDrive. Your application in this architecture will be a Service Provider (SP) that will consume SAML assertions, as well as OneDrive is a SP that consumes SAML assertions. There are a number of SSO/Federation vendors that provide the IdP Server.
As far as implementation, once you have chosen and installed the IdP Server, you will need to implement your web application to consume the SAML assertion and configure the IdP Server as a connection. OneDrive will simply be a configuration as it already supports SAML and WS-Federation.
In addition to SAML as a protocol, there are other standards with respect to SSO/Federation such as OpenID Connect (OIDC) and OAuth2. When choosing a IdP Server solution you may want to look at these other protocols that can solve additional use cases. SAML works well for web applications and the use case you have described. OIDC and OAuth2 are better suited for secure APIs and native mobile applications.
Another consideration when looking at an IdP Server is how authentication is to be performed. Options for authentication could be using Kerberos/IWA if all clients are on a common domain, or authentication using a Login Form. You may also want to look at MFA support when looking at an IdP Server as part of the SSO solution.
I am working on SAML2.0. One of our clients(IDP) requested us (SP) to have SP initiated requests without sending AuthnRequest.
Instead of sending AuthenRequest they have asked us(SP) to send a parameter on the URL that can tell them that the request has come from the designated SP. Is it an industry standard to implement SP initiated requests without having AuthnRequest parameter?
I would actually call this IDP initiated, as from the viewpoint of SAML, the IDP sends the first message. IDP initiated is part of the standard, so it does not break SAML.
But if you are going to have the SP tell the IDP to start authentication I would consider it bad practise not to have the SP start this by using a SAML AuthnRequest.
This would be a more interoperable approach making it easier to use standard SAML product without the need for customizations.
No it's not. However, from our experience, some IdPs do not support SP-initiated SSO. Instead, they require a redirect to the IdP including a parameter that identifies the SP. This then will trigger IdP-initiated SSO to the SP. This is not covered by the SAML v2.0 specification and therefore the format of the URL including the parameter name etc is not standardized.
I suggest double checking with the IdP to see whether they do support SP-initiated SSO as per the SAML specification. Perhaps they simply haven't enabled this support. If they don't then you're only option is to use this non-standardized approach.