Authentication in OA4MP may be accomplished in several ways. This configuration element will tell the system which method you are using. It also is used in constructing the well-known endpoint's information. Note that the OAuth specification places authentication at the /authorize endpoint, which does not help clarity. For purposes of this blurb, these should be considered synonyms, but OA4MP itself has stark differences between them. Authentication identifies you to the system (typically via a login) while authorization is what you can access, typically set through policies per client.
The configuration has the elements for all cases.
| Attribute | Required? | Default | Description |
| authorizationURI | N | -- | This is the address of whatever application does the authentication. It may be specified in all cases. In various default cases (such as OA4MP extended) it is optional, since the system will assum that the specification default is in use. Otherwise, this must be specified so that it can be put into the well-known endpoint for discovery by other services. It is required in replacement cases. |
| use | N | default | Which paradigm of authentication you are using. Options are
|
| useProxy | N | false | (Deprecated) If "true" this is the same as setting the use attrbute to "proxy". See also cfgFile and cfgName |
| cfgFile | N | (Proxy case) This is required if useProxy is true and ignored otherwise. This is the path to the client configuration file. | |
| cfgName | N | (Proxy case) This is required if useProxy is true and ignored otherwise. The name of the configuration within the cfgFile to use. | |
| localDFConsent | N | false | (Proxy case) As per the OIDC specification, showing a consent screen is optional. When proxying, this will request that the proxy redirect the user back to the local service to use the consent screen there. Otherwise, the assumption is that the consent the user gave on the proxy is sufficient. Also, note that the request parameters used are OA4MP only, so if you are using another system for proxying, the request will be ignored by that proxy. |
| useHeader | N | false | (Deprecated) Use an HTTP header. Same as setting the use attribute to "header". |
| requireHeader | N | false | (Header case) Valid values are "true" or "false". This flag forces the server to use the specified header. Note especially that if this is true and no such header is received then an exception is raised. |
| headerFieldName | N | REMOTE_USER | (Header case) The name of the header field to use. Generally this is REMOTE_USER. Other fields are permissible. |
| returnDNAsUsername | N | N/A | (Deprecated) Valid values are "true" or "false". This flag forces the server to return the DN (distinguished name) on the certificate as the username, as opposed to the usual name of the user. This has nothing to do with enabling the use of the header field. |
| convertDNToGlobusID | N | N/A | (Deprecated) Standard DN's (Distinguished names) are comma separated. Some versions of Globus, however, require that these be slash delimited. Enabling this option will convert commas to slashes using Globus's own utility for doing this. This means that you must follow the installation instruction for JGlobus to your Tomcat. Generally this option should rarely, if ever, be needed, so don't just enable it unless you are sure you know what it does and need it. |
<config>
<server name="my-config">
<authorizationServlet use="proxy"
cfgFile="/opt/oa4mp/etc/clients.xml">
cfgName="cilogon-proxy">
<!-- rest of config -->
</server>
</config>
In this case, there is a service configured (you have registered a client with it) and you need to have calls for authentication forwarded to it. All you need to do is ensure the configuration in the file is correct and that your Tomcat web.xml file is set right and you are good to go. See more at using proxies for authentication
<config>
<server name="my-config">
<authorizationServlet use="header"
headerFieldName="REMOTE_USER"/>
<!-- rest of config -->
<\server>
<\config>
In this case, use of authentication headers is enabled and a header named REMOTE_USER will be used. If it is missing though, no exception will be raised. By default, the header field will be shown to the user along with client information and the user will be prompted if s/he wishes to continue. Be sure to enable the correct machinery in the web.xml file. The one supplied with the standard distribution is annotated. See more at using headers for authentication.
Options that may be configured here to
Specifying that the header should be used implies that the header may be present. Since the username may be created also via an extension to the system (see below for details) the lack oof a header field is not an error. However, requiring the header will cause an exception if the header is not found. The default is to assume that the header is the REMOTE_HEADER field, though any field name may be specified.
<config>
<server name="my-config">
<authorizationServlet use="default"/>
<!-- rest of config -->
</server>
</config>
This tells the system that the entire authentication is handled at the endpoint in the OAuth specification and the well-known file generated by OA4MP will point to that. See extending OA4MP.
In this case, you have an external AS which handles all authentication and you need to simply notify OA4MP of its state. Thius implies you have deployed the DI service as well.
<config>
<server name="my-config">
<authorizationServlet use="external"
authorizationURI="https://your/AS/address"/>
<!-- rest of config -->
</server>
</config>
In this case, the well-known file points to the authorizationURI value and all clients will therefore make requests to that. Your AS should be able to do all the authentication needed. OA4MP must be configured to run its DIService so your system can send it notifications.
Additionally, make sure that if you set the device endpoiont for the device flow (so user's are directed to your AS to authenticate for the device flow) by configuring the verficationURI in the deviceFlowServlet configuration. The device_authorization endpoint (where user's start the device flow) must be managed by OA4MP, since that sets up all the state needed for the flow, although you can hide it and simply call it on behalf of users.
In this case, you have a DTI (Dedicated Token Issuer) service that generates token requests which OA4MP will service, but there is need for the DIService. All that is needed is the endpoint for your service to be specified in the configuration so it will be correctly set in the well-known page:
<config>
<server name="my-config">
<authorizationServlet use="dedicated"
authorizationURI="https://your/DTI/address"/>
<!-- rest of config -->
</server>
</config>