USE CASE for MailMan Authentication with Single Sign On

For the Existing Users and New Users Coming to Systers.org for Subscription, each Section provides Scenario with Use Case.

• A user who comes to join the Mailing List of Systers and submits her Credentials with the Email Address she chooses, the Name and the Password.
• There could be many number of list that happens to be on the Systers.org server and if she joins more than the one list , then it might be possible with the different passwords
• Now here the preference would be to store the password in the common database , apart from the dlist database and also to use the email id as the primary key to match the corresponding id to be used in the relational database .

• The question arises which password to be used as the primary one for the OpenID.
• After Providing the OpenID identifier the user can be redirected towards the OpenID Provider and after confirming her identifier by supplying the password will be redirected to the listpage of all the Mailing Lists for which the user is subscribed.

In the UI for single sign on, we can have an option where the user specifies the list whose password (s)he wishes to use as her single sign on password.

• Let us suppose that a new/existing user comes to the Systers.org , she subscribes to a Mailing List ‘A’ and also subscribes to mailing List ‘B’ , now what we can have is to either use the Mailing List ‘A’ Password to be used as primary and use ther password for the OpenID Authentication.

• There will be an identifier which will be primarily using Email as the user identifier created as the user supplies her email id while subscribing and it will be notified to the user about her OpenID identifier .

• Now as she comes to the CGI which will be using the Open ID Relying party which will be verifying with the Provider by redirecting and authorizing him to the login.

User chooses to enable single sign on for her already existing systers account. She specifies list A to be the list whose password is to be used as the single sign on password.

Enable single sign on for existing account using an already existing list.

The User who has an account for systers first register herself for the OpenID identifier(email-address) which will be used to provide her the identifier which will be used for the further logins and gives the option to select which list password does she wants to use for the OpenID. If she chooses List 'A' then she needs to give the password for list 'A' that she had choosen while subscribing. Once she is logged in she can edit the profile to change the list from 'A' to 'B' with the password of 'B' to be used.

User changes the list which is to be used for enabling single sign on

Change the list.

The same as mentioned on the Use case 1

Assuming systers provides multiple accounts to its users. Now if a new kind of account is offered - how will the single sign on service respond. Note this use case can be broken down into when the user adds an account to the set of accounts that have single sign on enabled and when she deletes an account for which she had single sign on enabled

Change the set of user accounts bundled together for single sign on

User changes password. (How is the change propogated in the database??)

1.) When the user comes to the ‘Listinfo’ page and chooses to use her openid , she is redirected to the providers page from where she is verified and returned back to her own lists page. Now there is a query in the Membership table about selecting the address ,password and list which will be used for the selection and verifying the authentication for the user.

2.) When she is redirected back to own her listpage , the option could be to use the diffrent password , a seprate table which will store the listname and password with the reference to the username (i.e.the email address) ,the query will be selected to update the listname and choose password from the membership table to get it updated into the refernce table.

User disables single sign on for her account.

If the user disables her account then it could be done with her Options page that will allow her to use it further with the normal signing as usual before.