Participants: 80
Sara Bertocco is making the introductory presentation:
Current specification is based on existing standards:
More than one method available
Discussion in Groningen
Some example of SSO has been discussed (CADC, LSST etc.): they are using tokens. The problem for apps is how to get the token. Markus proses the tokenGetter attribute.
Good but it remains some open questions:
1) how to retunr the token?
2) how many token Getter may I have?
3) federated auth? JSON token signed.
Credential Delegation: different apps should be able to work togeter. Now X509, what happens with tokens?
Credential Delegation necessary also for authz: Group Managment.
Pat Dowler (and Brian M and Mark T) presentation on CADC proposal:
Services describe the auth method (securitymethod) they support (including anonymous). Client can use anyone of them.
In SSO v2 the x509 cert is for a global sso.
The problem is how and where to login.
1) url for endpoint
2) APIs
3) credential endpoint
Proposed solutions:
a) to use VOSI cabability: client reads the VOSI cap to undestand how to auth, not so easy
b) HTTP header. WWW-Authenticate to extend with the SSO securityMethod and accessURL
What happens if a server use Auth and Anon access?
Christine B.: On Rubin observatory they have a proxy that rederect users when you not have a valid token. Negotiation is tricky, and also for clients, if you have multiple credential the problem could be how to decide what to use.
Pat: CADC has a similar proxy to riderect, but when a cli calls it, it is a problem, browsers are more easy to work with proxies.
Christine B.: proxy (MISSING...)
Jesus: In case of, e.g. basic authentication, is there a standard way to say to the client the parameters
names for "username" and "password"? (or, are the name standardized?)
1) if you have a mix endpoint you can use a dummy authentication
2) standardize Useranme and passwd but maybe uname and pass is not
We can have in the Registry the description of the secutiry Method. User the registry to find the scope of the credentials, so that the client do not send tokens when not necessary. Prefer to use WWW-Auth.
Russ A: what is the goal of this approach?
Pat: some of the SSO methods are reccomendations to use on services.
there are a lot of usecases where you are not using a browser, but there are command line clients in particular on computing.
Russ: what happens on bach jobs when it is not a user to manage them?
Mark T.: Support the WWW-Auth... because putting the securitMethod is more complex for Apps.
Christine B.: Auth and Datalink can be tricky.
Stanislaw P: rise a security problem on the way we can use token....
Sonia: he is talking about CSRF (Cross Site Request Forgery) (thanks)
Sonia: Why not just use BasicAuth instead of programmatically perform a POST on a form?
Christine B.: what about federated auth?
Rass A.: CSRF implication is that you should have different end-point for non-interactibe and browser.
Greg Sleap: would like to implement data link, TAP is anonymous but datalink must be authenticated, we use edugain orcid, so federated. Local account is only for users that do not have fed accounts.
ACTION: prototy WWW-Auth.... on client servers prototype. OAuth is a good starting point.
Pat and Brian from CADC
Mark Taylor
Sara Bertocco
Dave Morris - happy to contribute with server side prototypes
Sonia Zorba : At INAF-IA2 we are using OAuth2 too, we can contribute with the prototyping

Paul Harrison

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r2 - 2020-05-08 - PaulHarrison
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback