WSO2 Identity Server cannot handle IdP initiated logout with special SP names - wso2

It seems that WSO2IS does not honor the special characters in spEntityID parameter such like:
https://wso2is.localnet:9443/samlsso?spEntityID=http://otherhost/&RelayState=http://otherhost/logout.jsp
Do you have any idea how to sort this out? The SP cannot be set to use different issuer. The UrlEncoding doesn't help.

It seems that if the the SP doesn't send to WSO2IS IdP the SessionIndex in the SAML2 LogoutRequest, it fails since cannot get it from it.
This answer was posted by OP (toma) as a separate question, I've just pasted it here to get evertyhing in one place.

Related

WSO2 IS Custom claim dialect not passed to the Service Provider

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
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/

IdP and SP per Tenant in WSO2 identity Server using SAML Web SSO

I am setting up a WSO2 Identity Server at the moment . The first step was to use the resident identity provider in super tenant and setting up service providers as SaaS applications. This worked pretty nice so far.
The bad thing about it is that (1) users need to login by identfying themselves using the username#tenantdomain schema. The next bad thing about it is, (2) that we can not configure login policies or account management policies per tenant. We only can handle it globally.
For testing reasons we modified the authenticationendpoint application to inject the tenant domain on the fly while logging in (by analyzing relyingParty parameter). This worked so far, but point (2) still remains.
Next step was to configure an IdP and SPs per tenant. For my understanding that is the way to get rid of points (1) and (2).
That is where I am completely stuck. The carbon log only mentions that we need to register the SPs in advance. I am reading various posts, jiras issues and blog entries for the last week but I still do not have a working solution. Seems to me that even though I configured the tenants resident IdP and exchanged metadata accordingly the IS still thinks we are trying to communicate with the super tenants resident IdP.
The SPs we are using are created using SimpleSAMLphp.
Maybe I missunderstood the principles of setting up IdP/SPs per tenant in WSO2 IS? Maybe I am handling the resident IdPs the wrong way?
Any help/advice is welcome.
Even though this question is old, below part from the documentation will help whoever searching for an answer.
From WSO2 Identity Server 5.0.0 onwards, there are different SAML
endpoints for each tenant. If the service provider calls the identity
provider's SAML endpoint URL as
https://is.com:9443/samlsso?tenantDomain=foo.com or the issuer name is
appended with #<TenantDomain> like travelocity.com#foo.com, the SAML
requests are directed to the foo.com tenant.
Additionally, note that when using SAML SSO with a tenant (using either of the above methods), the SAML response is signed with the private key of the particular tenant.

WSO2 Identity Server 5.0.0 fails to return user claims in SAMLResponse for user from secondary user store

I have this problem when using SAML SSO authentication. I have successfully set up WSO2IS 5.0.0 Identity server, I also succeeded setting up (at least I hope so) secondary user store. I used JDBCUserStoreManager implementation. I have set this store as DOMAIN. This user store works nice, at least I think it does. Because it is storing user attributes into its tables (USER_ATTRIBUTES) and those attributes are read by WSO2IS administration ...
https://localhost:9443/carbon/userprofile/edit.jsp?username=DOMAIN/demo_jbu&profile=default&fromUserMgt=true
Users are identified as DOMAIN\username so when I want to log in user from this DOMAIN, request goes to my AUTHENTICATOR implementation so I can manage authentication for users from this domain.
What is strange is, that if I use WSO2IS administration pages, I can set and read users's attributes well. And if I use SAML SSO authentication (have already set up service provider & claim mappings) for users from PRIMARY domain, everything goes fine and calling SP gets all attributes - mapped in WSO2IS administration here:
https://localhost:9443/carbon/application/configure-service-provider.jsp
If I use SAML SSO authentication, but I want to log user from my DOMAIN, SP doesn't get anything.
I can override this behavior in DefaultResponseBuilder, I can put into SAMLResponse anything I want, but I don't feel this approach is OK. Can anyone tell me, where to look for an error? What may be wrong? Where should I start looking for problems? I have already tried to debug it, and it seems it (SAML SSO/AUTHENTICATOR) doesn't find any claim for DOMAIN user.
Thank you in advance.
Josef
I think this is bug in Identity Server 5.0.0. When you are using SAML2 SSO, user can login to Identity Server with both username with domain name and username without domain name. Basically
bob and foo.com/bob must both works and returns the bob user's attributes from foo.com user store. However there is issue with IS 5.0.0, if secondary user store user login without domain name, Identity Server does not returns the user attributes. But, please try to login with foo.com/bob , Then it would return the user's attributes.
You can find the public jira. It contains source diff. It must be a simple fix and you even can compile the source and add fix in to the Identity Server.

Extend Identity Provider URL

I just have a question regarding to Identity Provider URL.Is it possible if i would like to modify|custom|extend the Identity Provider URL? (localhost:9443/samlsso)
I currently run two SSO (SAML2) enabled apps on my local tomcat on localhost and name app1 and app2. The behavior of the applications is to redirect to login panel when the user is trying to access the applications. Since it is SSO enabled, it redirect to WSO2IS login panel. If both application are not logged in and redirected to the SSO login page of WSO2IS. The first one to login works successfully. Because the first one already logged, the second one doesn't need to be sign on again. But i would like to make the second one must be sign on again because there are 2 different issue name and i intend to use the issue name for the filter or condition
I am using WSO2 identity server 4.6.0
Regards,
The question is bit unclear to me. Is it that you don't want SSO between webapps, but only between webapp and IDP? Then it seems, it's not complete SAML SSO scenario.
Still for the filtering, you may be able to write a 'custom authenticator', implementing the interface 'org.wso2.carbon.core.services.authentication.CarbonServerAuthenticator' and engage it in the flow.

WSO2 Identity Server: Cannot use custom claims with OAuth2

We've Installed Pre-Packaged Identity Server 5.1.0 with API Manager 1.10.0 and use sqlserver as a data store.
We use OAUTH2 to authorize our API's and we want to map our local claims to a service provider (an application?). Behind the API we have a .Net Wcf Service with some logging where we read the header with WebOperationContext.Current.IncomingRequest.Headers["assertion"] and print the claims which are present.
The Claims which are returned are:
{"iss":"wso2.org/products/am"
"exp":1462357259751
"wso2url/claims/subscriber":"Sjaak"
"wso2url/claims/applicationid":"1003"
"wso2url/claims/applicationname":"DefaultApplication"
"wso2url/claims/applicationtier":"Medium"
"wso2url/claims/apicontext":"/Test/v1.0"
"wso2url/claims/version":"v1.0"
"wso2url/claims/tier":"Silver"
"wso2url/claims/keytype":"PRODUCTION"
"wso2url/claims/usertype":"APPLICATION"
"wso2url/claims/enduser":"Sjaak#carbon.super"
"wso2url/claims/enduserTenantId":"-1234"
"wso2url/claims/emailaddress":"sjakie#chocola.nl"
"wso2url/claims/givenname":"Sjakie"
"wso2url/claims/lastname":"van de Chocoladefabriek"
"wso2url/claims/role":"Internal/subscriber
Internal/everyone
Application/Sjaak_DefaultApplication_PRODUCTION"}
Where wso2url is http://wso2.org, but we cannot post this, because I don't have 10 reputation points...:(
The information in these claims is good, but only we want to use our own uri, so not wso2.org, but myorg.com. And we want to add other claims, with for example our own userId and some other stuff.
Among other things we have followed the guide for configuring claims for a service provider but had no success with this. We have made the assumption that an application is a service provider for which we can use the claims.
Has anyone got an idea what we are doing wrong? What do we need to do to add custom claims?
Thanks in advance!
[Added on 9th may]
Maybe this can point us in the right direction?
When we add a subscription to an application and we generate a new key than there is no new Service provider in the list:
The list of service provider without a new one for user Sjaak, so there is missing: Sjaak_CalculatorApp_PRODUCTION
But even when we do this for user admin the claims are not coming through. We have the following claim configuration and in my logging still the same claims as described above are there, no new ones, so no claim named accountnaam and no voogd.com uri:
Service Provider(SP) - It provides services to some end users and relies on a trusted Identity provider(IDP) to handle authentication and authorization for them. SP may use multiple protocols(Oauth2, SAML2, etc.) to communicate with IDP.
Claims are defined for SP, since same claims can be send over different protocols. In the default case, Identity server uses wso2 claim dialect(start with wos2.com) for claims. If you want a different claim dialect than this, use "Define Custom Claim Dialect" option in the service provider configuration. In there you can map wso2 claims(Local Claim) to your own claims(Service Provider Claim).