SSO/Service Provider Fields
From Authentication Tools for Joomla! (JAuthTools)
(New page: This page documents provider state, origin, published and trusted fields. = Provider Published Field = Only published providers are active for authentication. Unpublished providers will n...)
Newer edit →
Revision as of 02:08, 4 December 2008
This page documents provider state, origin, published and trusted fields.
Contents |
Provider Published Field
Only published providers are active for authentication. Unpublished providers will not be accepted for login regardless of their state.
Provider Trusted Field
This field controls the creation of user accounts on the local site. If a service provider is not trusted then if a remote user attempts to sign on, then their username locally has the service providers abbreviation field suffixed onto it. If a remote service provider is marked as trusted then users who log in locally from that service will be created without the abbreviation or if a local user exists this user will be used to log in with. If users have been created independently or are tied back to an alternative user source (e.g. LDAP) then this could be desirable.
In future designs a 'proxy' option is envisaged where 'trusted' service providers users could be proxied with permission from the service provider. This system is still under design.
Provider Origin Field
The origin field denotes where the service provider entry originated from. At the present moment it has two values: local (1) and remote (2). A provider created locally is different to a provider created remotely as this may impact on partial reciprocity plugins. Local providers are those that the administrator of the local site created themselves where as a remote provider (or client, the distinction is blurred) is created when the remote system requests authorisation.
Provider State Field
A service provider can be on one of many different status levels signifying the relationship between your local site and the remote site.
State 0: Unknown/Unregistered
When a service provider is first created it is assigned this status level. From here a service provider client can request authorisation from the remote service.
State 1: Requesting Authorisation
In this stage the client has transitioned from being in an unknown status to requesting authorisation from the remote service provider to authenticate users from it.
State 2: Authorisation Pending
When a remote service provider client requests authorisation, the service provider may also wish to set up a reciprocal arrangement and may initialise a new service provider entry with this value and the service provider may wish to grant the request to enable remote logins locally (state 4) or enable local logins to be transferred remotely (state 5) or to allow both local and remote logins (state 3). If reciprocity is not available (e.g. the client is not a client/server system) then this will be created as well, however the system can only provide the ability to transfer local logins to the remote site (state 5).
State 3: Allow all logins
In this state if a remote client wishes to identify a local user to log them into the remote site or if a remote user wishes to log into the local site both of these options will be available.
State 4: Enable remote logins locally
This option only allows the remote user to log into the local system but not allow the remote system to authenticate local users (requests will be provided with incorrect token errors). This means that local accounts cannot be authorised to leave to alternate sites however remote users can be logged in locally.
State 5: Enable local logins to be transferred
This state permits users who are logged in locally to log into remote sites but doesn't permit users of remote sites to log in locally. This could potentially be desirable for situations where a central well protected parent site is the point of login for multiple child sites. Logins from the child sites should not be permitted or transferred to the parent however the inverse is possible.
