RE: [security-services] DAON Slide Thoughts

[Hal Lockhart <hal.lockhart@oracle.com>]

Oops, sorry. RFC4949 – replacement for RFC 2828.

 

Check out definitions for credential and token.

 

It does not define CSP, but a lot of the definitions for CSP include those two words.

 

Nice to see the FICAM terminology in black and white. Unfortunately I see problems with all three definitions and I don’t understand most of the boxes in the diagrams. Is there a long version of that web page?

 

Now how about some alignment with NTSC? ;)

 

Hal

 

 

From: Anil John - M1EI [mailto:anil.john@gsa.gov]
Sent: Monday, February 03, 2014 3:51 PM
To: Hal Lockhart
Cc: La Joie, Chad; OASIS SSTC (security-services@lists.oasis-open.org)
Subject: Re: [security-services] DAON Slide Thoughts

 

Hal,

 

>Be careful of the many meanings of "credentials" and "token". 

>RFC 4646 even goes to the trouble to diss the definitions provided by NIST and OMB.

 

Trying to find the afore mentioned diss to understand their definitions :-)  Is that the right RFC# ?

 

BTW, within the context of FICAM (which has a line back to OMB and NIST definitions), a Credential Service Provider (CSP) fulfills both the "Authentication Authority" and "Attribute Authority" Functions.

 

http://info.idmanagement.gov/2013/12/ficam-tfs-component-identity-services.html

 

Regards,

 

- Anil

:- 
:- Anil John [GSA]

:- http://info.idmanagement.gov/
:- 202.810.5091
:- 
:- Response Time - 24 Hours

 

On Mon, Feb 3, 2014 at 2:57 PM, Hal Lockhart <hal.lockhart@oracle.com> wrote:

> So, on the last call I noted that it was unclear to me what they
> thought the difference between a "Credentialing Service Provider" and
> an IdP was.  After another review I'm still confused but, I think their
> CSP may just be the authentication authority role in SAML.  I think the
> distinction they're trying to make is that many IdPs today implement
> both the authentication and attribute authority roles but most SPs this
> group encountered only cared about the former.
>

I went thru a similar exercise recently I concluded that most people using the term CSP mean Authentication Authority. I think a key point is that typically the SP has some attributes that they REALLY care about which they collect from the user or obtain from some authoritative source, out of band. This data is key to their value add, so they want to maintain total control of it, while they are glad (or at least willing) to farm out the Authentication task.

(Be careful of the many meanings of "credentials" and "token". RFC 4646 even goes to the trouble to diss the definitions provided by NIST and OMB.)

In SAML terms the difference is not really that great. If the Authentication request comes back with an AuthN Statement and an Attribute Statement and you are not interested in any of the attributes, nothing compels you to even look at them. As I recall, SAML 1.0 did not even include attributes for SSO. Another case of back to the future.

> On slide 10, second bullet, they note that a lack of authentication
> authority only conformance.  This is probably something to consider as
> we move to our thematic documents and perhaps helps inform the question
> of whether conformance should really be a separate document or simple
> part of each profile document.

I don't really understand what that means. Does it mean they think that the SSO Profiles require the IDP to deliver every known attribute on the planet about that Subject in an Attribute Statement? Do they think the SP is required to use or even look at the attributes provided by the IDP? Do they think that the SP is prohibited from maintaining and using its own attributes for its users or for fetching attributes from other sources? I see that the FICAM folks have defined two SAML profiles for exactly this case. They call them "Backend Attribute Exchange" or BAE for short. (confusingly the name of a major government contractor)

<rant
"I don't understand why people insist on calling things an 'exchange' when all the data flows in one direction!"
</rant>

>
> Slide 12, bullet #4 brings up geolocation within an authn request.
> This is something we recently started needing here at Covisint as well.
> Might be worth discussing on a call.

At least it is worth getting a clear statement of the usecase. Does this imply we have to treat a smart phone as a trusted device? If not, who is the Authority for this data? How much assurance is required? How fresh does it have to be?

>
> Slide 12, bullet #7 is also something I've seen come up here and at
> other places.  It's basically the question of "is there any way, as an
> IdP, I can 'ping' my SPs periodically just to make sure they're still
> alive".

Well IP and SMTP have trouble figuring this out, but if you have a way to do it, knock yourself out. Clearly it is a prerequisite to an airtight single logoff, which some folks seem to want. In my experience you can tell if somebody is surely up or if you haven't heard from them for a while. Anything else is pretty tough unless you are using something like SS7. (For example, most days Yahoo Groups doesn't seem to be able to tell if Yahoo Mail is up. ;)

>
> Slide 16 brings up a point that I ran face-first into here.  IdP
> proxies/brokers are in the SAML spec if you really read it but not in
> big bold font like other usages of the spec.  Might be worth putting in
> some verbiage somewhere to raise the visibility a bit and make sure
> people do "the right thing".

Here again it would be good to have a clear statement of the things that make this case different from regular SSO. I wonder if the parties can be described by some combination of the actors defined in SAML core: Requester, Presenter, Requested Subject, Attesting Entity, Relying Party and Identity Provider.

If so we could simply say A acts as an X and B acts as a Y and Z and the existing descriptions could stand. If we need to refactor the actors or define totally new ones, that is another matter.

Hal

> Chad La Joie
> Development Manager, Identity Services
> covisint | Connect. Engage. Collaborate.
> c 734.531.9087
> chad.lajoie@covisint.com| covisint.com

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php