[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Colin's Action: RE: [trust-el] Notes for January 8th call
|
Colin Will take this on the TC call tomorrow regards
From: trust-el@lists.oasis-open.org [mailto:trust-el@lists.oasis-open.org]
On Behalf Of Colin Wallis Folks A quick update on this. Following on from Mike Schwartz’s presentation, I made the comment that I was little concerned that his application’s particular approach to Trust Elevation might not be captured
in our Deliverable 2: Analysis of Methods. Of course, far too much time has passed for me to absorb all the finer details of Mike’s preso, and I am less sure than I was then, that there is a gap in D2. But if you apply the 4 categories of D2:
·
What you are
·
What you know
·
What you have
·
What you do ..you can kind of understand why I asked the question.. It seems to be kind of in the ‘what you have’ category, possibly as an alternative approach to ‘out of band’ Or it is in the ‘all others’ bucket of ‘Context’...”additional attributes relevant to the user or situation’
In Mike’s thing you have protected URI as an end point identity... Hmm ... I’m not sure that’s what was envisaged when we made up the list ..browser, OS, cookie, tokens and certs etc. But I guess if it goes anywhere, it might go there.. The alternative, and the most likely outcome of this cerebral internalizing, is that I’ve missed something blindingly obvious and I am barking mad! Anyway.. FWIW.. Cheers Colin
PS: It’s a Bank Holiday here tomorrow so won’t be at work to access gov email, so I’ve added my personal addy if you’d be so kind as to Reply All..
From: trust-el@lists.oasis-open.org [mailto:trust-el@lists.oasis-open.org]
On Behalf Of Mary Ruddy Minutes for the meeting of the Electronic Identity Credential Trust Elevation Methods (Trust Elevation) Technical Committee January 8, 2014. 1. Call to Order and Welcome. 2. Roll Call Attending (please notify me if you attended the meeting but are not on the list below)
100 percent of the voting members were present at the meeting. We did have quorum. 2. Agenda review and approval We used the following chat room for the call: http://webconf.soaphub.org/conf/room/trust-el chat room text is included at the end of the minutes.
The agenda was approved. 3. Approval of the Minutes Abbie asked for a motion to approve the minutes from the last meeting on December 12. Peter made a motion to approve these minutes. Don seconded the motion. There were no objections. The minutes were approved.
4. Editors Update on 3rd deliverable.
Abbie said the third deliverable is ready to go into the approval pipe.
Steve will open tickets to have it moved into the public review with the TC membership list.
Abbie asked so we are ready for public review? We have an ITU-T meeting shortly. Can we ask to send it to them?
Abbie made a motion to send the third deliverable to ITU-T 10 for their next meeting.
Peter seconded the motion.
Steve added that depending on comments, we may need to go for another round of review.
Abbie asked if there were any objections.
None were heard.
The motion passed.
Shaheen asked who is the liaison to ITU-T?
Abbie replied he is.
5. Presentation for 4th deliverable
"A Design for Trust Elevation Using the UMA and OpenID Connect profiles of OAuth2" by Michael Schwartz; Gluu Founder / CEO; Instead of slides, Mike posted his thoughts on this blog: http://www.gluu.co/trust_elevation
Abbie thanked Mike on behalf of himself and whole TC for speaking. He explained that we are in the process of investigating to see what we can use toward deliverable 4 requirements.
Mike began (see above link), it uses OAuth 2.0 for something SiteMinder has been doing for 10 years. SAML has an ACR parameter that can communicate more info about the authentication. You can use that parameter that would be provided by the authentication domain and would be provided in OIDC in the ID token. There is only one end point API in OIDC that is protected. It can be used by auth server or policy server. They followed SiteMinder’s lead in this. The ACR is really just a URI. Can use URL to indicate context for the authentication. It is very flexible. It is not rocket science. The IDP provides details and the PDP can use this information to evaluate policy.
Abbie asked what happens if the auth is not good enough?
Mike replied if the RPT is not authorized, the response doesn’t provide useful info to the client. It would be better if the auth server could return a hint. For example, yes this is a 403, but this level is required. So it returns an extra JSON object. The client may not care, or may send the person for extra authentication.
Mike said Eve may have added this to the protocol. This is an optional response for the UMA server. So we give a suggested structure for the JSON structure such as need LOA-2, etc. so RP can decide to send for some other auth.
Abbie said this is static. Does it support on line banking? Say LOA-2 for account balance, need higher for transfer. Can it handle this?
Mike replied you would need a smart client that could handle the UMA protocol. So yes, but the client would need to be pretty smart. Sounds possible.
Shaheen asked do you know of a client like that that could support it?
Mike replied the first production use is a legacy data access company that does long term storage for hospitals. Don’t see any reason why it would not work. It was designed for API access management.
Mike will look for the Webex.
Abbie asked what is the issue now?
Mike responded, the question is could you handle taking a wire transfer and needing a higher level of access. The answer is if the client was ensuring that the RP token was authorized and if the token could respond back with this is the reason, the client could then initiate an appropriate action,
Peter said Shibboleth has been doing it in SAML for years.
Mike said this is a little different. Shibboleth doesn’t do folder level access.
Peter agreed. The point is that Shibboleth has a transaction protocol that allows communication back and forth on needed elements.
Abbie said we don’t want to dig into details of how it is consumed at end points. Correct me, but we need to define how we exchange the needs for client to RP or RP to client. The RP can say if you are connecting to this service, this is the protocol to exchange information. So can stop, or move up or down. Are we going to cover both ways? The RP can assume how intelligent the client is or device. So we have some variables to take into account. So I want to know what are the core capabilities we need to support?
Peter said it sounds like we are on the right track. It is really the RP that has the baton. We are trying to develop a protocol so the RP can communicate in a standard fashion
Shaheen agreed. That is why he thought Gluu is doing that sort of thing.
Peter continued it seems like UMA work is key to this.
Mike said he joined the Webex, so he could do a quick demo.
Abbie said we need to know how to specify extensions. Another option is to create requirements and ask UMA to deliver. We could publish our own profile too, but we don’t want to confuse people. Ultimately if we go this route, we want some of our stuff to be published by UMA.
Mike responded we would need to specify how to use URI’s. The URI gives you lots of ways to centralize authorization. I don’t know if Eve is going to put this in. Let me show you how to specify the scopes in the Apache plugin. This could be front ending your APIs. For a certain resource, this is two factor with a level greater than 1. Can also have multiple auth servers with different policies.
Mike asked if we have seen Duo? The InCommon list has interesting questions.
Abbie says what you are showing me is not true MFA.
Mike replied I will show in the interface. In the ACR: domain.com in OX can define multiple of these auth mechanisms. We have been open sourcing these as we write them. Duo has a Python API. The Duo code is simple. The scripts are in Jython. In step one are doing local auth and in step two we just call the Duo API, then we verify… We have a bunch of auth scripts. In Shibbolith if introduce a new login handle, it needs to be compiled and deployed, if you have a cluster it is hard to deploy quickly, so we decided it is best to use an interpreted way. Also systems admins are uncomfortable changing the scripts. We support both interactive and … They are Shibboleth users themselves. They have a login handle that sends the xxx to ox so only have to write the two-factor in one place.
Shaheen asked Mike to show the architecture diagram.
Abbie said one option is looking at open source implementations of what we do.
Mike said we just showed you the administration for the two factor. I think the client tells you what the best method is. There is no way to pick one workflow. As Scott David says there are tools and rules and there is a point where the Trust Framework defines things in the ecosystem of SP and IDP. If you have more than one IDP, can define industry specific methods or standards… They have a SAML proxy in the stack. He showed us the policy side. In OAuth 2.0, can define scopes, ideally URIs. This is sort of manual. If use Apache, the resource gets … similar to SiteMinder… If you manually added a resource, a folder (SiteMinder is rules, ) with UMA can associate a scope with this. For example, let’s add a policy of my token. There may be one or more policies associated with my token. In UMA it is better to write polices. You need to implement a UI and associate a scope. The one method you need to use is authorize. Can have multiple scopes referencing a policy. UMA doesn’t say how you express the policy. He is neutral on XACML. Centralization is a big value prop by itself. Can also use Java or Python. UMA is neutral on how to express policy and who makes policy. (In Uma RP AND RS are combined.) An apache filter approach is very scalable. If have a fancy client like Yahoo, or a bank, they can create a smarter client with more control. There are a lot of clients out there so there is a lot of meta client registration.
Mike said in Ireland every campus has a federation and they have a national federation. And they don’t want to join Edugate as it costs money. He suggests emulating the higher ed industry. What does the RP agree to when they are using the data and aligning the schema? OIDC added scope jargon. There is more to be defined than in SAML.
Abbie a lot of our compliance issues come into the issue do to the dynamicness. And SAML is only a tiny tool for third-party federation.
Mike said it is harder to write legal agreements than technical stuff. So maybe just launch the process. Recently added a tool called Jaeger (sp?) It is an open source tool for federation management used by Ireland. It provides a workflow for adding a participant and submitting their meta data.
Abbie commented that rules are out of scope for our TC. We are the plumbing. Am I right?
Don replied we be plumbers.
Abbie said we are plumbers and want to unify the language.
Colin said he is looking at deliverable 2. It feels like we didn’t cover this scenario in our analysis. in d2. It is a small point.
Abbie replied can you elaborate on that scenario?
Colin said the second deliverable has different categories. He is trying to categorize what Mike said.
Abbie said that is good to know. We can revisit it. Can you create an action to bring this forward for your next meeting?
*** Action item for Colin to follow-up on the potentially missing category in the second deliverable.
Abbie asked Mike how can you work with us to move forward. This fits very well with what we are doing. We want to build on what you have done.
Mike replied that he is not a member of OASIS or OIDF anymore. Anyone can go to support.glue.org for support or if they need an IDP, they can create one. InCommon’s Steve Carmody and Keith H. are interested in doing an UMA POC.
Abbie suggested they continue the discussion off line.
Mike said we could suggest this as a use case for the proposed interop.
Abbie thanked Mike.
6. Adjourn
Shaheen made a motion to adjourn
Peter seconded it.
The meeting was adjourned.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
abbie barbir (BofA): CHAT ROOM
http://webconf.soaphub.org/conf/room/trust-el
Passcode: 637 218 8139
US toll free 1-866-222-6652
Int'l Toll: 1-980-939-6928
- Australia, Sydney: +61 (0) 2 8064 4811
Webex: Meeting scheduled: Trust Elevation TC Bi-weekly
-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to
https://attend.webex.com/attend/j.php?ED=179798197&UID=1382908852&RT=MiMxMQ%3D%3D
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: (This meeting does not require a password.)
4. Click "Join".
abbie barbir (BofA): 1. roll call/ agenda bashing
2. approve minutes
3. editor update on 3rd deliverable
4. presentation on 4th deliverable
"A Design for Trust Elevation Using the UMA and OpenID Connect profiles of OAuth2" by Michael Schwartz; Gluu Founder / CEO; Instead of slides, Mike posted his thoughts on this blog:
http://www.gluu.co/trust_elevation
5. roll call
6. adjourn
anonymous morphed into don thibeau
don thibeau: Happy New Year All
abbie barbir (BofA): don please dial to webex
abbie barbir (BofA): same to u
anonymous morphed into Mike Schwartz
anonymous morphed into Shahrokh This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]