Does anybody know what type of <KeyInfo> does ADFS expect to find in field of a SAMLRequest message?
There are several options to choose from. I'm using Keycloak SAML library, which knows to send this field in <KeyValue> format only (which contains modulus & exponent of the RSA public key). Can ADFS digest this?
<ds:KeyInfo>
<ds:KeyValue>
<ds:RSAKeyValue>
<ds:Modulus>tfJ29N0G1...</ds:Modulus>
<ds:Exponent>AQAB</ds:Exponent>
</ds:RSAKeyValue>
</ds:KeyValue>
</ds:KeyInfo>
Answering my own question - apparently, the <KeyInfo> format doesn't matter.
I got keycloak working with ADFS, while using <KeyValue> format only.
As I was told on keycloak-user mailing list, "ADFS should be able to determine the correct certificate for signature validation itself by iterating all
available certificates."
Related
I have some questions related to tokens and encryption.
First of all Access Tokens :
Regardless the various attacks(that you need to bear in mind so that you take measures against), would you recommend storing an access token on the client?(localstorage/ cookies).
If yes, will I need to encrypt it and store the encrypted token on the client. However, is that really needed since I am using SSL? You are using SSL to prevent a MIM attack.But since you are using HTTPS, why should we also encrypt the access token?
My second question is related to encryption. For SSL, I understand that I need a certificate (or self-signed certificate to test it locally). However, for encrypting the token, do I need the same SSL's certificate, or can I use an RSACryproProvider to generate a pair of public/private keys?
For Refresh tokens :
I believe the best approach is to save the encrypted refresh tokens in the database. It could be an actual API that reads/Writes refresh tokens in the database. However, the refresh token, must be stored along with some user attribute ie UserId, so you can retrieve it based on i.e userid, email etc. Assuming, I use the UserId, I would encrypt it along with some character and date and store it on the client. Do you agree on that? And also, I am thinking to restrict the access on that API, so that it can only serve requests from a particular server or servers (web farm). What is your opinion about this approach?
I would REALLY appreciate your help, as I am really trying to understand in depth some concepts. If there is something, I don't express correctly, please let me know to rephrase my question.
Thanks
I just implemented Json Web Tokens to my api, but I don't understand how to verify if the user that created the token, is the one that is making the request.
For example, I have the /user/login end point, and I received the user and password for login. Then I create a json web token with the user data inside, and return it. And here is my problem, how do I know that the user that create that token, is the one that is making the request ?.
I found several ways to verify this, for example saving the user-agent + ip of the user and only accept request for that token if the user-agent + ip is xxx, but I am not really sure that is the best way.
I hope you can help me with some tips,
Thanks for all
how do I know that the user that create that token, is the one that is making the request ?.
Because the JWT includes the user ID and is signed, therefore any alterations to the content will be detected. Possession of the token is proof of authenticity
The process of issuing and authenticating with JWT is more or less like this
Issuing new JWT
User performs and authentication using its credentials
The server validate credentials, generate the JWT payload including the user data and some fields such as expiration time or issuer, and signs the token with server private key
The client receives the token and store it (in a secure storage).
Authentication
User sends a request to server. The request includes the JWT, usually in headers or as url param
The server validates the signature with the key, and extracts the user ID to know the requestor. If the signature is not valid rejects the request
Any reason you can't use a standard like OAUTH2 and let the big boys handle security for you? Rolling your own security is usually very difficult to get correct and almost all the major players provide free OATH support.
That said, I'd be hesitant to lead you down a bad path, however I've been in your shoes before so if you must roll your own security, make certain you fully read all of what OWASP has to offer. They offer very detailed threat analysis and also give suggestions that will be invaluable along your journey.
OWASP Threat Analysis
EDIT 1
A good light weight and easy to implement standard is OpenID which as their banner explains is,
A Simple Identity layer on top of OAuth 2.0
See here for a very detailed explanation of how it works:
OpenID-Wiki
We are using STS token for claims based identity.
I found that following method validates the token from STS and generates claims.
FederatedAuthentication.ServiceConfiguration.SecurityTokenHandlers.ValidateToken(token)
1.Does this method validate the token against the schema provided by OASIS?
2.If so how does it know which schema it has to validate against? becasue there are multiple schemas (like 1.1, 1.2).
Or Am I asking wrong question.. Do we need not validate the token against schema?
Thanks in adavance
You should assume that, if the Token is XML, the TokenHandler will validate the XML. It has to do that anyway to avoid signature insertion attacks. If you are in doubt because you have prove that it actually allows invalid XML through, then you should report a bug.
The first element of the assertion has an attribute that indicates the version of the protocol/XML-schema
I am building an API following RESTful principles as much as possible. The request in discussion is to allow a user to check his/her credits available in a system. At the point of request, the system verifies the user by comparing the provided username and password already in the system. Please note that changing the authentication method (to OAuth or the like) is not an option at the moment.
As this is a "Read" request, GET method is used. So, I would have the following:
GET http://mydomain.com/credit?username=XYZ&password=123
By following the RESTful principle and using the verb properly I fear that the username and password is easily readable / accessible. In a non-API scenario I would have just used a normal form POST with SSL...
Am I wrong to assume the risk mentioned above?
You are quite correct that exposing the username and password in plain text in the query string is a bad idea. Like worse than the last three Star Wars movies.
You should be fine though if the same request is made over SSL (assuming a trusted certificate).
REST also has a host of other mechanisms for security like the DOSETA specifications for digital signatures, JSON Web Signature and Encryption, and so on. But you seemed to hint those kinds of things aren't an option.
The Http Authentication header is designed to store information such as username and password. You should use that.
The client is using oauth signing their request and call my server, I know the client's oauth key and secret, then how can I verify the call is from the actual user? should I calculate the signature with all parameters sent along with the request and compare it with the signature within the request? I am using singpost library.
Thank you, any hint will be very helpful!
OK for the future reference - to validate the signature, this is what I did:
Parse all parameters in the incoming request's header and use all these parameters and my own consumer credential to calculate the signature again, then compare with the incoming signature. It's a pain for me since no proper library can do it in a easy way, I have to write it myself...