[Openid-specs-fastfed] Mike's OTTO-centric comments on Dick's Fastfed agenda discussion points

[Mike Schwartz]

Below are my OTTO-centric replies to the posed questions:

> Does the group think
> [IDP published support attribute] metadata would be used in practice,
> or it is unnecessary?

I think it is necessary.

OP's already advertise this information, and federations like InCommon 
provide guidance (also with the goal of driving down the cost of 
federation). For example see: 
https://spaces.internet2.edu/display/InCFederation/Supported+Attribute+Summary

> [For SP's] is optional-vs-required
> a rich enough vocabulary to convey the needs, or is additional
> information necessary.

Probably not. See OTTO schema base vocabulary:
  
https://rawgit.com/KantaraInitiative/wg-otto/master/html/otto-vocab-1.0.html#schema

Also, note that OTTO is extensible. Within certain ecosystems, other 
metadata needs to be conveyed about schema. Of course you can make a 
static standard that is only good for a subset of consumer services, but 
why not make it extensible too?


> o    The logical portion uses a structure based off SCIM. However, the
> SCIM specification does not currently define a mechanism to describe
> which SCIM attributes can be vended/consumed, and whether they are
> required/optional. Any prior work in this area? Should this be part of
> FastFed, or should there be an independent extension to SCIM which
> FastFed leverages?

OTTO defines a boolean for required (not required = optional...)
https://rawgit.com/KantaraInitiative/wg-otto/master/html/otto-vocab-1.0.html#schema

> o    Binding the logical attributes onto the physical SAML/OIDC
> messages requires a mapping syntax. Similar to the previous question,
> should this be part of the FastFed spec or an independent extenstion
> to SCIM? Is the proposed mapping syntax sufficient?
> 

This can be handled in the schema class definition in OTTO. A subclass 
of schema, for example "SAML-attribute", can add a SAML2URI property. We 
also use the 'sameAs' property to express relationships. So "given_name" 
in OpenID COnnect could be sameas the SAML2 URI: "urn:oid:2.5.4.4"

> (2) Metadata Format and Contents
> The FastFed proposal describes two configuration files: a public
> ?Discovery? file, and a private ?Metadata? file.
> Questions for the group:
> ?         Any concerns about splitting the files?

This is really an attribute of the Entity (IDP,SP, OP, RP), which is 
protocol specific. In OTTO, we have a 'metadata' attribute which 
references a Metadata class, which provides quite a bit of flexibility 
with regard to supporting different mechanisms for conveying the 
configuration information and public keys for the entity.

> ?         Do they contain the right information? Is anything missing?
> Should anything in the private file be public?
> ?         The format is simple JSON key/values. OTTO has defined a
> richer metadata structure. Should FastFed apply a similar pattern?
> ?         Does anyone foresee future extensibility needs that cannot
> be met by the proposed format?

Yes, yes and yes.

> 
> (3) Entitlements
> Some applications offer different profiles/roles that users can
> attain. The permissions to do so are sometimes represented in extended
> attributes on the user profile, inside the Identity Provider.
> 
> Custom attributes are generally in conflict with the FastFed goals
> because they require an administrator to define/configure additional
> data. However, the need for profile management still exists. Can
> FastFed support these custom attributes without sacrificing usability?
> 
> If there is enough commonality in the representation of entitlements,
> it might be possible for FastFed to define a mechanism for Service
> Providers to declare the set of profiles/roles that can be attained.
> However, this is a slippery slope. Authorization rules become
> complicated very quickly. It is undetermined if this is possible or
> appropriate for FastFed to address.
> 

In general, I think FastFeds should avoid this. However, in OTTO by 
extending schema, and creating a 'category' for something like 
permission, role, or authorization... I think you could do it. In our 
openid connect profile, we also used the schema class to define acr and 
scope  (in addition to userclaim).


> (4) Credential Exchange
> FastFed needs to distribute credentials to the IdP and SP so they can
> communicate with each other. OAuth tokens are nice, but there is no
> existing OAuth grant type that aligns with the FastFed needs. An
> unorthodox flow is proposed. Does anyone have concerns with the flow
> and wish to suggest alternative strategies?

The question is who would manage trust between the IDP and SP? Really I 
think you have a trust question, not an OAuth question.  Can you explain 
in more detail what you see as the likely workflow for IDP's and SP's 
managing trust?

See Roland's federation spec.
   http://openid.net/specs/openid-connect-federation-1_0.html

Metadata statements, which could be used similarly to software 
statements, could perhaps fill the need you require.

> 
> (5) Certificate/Key Rotation
> The initial configuration of SSO is just the beginning. There is
> ongoing responsibility for certificate/key rotation. With the goal of
> ?simple federation?, how opinionated should FastFed be at specifying
> the rotation requirements to be FastFed compliant?  For example, is it
> practical to require that all parties support SAML certificate
> rotation without downtime?

This issue is solved by publishing your new public keys at a URI. The 
question becomes "how can I trust the fact that there are new keys?" 
That's where a federation can help, by publishing signing keys for 
entities, which can be used to verify that the new key is valid. Again, 
this is a trust issue, not really a technology issue.

> 
> (6) User Provisioning/Deprovisioning
> May apps require user provisioning. With the goal of ?simple
> federation?, FastFed needs a way for service provider to express their
> desired provisioning mode so that FastFed Compliant providers can make
> it ?just work?. There should be a small number of easily understood
> modes. What are they? Two candidates are ?None? and ?JIT?. Perhaps
> also ?Preprovisioned?.  Are those sufficient?
> 
> Deprovisioning is more complicated. Feedback from a large enterprise
> player is that SCIM?s boolean ?active? flag is insufficient to
> represent their user modes and deprovisioning requirements. They
> implement custom deprovisioning logic for each application. Let?s
> review this feedback and consider whether FastFed can meet the
> deprovisioning requirements.

We could make a SCIM vocabulary for OTTO that meets these requirements. 
There are other complex details about SCIM that you are leaving out. For 
example, there may be  a relationship between SCIM and UMA. SCIM is a 
very powerful API--you can add a user or change a password. Hack SCIM 
and you pwned the whole system. SCIM leaves security out of scope--this 
won't be workable for real world implementations. So requiring a client 
to obtain an authorized UMA RPT, or some other OAuth token, may be 
required to make it workable. Expressing the relationship between the 
security service, and the SCIM service is going to be tricky if 
everything is hard wired like you are currently proposing.

> 
> (7) Endpoints on the public internet
> The flows described in this document require that an SP be able to
> communicate programmatically with the IdP. For example, to load the
> FastFed Metadata configuration, refresh OAuth tokens, and rotate keys.
> Many existing installations of SAML IdPs exist in private networks
> with firewall restrictions. They may not be able to call (or be
> called) via endpoints on the public Internet. This has not mattered in
> the past because SAML relied on the user_agent as a data carrier.
> 
> Question for the group ? Is this a serious roadblock that needs to be
> considered? If so, it may be necessary to define a FastFed flow that
> performs the registration handshake through the user_agent via HTTP
> POSTS, and negates the need for public endpoints. This profile may
> only support a limited subset of FastFed functionality.
> 

> (9) Threat Model Review
> As the specification gets closer to finalization, a threat model will
> be performed. Let?s review the results with a critical eye.

(1) You can't trust SSL. For high value transactions, additional trust 
mechanisms like OIDC federation, or SAML signed federation metadata 
aggregates should be used.

I also would think that FastFeds shares the same attack surface area as 
authentication via dynamic client registration. If you could somehow 
trick the user to obtain a valid token, but send it to the wrong 
place...