-
Notifications
You must be signed in to change notification settings - Fork 1
AuthenticationAuthorization
- Form
- Basic Authentication
- Yahoo
Anything supported by Pac4j
For its internal purposes Tangram holds a list of login providers used when checking authorizations for the use of the internal facilities and redirecting to a login when the user is not authorized.
When your application decides, that the user needs to authentice himself, you simply ask the authentication service for the login target to redirect to.
TargetDescriptor target = authenticationService.getLoginTarget(loginProviders);You will need to pass as set of login provider names to this call so that you application can decide which external services should be allowed for the user.
If this list is just the same as you use for Tangram internally, there is a short cut in the authorization service to handle this and also deal with the handling of a return url bringing the user pack to the originating page after the login.
TargetDescriptor target = authorizationService.getLoginTarget(request);If you don't like the default login page, you can easily override it with the standard Tangram view means.
If you don't like the default login page are login fragment you can easily override it with the standard Tangram view means.
Some URLs must not be considered when checking for login and redirecting to a login page in any case. These URLs are called "free URLs" and at least need to contain URLs for login handling. Be aware that also external login providers need redirecting URL internal to your application.
<util:set id="freeUrls" value-type="java.lang.String">
<value>${tangram.servlet.path}/stats</value>
<value>${tangram.servlet.path}/login</value>
<value>${tangram.servlet.path}/callback</value>
<value>${tangram.servlet.path}/login-form</value>
<value>${tangram.servlet.path}/redirect/form</value>
<value>${tangram.servlet.path}/redirect/basic</value>
<value>${tangram.servlet.path}/redirect/yahoo</value>
<value>${tangram.servlet.path}/redirect/twitter</value>
<value>${tangram.servlet.path}/redirect/google</value>
</util:set>spring free URL list example from an application.xml configuration file
# urls free to access
freeUrls=/s/stats,/s/login,/s/callback,/s/redirect/gae,/s/redirect/form,\
/s/redirect/yahoo,/s/redirect/twitter,/s/login-form)
guicy free URL list from an example application's tangram.properties file
freeUrls=java.util.Set(/s/stats,/s/login,/s/callback,/s/redirect/form,\
/s/redirect/yahoo,/s/redirect/twitter,/s/login-form)
dinistiq free URL list in an application.properties example file
The basic authentication and the form authentication need a username to password mapping in order to check if login with username and credentials was valid.
Internally this is achieved by a simple map mapping usernames to SHA256 hashes. When using the form or basic authentication this map must be present but obviously should only contain a very minimal set of logins which do not change very often (and at least one admin login).
<util:map key-type="java.lang.String" value-type="java.lang.String"
id="usernamePasswordMapping">
<entry key="user"
value="04f8996da763b7a969b1028ee3007569eaf3a635486ddab211d512c85b9df8fb" />
<entry key="admin"
value="8c6976e5b5410415bde908bd4dee15dfb167a9c873fc4bb8a81f6f2ab448a918" />
</util:map>spring username password mapping example from an application xml configuration file
log.info("configuring name password mapping")
Map<String,String> mapping = new HashMap<>()
mapping.put('admin',
'8c6976e5b5410415bde908bd4dee15dfb167a9c873fc4bb8a81f6f2ab448a918')
mapping.put('user',
'04f8996da763b7a969b1028ee3007569eaf3a635486ddab211d512c85b9df8fb')
module.bind(module.stringStringMap).
annotatedWith(Names.named("usernamePasswordMapping")).
toInstance(mapping)guicy username password mapping from an application.groovy configuration example
admin=8c6976e5b5410415bde908bd4dee15dfb167a9c873fc4bb8a81f6f2ab448a918
user=04f8996da763b7a969b1028ee3007569eaf3a635486ddab211d512c85b9df8fb
dinistiq username password mapping in a usernamePasswordMapping.properties example
Since the authorizations of a logged in user are a very application specific part, Tangram itself only deals with the needs of the content editing facility. Furthermore Tangram for this purpose only defined one role which is considered an "admin" role. Admins are allowed to use the editor and the tools from the Tangram based application.
Internally Tangram holds a list of admin users. Each user in this list is defined by the login provider to use and the username within that provider. (s.a.)
<util:set id="adminUsers" value-type="java.lang.String">
<value>form:admin</value>
</util:set>spring admin list example from an application xml configuration file
# admin users to be allowed to edit content
adminUsers=form:admin,basic:admin
guicy admin list from an example application's tangram.properties file
adminUsers=java.util.Set(form:admin,basic:admin)
dinistiq admin list in an application.properties example file
(TODO)
Since users need to be added and removed more often than you might want to deploy your application, users and admin role can be defined in the repository.
You have to create and maintain a code resource with the annotation users.properties and the mime type text/plain. Each line of this resource maps a username to a SHA256 hash value like in the dinistiq example for the static case above.
jeff=2e0b8d61fa2a6959d254b6ff5d0fb512249329097336a35568089933b49abdde
Also some of the users - be they defined within the application configuration or the repository - can be added to the list of users in the "admin" role. You simply have to add a mapping line "admins" with a comma separated list of additional admin users not presented statically in the application configuration.
jeff=2e0b8d61fa2a6959d254b6ff5d0fb512249329097336a35568089933b49abdde
admins=form:user,form:jeff