0

I'm using WSO2 Identity Server version 5.10

I'm facing a strange behaviour. I configured some external IdPs (SAML2 based)

I configured claims returned by these IdPs with WSO2IS local claims. For example, let's suppose that my external IdP returns these SAML attribute name: a, b and c I configured claim in this way:

External IdP Claim configuration

Identity Provider Claim URI Local Claim URI
a http://wso2.org/address
b http://wso2.org/givenname
c http://wso2.org/lastname

Then I defined a custom claim dialect in this way; let's call it custom_claim_dialect. I defined in it my claim mapping in this way:

Custom claim dialect

Dialect URI Claim URI Mapped Local Claim
custom_claim_dialect a http://wso2.org/address
custom_claim_dialect b http://wso2.org/givenname
custom_claim_dialect c http://wso2.org/lastname

Then I defined a Service Provider (Inbound configuration: SAML2 Web SSO) and I configured it by using these external IdPs In my Service Provider I configured my claims by adding the custom dialectby specifying it in Service Provider Claim Dialect

Then I tried the access the access to the Service Provider. All worked pretty good just only the first time. WSO2IS asks to me the consent for the claims and I can land on my authenticated page.

When I close the browser and clent cookies and I try again the access. All works good (no consent ask is showed by WSO2IS) but when I land on my private page no attribute is contained in the SAML Response.

If i configure my ServiceProvider with WSO2IS local claims, all works good.

Is this correct? Am I missing anything?

Thank you

Angelo

UPDATE

I'm pretty sure it's a kind of bug.

I debugged till the class org.wso2.carbon.identity.application.authentication.framework.handler.claims.impl.DefaultClaimHandler

The org.wso2.carbon.identity.application.authentication.framework.handler.claims.impl.DefaultClaimHandler.handleClaimMappings(StepConfig, AuthenticationContext, Map<String, String>, boolean) returns the correct claims Map In fact I printed the following log:

INFO {org.wso2.carbon.identity.application.authentication.framework.handler.claims.impl.DefaultClaimHandler} - Returning filtered claims {familyName=Surname, name=Example, dateOfBirth=1980-01-01, spidCode=ABCD123456789A, fiscalNumber=TINIT-SRNXPL80A41A662G, MultiAttributeSeparator=,} to SP mySP

In some point during the process WSO2 IS decides that this Map must not be used.

Any tip?

UPDATE 2

This picture shows how I configure my SP claims. As you can see I'm using a defined custom claim. When I define custom claim, I can't make claims mandatory

SP Claim configuration

Community
  • 1
  • 1
Angelo Immediata
  • 6,635
  • 4
  • 33
  • 65
  • What did you mean by "when I land on my private page"? – Nipun Thathsara Feb 14 '21 at 15:20
  • When inland on my SP protected page. By using saml tracer i noticed that in one case I always have saml attributes in saml response while in another case I just have them the first time I access – Angelo Immediata Feb 14 '21 at 15:50
  • Since this is a federated authentication, IS doesn't have a local entry of the user. When you login for the first time IS has retrieved user claims from the federated server and cached. Once the cache is expired, your SAML trace wouldn't contain claims anymore. Do you experience this after about 15 minutes of the login? – Nipun Thathsara Feb 16 '21 at 17:00
  • Well what is sure is that if i login before 15 minutes, i get what i described. I'll deeply check after 15 minutes.. but if so... how can i solve it? Should I disable caching? – Angelo Immediata Feb 16 '21 at 17:05
  • Moreover... if claims are cached, when I log the second time in less than 15 minutes, I should receive them back and now it doesn't give them me back – Angelo Immediata Feb 16 '21 at 17:13
  • @NipunThathsara I debugged the code and I saw that effectively in method `org.wso2.carbon.identity.sso.saml.servlet.SAMLSSOProviderServlet.getAuthenticationResult(HttpServletRequest, String)` when we try to recover user from cache `result = getAuthenticationResultFromCache(sessionDataKey);` recovered user has no attribute. I switched the claim configuration but I'd like to know why this behaviour – Angelo Immediata Feb 23 '21 at 13:48

1 Answers1

0

Did u try making these claims mandatory on the IS SP side? Making claims mandatory will ensure that u always receive the claim for the applications.

If caching is the problem then u can try to JIT provision the user[1]. This way we can save the claims from FIDP on the IS side. "Provision silently" is an easy option to check.

[1] https://is.docs.wso2.com/en/latest/learn/configuring-just-in-time-provisioning-for-an-identity-provider/

Inthirakumaaran
  • 369
  • 1
  • 8
  • I'll try the JIT although It seems to me a bug and not a cache problem. What do you mean when you say "making these claims mandatory on the IS SP side"; i'm using a custom dialect and I can't make claims mandatory when I define dialect. – Angelo Immediata Feb 22 '21 at 10:50
  • when configuring a custom dialect in the SP claims section, you have a tick box to make the claims mandatory https://docs.wso2.com/display/IS570/Configuring+Claims+for+a+Service+Provider?preview=/92523398/92523400/Mandatory-claim-custom.png – Inthirakumaaran Feb 23 '21 at 10:17
  • As I said, I'm using a custom dialect. This means that I selected the option `Service Provider Claim Dialect:` when I configured the SP. I updated my question so it is clearer. – Angelo Immediata Feb 23 '21 at 10:26
  • The expected use case of Service Provider Claim Dialect configuration is eIDAS SAML Attribute Profile for IS [1]. This is not recommended to be used as an alternative for requested claims. Ref [2]. [1] https://is.docs.wso2.com/en/5.10.0/learn/eidas-saml-attribute-profile-support-via-wso2-identity-server/ [2] https://github.com/wso2/product-is/issues/11390#issuecomment-806419822 – Sajith Jul 05 '22 at 08:03