Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><strong>HTTPS</strong></p> <p>First of all, I think you misunderstood all HTTPS thing. Using HTTPS, you can provide client certificate, but in the most common case, only server certificate is used. So, in this common case HTTPS does not provide the way to authenticate the user, only the server itself. Also it provides message encryption.</p> <p>If you are using HTTP, even if you can protect from real MITM attacks, any MITM will see all your messages. Maybe it's OK if they are not to be held private (some private data etc.)</p> <p>Another thing is authenticating the server itself. As far as I can see from the data you specified (maybe some of it's missing or I misunderstood), all requests are signed, but responses are not (or are they). In this case you are vulnerable to MITM attack as an attacker can pretend to be your authentication server.</p> <p>I would suggest to use both HTTPS for authenticating the server and encoding the messages and signatures for authenicating the client. Also keep in mind that to prevent MITM attacks you must also checks the server certificate using come root CA certs.</p> <p><strong>Private keys</strong></p> <p>I don't quite understand how you can be initiating the private keys to your client. Well, technicaly - yes, but private keys are to be private. If you generate them they are no longer private. In this case you can just generate some shared secret and use some simpler algorithms to sign the requests. Using PPK when you know both keys are no more secure than a shared secret, at least in my opinion.</p> <p>Another way to do this, is to allow client to upload the public key to your server after generating it.</p> <p><strong>Passwords</strong></p> <p>In my opinion, authorisation server should make all the decitions about authorisation. So, I would store passwords and public keys (or shared secrets) in the authorisation server, not the UI part.</p> <p><strong>Conclusion</strong></p> <p>Your situation reminds me of <a href="http://tools.ietf.org/html/rfc6749" rel="nofollow">OAuth2 protocol</a>. There is a resource owner, a client, an authorisation server and a resource server. Resource owner grants an access to a client in some way, client gets an access token from authorisation server providing that grant. Then it uses it to access the resource server.</p> <p>There are two grant types that can be used in your system: Resource Owner Password Credentials Grant and Client Credentials Grant.</p> <ul> <li>Your resource owners are clients themselves.</li> <li>UI is also a client.</li> <li>UI gets access token by providing the client's password credentials and then make some calls to resource server.</li> <li>Clients gets access token just by authenticating themselves by using shared secret or public key.</li> </ul> <p>Of course, you can just take some ideas from the protocol if it is not suitable fully in your case.</p> <p>As for signing the request, there is <a href="https://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-05" rel="nofollow">MAC access authentication</a>, which can be used in the same OAuth2.</p> <p>So, I would suggest to store passwords in authorisation server, UI would just pass them to modify some resources. Don't generate private keys for clients - use shared secret or let them upload public keys. Use HTTPS for authenticating the remote server.</p>
    singulars
    1. This table or related slice is empty.
    1. POSOA - Signature Authorization Service - how to make the web interface to access user data
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USMarius Balčytis
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload