Bug 633503

Summary: Reorganise Security chapter
Product: Red Hat Enterprise MRG Reporter: Lana Brindley <lbrindle>
Component: Grid_User_GuideAssignee: David Ryan <dryan>
Status: CLOSED NOTABUG QA Contact: MRG Quality Engineering <mrgqe-bugs>
Severity: medium Docs Contact:
Priority: low    
Version: DevelopmentCC: iboverma, matt, mhideo, rlandman, rrati
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-17 02:57:22 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 652506, 733205    
Bug Blocks:    

Description Lana Brindley 2010-09-13 20:43:36 UTC 
From rrati on BZ #632238. This task held over to 1.4:

>  - Expand overview to relate "access levels" to "authorization" in overview
>  - Order subsections the same as concepts are introduced in overview, and how
> they are referenced, e.g. authentication before authorization because that is
> the order they are introduced and authorization refers to details of
> authentication

LKB
Comment 1 Lana Brindley 2010-09-13 20:50:11 UTC 
>   - How do we map the information from the table onto actual configuration? 
> Suggest changing "Access level required" to Context as that's the correct

 <thead>
	<row>
		<entry>
			Activity
		</entry>
		<entry>
			Service
		</entry>
		<entry>
			Security Context
		</entry>

	</row>

</thead>

> security jargon here, and moving the table into an appendix that is referenced
> throughout the chapter.  These security contexts can be used in the more
> restrictive security context (authentication, integrity, etc) as well as the
> Host-Based security (which is the type we ship by default).  This table is
> really meant as a reference to ease the understanding of the type of security
> context needed for a certain task.  It is important we keep the jargon the
> same, as the format we tell users to use in 3.2 is SEC_CONTEXT_FEATURE, and the
> table is providing the type of CONTEXT for given activities.  There needs to be
> better wording to clarify what the table is representing in the overall
> security configuration.
> 

I'll restructure this for 1.4. Added to BZ #633503.

LKB
Comment 2 Lana Brindley 2010-09-13 23:35:28 UTC 
>  3.2. Security negotiation
>   - Concept needs introduction in the overview
>   - "Negotiation is performed by the condor_negotiator service" - incorrect as
> negotiation happens between any client and service when a connection is made
>   - Need link between Access Levels and /CONTEXT/ or use common vernacular
> throughout.  I suggest using context.
>   - DEFAULT concept introduced but not explained.  From the condor manual "The
> DEFAULT value for <context> provides a way to set a policy for all access
> levels (READ, WRITE, etc.) that do not have a specific configuration variable
> defined"
Comment 3 Lana Brindley 2010-09-13 23:43:47 UTC 
>  3.3. Authentication
>   - Needs overview (see condor manual)
Comment 4 Lana Brindley 2010-09-13 23:48:15 UTC 
>  3.4. Authentication methods
>   - Need link between "Windows"" and NTSSAPI
>   - Generally need linkage between type here and from previous section, e.g.
> Filesystem = FS
>   SSL
>    - Needs to expand with an example (example for setting up a Certificate
> Authority for use with SSL provided in earlier BZ, but here it is again:
> http://pages.cs.wisc.edu/~zmiller/ca-howto/)
Comment 5 Alison Young 2011-02-15 02:35:11 UTC 
Pushing to 2.1 due to time and resource constraints.