Quick Demo Junction and Credential Viewer

Sometimes its necessary to quickly setup a demo host with IBM Security Verify Access (ISVA) and you need something that will output some diagnostic information.

Introducing the https://resource-server-demo.verify.ibm.com/

This is an IBM Hosted demo host – that gives you some demo resources – so you can try out ACLs, or more elaborate configuration.

Setting it up can be done in 3 easy steps:

  • Import the hosts Certificate into the pdsrv Keystore
  • Deploy the changes and restart the reverse proxy
  • Finally – Create a standard SSL Junction, being sure to supply the Server Name Indicator

Then – after authenticating – access the site – https://<isva_host>/demo

Credential Viewer

Now – that might not be enough – perhaps you’re trying to troubleshoot whether something is added to the credential? Or are your groups getting loaded?

Try the ‘local-apps’ cred-viewer – define the path and enable it – in one simple configuration entry:


[local-apps]

# An example local application definition which enables the authorization
# decision API and makes this application available at the /aznapi path on the
# local junction:
#
# azn-decision = aznapi
#
# You can define your own path as the second parameter:
cred-viewer = creds

This is also available as a JSON response, and can be customized to only return specific attributes – so you can even get creative for production use cases!

[cred-viewer-app]

#
# Should we enable the embedded HTML page which can render the JSON data?
#

enable-embedded-html = true

# The rules which define the credential attributes which will be
# included in the response data.  The rule is of the format:
#
# [+|-]<attribute-name>
# where:
#     +:                indicates that the attribute should be
#                       included
#     -:                indicates that the attribute should not
#                       be included
#     <attribute-name>: the name of the attribute, which can also
#                       contain pattern matching characters
#                       (i.e. * ?)
#
# This entry may be repeated multiple times, once for each rule
# which is to be defined.
#
# Each attribute in the credential will be matched against each rule
# in order until a match is found.  The corresponding prefix (+|-)
# will then be used to control whether the attribute is included
# or excluded from the response data.  If no matching rule
# is found the attribute will be included in the response data.
#
# Example:
#  attribute-rule = -AUTHENTICATION_LEVEL
#
# The rule could alternatively contain the name of a single credential
# attribute whose value is used to define the attribute rules.  In this
# scenario each individual rule in the attribute should be separated by a
# space character.  If only a single attribute-rule configuration entry is
# defined, and the entry does not start with a '+' or '-' character, it will
# be used as the name of the credential attribute which contains the
# attribute rules.
attribute-rule =

Hope this helps – as these are things I use alot!

Comments are closed.

Website Built with WordPress.com.

Up ↑