Using WSO2 IS (5.0.0.SP1 or 5.1.0) - is it possible to disable the default basic authenticator?
The reason is - at the client a custom authenticator is used to provide additional security measures (one time password, client certificate, ..).
Once the user forces use of the basic authenticator authentication (e.g. using /samlsso?spEntityID=any_invalid_data_here), the user is authenticated only with its username and password skipping any additional authentication. Once authenticated, the IS won't validate other security measures (assuming the username and password is not always enough and additional authentication is required by the client or even sec standards).
Seeing the application-authentication.xml config file, I've tried to disable the basic authenticator there or replace it in the default Sequence config with no success.
To close the question: IdP-initiated SSO with invalid issuer seems fixed in 5.1.0, where the authenticator chain is better enforced
Related
I have setauth_password_format: scram in ejabberd.yml and ldap auth method.
LDAP authentication works only for passwords in plaintext.
I can even set scram hash value as a password in my xmpp client and successfully login, since ejabberd checks it as a plain text against LDAP record, but how do I make ejabberd hash the password with scram before checking it against the LDAP record?
I thought auth_password_format would do that, but apparently it still thinks userPassword attribute in the LDAP record is in plain text.
Is there some additional check that ejabberd preforms on the userPassword value to see if it is indeed scram and then fails for some reason? Or is it ignoring auth_password_format option when ldap is set as auth method? Or something else entirely?
Is there a way as a non-erlang developer that I can make this work? The only idea I have is to use external auth scripts if ejabberd cant use scram and ldap together for some reason, but I would really like it if I can just set this up in the configuration file instead.
Looking at the ejabberd source code, scram is mentioned in ejabberd_auth.erl, ejabberd_auth_mnesia.erl and ejabberd_auth_sql.erl. There is no mention to scram in the other authentication methods, which points to what you concluded.
In this sense, I later noticed that the SCRAM section mentions only internal (Mnesia) and SQL auth methods:
https://docs.ejabberd.im/admin/configuration/authentication/#scram
I would say that external auth will not support it either.
I'm using cypress-ntlm-auth plugin in my cypress automation project, providing me windows authentication (Ntlm, kerberos etc.)
In particular, I use the ntlmSso option for Negotiate with my app. If the server sends an authentication challenge, the ntlm-proxy will perform a NTLM or Negotiate login handshake with the credentials of the user running the test client.
The problem is that I need to use a pre-defined user (to be used in my pre-prod environment) to make api requests, instead of the logged on user on the computer.
How can I do that? thanks in advance
The cypress-ntlm-auth library allows you to specify this with cy.ntlm(), by passing in hosts, username, password, and domain.
cy.ntlm(["my.host.com"], "myUser", "myPass", "myDomain")
Check out the docs here. Take note of their strategy on storing passwords.
The primary purpose of an authorization code in the oAuth flow is to prevent replay attacks, TLS also prevents replay attacks.
If you simply made a password grant request to an oAuth enabled server using TLS would that not be sufficient?
The primary purpose of an authorization code in the oAuth flow is to
prevent replay attacks
I think the primary purpose of Authorization Code flow is different then prevent replay attacks. OAuth does not guarantee this and regardless of the grant, OAuth 2.0 suggests us use always TLS for all grants to transmit Access token:
Access token credentials MUST only be transmitted using TLS as
described in Section 1.6 with server authentication as defined by
[RFC2818].
There are also other grants in OAuth 2.0 like;
Authorization Code
PKCE
Implicit (Legacy)
Client Credentials
Password (Legacy)
Device Code
Refresh Token
and each has its own purpose. Password flow is legacy and you should have a strong reason to keep using it because of the following reasons:
Your user exposing their credentials to 3rd party for no reason. It was the reason OAuth exist, not sharing credentials to 3rd party (like e.g: Service Foo) to get access to their service (like Google, Facebook)
User does not have any control what your Service Foo can do with these credentials.
It was required before like Implicit flow, but both Password and Implicit flows are replaced now with Device and PKCE based on their usage. For instance; if the main reason one application uses Password Grant is their clients can not support redirection, they can also use now Device Code Grant.
I'm trying to use the authenticationendpoint application that comes with WSO2 as the new only login entry point of an old application. For testing purposes I just did a page that redirects to thi URL
https://localhost:9443/authenticationendpoint/login.do?relyingParty=My-Issuer&sp=Test-App&sessionDataKey=14792551&authenticators=BasicAuthenticator:LOCAL
The login page appears as expected, but once I set the user and password shows this message:
Authentication Error !
Attention:
Something went wrong during the authentication process. Please try signing in again.
Seeing the output in the console on debug mode, this is what is shown
... Many of the same error saying that Authentication Context is null
[2017-01-06 15:40:08,836] DEBUG {org.wso2.carbon.identity.application.authentication.framework.util.FrameworkUtils} - Authentication Context is null
[2017-01-06 15:40:08,836] DEBUG {org.wso2.carbon.identity.application.authentication.framework.util.FrameworkUtils} - Authentication Context is null
[2017-01-06 15:40:08,836] DEBUG {org.wso2.carbon.identity.application.authentication.framework.util.FrameworkUtils} - Authentication Context is null
[2017-01-06 15:40:08,837] DEBUG {org.wso2.carbon.identity.application.authentication.framework.handler.request.impl.DefaultRequestCoordinator} - Session data key : 22451696
[2017-01-06 15:40:08,837] ERROR {org.wso2.carbon.identity.application.authentication.framework.handler.request.impl.DefaultRequestCoordinator} - Context does not exist. Probably due to invalidated cache
I thing I'm doing something wrong, maybe there are not enough parameters sent, or they are the wrong ones, the user and password are correct because I can login into the carbon itself with it, and it is also a valid user for the testing SP.
The SP config is described:
Basic Information
Service Provider Name: Test-App
Claim configuration
Use Local Claim Dialect
Subject Claim URI http://wso2.org/claims/username
Role/Permission Configuration
Permissions AdminTest
Role Mapping AdminTest->Admin
Inbound Authentication Configuration
SAML2 Web SSO Configuration
Issuer: My-Issuer
Assertion Consumer URLs: https : //localhost/Test/main.asp
Default Assertion Consumer URL: https : //localhost/Test/main.asp
NameID format: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
Certificate alias: wso2carbon
Response Signing Algorithm: ...#rsa-sha1
Response Digest Algorithm: ...#sha1
Checked values
Enable Response Signing
Enable Single Logout
Enable Attribute Profile
Include Attributes in the Response Always
Enable IdP Initiated SSO
Enable IdP Initiated SLO
Others are in blank OAuth, OpenID, etc (let me know if that is maybe the problem, so which should be filled out.
Local and Outbound Authentication Configuration
Authentication Type: I tried with Default and Local Authentication = basic and password-reset-enforcer
This is checked:
Assert identity using mapped local subject identifier
Use tenant domain in local subject identifier
Use user store domain in local subject identifier
Request Path Authentication Configuration
basic-auth
Inbound Provisioning Configuration
SCIM Configuration
PRIMARY
Dumb Mode is not enabled
The rest is left blank
I have spent many days tracking this problem but no answers or are for older versions.
I tested with JDK 7 and 8 (latest of them) I'm working with WSO2 IS 5.2.0. Someone can lead me to a solution to use this application as the only entry point for my SPs? The idea after is to send back a SAML2 response to a page in the SP side that read the information and control the authorization part.
Thanks in advance.
You have configured for a SAML SSO scenario. Therefore your SP have to call the SAML SSO endpoint of WSO2 Identity Server with a valid SAMLRequest. That is https://hostname:port/samlsso.
AuthenticationEndpoint is just an intermediary application. SAML SSO endpoint is the one that should redirect the user to AuthenticationEndpoint after first processing the SAMLRequest. You must not call it directly.
Refer this to learn how to run a sample SAML SSO application with WSO2 IS. While running that, you can monitor the HTTP Request/Response flow using a tool like SSOTracer for Firefox and understand how the communication works.
In similar to SAML SSO flow, if you are using any other authentication protocol, you first have to call the protocol specific endpoint. E.g. If you are using OAuth2 or OpenIDConnect, then you should call /oauth2 endpoint. Never /authenticationendpoint directly.
I'm aware of how SAML is used for single sign on (SSO). That is, redirection to IDP from SP and getting the user's identity from the SAML response/assertion.
My question is - Does SAML 2.0 specification define how to pass username and password as part of a SAML request xml for authentication? Note that I'm not talking about single sign on and just want authentication of username/password.
Thanks,
The SAML standard supports passing a user identifier in the <saml:Subject> field of the <AuthnRequest> (i.e. the request for authentication).
There is however no built in support for passing a password as part of the AuthnRequest. IMHO doing so goes against the principles of SAML2 as that expects the Idp to only use a password when authenticating. Normally the Idp may use any means it finds suitable to confirm the identity of the subject. That could be a password, but also a certificate or a one time pad exchange over SMS. Or something else - it's up to the Idp.
That said, there is an <Extensions> element in the <AuthnRequest> that could be used to carry a password. Doing so would require careful security considerations as the AuthnRequest contents are not designed to be kept secret. If using the Http Redirect binding the contents are logged in a web server and visible in browser history. If using the Http POST binding the password is still visible to the browser. I would suggest using the SOAP or Artifact binding to make sure the data is transferred directly from the SP to the Idp. Note however that those bindings have considerable less support in frameworks.