reminder: Stratus is a free beta service and is for experimental, development, non-commercial use only.
Stratus does three things: 1) accepts connections (with a valid developer key) and records the IP address(es) and UDP port(s) associated with the connecting peerID; 2) answers lookup requests from anywhere/anyone by translating peerIDs to the recorded addresses/ports and by forwarding an introduction to the requested peerID for UDP hole punching; 3) automatically bootstraps RTMFP groups that have the "server channel" enabled.
there is no way to use Stratus such that it would have the login/password credential flow you describe. Stratus doesn't know anything about the semantics of any application that uses it nor of application-specific credentials or identities. it just knows about peerIDs and network addresses.
peerIDs are cryptographically pseudorandom, unguessable and unforgeable. you must know the peerID to communicate with that peer. it is up to your application logic to guard and/or disseminate the peerIDs as appropriate.
you can leverage the unforgeable property of peerIDs to allow your centralized application server to arbitrate/authenticate bidirectional communications under your application's centralized control. your central server would be asked by peerA for a counterpart. the server would return to peerA, for example, peerB and a secret nonce to be used as the stream name for the NetStream.play(). when peerB sees the onPeerConnect() callback, it can say "ok", but will not be publishing a stream name that's the same as the secret nonce. peerB then queries the central server for what to do about an incoming connection from peerA. if it's allowed, the server will return the secret nonce and peerB can say NetStream.publish(secretNonce). if it gets a "not allowed", peerB can just do NetStream.close() on the unconnectedPeerStream for peerA. the decision over what's "allowed" or "not allowed" is up to your application logic, and presumably will involve some kind of logging-in.