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/
Related
Does WSO2 Identity Server has api for session management?
I have an app with SAML SSO.
What I would like to achieve is to check if for given saml token there is an active session.
Validity of the SAML token has nothing to do with validity of the user session.
In theory - when user does "logout", the identity server should execute SLO (single logout), however based on our experience with WSO2IS 5.0.0 it works only for limited number of options.
Since version 5.2.0 there's OpenID Connect Session Management implemented using iframes, see http://malithiedirisinghe.blogspot.be/2016/03/openid-connect-session-management.html
But generally - you will have hard time to synchronize session between multiple service providers and WSO2 IS. With the claim based authentication (SAML, OAuth 2.0) the sessions between the IdP and SP are independent. (the only option I've see when the IdP is working as the pass-through-proxy for backend SP, but that's not what WSO2IS is intended for)
In version WSO2IS 5.3.0 there should be "user session management" implemented, but I haven't worked with that yet (managing session for WSO2IS, not external SPs)
Seems like it does, you should investigate the documentation here and here, those links were provided by a WSO2 team member to me or ask directly to your local WSO2 office.
Able to get only,
{"sub":"u003#tenant.com#carbon.super"}
Things done :
Not able to choose dialect in claim configuration in Wso2-IS 530
WSO2 IS 5.1.0 as OAuth/OIDC IdP response with different claims on UserInfo endpoint
Issue : https://wso2.org/jira/browse/IDENTITY-4463
Tried mapping claims & oidc etc .. nothing seems working : ref
Can some one help me out ?
Update:
call is made to
https://localhost:9443/oauth2/token?scope=openid
Environment is "milti-tenant", I am basically trying to getUserInfo who resides within a domain, not a user from admin.
For a valid token, even the claims are not being fetched under service calls..: reference Oauth2 validation
I have added a local custom claim namely http://wso2.org/claims/fg_imprenditore to http://wso2.org/claims dialect and mapped it on a custom primary user store attribute (JDBC user store).
The custom claim appears in the user profile and I can set/update the value correctly.
I have defined a new service provider and added the custom claim in Claim Configuration -> Use Local Claim Dialect.
In addition I have edited /_system/config/oidc and modified the openid property to include the new claim as follows: sub,...,street,http://wso2.org/claims/fg_imprenditore
Now the issues.
I ask a JWT Token from a javascript client with the following request:
http://**********/?response_type=id_token&client_id=" + "f8SatEWpyi1qvPLVspsDfTbefm0a" + "&scope=openid&redirect_uri=http://localhost:3000/oauth_callback.html&nonce=" + nonce
After login the WSO2is server prompts the following message (even if the attribute is already present in the profile): You are trying to login to **** application, but it needs following information filled in the user profile. You can fill those below and proceed with the authentication. But it is advised to fill these information in your Identity Provider profile in order to avoid this step every time you login.
If I fill the field (correctly) labeled "http://wso2.org/claims/fg_imprenditore" I can proceed. In any case the claim is not returned in the JWT Token.
In addition if I go in the user profile the attribute is set correctly (with the new value!) but if I try to authenticate again I need to fill the attribute again..
Many thanks for the support.
If you don't mark the claim as mandatory on your Service Provider it shouldn't request it when you try to log in. Also, in order for the jwt to contain your custom claim you need to map the custom claim to a new custom claim under the oauth dialect, and then map the new oauth claim under the oidc scope you use. It took me a while to get it too as there isn't sufficient documentation describing these steps. Hope this solves your issue.
This happens because "http://wso2.org/claims/fg_imprenditore" claim is not mapped to any oidc claims in WSO2 IS. Do the following in get rid of the issue.
Go to List under Claims in IS Management Console Main tab.
Click on http://wso2.org/oidc/claim
Add new claim with the name fg_imprenditore in oidc claim dialect. You will see a drop down to select "Mapped Local Claim". Map it to http://wso2.org/claims/fg_imprenditore. (Check "Add External Claim" section in this)
Save new oidc claim and try again.
I am attempting to configure our WSO2 Identity Server (5.1.0) to talk to our Shibboleth Identity Provider v3 (3.2.1) server.
When I attempt to authenticate, I get an error in my Shibboleth IdP logs which suggests to me that my metadata for the WSO2 server is wrong:
2016-06-30 15:24:48,564 - DEBUG [org.opensaml.saml.metadata.resolver.impl.AbstractMetadataResolver:334] - Metadata backing store does not contain any EntityDescriptors with the ID: MYENTITYID
2016-06-30 15:24:48,564 - DEBUG [org.opensaml.saml.metadata.resolver.impl.BasicRoleDescriptorResolver:198] - Metadata document did not contain a descriptor for entity MYENTITYID
2016-06-30 15:24:48,564 - DEBUG [org.opensaml.saml.metadata.resolver.impl.BasicRoleDescriptorResolver:281] - Metadata document did not contain any role descriptors of type {urn:oasis:names:tc:SAML:2.0:metadata}SPSSODescriptor for entity MYENTITYID
2016-06-30 15:24:48,564 - DEBUG [org.opensaml.saml.metadata.resolver.impl.BasicRoleDescriptorResolver:252] - Metadata document does not contain a role of type {urn:oasis:names:tc:SAML:2.0:metadata}SPSSODescriptor supporting protocol urn:oasis:names:tc:SAML:2.0:protocol for entity MYENTITYID
I'm following documentation from the WSO2 site here:
https://docs.wso2.com/display/IS510/How+To%3A+Configure+Shibboleth+IdP+as+a+Trusted+Identity+Provider
I have the Shib IdP v3 working with other services, but a very new to that version and don't generally dig deep into Shibboleth anyway beyond setting up attribute resolution and release for relying parties.
Could someone with more experience in either the Shibboleth IdP arena or the WSO2 Identity Server arena point me in the direction of resolving this or at least narrowing down whether it's a general IdP configuration issue or a WSO2 metadata issue ?
The documentation from WSO2 site is based on Shib IdP v2.
You can still use it on v3, but you would need to enable v2 compatibility
https://wiki.shibboleth.net/confluence/display/IDP30/NameIDGenerationConfiguration
There is no need though, the steps for v3 are quite similar.
AFAI can tell, Shibboleth does not support the unspecified name id format. It could be possible to tweak it to support it, but I have not found issues letting Shibboleth use the transient format. Likewise, I see reason to not use a persistent name id either. Thus, there is no need to modify the name id configuration.
The AttributeFilterPolicy is now defined on file /conf/attribute-filter.xml (or the attribute filter file loaded by /conf/services.xml). This policy specifies which attributes can be disclosed to each SP, so you need one entry for each of your SPs.
Since IS does not support metadata files yet, you need to tailor one and save it at /metadata/wso2is.xml The one in the WSO2 Site is a good start. Just keep in mind that the NameID Format does nothing if it requires the unspecified format, and that you might want to pass additional attributes in the SPSSODescriptor, in my case I had to add the following: AuthnRequestsSigned="true" WantAssertionsSigned="true". I also added the signing and encrypting x509 certificates that WSO2IS will use when sending requests to Shibboleth.
Next, you need to tell Shibboleth that you want to use that metadata file by adding something like the following to file /conf/metadata-providers.xml
<MetadataProvider id="wso2is"
xsi:type="FilesystemMetadataProvider"
metadataFile="%{idp.home}/metadata/wso2is.xml">
</MetadataProvider>
Now, when you configure the IdP on WSO2IS, you need to map the claims/attributes that Shibboleth shares with WSO2IS (as defined in Shibboleth by /conf/attribute-filter.xml) to the WSO2 IS dialect. To do that, you go to your IdP configuration, expand Claim Configuration, then expand Basic Claim Configuration, there you can add as many claim mappings as you need.This is an example of the Claims Mappings
I hope this helps.
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).