I have found that my users are sometimes entering a trailing space after their username. This happens most often when copy & pasting their user name from an email or other electronic document.
What happens is that the server will trim that space when authenticating that user, which then succeeds, but will not trim that space with retrieving claim values, which then fails.
The result is that the user is passed to the service provider and then the service provider reports they do not exist.
Is there a way to trim those spaces so that both the authentication and claims processes work?
WSO2 Identity Server 5.1.0
Thanks,
pat
Related
Is it possible in WSO2 Identity Server self-registration process to request only the First and Last name of a User and generate a username instead of asking the user to enter the desired username?
The default WSO2 identity server self-registration process does not allow generating username by the given first and last name.
But according to the wso2 documentation of Customizing WSO2 Identity Server UIs, you can customize the WSO2 Identity Server self-registration process to request the First and Last name to generate a username by concatenating the first and last name accordingly.
The generated username should be unique and obey the defined username regex in the user store. In the documentation of Working with Properties of User Stores, you can find the user store properties related to username regex. Therefore you should verify that the concatenation of first and last name, generates a unique username that complies with the username regex.
community.
I'm using WSO2 IS 5.7.0 to integrate an Angular app with an external IDP.
The external IDP is configured with SAML2 and the service provider Inbound Authentication is set with Oauth/OpenID.
The service provider uses Federated Authentication to comunicate with the IDP.
The user uid from the IDP is matched with the claim userid, so when I ask for an oauth token, I get the correct scopes (matching a local user with roles configured) to use the token with WSO2 AM. This is working well whe I get the initial oauth token using code grant.
If I introspect this token, I can verify the token belongs to the username XXXXXXXX and the scopes are the ones to consume an API on WSO2 AM, based on the roles associated to the local user XXXXXXXX.
The problem is when the refresh token is used to get a new access token after expiration. The new access token comes with the same scopes, but I cannot consume the same API I was consuming with the first token. I get a 403 Forbidden on every call and the AM log shows:
WARN - APIAuthenticationHandler API authentication failure due to Invalid Credentials
(The first WARN appears only once)
WARN - APIAuthenticationHandler API authentication failure due to The access token does not allow you to access the requested resource
(this WARN appears on the subsequent calls)
If I introspect the receibed token, I can see the same scopes as the original access token, but the username is different:
FEDERATED/XXXXXXXX#carbon.super.
I think this username change on the token information leads to the 403 error.
The problem is worst if I activate the Service Provider option "Use tenant domain in local subject identifier" on the Local & Outbound Authentication Configuration. In this case, every time I ask for a new token with refresh token, the tenant is appended to the username on an infinite loop:
XXXXXXXX#carbon.super#carbon.super#carbon.super#carbon.super
On every token I get, the introspect shows me another #carbon.super is appended to the username of the actual token. In this case, the FEDERATED/ is not always present on the username.
I expect the username associated to the refreshtoken to be equal to the one on the first access token.
Is there a configuration to solve this or this is a bug? is resolved on new releases of WSO2 IS?
(sorry for my english)
Thanks!
Similar issue is reported[1] and fixed with PR[2].
[1] https://github.com/wso2/product-is/issues/4472
[2] https://github.com/wso2-extensions/identity-inbound-auth-oauth/pull/1022
If you don't have a WSO2 subscription, upgrading to the 5.8.0 will resolve the issue.
I'm using Postman 6.7.3. Instead of typing in the Username and Password values for the Authorization (tab) NTLM Authentication (type), alternatively, I'd like Postman to retrieve the needed information from the logged-on user. Is that possible today? I'm running a "corporate"-configured version of Windows 10 that resides on an (AD) domain (that we call "US").
FWIW, my "web api" calls work just fine when I do type-in the credentials for myself in the Postman Authorization screen. (just looking to do "less typing"...and perhaps avoid the security risk of exposing my domain password)
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.
I am facing a problem understanding the reason why to use mod_auth_kerb for authentication to a Kerberos server.
I am developing a website using Django + mod_wsgi + Apache .
The first page of my website asks the user to enter username/password and one of my Django app will take the username/password and use Python kerberos module to authenticate the user to the kerberos server.
Where do I need to use mod_auth_kerb here ?
I understand that I will have the power to use the username/password to my advantage,is this the reason of using mod_auth_kerb ?
mod_auth_kerb can do two things:
Prompt the user for a username and password via HTTP Basic and validate them using Kerberos on the server side, or
Allow the browser to authenticate using Kerberos on both sides, via HTTP Negotiate. If the client supports Kerberos, this provides single-signon: the client automatically authenticates to the server via the Kerberos system without prompting for a password, via credentials obtained when the user logged in.
You are doing #1 in your application. It might be useful to move that into Apache, where it can be done once consistently for all apps. #2 you're not doing at all, but it's only useful in an environment in which Kerberos infrastructure is available.
A word of warning: I don't know about the "Python kerberos module," but it's very possible that it is not doing password validation securely. Many things which claim to do this do the equivalent of "kinit": they use the username and password to obtain an initial Kerberos credential (TGT), and claim success if it appears to work. The problem is that they have asked a third party (the Kerberos authentication server (key distribution center), or KDC) to validate the password -- but they have not checked that they are actually talking to a real KDC. They might just have received a message from the same user who gave them the password, and the message of course says, "the password is right." In order to do this properly the verifier needs its own identity in the Kerberos realm (a "principal"), and to take the extra step of using the TGT to obtain a ticket for itself and verifying it; this ensures that the reply is from a genuine KDC.
Another common way of doing this, if your KDCs are Windows domain controllers, is to use LDAP: connect to a domain controller via LDAP and authenticate with the password; the DC will check the password against Kerberos itself. Of course, you have the same problem: you need to verify that you're talking to a genuine domain controller -- but you can do that with TLS via certificates, which may be easier.