Database Reference
In-Depth Information
the higher the probability that it has been compromised. For this reason, pass-
words should require periodic refreshing, and users should be informed of the risk
of passwords that remain in use for too long.
The common tasks around identity management can be described as gathering and storing
all credential information in a secure way (passwords as hash, storage media encrypted,
and DB row-level security). We have to remember that identity data is quite often
scattered around several applications in different business domains, so MDM could be the
essential part in Identity Data Maintenance and protection. Once collected and synchron-
ized, credentials will be exposed through a secure API to a Security Token Service, which
will provide/renew/revoke tokens, and to the authentication services (usually in scope of
Perimeter Guard) and making authentication decisions based on the information in the in-
coming message. Following the separation of the concerns principle, ID storage (ID man-
agement), ID validation (access management), and ID extraction/injection (on SG) are
three different components of the AAA security subsystem.
As you can see in the following figure, the starting point is always Perimeter Guard; its
main purposes will be to scan the message before AA's operations and isolate IDM sys-
tems from the client. The additional level of isolation can provide the reverse proxy pat-
tern, shielding internal Web/REST resources from direct calls.
IDM modularity opens the possibility for the parallel implementation of Direct and
Brokered Authentication. The first one is simple and described by the name itself.
Brokered Authentication (the synonym is SSO) requires an Authentication Broker, usually
to act as a Security Token Provider, which returns the entry validation ticket (token) to the
service-requestor for a predefined amount of time with a list of the allowed resources. As
this operation requires redirection (see OWASP risks), SG shall be involved in scanning
redirects, signing the tokens, and minimizing redirects (the initial client request can be im-
mediately redirected to STS without it reflecting back to the client).
From the following figure, we see that Oracle Identity suite and API Gateway can be
combined with other products such as Tivoli Federated Identity Manager (as STS) and
WebSEAL reverse proxy.
Search WWH ::




Custom Search