I am new to the SSO and SAML . We have to set up Single sign on the our customer site using ADFS 2.0 and we did that successfully and when we try to access ../adfs/ls/idpinitiatedsignon.aspx and it redirects to the customer site and if we enter the user name and password and it brings back to the idpinitiatedsignon.aspx page with you are signed in label. When i check the http transactions using SAML Tracer firefox plug in , i can see the <samlp:Response> is coming to our_site_name/adfs/ls/ and when i tried to access Request["SAMLResponse"] in idpinitiatedsignon.aspxpage , it shows as nothing.
how do i read the samlp:responsethat comes to my server and not
to particular page ?
I can see in the SAML Tracer that i'm getting <EncryptedAssertion>.How can i read the assertion values?
I'm answering from SAML and not from ADFS. Regarding question 2, i would expect that you would have received a block of XML called SAML Metadata that describes your customer's IDP. In that metadata, i would expect that you would receive your customer's public key (2.4.1.1 Element KeyDescriptor). I don't think it's possible to decrypt in SAML Tracer unless there is a way to install the encryption cert in the tool. My team has used the XmlSecTool, available from https://wiki.shibboleth.net/confluence/display/SHIB2/XmlSecTool, for verifying an XML signature pulled out of SAML tracer, but i don't know if anyone has a way to decrypt at the browser. Forgive me if you are asking more specifically at the ASDF level.
Related
I am trying to access https://api-crt.cert.havail.sabre.com/v3/auth/token from the postman with valid base64 encoded Authorization header.
What is the valid value for username? Isn't it same which I used for registration. Document showing it as EPR in form 'user-group-domain'. Please help
I am getting an error.
{
"error": "invalid_client",
"error_description": "Credentials are missing or the syntax is not correct"
}
Go to: https://developer.sabre.com/user/{YOUR_USER}/applications
There you'll see YOUR_USER's application
Your user is what you have below Client ID and the password is below Client Secret. On that you have: Base64(Base64(Client ID):Base64(Client Secret)) (this is generic, to show how it should be coded.
This will only work on CERT environment.
It may be obvious what I am going to talk about, but you must have a SABER GDS authorized user to use this service.
If you do not have an authorized web user you will not be able to make the service work.
Ask Sabre or the agency that you represent this user to access, because without this credential correctly released you will not be able to make any REST / SOAP services work.
You can download the postman functionality package from the link below:
https://github.com/SabreDevStudio/postman-collections
https://developer.sabre.com/product-catalog?f%5B0%5D=product_type%3Aapi_reference
I'm building an installed application that will have features requiring the Google Drive REST API using Qt and C++. I understand Qt is now releasing new libraries to support OAuth flows but let's assume I'm a student and learning to use OAuth at this layer is a requirement for this project.
In my application, I have a working OAuth flow for installed applications that ends with an Access Token and Refresh Token being stored using QSettings (I'm open to input on whether this is a disastrously bad idea too). The application requires no authentication/login for its own sake/data, but it does need authentication to Google for calling API's using an Access Token. This application has no associated web backend being hosted; its simple and should be deployable completely locally (I've written and included a simple TCP server that will receive the authorization redirect_uri and will run and close when called from within the application).
As such, I'm curious about the best way to make sure that, when a user opens my application and wants to use the Google Drive features, they are appropriately authenticated on Google's end. Say, if I maintain an access token in the registry, and this access token is granted per-user/per-application basis (right?), then how can I make sure only the user the token belongs to is able to make calls to the API with it?
Here's my understanding and approach; feel free to correct me or educate me if I've got the wrong interpretation.
If an Access Token is found, perform the following:
Open a browser page to a Google login domain and have the user authenticate there (this could prohibit a user from being able to use a cached login session that would have access to a token they otherwise shouldn't have access to)
If user has correctly authenticated with a Google account, return control to the application and make a test call to an API using the stored token.
If the call fails (responds with an invalid_credentials) I should be able to be sure its because the access token has expired and the application will go through the flow to renew an Access Token from a Refresh Token.
If no Access Token is initially found:
Start a normal OAuth installed application flow
Get the tokens and store them so that when the user opens the application next time the former procedure is used
My issue then is the first two steps if the Access Token is found. Nominally this could be done by the typical OAuth flow but it appears that when using a localhost as the redirect uri, Google will always prompt for consent, regardless of settings for prompt and access_type authorization query parameters.
What can be done to accomplish these first two steps in a way that my application can control (i.e. not a solution that relies on a backend server being hosted somewhere)?
If this question is too open-ended for SO requirements I can make some more restrictions/assumptions to limit the problem domain but I'd rather not do that yet in case I unknowingly rope off a good viable solution.
Thanks for reading! Sorry if its a verbose; I wanted to ensure my problem domain was fully fleshed out!
If you are using an installed application, I wouldn't recommend using or storing refresh tokens. Storing refresh tokens on the client side means that if an intruder gains access to the client's application, they have infinite access to the user's application without ever having to enter the user's credentials. If you do insist on having a refresh token, ensure you follow the Google's installed app flow, with the code_verifier parameter included in your requests.
If the access token is found, you should try to verify it, and if verified then use it at the google api, otherwise force the user to login again (or refresh it if you chose to still use refresh tokens).
If no access token is found, your flow sounds fine.
A few notes on loggin in with Google:
Google will only return a refresh token if you specify access_type=offline in your auth request.
Google will only return a refresh token on the user's first authorization request, unless you always specify prompt=consent in your query params.
In my experience, when leaving out the prompt query param, the user is not prompted for their consent again. If they are logged in to google, you will get a new access token, but no refresh token, unless you have prompt=consent.
I think the idea is you use prompt=consent if you have no record of the user ever using your application. Otherwise if they have used it before, you may prefer to use prompt=select_account to allow the user to select which account he wants to use in case he has more then one, or you can just use prompt=none.
This is just my understanding of it all.
My approach I ended up using was just to deploy with an SQLite db that will be stored in the AppData roaming directory. The db schema includes a field for the user's Name (from the OpenID IDToken field if it exists), the user's picture URL (again from IDToken if it exists), the refresh and access token strings (will be stored as encrypted strings when I get around to it), the user's UID/sub string, and a field for a user name and password.
These latter two fields are authentication fields for within my own application, which, again, I wanted to avoid but it seems impossible to do so. So the user will be prompted to enter a username and password into a form, and these credentials will be checked against the existing SQLite db file mentioned previously.
If they exist and are correct, the user gets logged in and will have access to their respective access and refresh token.
If the user has forgotten their password, they'll be asked for reconsent (going through the installed app flow again), and whatever password they provided during initial login will be used as the reset password. It is considered, for my purposes, that logging into Google for the installed app flow is proof enough that the user account belongs to them and they should have authorization to reset the password.
If the user is a new user and doesn't have a record in the local SQLite db file, then they can also click a button to "Create New Account" - which effectively goes through the authorization flow as well but this time a whole new record is posted to the SQLite db with the appropriate fields filled.
There's still more optimization that could be done but at least I am getting closer to the level of security and control of access to Google user accounts that I want.
I'm not marking this as an answer because I feel like this solution is still not desired and that there should be an easier way. So if someone has evidence or experience of providing an equivalent level of authentication control without needing to maintain a local user account database then I would be more than happy to mark such a method as the solution!
Thanks again!
I will not post any of my code, because this is more just a question to know if it's possible.
I've been googling a lot, but didn't find any concrete solutions. I hope someone can help me here.
The facts:
I have a login form
I need to authenticate the credentials over a web-service
I need to send both username and password, to get back a token if logged in successfully.
The problems:
With a custom provider I'm always stuck with the fact that they only have direct access to the userename, like: loadUserByUsername. I need to access the password there as well, to be able to send this to my web-service.
I have only 1 web-service which sends only back a token if provided username and password are correct.
Question:
How can I access and send both username and password to my web-service?
Thanks!
Generally speaking one would authenticate using an API token to a web service.
That API token is usually issued via an auto-generation script when the user account is created (either by an admin or by a registration form). This token is then passed by the API call to the web-service in a header which then uses it to authenticate the user.
As far as Symfony goes, by far the easiest way of doing this is with Guard. A new component built by Ryan Weaver from KNP.
KNPUniversity has a great tutorial on it (for free).
Note that this is only one option of many, and the 'best' way is probably mainly opinion based and directly related to the use case in question. But it might help you get on the right track.
If the token you want to create should be a JSON Web Token (JWT), a very conventient bundle is LexikJWTAuthenticationBundle, which does almost all of the work automatically. If you just follow the documentation, you will have it quickly up and running. You can combine it with FOSUserBundle, with a custom User entity or whatever.
Problem statement:
Hi. I have some secured data which I want to expose through Web API and ASP.NET Identity mechanism. I want to use out of the box classes of ASP.NET Identity. I take a payment manually and change a value in the table. But there are cases where the user will share his username + password with some other guys so that the others can access the same content without paying anything.
Work plan:
So, I have extended the AspNetUsers table with a column named ApplicationToken (varchar). After successful login, I want to generate a token, update the field of the user's row in the table, and add this value as a claim information and send back to the client app. Now, when the user requests for a paid content, my client app will send the token also. So, somewhere in my server side codes, I need to check this ApplicationToken with the Database token value. If both are equal, I allow the request to proceed, otherwise I will send 401 Unauthorized and tell them to login again.
Implementation options:
After studying and searching, I found the below options to implement:
Create Custom Authentication Filter attribute so that I can grab the claims send from the client and do my required validation
Create a base class of the secured API and get the claims there and do my required validation.
Go for different Jwt based implementation where I should have access in both issuing and checking the Json Web Tokens.
If you have any other options, I would be very glad to hear those.
My question is, which approach is better to proceed. I have enough time to implement, so time is not a factor here. Thanks.
I have the ability to login via Facebook and Google on my website. This is done using OAuth2.
I use the same redirect URL whether the user is returning from facebook or google, and pass through the provider name in the state field. Is this the recommended way to track the provider? Otherwise I do not know who to validate the token with if I do not know which provider the token comes from.
Are there other preferred methods for accomplishing this?
The state parameter should be an opaque value that cannot be guessed by an attacker since it is not protected from modifications. If you need to track state, you should refer to it by using the state parameter but that parameter itself should be randomized and/or encrypted. Storing the provider identifier in plaintext in the state parameter is not safe. Users could modify the state parameter themselves or attackers could craft an authorization request with a state value that they choose.
The way to track the provider is by storing it in the backend session state and generate a reference to that session/state that you pass in the state parameter. To prevent cross-site request forgery you should also keep some encrypted/randomized cookie that binds the state to the browser. This is described in more detail: https://www.rfc-editor.org/rfc/rfc6749#section-10.12
Addendum:
One of the problems with using OAuth 2.0 + provider specific extensions for login is exactly this: you cannot establish the provider and user identity in a way that works for all providers in a uniform and generic way. In your case you'll already have to know the provider before you can perform a sensible interaction with it. Enter OpenID Connect: it is a extension profile of OAuth 2.0 that gives you login semantics in a standardized way. It would give you a verifiable JSON object (JWT) with standardized values that tell you who the provider is (iss) and who the user is (sub).
Google signin already has migrated already to OpenID Connect, as has Microsoft and others like Salesforce, hopefully Facebook will follow.