SSO current status

10/6/10 Area Director’s call

Easy as 1-2-3!Fully diagrammed login and certificate set-up process, pre-Single Sign-on

You can see from the flow chart that things could potentially be easy.

The most important thing I get from this in hindsight is that it was all exception driven.

•Flow chart, presented Jan, 2008 •Impetus for SSO improvements

9/10 services-wg call• Portal Single Sign On issue• This usually doesn't work because the user doesn't exist on the system. Other times it

is just a system issue [CRLs out of date etc]. This can happen in several scenarios. Sergiu has seen the following:

1. RP allocations: Sometimes accounts don't automatically get created on newer machines under RP allocations. I believe this is what happened in Nancy's case and in my case. Once we got added on the machines, single sign on worked fine.• Error doesn’t indicate what needs to be done

2. User already has a portal account and allocations on some machines. A new machine gets added to his/her allocation. User gets approval notice from the allocations side. There is a lag between that and the account being created on the new machine. The users maybe unaware of this and try the SSO since they already have portal access.

3. RP site has an account activation process. I did this for TACC/Ranger/Lonestar but that was sometime ago. We can confirm w/ TACC folks if the process is the same now.

4. This is similar to (2). Sometimes the portal account gets mailed out to the user but the accounts on the machine itself are not setup. I know there is a turnaround period [5 days?] for RPs to create accounts but I don't know if the portal mail out waits for this [esp. if multiple sites are involved and some sites create the accounts in time].

Activation processes can cause confusion

• Notice about activation arrives before TG packet– Users think this is their TG SSO info

• This very thing happened to a new gateway developer in the last 2 weeks

• What if there were 11 different activation sites to go to?– Thought we tried to address this when we

negotiated a single user responsibility form in 2003

So, what remains to be done?

• SSO is frequently touted as something that makes TG very easy to use

• This is often a user’s first impression of TG• Need to lessen the number of scenarios where

SSO doesn’t work or where steps cause more confusion– It really makes us look bad if this doesn’t work as

advertised

• https://www.teragrid.org/web/user-support/login_quickstart

• Works for 17 systems– Doesn’t work for 9

• https://www.teragrid.org/web/user-support/site_passwords

Paul’s 9/22 KB additions• On the KB side, I added the NICS and TACC warnings to the

following docs (using shorter IU URLs):– What's the recommended method for everyday access to the TeraGrid?

(https://kb.iu.edu/data/asvw.html) – What is a TeraGrid-wide login? (https://kb.iu.edu/data/avtc.html) – On the TeraGrid, what is Single Sign-On? (

https://kb.iu.edu/data/avup.html) – Why do I get an authentication error after installing Single Sign-on

capability on my Unix, Linux, or Mac OS X computer? (https://kb.iu.edu/data/axsn.html)

– How do I get started using the TeraGrid? (https://kb.iu.edu/data/ayrd.html)

– What methods can I use to access TeraGrid resources? (https://kb.iu.edu/data/ayry.html)