I am trying to create jmeter script for login in to iphone native app. App is using cognito to authenticate the user.
As response of first page of app I am getting SALT and Secret block.
I am passing this secret block in and other required parameters in next request, however I got error message as "User name or password is in correct".
Did anyone worked successfully on similar things which can help me.
Looking into Amazon Cognito page:
Social and enterprise identity federation
With Amazon Cognito, your users can sign in through social identity providers such as Google, Facebook, and Amazon, and through enterprise identity providers such as Microsoft Active Directory via SAML.
Standards-based authentication
Amazon Cognito User Pools is a standards-based Identity Provider and supports identity and access management standards, such as Oauth 2.0, SAML 2.0, and OpenID Connect.
You will not be able to record and replay none of the mentioned protocols, depending on underlying identity provider mechanism you will either need to apply advanced correlation or a way to provide the required Bearer Token.
So you need to identify which identity mechanism is used under the hood and amend your JMeter test accordingly.
Reference material:
How to Load Test SAML SSO Secured Websites with JMeter
OpenID Connect - How to Load Test with JMeter
How to Run Performance Tests on OAuth Secured Apps with JMeter
Related
We have an in-house OAuth2 server used by our applications. Now we want to use Windows SSO for our applications but without them to change anything: they'll still reach our OAuth2 server for an access token and the authentication part will be delegated to Kerberos (which Windows use, if I understood properly).
Is there a way to do that?
That is a standard setup and should just require configuration changes in the Authorization Server (AS) - with zero code changes in applications.
Most commonly:
The AS might be hosted in the cloud
It will redirect browsers to an on premise Identity Provider (IDP)
The IDP can connect to Active Directory
You may also need a fallback option for when users are not joined to the work domain. See this Curity guide for an example and some infrastructure factors to think about.
If the AS is in house it may even be able to make a direct Kerberos connection via an LDAP data source, though the preferred architecture is a separate IDP.
Of course you need an AS that supports the ability to make this type of connection, so would need to check the vendor docs.
REQUEST FLOW
Kerberos has always been the simplest protocol conceptually but the deepest to understand - here is a bit of a summary:
Your apps will make a standard OpenID Connect authorization redirect to the AS
The AS may then present an authentication selection screen to the user, unless there is only a single option
Alternatively an app can send the acr_values query parameter to say which authentication method to use
The AS will then redirect the browser to the next stage of processing, that uses a 'Windows SSO authenticator'
The redirect to the Windows SSO authenticator does not have to use OpenID Connect - it could be any vendor specific HTTP request
The browser will send an encrypted Kerberos ticket automatically by connecting to AD - a prerequisite for this to work might be that the domain in the URL is in the Local Intranet zone on end user computers
The Windows SSO authenticator will need to be able to decrypt this credential, which typically requires a Service Principal Name to be configured
Once the Kerberos ticket is decrypted, the authenticator will make an LDAP connection to an Active Directory data source via its standard LDAP endpoints, to verify the received ticket
I am new to OpenID connect & security domain. I have configured Nifi to use OpenID for authentication using online documentation. And to automate a few nifi related tasks we are using nipyapi.
I have already written python code which does automated flow deployment for basic nifi installation (unsecured & without user authentication)
Now, I have to move the code to secured Nifi installation. How to authenticate to OpenID connect using nipyapi/rest API ?
AS per discussion with Bryan, i am planning to use client certificate for authentication but it started giving authorization error. and have created another question with the details.
Nifi - Client Certificate Authorization Error
OpenID Connect generally requires that you follow a flow of re-directs, typically in the browser. NiFi re-directs you to the login page of the OIDC provider, upon completion, the OIDC provider redirects you back to NiFi. I'm not exactly sure how, or if you even can, perform this login process from scripts. An easy alternative would be to just generate a client certificate to represent an automation user for any NiPyApi scripts. Client certificate authentication is always enabled by default for NiFi.
We are trying to put an app on the marketplace which needs multiple client_ids
(The app is running on appengine standard with python 2.7)
a client_id for the service_account with domain wide authority
a client_id for the web application
a client_id from an apps-script library
All client_ids use different scopes. I have combined all scopes and entered them on the marketplace SDK configuration.
When i deploy the app on a test domain, only the serviceaccount seems to be authorized.
When the user then access the webapplication he is presented a grant screen which we want to avoid.
The documentation https://developers.google.com/apps-marketplace/preparing?hl=fr seems to imply that multiple client_id's are possible.
How should i configure the marketplace app so that multiple client_ids are authorized?
Is there something special i should do on the credentials configuration page of the api-manager?
Check how you implement the authorization using OAuth 2.0, Service accounts allow a Google Apps domain administrators to grant service accounts domain-wide authority to access user data on behalf of users in the domain. You can also read Server to Server Applications documentation.
Note: You can only use AppAssertionCredentials credential objects in applications that are running on Google App Engine or Google Compute Engine. If you need to run your application in other environments—for example, to test your application locally—you must detect this situation and use a different credential mechanism (see Other). You can use the application default credentials to simplify this process.
Hope this helps.
It turned out all three client_id's were being authorized after all.
the days that i was testing this, it took very long for the authorization to take effect.
At this time all scopes and clientid are authorized within a few minutes.
Amazon Cognito supports OPENID auth and OATH. Is it possible to use LDAP instead to authenticate the user?
You can support any authentication system with Cognito, but you will need to use a slightly different authentication flow than existing public providers. Instead of calling Cognito directly from the device you will need to construct your own backend that will handle the authentication then call Cognito to establish the trust of your identity.
Please see the following for more details:
Amazon Cognito : Announcing Developer Authenticated Identities
Understanding Amazon Cognito Authentication Part 2: Developer Authenticated Identities
Is there other ways of authorizing against the Azure Service Bus using AMQP than username and password such as tokens from the ACS?
In my scenario I want to be able to give resource level client access to the service bus without exposing my credentials.
Today, in the preview release of AMQP support in Service Bus, the SASL username/password scheme is the only authentication option.
It is still possible to provide resource-level client access with this model though as you're free to create multiple identities within ACS and associate a limited set of claims with those identities. In fact, this is recommended best practice. The alternative of using the default namespace 'owner' identity in a production set up is analogous to giving application components access to the root password.
So, my recommendation would be to create ACS identities for each "role" in your application and then grant only the claims required by that role. For example, if a Web tier component requires the ability to send to a queue, q1, then create an ACS identity for this Web tier role and grant the 'Send' claim to that identity.
Thanks,
Dave.
Service Bus Team, Microsoft.