We are using WSO2 Identity Server 5.8.0.
We have made an extension to the org.wso2.carbon.identity.application.authenticator.samlsso.manager.DefaultSAML2SSOManager located in the project identity-outbound-auth-samlsso
Basically we need to add some checks to the SAML Response when we use external IdPs based on SAML authentication.
We made all the checks and all works good. We are facing one little issue. In some cases, when some access errors happem, we need to customize the error message to the user.
I saw here I saw it's possible to customize error message and it's possible to configure WSO2 IS in order to pass error code in request param.
So, what I wanted to do is to generate custom error code when one error happens. I tried the previous configuration and then in the org.wso2.carbon.identity.application.authenticator.samlsso.SAMLSSOAuthenticator class I did the following
#Override
protected void processAuthenticationResponse(HttpServletRequest request, HttpServletResponse response, AuthenticationContext context) throws AuthenticationFailedException {
try{
//Original code
} catch (SPIDCheckException spe) {
// whenever the code reaches here the subject identifier will be null. Therefore we can't pass AuthenticatedUser object with the exception.
AuthenticationFailedException afe = new AuthenticationFailedException(spe.getMessage(), spe);
afe.setErrorCode("MY_CUSTOM_ERROR_CODE");
throw afe;
}
}
I was expecting that with the previous configuration my custom cose would apper in request parameter but it's not so. So I had to find a workaround; my solution was to add a cookie to the response but I don't like it.
Is there any chance to propagate a custom error code from SAMLSSOAuthenticator to the login error JSP page in a query string param?
Am I missing anything?
Thank you
Angelo
context.setProperty("AuthErrorCode", "666");
context.setProperty("AuthErrorMessage", "extended class error message");
Set above in side the processAuthenticationResponse method's catch block. Parameters will be passed to the retry page URL params.
EDIT to cater new details of the comment.
The flow is as 'SAML -> SAML'. But the above suggested improvement was only introduced in 'Oauth -> SAML/Oauth' flows. This was initially introduced to 5.3.0. But, I've just checked 5.8.0 as well, and it's there.
The architecture is like this.
Inbound Authenticator -> Framework -> Outbound Authenticator
In the original improvement, WSO2 has fixed the framework component and inbound Oauth components. So that anyone can set those properties to the framework context. And those will be propogated to the Inbound side. And if the inbound is Oauth, this will work by default as Oauth Inbound authenticator is also being addressed fro the same improvement.
Since your inbound is not Oauth, but SAML, your default SAML inbound authenticator doesn't know how to read the set properties from the framework's context object.
If you want to achieve this, you need to write a custom 'Inbound SAML Authenticator' as well. (As of now you've written an outbound SAML authenticator. We need that as well to populate the error message.)
Extend the existing SAML inbound authenticator and write a new authenticator to read and set the error message.
Improvement
Related
I'm not an expert but seems like one of the OpenID requirements is to have a /.well-known/openid-configuration endpoint.
Seems like Cognito is implementing this well as long as you don't use custom domain, e.g. point your browser to the URL below and you get a properly defined openid config JSON.
https://cognito-idp.{your region}.amazonaws.com/{your pool ID}/.well-known/openid-configuration
Now, if you use a custom domain try pointing your browser to the URL below, and you will see there is nothing but an error message:
https://{your poolname}.auth.us-east-2.amazoncognito.com/.well-known/openid-configuration
This is an issue because other apps/framework/library that rely on OpenID standards fail when trying to connect to a Cognito user pool.
Am I missing something?
Adding a custom domain doesn't change the issuer (iss claim in your tokens) and therefore the discovery URI is unchanged.
Your configured domain will be properly reflected in the configuration document (/.well-known/openid-configuration) and clients supporting discovery will be configured with your custom endpoints (authorization, userinfo and token).
Could you please explain why the WSO2 Travelocity test application requests a "Domain Name" input field in the sign-in screen, when the WSO2 is configured to use, beside basic auth, also a federated authentication mode (WS Release 5.1 - Advanced Configuration). What is the reason to request the domain name part, as for external authentication, for example by use of SAML protocol, I expect to see a redirect onto the external IdP login screen. Apparently the Login redirect is rejected due to this missing input field at the Domain Name. Is there a sample configuration and use case available for setup of outgoing IdP federation?
Further Details from Testings
I've updated the IdP configuration following the WSo2 setting which describes the federation effort with help of Shibboleth products (see below). After this change now I see a login screen from the external IdP ("zee") as well as an interchange of messages between the browser and the external IdP. I also see a SAML POST message in the SSO protocol tracer plugin of the Browser, displaying a long list of claim assertion data, which signals that Login was successfully processed, returning the profile data of my account.
At the Travelocity service provider (SP), now I see the following error message at the screen:
"The entity name must immediately follow the '&' in the entity reference."
I've validated the SAML feedback data and its XML format consistency using an online XML validator, which passed successfully for SAML response XSD format. Such type of XML parser errors are often caused by use of special characters, but its not the case at the current assertions and tests.
The issue happens inside the Travelocity which has difficulties to read the SAML assertion data.
Suggestions from the community how to parse the SAML feedback data using the Travelocity tool, are welcome.
Refer https://docs.wso2.com/display/IS510/Configuring+Single+Sign-On for configuring Basic scenario with travelocity app
To configure federated authenticators:
https://docs.wso2.com/display/IS510/Federated+Authentication
For Advanced Configuration with Multiple Authenticators
https://docs.wso2.com/display/IS510/Configuring+Local+and+Outbound+Authentication+for+a+Service+Provider
Refer https://docs.wso2.com/display/IS510/How+To%3A+Configure+Shibboleth+IdP+as+a+Trusted+Identity+Provider as an example use case.
It seems that you have custom authentication since you have domain name filed at the login prompt.
I am using omniauth-saml 1.3.1 with omniauth 1.2.2 in rails 4.2. It works well with my test identity provider set up at openidp.feide.no (a nifty tool for those setting up a SAML service provider). It even works in production.
Now I am trying to get an IdP set up with a client of mine. When the user visits /auth/saml, they are directed to the client's IdP as expected. The user is able to use their email/pw to login.
The IdP then responds to my SP, but omniauth is redirecting to the failure callback.
As seen here, I get an error message "invalid_ticket". However, the error itself isn't getting passed to my failure controller action in env["omniauth.error"], as I read it should somewhere (unfortunately I can't find that documentation right now).
I'm hoping somebody will have some advice as to how I can figure out what is causing the "invalid_ticket" to happen. Is there perhaps a way to see the raw SAML response from the IdP?
I should note that I need to find this information in production because the client's IdP points to our production SP and I can't convince them to point it somewhere I can do some more extensive testing (like my localhost dev machine). I can, however, write in some more logging or Honeybadger exception reporting if that will help.
Currently, I am reporting to Honeybadger all env["omniauth.*"] values and params when omniauth redirects to the failure route, but I am not getting any information further than Omniauth message: invalid_ticket.
A big thank you to anyone who can help me go in the right direction here!
You might want to try adding other environments to failure_raise_out_environments:
OmniAuth.config.failure_raise_out_environments = ['development', 'staging', 'production']
to your initializer. You will get meaningful error messages in your log or Honeybadger.
These errors are by default raised only in development environment.
I'm trying to integrate WSO2 IS with Liferay as service provider, but I haven't been successful so far. Some modifications were made to the code, as per three JIRA issues raised and patches contributed by Benjamin Schmeling on WSO2 oxygen tank:
https://wso2.org/jira/browse/IDENTITY-2856
The SAML settings on WSO2 IS are as follows:
Assertion Consumer URL: liferayserver:8080/c/portal/saml/acs
NameID Format: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
Use fully Qualified username on NameID
Enable Response Signing
Enable Assertion Signing
Enable Single logout
-> ConsumerURL: liferayserver:8080/c/portal/saml/slo_redirect
Enable attribute profile
Yet Liferay returns the following exception:
Liferay returns the following exception:
[code]23:00:50,071 ERROR [http-thread-pool-8080(4)][BaseSamlStrutsAction:45] com.liferay.saml.UnsupportedBindingException
com.liferay.saml.UnsupportedBindingException
at com.liferay.saml.profile.SingleLogoutProfileImpl.processSingleLogout(SingleLogoutProfileImpl.java:216)
at com.liferay.saml.profile.SingleLogoutProfileUtil.processSingleLogout(SingleLogoutProfileUtil.java:54)
at com.liferay.saml.hook.action.SingleLogoutAction.doExecute(SingleLogoutAction.java:39)
at com.liferay.saml.hook.action.BaseSamlStrutsAction.execute(BaseSamlStrutsAction.java:42)
at com.liferay.portal.kernel.struts.BaseStrutsAction.execute(BaseStrutsAction.java:39)
I also tried changing the single log-out endpoint to liferayserver:8080/c/portal/saml/slo to no avail. In both cases the session is closed on the Identity Server (WSO2), but not on the service provider (Liferay).
Any ideas of what the issue might be?
It turns out there are two additional modifications that are needed in order to make the Single log-out work. I'll leave these here in case they help someone else until these patches are integrated into their respective products. Special thanks to Benjamin Schmeling.
For SAML-based SLO you should use the /c/portal/saml/slo_redirect
endpoint, however, Liferay is not able to handle post requests (at
least in the newest version of the SAML portlet). You have to adapt
the Liferay SAML portlet as follows:
In SingleLogoutProfileImpl.processSingleLogout(HttpServletRequest
request, HttpServletesponse response) add a new else if branch:
else if(requestPath.endsWith("/slo_redirect") &&
method.equalsIgnoreCase(HttpMethods.POST)){
samlBinding = getSamlBinding(
SAMLConstants.SAML2_POST_BINDING_URI); }
Furthermore, in
SingleLogoutProfileImpl.sendSpLogoutRequest(HttpServletRequest
request, HttpServletResponse response) after logoutRequest.setVersion
add the SessionIndex required by Wso2 by calling:
addSessionIndex(logoutRequest, samlSpSession.getSessionIndex());
In peoplesoft User registration service SCC_USERREG, create account service operation SCC_USERREG_CREATEACCT.v1 isnt working.
Error I get:
An Error occurred processing this request (14098,286)
I have checked security settings, scc_guest, SCC_ss_template
How are you making the tests? With SOAP UI?
Is your gateway running and the handler active?
This service of mine works fine, but there were a trick with the XML (If I recall correct, it is with the constituent collection), so if you can post the XML here, it would be nice. BTW, which CS bundle are you?