simplifying bus proxying



So what do we see, above?

The UI side of an azure website talks to the WebAPI side of the same site. The latter is implemented using MVC-patterns for webAPI building. These include using a resolver class for instantiating the interrupt handlers (controllers), that itself is implemented using dependency injection techniques. As a result, the product entity controller is constructed while inserting a repository implementation (for said product entities). In reality, this is an component with an embedded UA, created by the interrupt handlers. The UA client can talk to either of 2 services, for repository access, depending on state. When the state indicates use service , the client uses a wcf factory class to create channels to the message-relaying service bus, that forward webhttp or soap messages to WCF-implemented service hosted somehow.

Now lets try adding AAD to this picture.

ON clicking login at the UI website, ADAL is used to start an authorization flow, with the desired AAD tenant. The result is a redirect to the UI site’s handlers, bearing a token with user-delegated scopes for the webAPI side of the same site. Alternatively, the handler uses a client-credentials flow providing the inbound token alongside its clientid/pwd to AAD, seeking a new access token suited to the WebAPI.

The latter seems interesting as we could be obtaining 2 API scopes, for the UA to talk to the webAPI and for the WebAPI itself to be talking to the servicebus (which needs a SWT issued token, currently).


About home_pw

Computer Programmer who often does network administration with focus on security servers. Sometimes plays at slot machine programming.
This entry was posted in Azure AD. Bookmark the permalink.